Loading ToolBench
Headless MCP server for Excalidraw scene manipulation. Exposes tools to read, create, update, delete, and export drawing elements with support for bindings, text, and arrow connections.
ExCaliber MCP provides 11 well-named tools with clear action verbs (get_, create_, update_, delete_, add_, connect_). All tools have descriptions (avg ~120 chars, within 10-1024 baseline). Input schemas are present and typed for all tools. However, parameter descriptions are sparse, many lack detail on constraints, formats, or valid ranges. Output schemas are not documented. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool composition is sound (single responsibility), but descriptions could be more LLM-optimized per the 50-200 char pattern baseline.
Add a text element at a world position or inside a container shape.
Create an arrow connecting two shapes with optional label and arrowhead styles.
Create one or more elements from Excalidraw JSON fragments. Accepts partial elements (x/y/width/height + type minimum); ids, seeds and z-order are assigned and returned as {index -> id}.
Delete elements by id. Bound arrows and container labels travel with their targets.
Export the scene to SVG, PNG, or Excalidraw JSON format. Returns bytes inline or writes to a file.
Read the current scene: element list (id, type, geometry, style, text, bindings). Filter by type or read everything.
Output schemas not documented. LLMs cannot infer what fields are returned by create_elements, update_elements, connect, or screenshot. This forces agents to guess at response structure and breaks tool chaining.
Parameter descriptions lack constraint details. 'scale' in screenshot has no min/max; 'target' in reorder accepts 'front', 'back', or element id but this is not enumerated; 'format' in export_file should be an enum (svg|png|excalidraw) not free-form string.
No error handling guidance. Tools like delete_elements and export_file have no documented error cases, recovery steps, or actionable error messages. Agents cannot distinguish retryable from fatal failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Redo the last undone mutation.
Change z-order (stacking) of an element: front (topmost), back (bottommost), or relative to another element.
Render the scene or a subset of elements to PNG. Returns base64-encoded PNG data or writes to a file.
Undo the last mutation.
Patch existing elements by id. Top-level fields merge; use for moves, resizes, style and text changes. Bumps version and updates undo history.
Destructive operations (delete_elements) lack confirmation or dry-run support. Agents can permanently delete elements without a safety gate, risking data loss.
undo/redo have minimal descriptions (60 chars). No mention of undo stack depth, whether they are idempotent, or what happens if called at stack boundaries.