Loading ToolBench
MCP server for generating draw.io diagrams using mxgraph. Create and manage diagrams programmatically with VSCode compatibility.
Server provides 6 tools with explicit schemas and descriptions. Naming follows verb_noun convention well (new_diagram, add_nodes, link_nodes, get_diagram_info, edit_nodes, remove_nodes). All tools have descriptions between 34-89 characters, meeting the 10-1024 baseline. All parameters have type definitions and descriptions. However, critical issues reduce the score: (1) descriptions are brief and lack WHEN/WHY context that LLMs need for tool selection, (2) output schemas are not documented, tools return generic success messages without specifying what fields/structure agents should expect, (3) error handling lacks recovery guidance, McpError is thrown but responses don't suggest next steps, (4) some parameter descriptions could be more prescriptive about constraints, (5) remove_nodes tool has no dry-run or confirmation pattern despite being destructive. Tool composition is good: separate tools for each operation (create, add, link, edit, remove, inspect). Parameter naming is consistent (file_path is used across all tools). Schemas are well-formed JSON Schema with enum constraints and required fields declared properly.
Add one or more nodes to a diagram file. Optionally run an automatic layout after insertion.
Edit one or more nodes or edges in a diagram file
Get xml representation of a diagram file
Create one or more connections between nodes in a diagram file
Create a new empty diagram file
Remove nodes or edges from a diagram file
Output schemas not documented. Tools return only generic success messages ('Nodes added to {file_path}') without specifying structured response fields or types. LLMs cannot plan downstream calls or extract result IDs.
Descriptions lack WHEN/WHY context. Descriptions like 'Create a new empty diagram file' and 'Add one or more nodes to a diagram file' state WHAT but not WHY to use this tool vs related operations, when to call it, or what it returns. LLMs struggle to select between similar tools without this context.
Error handling lacks recovery guidance. McpError is thrown with InvalidParams codes, but responses don't suggest what the LLM should try next (e.g., 'file_path must be an absolute or relative path ending in .drawio.svg, check that the directory exists').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Destructive operations (remove_nodes) lack confirmation or dry-run support. Agents can delete diagram nodes without a confirmation step, risking irreversible data loss.
get_diagram_info description is vague. It says 'Get xml representation of a diagram file' but doesn't explain WHEN to use this (e.g., 'Call this to inspect node IDs, layout, or connections before editing'). The term 'xml representation' is also technical jargon that could confuse LLMs about what data they'll receive.
Parameter descriptions in add_nodes/edit_nodes could specify format constraints more explicitly. 'Absolute or relative path' is clear, but 'kind' enum values lack descriptions, it's not obvious what 'Actor' or 'Step' shapes look like or when to use them.
Layout options are underdocumented. add_nodes accepts layout.options as 'Algorithm-specific options (e.g., { direction: "top-down" | "left-right" } for hierarchical)', this inline example may be reused literally. Should use explicit schema or enum constraints per algorithm.