Loading ToolBench
Provides Draw.io services to MCP Clients, enabling diagram creation, manipulation, and export through the Model Context Protocol
This server defines 29 diagram editing tools with consistent schemas and basic descriptions. All tools are explicitly registered in tool-registry.ts with JSON Schema input validation. However, descriptions are brief and often lack context about WHEN to use a tool or WHAT it returns. Many parameters lack detailed constraints (enums, min/max). Output schemas are not documented. Error handling guidance is absent. The codebase shows solid engineering (TypeScript, modular plugin architecture), but the tool definitions fall short of production-grade LLM optimization.
Add a cell with a specific shape from the shape library
Add an edge (connector) between two cells
Add a new rectangle shape to the diagram
Copy an existing page
Create a new layer on the target page
Create a new page in the document
Delete a cell by its ID
Descriptions lack WHEN/WHY context and output structure. Most descriptions are 30-55 characters with no guidance on what the tool returns, when to call it instead of similar tools, or prerequisites. Examples: 'Set the active layer on the target page' tells LLM the action but not what data is returned or when this differs from move_cell_to_layer.
Parameter descriptions are generic or missing context. Parameters like 'style' (Cell style string) offer no guidance on valid values, format, or examples. 'target_page' (Target page selector) does not explain whether to pass index or ID.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Edit a cell's properties
Edit an edge's properties
Export the diagram in various formats (SVG, PNG, XML)
Get the currently active layer on the target page
Get information about the currently active page
Get the currently selected cell on the target page
Get a specific shape by name
Get available shape categories from the shape library
Get shapes available in a specific category
Import a diagram from SVG, PNG, or XML format
Import a Mermaid diagram and convert it to Draw.io format
List all layers on the target page
List cells in the diagram with pagination and filtering
List all pages in the active document
Move a cell to a different layer
Rename an existing page
Save the current document
Set the active layer on the target page
Set custom data on a cell
Change a cell's parent container
Change the shape of a cell
Set the title of the current document
Output schemas are not documented. The JSON schema shows INPUT shapes (parameters) but no explicit OUTPUT schema. LLMs need to know what fields to expect in responses to plan downstream calls and extract data correctly. Example: does get-selected-cell return {cell_id, x, y, width, height, text}? Unknown.
Destructive operations lack error handling guidance. delete-cell-by-id, save-document, and import-diagram (with mode='replace') can destroy data. No descriptions mention dry-run, confirmation, or recovery paths.
'target_page' parameter is overloaded and underdefined. Appears in 20+ tools as {type: 'object', description: 'Target page selector (index or id)'}. LLM does not know whether to pass {index: 0}, {id: 'page-1'}, or a string. This forces trial-and-error.
Lack of enum constraints for free-form string parameters. 'style' in add-rectangle, set-cell-shape, edit-cell, etc. accept arbitrary strings with no documented valid values. 'format' in export-diagram correctly uses enum ['svg', 'png', 'xml'], this pattern should apply to 'style', 'mode', 'size' throughout.
No documentation of parameter dependencies. 'points' array in add-edge and edit-edge is only relevant for connector lines, not rectangles. 'selection_only' in export-diagram requires a selection to exist first. Undocumented dependencies cause silent failures.
No pagination guidance in list_* tools. list-paged-model accepts page and page_size but does not document valid ranges (page ≥ 1?, page_size max?), what 'total' or 'next_cursor' is returned, or whether results are ordered.
Response structure not specified for tools returning data. 'get-shape-by-name', 'get-shape-categories', 'get-shapes-in-category' have no documented return format. Does get-shape-by-name return a single object or array? Does it include metadata, SVG data, or just the name? LLMs cannot compose downstream calls without knowing response fields.