Loading ToolBench
MCP server for draw.io diagram manipulation with SVG feedback
This server defines 4 tools with reasonable descriptions and mostly complete schemas. Naming follows the verb_noun pattern (render_, export_, modify_, get_). Descriptions are present and actionable (75-200 chars, within the 10-1024 baseline). However, several issues limit the score: (1) parameter descriptions are often generic (e.g., 'Unique identifier for this node' repeats across tools without explaining the semantic meaning); (2) error handling is minimal, timeout is the only explicit case, with a generic fallback message; (3) no output schema documentation beyond inline comments; (4) no confirmation step for destructive operations (render_subgraph with clear_first=true, modify_subgraph with remove operations); (5) no rate limiting or context-window guidance for large diagrams. The schemas are well-formed (JSON Schema with types, enums, required fields) and registration is explicit via server.tool(), but the implementation lacks production-grade error guidance and output structure documentation.
Export the current draw.io diagram as SVG. Use 'svg_image' format to get a base64-encoded image that vision LLMs can render, or 'svg_text' to get the raw SVG XML as text for programmatic analysis.
Retrieve the current state of the draw.io diagram as a JSON object listing all nodes (with id, label, style, geometry) and edges (with id, source, target, label, style).
Make incremental changes to the existing diagram: add nodes, remove nodes, add edges, remove edges, or update existing node labels/styles. Optionally re-run a layout algorithm after changes and return the updated SVG.
Render a complete subgraph on the draw.io canvas with auto-sizing and auto-layout. Provide nodes and edges; the extension creates shapes, connects them, applies a layout algorithm, and optionally returns the result as an SVG image for visual verification.
No explicit error handling or recovery guidance. Tools return generic timeout messages; no categorization of retryable vs fatal errors, no actionable next steps for LLMs.
No confirmation step or dry-run mode for destructive operations. render_subgraph(clear_first=true) and modify_subgraph(remove_node_ids) can permanently destroy diagrams without user confirmation.
Output schemas not documented. No explicit description of return structure for export_diagram (is base64 image valid SVG? what encoding?) or get_diagram_state (what fields in the geometry object?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions are generic and repetitive. 'Unique identifier for this node' appears verbatim for node.id across render_subgraph and modify_subgraph; no explanation of ID format, constraints, or collision avoidance.
No guidance on result limits or context-window impact. Large diagrams with hundreds of nodes/edges could generate massive SVG strings or JSON responses; no pagination or chunking strategy documented.
modify_subgraph description says 'Make incremental changes' but does not clarify idempotency. If an add_node with the same ID is sent twice, does the second call fail, overwrite, or no-op? This ambiguity can cause silent data loss.
No tool composition guidance. The tools are designed for a draw.io extension, but no documentation of expected workflow: do agents call get_diagram_state first, then render_subgraph? Or render directly? The right order is not obvious.