[GH-ISSUE #12479] issue: openapi tool payload conversion only uses summary not description #16617

New Issue

GiteaMirror · 2026-04-19T22:30:45-05:00

GiteaMirror commented

2026-04-19 22:30:45 -05:00

Originally created by @dan-sullivan on GitHub (Apr 5, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12479

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

v0.6.0

Ollama Version (if applicable)

No response

Operating System

Debian Bookworm

Browser (if applicable)

No response

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have listed steps to reproduce the bug in detail.

Expected Behavior

OpenAPI tools often have both a summary and description field - this is also true of MCP servers proxied via mcpo. It seems that description often has more details for how the model should use the tool. I would think using at least the description is more valuable than the summary or a combination of both would make the tools more accessible to the models.

Actual Behavior

We can see in https://github.com/open-webui/open-webui/blob/main/src/lib/utils/index.ts#L1131 only the summary is used.
So when, for instance, we use the reference openapi filesystem server we have in openapi.json:

    "/write_file": {
      "post": {
        "summary": "Write to a file",
        "description": "Write content to a file, overwriting if it exists.",
        "operationId": "write_file_write_file_post",

But only "Write to a file" makes it way to the tools:

{
    "type": "function",
    "name": "write_file_write_file_post",
    "description": "Write to a file",
    "parameters": {
        "type": "object",
        "properties": {
            "path": {
                "type": "string",
                "description": "Path to write to. Existing file will be overwritten."
            },
            "content": {
                "type": "string",
                "description": "UTF-8 encoded text content to write."
            }
        },
        "required": [
            "path",
            "content"
        ]
    }
}

Steps to Reproduce

Add an openapi tool server.
View the openapi.json of the server
Note the description field of one of the functions
Inspect the request in brower tools the functions as passed to the /chat/completions endpoint

Logs & Screenshots

See above

Additional Information

This is especially a problem for tools that have more complex descriptions such as sequential-thinking which only has a description of "sequentialThinking" rather than the full instructions for the model.

I dont know if it would be more sensible to switch to use the description or to add both in a structured way incase some tools use only summary and some use only description. e.g.

Summary: {summary}\nDescription: {description}

Or fallback from description, to summary, to a placeholder.

Originally created by @dan-sullivan on GitHub (Apr 5, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/12479 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.6.0 ### Ollama Version (if applicable) _No response_ ### Operating System Debian Bookworm ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have listed steps to reproduce the bug in detail. ### Expected Behavior OpenAPI tools often have both a summary and description field - this is also true of MCP servers proxied via mcpo. It seems that description often has more details for how the model should use the tool. I would think using at least the description is more valuable than the summary or a combination of both would make the tools more accessible to the models. ### Actual Behavior We can see in https://github.com/open-webui/open-webui/blob/main/src/lib/utils/index.ts#L1131 only the summary is used. So when, for instance, we use the reference openapi filesystem server we have in openapi.json: ``` "/write_file": { "post": { "summary": "Write to a file", "description": "Write content to a file, overwriting if it exists.", "operationId": "write_file_write_file_post", ``` But only "Write to a file" makes it way to the tools: ``` { "type": "function", "name": "write_file_write_file_post", "description": "Write to a file", "parameters": { "type": "object", "properties": { "path": { "type": "string", "description": "Path to write to. Existing file will be overwritten." }, "content": { "type": "string", "description": "UTF-8 encoded text content to write." } }, "required": [ "path", "content" ] } } ``` ### Steps to Reproduce 1. Add an openapi tool server. 2. View the openapi.json of the server 3. Note the description field of one of the functions 4. Inspect the request in brower tools the functions as passed to the /chat/completions endpoint ### Logs & Screenshots See above ### Additional Information This is especially a problem for tools that have more complex descriptions such as [sequential-thinking](https://github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking) which only has a description of "sequentialThinking" rather than the full instructions for the model. I dont know if it would be more sensible to switch to use the description or to add both in a structured way incase some tools use only summary and some use only description. e.g. `Summary: {summary}\nDescription: {description}` Or fallback from description, to summary, to a placeholder.

GiteaMirror added the bug label 2026-04-19 22:30:45 -05:00

GiteaMirror closed this issue

2026-04-19 22:30:46 -05:00

GiteaMirror commented

2026-04-19 22:30:47 -05:00

@dan-sullivan commented on GitHub (Apr 5, 2025):

Current you can see the tool isnt picked up:

Whereas with the following small change it is:

description: operation.description || operation.summary || 'No description available.',

@dan-sullivan commented on GitHub (Apr 5, 2025): Current you can see the tool isnt picked up: <img width="740" alt="Image" src="https://github.com/user-attachments/assets/d0574d2b-f1fc-44c4-a7f7-d42c17f4b656" /> Whereas with the following small change it is: ``` description: operation.description || operation.summary || 'No description available.', ``` <img width="746" alt="Image" src="https://github.com/user-attachments/assets/4bfaf158-344e-482f-ac89-da977886b24a" />

GiteaMirror commented

2026-04-19 22:30:47 -05:00

@tjbck commented on GitHub (Apr 5, 2025):

description is the correct 1:1 mapping.

e.g. mcp puppeteer:

@tjbck commented on GitHub (Apr 5, 2025): description is the correct 1:1 mapping. e.g. mcp puppeteer: <img width="786" alt="Image" src="https://github.com/user-attachments/assets/5c3e0b16-916f-4cb2-aeab-f4310f49a723" />

GiteaMirror referenced this issue

2026-04-20 05:16:39 -05:00

[PR #16617] [CLOSED] feat/enh: async dao #24185

GiteaMirror referenced this issue

2026-04-25 12:15:24 -05:00

[PR #16617] [CLOSED] feat/enh: async dao #39815

GiteaMirror referenced this issue

2026-04-29 22:23:07 -05:00

[PR #16617] [CLOSED] feat/enh: async dao #47233

GiteaMirror referenced this issue

2026-05-06 07:34:36 -05:00

[PR #16617] [CLOSED] feat/enh: async dao #63041