Draw.io MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, targeting different resources and actions. However, a few style-related tools (apply_theme, manage_colors, update_style) may cause some confusion, though descriptions mitigate ambiguity.
Naming Consistency3/5
The naming convention is mostly snake_case with verb-first patterns (create, get, update, delete), but several tools use noun-phrase names like layer_management, version_management, batch_operations, auto_layout, and copy_paste, deviating from the consistent verb_noun style.
Tool Count2/5
With 26 tools, the count exceeds the 25-tool threshold for a heavy surface. While the domain is broad, the large number may make the tool set feel bloated and harder to navigate.
Completeness3/5
The tool set covers a wide range of diagram operations, including creation, element manipulation, styling, layout, import/export, and versioning. However, it lacks direct 'delete_diagram' and 'get_element' functions, leaving minor CRUD gaps for diagrams and elements.
Average 2.6/5 across 26 of 26 tools scored. Lowest: 1.7/5.
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 ISC 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'create flowchart', disclosing no behavior about side effects, persistence, or return values. This leaves the agent entirely without safety or runtime context for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The phrase is extremely short, but this is under-specification rather than effective conciseness. The description merely mirrors the name and earns no place as added guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with a nested steps array, no output schema, and no annotations, a one-phrase description is far too sparse to guide an agent. It lacks information about required fields, semantics of steps, layout options, or what happens after creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contributes no parameter semantics; only 67% of params have schema descriptions, and layout is left without a textual explanation. The tool relies entirely on the schema, so the description fails to add value beyond structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建流程图' is a direct Chinese translation of the tool name 'create_flowchart', providing no additional specificity. It restates the name rather than explaining what creating a flowchart entails or how it differs from siblings like create_diagram or create_mindmap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over create_diagram, create_timeline, or other siblings. The description offers no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states what the tool does (creates a mind map) without any information on side effects, permissions, overwrite behavior, return values, or limitations. This is completely opaque for a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is efficient, but it is under-specified to the point of being a restatement of the tool name. It does not earn its place by adding any useful information. A concise description should convey essential context, not merely translate the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has a complex schema with 5 parameters, nested objects, and no output schema or annotations. The description provides no information about return values, behavioral side effects, or usage context. It is completely inadequate for an agent to safely and correctly invoke this 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?
The input schema is highly detailed with 100% description coverage, so the baseline is 3. The description itself adds nothing about parameters, but the schema's per-property descriptions (e.g., '中心主题文本', '分支层级（1为主分支）') provide sufficient semantics for an agent to understand the meaning of each field. The description does not compensate for any gaps, but none exist in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建思维导图' literally translates to 'Create mind map', which is a direct restatement of the tool name. It provides no additional specification or distinction from sibling tools like create_diagram, create_flowchart, or create_org_chart. A tautology does not help an agent understand what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios where a mind map is appropriate, or exclusions (e.g., when to use create_diagram instead). For an agent choosing among many diagram creation tools, this is a critical gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it reveals nothing about side effects, permissions, or operation-specific outcomes. For a tool with destructive actions like delete_version, this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but brevity is not conciseness. It under-specifies the tool completely, lacking any structure or key information needed for an agent to understand its scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, six distinct operations, no output schema), the single phrase is grossly insufficient. The description fails to convey operation-specific requirements, relationships between actions and parameters, or expected 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?
Schema coverage is 100%, and each parameter has a description, so the baseline is 3. The description itself adds no semantic value beyond the schema, which is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '图表版本管理' (diagram version management) names the resource but lacks a specific verb or action. It provides minimal differentiation from siblings like save_diagram or load_diagram, and the actual operations are hidden in the action enum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor when to select specific actions like create_version vs list_versions. The description is purely a label.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden; it discloses no behavioral traits such as mutation, deletion risk, connection preservation, or required prerequisites. The description is completely opaque about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise, but it is under-specified rather than efficiently informative. It omits essential operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, nested objects, no output schema, and no annotations, the description fails to explain the operation types, options, or side effects, making the tool's behavior largely obscure and incomplete.
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 top-level parameters, so the baseline is 3. The description adds no extra parameter context, and nested properties like size/position lack descriptions, but the schema already provides meaningful top-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '批量操作图表元素' (batch operations on diagram elements) identifies a resource and a broad action, but 'batch operations' is not a specific verb and the tool's actual operations (create, update, delete, etc.) are left to the schema. It does not distinguish this tool from siblings like batch_import or copy_paste.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus individual element operations or batch_import. The description is only a noun phrase and provides no context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. '创建通用图表' discloses no side effects, return behavior, permissions, or validation details. For a write operation, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is extremely concise but under-specified. It is not 'appropriately sized' because it lacks necessary context. This is under-specification, not efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, a rich enum, no output schema, and many sibling tools, the description provides almost no context. It fails to explain what 'general' means, how this relates to specialized creators, or what the tool returns. Entirely insufficient.
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 the baseline is 3. The description adds no extra meaning about how the parameters relate or should be used, but it does not mislead either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates general diagrams, which is a clear verb+resource, but 'general' is vague and does not differentiate it from specialized creation siblings like create_flowchart or create_org_chart. The schema enum lists supported types, but the description itself lacks that specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With multiple sibling tools for specific diagram types (create_flowchart, create_org_chart, create_mindmap), the description offers no criteria for choosing the generic create_diagram.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It merely says 'manage' without mentioning side effects like deletion, visibility changes, or reordering impact. It doesn't state whether actions are destructive, require permissions, or what the return values look like. This is a severe gap for a tool with actions like delete_layer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague sentence that underspecifies the tool. For a tool with 7 parameters and 6 distinct actions, it should offer more structured detail. It's not concise; it's just incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple action types, nested layer_properties, no output schema), the description is far from complete. It doesn't enumerate actions, explain what each action does, or describe any output or error behavior. The description fails to provide a complete picture even with a rich schema.
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 has 100% description coverage for all parameters, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides. It doesn't explain the relationship between action and required parameters, but the schema's per-field descriptions are sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'manage chart layers and groups,' which is vague and does not specify the actual operations (create, delete, move, reorder, visibility). It also mentions 'groups' but the schema has no group-related parameters or actions, making the purpose somewhat misleading. Sibling tools don't cover layers, so some differentiation exists, but the verb 'manage' is too generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There are no usage scenarios, prerequisites, or exclusions. The sibling tools include similar management operations, but the description doesn't distinguish when layer_management should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for disclosing behavior. It only says 'manage color schemes and palettes', giving no information about side effects, whether operations are read-only or mutating, or what happens to existing colors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence but it is under-specified rather than concise. It lacks actionable detail, so it does not earn its place as a useful descriptor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a complex 4-parameter input (including nested objects), the description is far from complete. It does not explain the actions, their effects, or expected return values.
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 the baseline is 3. The description adds no additional meaning to the parameters; all semantics must come from the schema, which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the generic verb 'manage' (管理), which does not specify the concrete operations available (set, get, apply, reset). It does not distinguish this tool from overlapping siblings like apply_theme or update_style.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as apply_theme or update_style. The description gives no context about the intended scenarios or exclusions.
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 provided, the description must disclose behavior, but it only states the basic action of creating an org chart. It does not mention side effects, whether the operation is destructive or saves to the workspace, permissions needed, or what output to expect. This is a minimal disclosure that fails to convey the tool's behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase, which is concise and front-loaded. However, it is under-specified and adds no distinct value beyond the tool name. It is not wasting words, but it also does not earn its place by providing useful information, so it merits an average score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a create operation with a nested root object, missing annotations, and no output schema, the description is far from complete. It does not explain the expected structure of the org chart, how it interacts with existing diagrams, or what the function returns. The description leaves critical context unaddressed.
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 describes both parameters with a brief description each (root and title), giving 100% schema coverage. The description itself adds no parameter explanation beyond what the schema provides. The nested root object's properties lack descriptions, but since the tool-level description is silent on parameters, the baseline of 3 applies for adequate schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建组织架构图' is a direct translation of the tool name 'create_org_chart', essentially restating it without adding any new information. It clearly names the action and resource, but because it merely repeats the name, it falls into the tautology category rather than providing a meaningful purpose statement that distinguishes it from the sibling create_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_flowchart, create_mindmap, or create_timeline. There is no mention of specific use cases, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only states 'Batch import chart files'. It omits critical side effects such as file overwriting, backup creation, format validation, and permission requirements, all of which are specified in the schema options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy, making it concise and easy to parse. However, it is so brief that it borders on under-specification, though this is better addressed in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters including nested objects) and the absence of an output schema or annotations, the description fails to convey return values, error behavior, or operational context. It is insufficient for an agent to fully understand the tool's capabilities and side effects.
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 descriptions for all parameters, so the tool description adds no additional parameter semantics. The baseline of 3 applies because the schema already effectively documents all parameters and their options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Batch import chart files' clearly states a batch import function for diagram files. The verb 'import' and resource 'chart files' distinguish it from siblings like load_diagram and create_diagram, though it could more explicitly mention the source directory context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like load_diagram or batch_operations. There is no mention of prerequisites, exclusions, or scenarios where this tool is preferred, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 side effects, persistency, or reversibility. '自动布局图表元素' only states the action and does not reveal whether it mutates the diagram, requires specific permissions, or has any behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no filler words, making it very concise. It sacrifices depth for brevity, but as a structure, it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (four parameters with nested objects, no output schema, no annotations), the one-line description is insufficient. It fails to communicate what the tool returns, how it behaves, or what effects it has on the diagram, leaving significant gaps for the 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?
The schema description coverage is 100%, so the baseline is 3. The tool description adds no additional parameter meaning beyond what the schema already provides, but it does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '自动布局图表元素' clearly states the tool auto-layouts diagram elements with a specific verb and resource. It is distinguishable from sibling tools like connect_elements or update_style, though it does not explicitly name alternatives or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other layout-related tools, no mention of prerequisites, and no exclusions. The description simply states the action without contextualizing its use case.
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 provided, the description must carry the full burden of behavioral disclosure. '获取' implies a read operation, but the description does not explain return format, aggregation behavior, performance implications, or how statistics are computed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise. However, it is underspecified for a tool with 7 parameters and nested options, making it more under-specification than appropriately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex schema, no annotations, and no output schema. The minimal description fails to convey the tool's broader capabilities, use cases, or limitations, leaving the agent with insufficient context to invoke it effectively.
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 description coverage is 100%, providing descriptions for all parameters and nested properties. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 (get) and resource (chart statistics), providing a specific verb and resource. However, it does not differentiate from sibling tools like get_diagram_info, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_diagram_info, list_diagrams, or export_diagram. No usage context, prerequisites, or exclusions are mentioned.
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?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only says 'copy and paste diagram elements' and does not explain the effects of each action (e.g., cut deletes original, paste creates new instances), the role of clipboard_data, or how target_diagram_id affects operations. This is a significant gap for a tool with multiple actions and nested options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it essentially restates the tool name ('copy_paste' -> 'copy and paste diagram elements'), providing little added value. It is under-specified rather than efficiently informative, so it does not fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, including nested paste_options and clipboard_data, no annotations, and no output schema. The one-line description is insufficient to understand the tool's full scope (actions, cross-diagram pasting, style copying, connection preservation). Given the complexity, the description is far too minimal to enable correct invocation.
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 for parameters, including descriptions for action enum values, clipboard_data, paste_options, and target_diagram_id. The tool description itself adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '复制和粘贴图表元素' (copy and paste diagram elements), which clearly identifies the operation and resource. However, it omits mention of cut/duplicate actions supported by the schema, and does not distinguish the tool from siblings beyond the basic copy/paste function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention cross-diagram copy capabilities, prerequisites, or situations where copy vs. cut vs. duplicate should be chosen. There is no mention of alternative tools or when not to use this tool.
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?
There are no annotations, so the description must disclose behavioral traits. It simply says 'create or manage chart templates' without any information about side effects (e.g., delete is destructive, apply modifies diagrams), required permissions, or operational details. The schema hints at these actions, but the description itself is silent on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase, which is efficient, but it is under-specified for a tool with 5 parameters and multiple discrete actions. For the complexity level, a one-line phrase is too minimal to serve as a complete tool description. It is not verbose, yet it fails to convey necessary structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, nested template_data object, no output schema, no annotations), the description is far from complete. It provides only a high-level purpose and leaves out crucial context like return values, side effects per action, and which parameters apply to which action. The schema covers parameter syntax but not the operational context.
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 parameters, so the schema already documents each parameter and its purpose. The description adds nothing about parameters—it doesn't explain how the action field drives the operation or how parameters relate. Baseline 3 applies because the schema carries the burden, but the description contributes no additional semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates or manages chart templates, which clearly identifies the resource (图表模板) and a verb (创建/管理). It distinguishes from sibling tools like save_diagram or apply_theme, which target diagrams or themes rather than templates. However, 'manage' is vague and doesn't enumerate the specific actions (create, save, list, delete, apply) that the schema reveals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or exclusions. The sibling tool names (e.g., save_diagram, load_diagram) offer context, but the description itself gives no usage direction.
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 provided, the description carries the full burden of behavioral disclosure. 'Connect two diagram elements' only states the action without revealing side effects, such as whether it creates a new edge, modifies existing connections, requires existing elements, or affects layout. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action. It contains no unnecessary filler, though it is so minimal that it sacrifices useful context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters including a nested object (style) and no output schema, the description is severely incomplete. It explains neither the meaning of connections nor expected behavior, leaving the agent with insufficient context for correct invocation.
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 the baseline is 3. The description adds no extra meaning to parameters like 'label' or 'style', relying entirely on the schema's per-field descriptions. It does not compensate for any gaps, but none exist in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('connect') and the resource ('two diagram elements'), which is a specific verb+resource pair. It distinguishes this tool from siblings like add_element or update_element, though it could be more specific about what 'connect' entails (e.g., creating an edge).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., elements must exist), exclusions, or related tools that might be better suited for similar tasks.
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 carries the full burden of behavioral disclosure. It only says 'get basic information', which implies a read operation, but it does not disclose what 'basic information' consists of, whether permissions are needed, or what the response format is. No output schema exists, so the description should provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short phrase that efficiently communicates the core purpose without unnecessary words. It is appropriately sized for a simple tool, though it could have been more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is still insufficient. It does not explain what 'basic information' includes, does not describe the return value, and does not differentiate from similar tools like load_diagram or get_statistics. This leaves the agent without enough context to decide when to use it or what to expect.
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% (diagram_id is documented as '图表ID' meaning diagram ID), so the baseline is 3. The description does not add any additional meaning to the parameter beyond the schema, such as expected format or examples, but it is not misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取图表基本信息' (get diagram basic information) states a clear verb+resource action, indicating it retrieves basic information about a diagram. However, it does not specify what 'basic information' includes or distinguish it from sibling tools like load_diagram or get_statistics, so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. For example, it is unclear whether this should be used to fetch metadata vs. full content, or how it relates to load_diagram.
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 provided, the description carries the full burden of behavioral disclosure. It only states 'List all diagrams' without mentioning important behavioral traits such as pagination, depth of listing (direct children vs. recursive), or any access restrictions. The read-only nature is implied but not explicitly stated, and there is no disclosure of how the 'directory' parameter affects the listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded and easy to parse. While it is minimal, it is appropriately sized for such a simple tool and does not contain fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is relatively simple, the description is incomplete for an agent to invoke it correctly. It does not specify the scope of 'all diagrams' (e.g., all in the current workspace, all in a given directory), nor does it mention any return format or potential side effects. The existence of the 'directory' parameter implies the listing can be scoped, but this is not reflected in the description. There is also no output schema to fill the gap.
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 covers both parameters with descriptions: 'format' as file format filter and 'directory' as directory path. Since the schema description coverage is 100%, the baseline is 3. The tool description adds no additional parameter context, but it also doesn't need to compensate because the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出所有图表' clearly states the action (list) and the resource (all diagrams). It is a direct translation of the tool name, but it still conveys a specific and distinct purpose. It does not explicitly differentiate from siblings like get_diagram_info or search_elements, but the scope 'all' implies a listing function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of preferred contexts, limitations, or exclusions for other tools. The agent is left without information on whether this is the default for browsing diagrams or if search tools should be used for filtering.
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?
No annotations are present, so the description carries full responsibility. It only states the generic action without disclosing behavioral details such as file overwriting, permission requirements, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is concise and to the point. However, it adds minimal value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool with a similar sibling like 'export_diagram'. It lacks behavioral context and usage guidelines, making it incomplete for an agent to select and 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?
The input schema has 100% coverage with descriptions for all three parameters. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '保存图表到文件' (save diagram to file), providing a specific verb and resource. It is clear but does not differentiate from the sibling tool 'export_diagram', which may perform a similar action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'export_diagram' or 'load_diagram'. The description lacks context about appropriate use cases.
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 carries the full burden, but it only states the action without any behavioral details such as whether hidden/locked elements are excluded by default, whether results are highlighted, or how results are returned. No side effects or permissions are mentioned.
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, clear sentence with no redundant content, making it easily scannable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (five parameters, nested objects, no output schema), the one-sentence description is grossly insufficient. It lacks information about return values, default search scope (current vs all), result limits, and how filtering works, leaving the agent to infer almost everything from the schema.
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 provides descriptions for all properties including filters, search_options, and sort_options, achieving 100% coverage. The description itself adds no parameter semantics, relying entirely on the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '在图表中搜索元素' (Search elements in diagrams) clearly identifies the operation and resource, distinguishing it from create/update/export tools. However, it does not convey the extensive filtering and search options available, so it is clear but not fully descriptive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't state when to use this tool versus alternatives like get_diagram_info or batch_operations, nor any prerequisites or context.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic update action and does not mention validation, style merging, connection updates, or potential side effects, even though the schema options imply these behaviors.
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, concise sentence that conveys the core purpose without any fluff. It is front-loaded and immediately understandable, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—nested update objects, merge options, connection updates—the description is too sparse. It lacks guidance on usage scenarios, side effects, or return behavior, making it inadequate for a tool of 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?
All parameters have schema descriptions, so the description adds no extra parameter meaning. The tool description does not explain partial updates or the effect of options, but the schema already covers the parameter details, yielding a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 element's attributes, with a specific verb and resource. It distinguishes from add_element and delete_element, but does not explicitly differentiate from the sibling update_style, which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context on prerequisites, when to prefer this over update_style or add_element, or any exclusions.
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?
No annotations are provided, and the description does not disclose behavioral traits such as irreversibility, side effects on related elements, confirmation behavior, or cascade handling. The schema hints at options like confirm and cascade_delete, but the description fails to surface these important behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, making it highly concise. However, it is arguably too sparse, lacking important context, but that is more a completeness issue than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, nested options) and lack of annotations, the description is insufficient. It does not explain deletion behavior, effects on connections, confirmation requirements, or irreversibility. The schema covers parameters but the description adds no procedural or safety context, making it incomplete for safe invocation.
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 all four parameters described in the input schema. However, the tool description adds no additional meaning beyond the schema, 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 the action (delete) and target (elements or connections in a diagram), distinguishing it from siblings like add_element, update_element, and connect_elements. The verb+resource structure is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions or context for choosing it over batch_operations or similar. It merely states what it does, so no usage guidance is present.
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?
No annotations are provided, so the description carries the full burden. It only says 'update style' without disclosing whether styles are merged or replaced, what happens to unspecified styles, or any side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, and it effectively front-loads the core purpose. However, it lacks any structural elaboration that could aid scanning, so it is not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with three target types and a nested style object, but the description is too minimal. It does not explain partial vs full updates, return values, or how it relates to sibling style-related tools, making it incomplete for an agent to use confidently.
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 description coverage is 100%, with every property fully described. The description itself adds no extra meaning beyond the schema, 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 the verb 'update' and the resource 'style', and explicitly names the three target types (diagrams, elements, connections). This distinguishes it from siblings like update_element or apply_theme, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or contrast with sibling tools such as apply_theme or manage_colors, leaving the agent to infer usage.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'add element,' implying a mutation but not explaining that it modifies an existing diagram, whether it is reversible, permission requirements, or potential errors. This is minimal and insufficient.
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 concise sentence that is front-loaded with the core purpose. It contains no redundant or unnecessary words, and the brevity is appropriate for a straightforward action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested element schema and no output schema, the description should provide more context about what an element is, valid element types, or the requirement that the target diagram already exists. The one-sentence description leaves critical gaps for an agent to fully understand the tool's 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 describes both parameters (diagram_id and element), so schema coverage is 100%. The tool description adds no further meaning beyond the schema, meeting the baseline but not enhancing understanding of nested properties like type or position.
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 '向图表添加元素' ('Add element to diagram') clearly states the specific action (add) and resource (element to a diagram). It distinguishes itself from sibling tools like delete_element and update_element by conveying the operation's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_diagram or create_flowchart, nor does it mention prerequisites like the diagram existing before adding elements. There is no explicit usage context or exclusions.
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?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It merely states the action ('apply theme') without revealing side effects (e.g., overwrites existing styles), reversibility, permission requirements, or the resulting state of the diagram. This is a significant gap 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 a single, concise sentence with no redundant words. It communicates the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too terse. It provides the basic action but omits context about the predefined themes, whether the operation is destructive, or how the result is reflected. For a 2-parameter tool, this might be minimally sufficient, but the lack of behavioral detail makes it incomplete.
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% (both 'diagram_id' and 'theme' are described in the schema). The description adds no extra meaning beyond what the schema already provides, so the baseline of 3 applies.
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 'Apply predefined theme to diagram' uses a specific verb ('apply') and clearly identifies the resource ('theme' to 'diagram'). It distinguishes itself from sibling tools like 'update_style' and 'manage_colors' by focusing on predefined themes rather than low-level style/color manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'update_style' or 'manage_colors'. The description only states the action without any context about scenarios, prerequisites, or exclusions.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'load from file' without explaining side effects (e.g., replacing the current diagram), error handling, supported file formats, or permissions. This is inadequate for safe and correct usage.
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 concise sentence in Chinese, '从文件加载图表', with the verb and object front-loaded. It contains no unnecessary words or repetition, earning its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is too thin. It omits critical context such as return behavior, whether loading replaces the current diagram, supported file types, and potential errors. This leaves the agent with incomplete information for a task that could have side effects.
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 provides 100% coverage with the parameter 'filename' described as '文件名' (filename). The tool description adds no extra semantics beyond what the schema already states, and since schema coverage is high, 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 states '从文件加载图表' (Load diagram from file), specifying the verb 'load' and the resource 'diagram', which clearly distinguishes it from sibling tools like save_diagram and create_diagram. It is a concise and unambiguous statement of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as save_diagram, export_diagram, or create_diagram. There is no mention of preferred scenarios, prerequisites, or exclusions, leaving the agent without selection criteria.
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 carries full responsibility for disclosing behavior. It merely states 'create timeline chart' without explaining side effects, output format, or whether this creates a new diagram or modifies an existing one. It is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the action and resource. It is very concise and easy to parse, but given the complexity of the tool, it is arguably too brief to stand alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a rich schema with many options but no output schema. The description does not explain what the tool produces, any limitations, or behavior beyond creation. For such a complex tool, the description is severely incomplete.
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 the input schema already documents all parameters and nested properties. The description adds no parameter information. Baseline of 3 is appropriate because the schema handles the semantics, but the description does not enrich it.
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 '创建时间线图表' (Create timeline chart), using a specific verb and resource. It effectively distinguishes itself from sibling tools like create_org_chart, create_flowchart, and create_mindmap by focusing on timeline creation.
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 when a timeline chart is needed, but it provides no explicit guidance on when to choose this tool over alternatives (e.g., create_flowchart) or any exclusions/prerequisites. It relies on the tool name and common sense.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely restates the tool's function as 'export diagram to specified format' without revealing what the action entails, such as whether it triggers a download, requires permissions, or returns a URL. This is a near-tautology and fails to disclose any meaningful behavioral traits beyond the name.
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 redundant or filler content. It is front-loaded with the core action and resource, and every word earns its place. This is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested options object and no output schema, yet the description provides no information about return values, how options affect the export, or any limitations. The one-line description is insufficient for an agent to understand the full behavior and expected results, especially considering the complexity of the options parameter and the absence of annotations.
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 the top-level parameters (diagram_id, format, options), and the format parameter has an explicit enum. The description adds no additional parameter semantics, but the baseline is 3 given the high schema coverage. Nested option fields (scale, width, height, transparent) lack description, but the description does not compensate for this.
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 '导出图表为指定格式' (Export diagram to specified format) clearly states the action (export) and resource (diagram), and explicitly mentions the format parameter. It is distinct from sibling tools like save_diagram, which suggests saving in the app rather than exporting to an external file.
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?
No explicit guidance is provided on when to use this tool versus alternatives. The usage is implied by the tool's name and the export action, but there is no mention of exclusions, prerequisites, or comparisons with save_diagram or other related tools. This makes the guidance minimal and mostly implicit.
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:

[![drawio-mcp MCP server](https://glama.ai/mcp/servers/Geoffrey-Fang/drawio-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Geoffrey-Fang/drawio-mcp)

Score Badge

Copy to your README.md:

[![drawio-mcp MCP server](https://glama.ai/mcp/servers/Geoffrey-Fang/drawio-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Geoffrey-Fang/drawio-mcp)

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/Geoffrey-Fang/drawio-mcp'

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