openwebui-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation5/5
Every tool targets a distinct resource and action. Even similar operations like removing a file from knowledge vs deleting the file are clearly differentiated in descriptions. No two tools appear to do the same thing.
Naming Consistency5/5
All tool names follow the consistent pattern `openwebui_<verb>_<noun>`. Verbs and nouns are used systematically, with list tools using plural nouns and singular object tools using singular nouns, maintaining a clear and predictable convention.
Tool Count4/5
At 26 tools, the count is on the higher end, but the server covers seven distinct resource areas (chats, knowledge, files, functions, prompts, models, status). Each tool has a clear purpose, though some consolidation could be possible. Overall it's slightly over the ideal range but justified by scope.
Completeness3/5
Most core workflows are covered: chats have list/search/get/delete, files have full lifecycle, functions have full CRUD, and knowledge has create/update/add/remove. However, missing knowledge base deletion and prompt detail retrieval are notable gaps, and model operations are limited to listing only.
Average 4.1/5 across 26 of 26 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the prerequisite but does not disclose any side effects, permissions, idempotency, or error behavior. Since this is a mutation tool, the lack of such detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Each sentence earns its place: one states the purpose, the other states the prerequisite and parameter source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter add operation, the description covers the essential prerequisite and purpose. It lacks details about return values or failure modes, but the schema and simplicity of the tool make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already described. The description adds marginal value by re-emphasizing where to get the file ID, but does not meaningfully extend the schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add an uploaded file to a knowledge base') and the purpose ('for RAG retrieval'). It includes the prerequisite that the file must already be uploaded, which distinguishes it from upload and removal sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by specifying the prerequisite ('The file must already be uploaded via openwebui_upload_file') and how to get the file ID. It does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the response includes Python source code and configuration, which is useful. However, it does not mention error behavior, authentication requirements, or confirm the read-only nature, though 'Get' implies it. This is acceptable for a simple read operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. Every word earns its place — it conveys the purpose and key content without unnecessary details or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and a straightforward read operation, the description is largely complete. It specifies what is returned (source code and configuration). It stops short of describing the exact return format or any potential errors, but for this complexity level, the description is adequate and not misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (id) with a clear description and example, giving 100% schema coverage. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('full details of a specific function') with additional detail about contents (Python source code and configuration). It distinguishes this from sibling tools like list_functions, create_function, and update_function by focusing on retrieval of a single function's full details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when full details of a specific function are needed. However, it does not explicitly mention alternatives or exclusions, such as using list_functions for summaries or update_function for modifications. The purpose itself provides clear context, but no explicit guidance against other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It clearly indicates a read-only retrieval via 'Get', but it does not disclose error handling (e.g., 404 for unknown ID), the exact structure of the file list, or any potential side effects (none expected). The description adds minimal behavioral context beyond the inherent meaning of 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the main verb and object, then lists specifics. Every word adds value, and it is appropriately brief for a simple get-by-id operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, no output schema, no annotations), the description adequately covers what the tool does and what it returns (name, description, files). It could be more explicit about the exact shape of the file list or error behavior, but for this simple operation the information is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'id', which already has a description 'Knowledge base ID'. The tool description does not add new information about the id format, source, or constraints. It only implies that the id refers to a knowledge base, which the schema already states. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'specific knowledge base', and enumerates the returned details (name, description, file list). This distinguishes it from sibling tools like list_knowledge (listing all) and update/create (modifications).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving a single knowledge base via its ID, but it does not explicitly contrast with alternatives like list_knowledge or state when not to use it. There is no guidance on prerequisites or when one tool is preferred over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It states 'Create' (mutation) and 'Provide valid Python code,' hinting at code validation. It also explains what each function type does behaviorally. However, it does not mention error handling, permission requirements, return values, or side effects, which are significant gaps for a mutation tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states the primary purpose, the second explains the three types, and the third reminds about valid code. Every sentence earns its place, no redundancy, and the most important information is front-loaded. This is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward create operation with no output schema and no annotations. The description explains the function types and the need for valid code, but it does not describe the return value, potential errors, or any post-creation steps. For a CRUD create tool, this may suffice, but the absence of any outcome/response info leaves some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description repeats the type meanings already present in the schema enum descriptions, adding no new information. It does reinforce the requirement for valid Python code in the 'content' field, but this is marginal beyond the schema's own description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Create a new Pipe, Filter, or Action function in Open WebUI.' It immediately distinguishes from sibling CRUD tools (update, delete, list, get) and clarifies the three function categories with their purposes. This is a clear, non-tautological statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use each function type (pipe/filter/action), which helps the agent choose the correct 'type' parameter. However, it does not explicitly mention alternatives like update_function for existing functions, so the when-not guidance is missing. The intent is obvious from the name, so this is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only mentions that unspecified fields remain unchanged, but does not disclose permissions, error behavior, side effects, or whether the update is atomic. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and contains no redundant information. Every word contributes to the user's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple CRUD update but lacks details on return values, error conditions, or permissions. Given the absence of annotations and output schema, more context would be helpful, though the schema covers the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all four parameters (100% coverage). The description adds value by clarifying that only the fields passed are updated, which is key partial-update semantics beyond the schema's optional flags.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing function's source code, name, or description, using a specific verb and resource. It distinguishes itself from sibling create/delete/list/get functions by specifying the update action and the modifiable fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for updating an existing function, and the instruction to pass only the fields to change implies partial updates. However, it does not explicitly mention alternatives or when not to use this tool, though the purpose makes it reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context that this is a RAG collection and that population is a separate step, but does not disclose potential side effects, permission requirements, or behavior on duplicate names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the primary purpose and adding a single relevant workflow hint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with two parameters and no output schema, the description provides the essential information: what the tool creates and how to populate it afterward. It doesn't cover return values or error handling, but these are less critical for a create operation with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (name and description) with 100% coverage, so the description doesn't need to add much. It does not elaborate on parameter formats or constraints beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('create') and resource ('RAG knowledge base collection'), clearly distinguishing this from sibling tools that list, get, update, or delete knowledge bases. It also provides workflow context by naming the follow-up tools for populating the collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the creation purpose and explicitly points to openwebui_upload_file and openwebui_add_file_to_knowledge for the next step, guiding the agent on subsequent actions. It doesn't explicitly contrast with update/delete tools, but the workflow hint effectively carves out when to use this tool versus adding files to existing knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description carries the burden. It discloses the command prefix constraint and invocation behavior. However, it does not address duplicate command conflicts, error handling, or what happens on success (e.g., returned resource).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences lead with the action verb and give a useful usage tip. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with fully documented parameters and no output schema, the description is adequately complete. It covers the tool's purpose and a critical input format requirement. A note about uniqueness conflicts could be added but is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the schema already documents command, name, and content. The description only repeats the '/' requirement already present in the schema, adding no new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action 'Create a new saved prompt in Open WebUI' with a clear verb+resource. This distinguishes it from sibling tools like update_prompt, delete_prompt, and list_prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: prompts are invoked by typing their command in chat and must start with '/'. This helps the agent understand when the tool is appropriate, but does not explicitly mention alternatives like update_prompt for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It clearly states the operation is irreversible and requires confirm=true, which are critical for a destructive action. It does not mention permissions or error scenarios, but the key destruction trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary purpose and followed by key warnings. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter delete tool with no output schema and no annotations, the description covers the essential context: what it does, irreversibility, and confirmation requirement. It could mention error handling or return values, but these are not critical for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (Chat ID to delete, Must be true to confirm deletion), and the tool description only reiterates these without adding additional meaning. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'chat' and scoping 'by ID', making it clear what the tool does and distinguishing it from sibling tools like get_chat, list_chats, and search_chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to delete a chat) but does not explicitly mention alternatives, prerequisites, or when not to use it. The irreversible warning adds some caution but no explicit guidance versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive nature via the verb 'delete' and adds a key behavioral requirement (confirm must be true). However, with no annotations provided, it doesn't mention irreversibility, permissions, or side effects, leaving a partial transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains the essential information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter delete tool with no output schema, the description provides the necessary action, identification method, and confirmation requirement. It could be more explicit about permanence, but overall it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters have descriptions. The description adds minimal new meaning beyond the schema, only reinforcing that the tool selects by 'command' and requires 'confirm true'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete', identifies the resource ('saved prompt'), and specifies the targeting mechanism ('by its command'). This clearly distinguishes it from sibling delete tools for chats, files, functions, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear prerequisite: 'Requires confirm: true', which tells the agent how to invoke the tool safely. It doesn't explicitly mention alternatives or exclusions, but for a delete operation, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that it returns up to 50 chats per page and the fields (title, ID, last update time), giving a clear picture of the output. It does not mention potential caveats like whether it only returns metadata, but for a list operation the behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the verb and resource, and every sentence adds information - the page size, return fields, and pagination instruction. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and no output schema, the description gives enough to understand the return payload and pagination. It lacks mention of how to get full chat contents, but that is a separate tool. Given low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the page parameter with default and description, so the baseline is 3. The description adds value by stating the per-page limit of 50 chats, which is not in the schema, and explicitly connects the page parameter to pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names the resource 'chat conversations in Open WebUI', clearly distinguishing it from sibling tools like search or get. It also specifies scope with 'recent' and return fields, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the main usage context (listing recent chats) and instructs to use the page parameter for pagination, but does not explicitly mention alternatives such as openwebui_search_chats for searching or openwebui_get_chat for retrieving a single chat. Thus it lacks explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses search scope (titles and content) and return value (conversations with IDs), but omits details like pagination, ordering, or authorization scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no redundant information; every sentence contributes unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with a single parameter and no output schema, the description adequately covers purpose, search scope, and return value, though it could mention result ordering or access scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 'query' as a search keyword/phrase, and the description adds meaning by explaining that it searches through both titles and content, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('chat history') and explicitly states it searches titles and content, clearly distinguishing it from sibling tools like list_chats and get_chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Search chat history by keyword' but does not explicitly contrast with alternatives such as list_chats for browsing all chats or get_chat for fetching a specific conversation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds the key behavioral note that files are untouched, which is valuable. However, it does not disclose details about mutation semantics (e.g., partial vs. full replacement) or any error/permission conditions, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey the core purpose and the key caveat. No wasted words; the front-loaded action makes it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with three parameters and no output schema, the description covers the essential behavior and the non-effect on files. It may benefit from mentioning whether the update is partial or full, but overall it is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description's phrase 'name or description' aligns with the name/description parameters but adds no extra semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (update), the resource (knowledge base), and the specific fields affected (name or description). It distinguishes from sibling tools like create_knowledge and file-management tools by explicitly stating it does not affect files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use it: for updating metadata rather than file contents. The statement 'Does not affect files already in the collection' provides context but does not explicitly name alternative tools like add/remove file, so it is clear but lacking explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that base64-encoded content is required for MCP stdio transport and implies a returned file ID for downstream use. However, it omits details like persistence, overwrite behavior, or potential errors, which for a simple upload tool is understandable but leaves some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the core purpose, and the second provides a critical requirement and a clear next-step reference. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple upload tool with three parameters and no output schema, the description covers the main action, a key requirement, and the intended follow-up workflow. It does not mention size limits, authentication, or error conditions, but given the low complexity, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The description adds context about the base64 requirement for MCP stdio transport, which slightly enhances understanding, but this does not significantly elevate the semantic value beyond what the schema provides. Thus, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Upload' and resource 'file to Open WebUI', distinguishing it from sibling file-related tools like list_files, delete_file, and add_file_to_knowledge. The explicit mention of using the returned file ID with add_file_to_knowledge further clarifies its distinct role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: it handles uploading with base64-encoded content required for MCP stdio transport, and it directs the user to a follow-up action (add_file_to_knowledge). It lacks explicit exclusions or direct comparison to alternatives, but the workflow guidance is strong enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It reveals that the tool returns full details and all messages, which is helpful, but it does not explicitly mention important behavioral aspects such as read-only status, authentication requirements, or error behavior. Since 'get' implies a read operation, the gap is not severe, but more explicit disclosure would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core function, the second provides practical guidance for finding IDs. Every sentence earns its place with no wasted words, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool without an output schema, the description adequately conveys the main content (chat details and messages) and gives a path to discover IDs. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single 'id' parameter completely with a description. The description only says 'by ID', which adds no new semantic detail beyond the schema. Given 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving full details of a specific chat by ID, including all messages. This distinguishes it from sibling tools like list_chats (which lists chats) and search_chats (which finds by query), and it specifies the resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to openwebui_list_chats or openwebui_search_chats to find chat IDs, providing clear context for when to use this tool (when an ID is known) versus alternatives. It does not explicitly state exclusions, but the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool's output (returning function IDs, names, types, enable/disable status) but does not mention pagination, ordering, authentication, or side effects. With no annotations, it partially discloses behavior but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adding value: the first states the resource and scope, the second lists the returned fields. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool without output schema, the description fully covers what it lists and what it returns. It is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameter semantics to clarify. Baseline of 4 is appropriate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'functions installed in Open WebUI', with the scope 'all Pipe, Filter, and Action functions', clearly distinguishing it from sibling tools like get_function or list_chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for enumerating all functions, but does not explicitly state when to use it over get_function or mention exclusions. The usage context is clear but not directly contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return fields ('command, title, and a content preview') but does not explicitly state this is a read-only operation. The verb 'List' implies non-destructive behavior, but there is no explicit mention of side effects, limitations, or special behaviors beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every sentence adds value: the first states what it does, the second clarifies the domain and output. There is no redundant text or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema, no annotations), the description covers all necessary context: what the tool does, the domain concept of prompts, and the return fields. It explicitly states 'List all' and gives the fields returned, providing enough information for an agent to use the tool correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly adds no parameter-related information. Per the rubric, a zero-parameter tool gets a baseline of 4. The description's mention of what is returned is sufficient for an agent to know what to expect from invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List all saved prompts in Open WebUI,' which clearly specifies the action (List), resource (saved prompts), and context (Open WebUI). It also differentiates from sibling list tools like openwebui_list_chats and openwebui_list_files by focusing on prompts, and even explains what prompts are with an example command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: if you need to see saved prompts, use this tool. However, it does not explicitly mention when not to use it or point to alternatives such as openwebui_create_prompt/openwebui_delete_prompt for modifying prompts. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that deletion is permanent and requires confirm: true, which are critical behavioral aspects. It does not mention side effects or authorization, but for a simple delete, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, begins with the core purpose, and includes essential details without excess. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two required parameters and no output schema. The description covers purpose, permanence, and confirmation requirement, which is sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (id and confirm). The description adds the note that confirm must be true, which reinforces the schema, but does not add new meaning beyond that. With 100% schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a function from Open WebUI' with a specific verb and resource, distinguishing it from sibling delete tools for chats, files, and prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for deleting functions and notes the required confirm flag, which implies the usage. It does not explicitly compare to alternatives, but the resource scope is unambiguous given the tool name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states what the tool returns and explicitly notes it does not return file content, which is a key behavioral trait. It stops short of mentioning error conditions or access requirements, but for a simple metadata getter this is solid coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the verb and resource, then lists return fields and a key exclusion. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter metadata retrieval tool with no output schema, the description fully covers what the caller needs to know: what the tool does, what fields it returns, and that it does not return content. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the single parameter 'id' with description 'File ID' (100% schema coverage), so the description adds little beyond that. The phrase 'specific uploaded file' loosely connects the id to the operation, but no additional format or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves metadata for a specific uploaded file, enumerating the exact fields returned (name, size, content type, creation date). It distinguishes itself from sibling tools like list_files by targeting a single file and explicitly excluding file content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: use when you need metadata for a specific file, not when you need file content ('Does not return file content'). It does not explicitly name alternative tools, but the context is sufficient for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It communicates a read-only check of status/version/health, implying no side effects. However, it does not detail return format, authentication, or potential latency—basic but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, followed by a practical usage note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check with no parameters and no output schema, the description adequately conveys purpose and usage. It mentions status, version, and health, covering likely return contents. Nothing more is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. With no parameters, the description need not add parameter details; the baseline for zero-param tools is 4, and the description correctly omits parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks Open WebUI system status, version, and health, using the specific verb 'check' and a distinct resource. It distinguishes from sibling tools that operate on chats, files, knowledge, functions, etc., as none cover system status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context, noting it is useful for verifying connectivity and confirming the running version. While it does not explicitly list when not to use or name alternatives, the status check is unique among siblings, so no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states 'List all tags' which is a transparent, read-only behavior. There are no hidden side effects or permissions mentioned, but for a simple list operation, the description is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action ('List all tags used across chats'). Every word earns its place, with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description fully captures the tool's purpose and basic behavior. It is complete for a simple zero-parameter list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline of 4 applies. The description does not need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all tags used across chats in Open WebUI' with a specific verb and resource. It distinguishes from sibling tools like openwebui_list_chats (lists chats) and openwebui_get_chat (gets a single chat) by focusing on tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Useful for understanding how conversations are organized.' This implies when to use the tool, though it does not explicitly exclude alternatives or mention when not to use it. This fits 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It conveys that this is a read-only listing operation and specifies the return payload (file names, IDs, sizes, content types). It does not mention pagination or authentication, but these are not critical for a straightforward list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and includes essential return-field details and a practical cross-reference. Every sentence contributes value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately explains the purpose and return content. It could mention potential size limits or sorting, but such details are not necessary for basic usage. The cross-reference to add_file_to_knowledge adds useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage by definition. The description does not need to elaborate on parameters. Per rubric, 0 params receives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all files uploaded to Open WebUI' with a specific verb and resource. It then enumerates the returned fields (names, IDs, sizes, content types), which distinguishes it from sibling tools like get_file_info (single file) and upload_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the primary use case explicit: to list all files. It also provides a forward-looking hint, saying to use the returned file IDs with openwebui_add_file_to_knowledge. It does not explicitly exclude any scenarios or name alternatives, but for a simple list operation, this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the operation lists collections and specifies the return fields, which implies a read-only operation. It does not explicitly confirm non-mutating behavior, but 'List' is a strong signal and no side effects are suggested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action and resource, and every sentence provides useful information. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description adequately covers what the tool does and what it returns. It could mention potential pagination or filters, but given the simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description adds no parameter details because there are none to explain. A baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'List all RAG knowledge base collections in Open WebUI', using a specific verb and resource. It clearly distinguishes this from sibling tools like openwebui_get_knowledge by emphasizing 'all'. It also states what it returns (names, IDs, descriptions, file counts), which fully clarifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all' provides clear context that this is the tool to use when you need a complete inventory of RAG knowledge collections. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it falls short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full burden. It discloses the key constraint that command is immutable, which is valuable. However, it does not mention whether updates are partial or full, what happens if the command does not exist, permissions needed, or the return value. These are notable gaps for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no filler. It conveys the action, the scope, and a critical constraint in a compact and efficient manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 parameters, no nested objects, no output schema) and high schema coverage, the description provides sufficient context for invocation and highlights the main caveat. Missing return value/error details are acceptable for this simple update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (100% coverage), but the description adds crucial semantics: command is an immutable identifier for selecting the prompt, while name and content are the only fields that can be updated. This goes beyond the schema's simple descriptions and aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('existing saved prompt'), listing the mutable fields (name, content). It also distinguishes from sibling create/delete tools by noting the command cannot be changed, with a delete-and-recreate alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that the command/trigger cannot be changed and instructs to delete and recreate instead. This provides clear when-to-use guidance and names the alternative approach, making it easy for an agent to choose between update and create/delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses permanence, the knowledge base removal prerequisite, and the confirm requirement. It doesn't mention permissions or error behavior, but the key behavioral traits are well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The primary action is front-loaded, and the caveat and requirement are succinctly appended.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and the dependency on knowledge base removal, the description covers the necessary context: action, alternative, and confirmation. No output schema is needed for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'id' and 'confirm' already described in the input schema. The description adds minimal new meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'uploaded file from Open WebUI', while also specifying the 'permanently' nature. It distinguishes itself from sibling deletion tools by targeting files, and the knowledge base caveat shows scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs when not to use the tool directly ('If the file is in a knowledge base, remove it from the collection first') and names the alternative tool (openwebui_remove_file_from_knowledge). It also states the confirmation prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read-only listing operation and discloses what the tool returns (model IDs, names, sources). While it does not mention authentication or pagination, these are not critical for a simple list tool, and the behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose, lists inclusions, and states return fields. Every phrase adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool with no output schema, the description is fully complete. It explains what models are included and what information is returned, which is all the agent needs to invoke the tool correctly. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Per the baseline rule for 0 params, a score of 4 is appropriate. The description adds no parameter details because none exist, and the schema already covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List all available models'), specifies the resource (models in Open WebUI), and distinguishes it from sibling tools by enumerating the model sources (Ollama, OpenAI, custom pipes). This is a specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to retrieve available models), and sibling tools are all for different resources (chats, knowledge, files, functions, prompts), so there is no ambiguity. However, it does not explicitly mention alternatives or exclusion cases, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It explicitly states a key non-obvious behavior: the file itself is not deleted—only removed from this collection. This adds value beyond the tool name and covers the most important side-effect distinction. It doesn't mention other potential side effects (e.g., reversibility, permissions), but the statement is sufficient for the tool's scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the core action, the second corrects a potential misconception and points to an alternative. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no output schema and full schema parameter descriptions, the description is complete. It covers the tool's purpose, scope, and the key alternative. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with clear descriptions ('File ID to remove from this collection', 'Knowledge base ID'). The description adds no additional parameter semantics beyond restating the collection context. Baseline 3 is appropriate because the schema already provides full parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove a file from a knowledge base') and clearly distinguishes from the sibling tool by noting the file is not deleted, only removed from the collection. This differentiates it from openwebui_delete_file and mirrors the inverse of openwebui_add_file_to_knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool vs. the alternative: 'Use openwebui_delete_file to delete the file entirely.' This provides clear usage guidance and prevents confusion between removal and deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openwebui-mcp-server MCP server](https://glama.ai/mcp/servers/marccyberleda/openwebui-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/marccyberleda/openwebui-mcp-server)

Score Badge

Copy to your README.md:

[![openwebui-mcp-server MCP server](https://glama.ai/mcp/servers/marccyberleda/openwebui-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/marccyberleda/openwebui-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/marccyberleda/openwebui-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server