excalidrawer provides 2 core tools with visible schemas and descriptions. However, several critical gaps limit production readiness. Tool names lack clear action verbs (render_diagram, compute_layout are acceptable but generic). Descriptions exist but are terse (30-50 chars, below the 50-200 char LLM-optimized baseline). Parameter descriptions are sparse or missing type guidance. Input schemas are present but lack detailed constraints, ranges, and enum documentation. No documented output schema structure. No error handling guidance or recovery paths. The code structure is clean (tool registry in tools/index.mjs, explicit schema definitions), but the schemas themselves are minimal. STDIO transport caps protocol readiness at 50, and tool definitions lack the richness needed for confident LLM reasoning.
Tools (2)
compute_layoutread onlysource verified42/100
Compute coordinates from a layout helper (gridLayout, chain, swimlane, hubSpoke, etc.)
render_diagramwritesource verified47/100
Render raw Excalidraw elements to files (excalidraw, svg, png formats)
Tool names lack specific action verbs. 'render_diagram' and 'compute_layout' are generic and don't clarify the action taken. Pattern:tool requires verb_noun naming (export_diagram, calculate_coordinates, arrange_elements) so LLMs can infer intent from the name alone.
Descriptions are terse (30-95 chars), well below the LLM-optimized baseline of 50-200 chars. They lack WHEN to use the tool, prerequisites, and expected outcomes. Examples: render_diagram omits that this is a write operation; compute_layout omits what coordinate format is returned.
Parameters lack enum constraints and detailed descriptions. (1) render_diagram.formats should be an enum ['excalidraw', 'svg', 'png'] not a free-form array. (2) compute_layout.helper should be an enum of valid helpers (gridLayout, chain, swimlane, etc.), not a free-form string. Free-form strings invite hallucinated values.
render_diagramcompute_layout
Recommendations
Rename tools to use more specific action verbs: 'render_diagram' → 'export_diagram' (clarifies output format), 'compute_layout' → 'calculate_layout_coordinates' or 'arrange_elements_in_layout'.
Expand tool descriptions to 100-150 chars each. For render_diagram: 'Export Excalidraw diagram elements to files (excalidraw, svg, or png). Use this after building a diagram programmatically to save it to disk. Specify formats as a comma-separated list or omit for all formats.' For compute_layout: 'Calculate x/y coordinates for diagram elements using a layout algorithm (gridLayout, chain, swimlane, etc.). Returns coordinate objects ready to pass to render_diagram. Call after defining elements to auto-arrange them.'
Output schemas are not documented. LLMs need to know what fields and types to expect from each tool so they can plan downstream calls. (1) render_diagram: does it return {success: bool, path: string} or just the path? (2) compute_layout: does it return {x, y, width, height} objects? An array? A nested structure? No schema means LLMs must guess.
Parameter descriptions lack type guidance and constraints. Examples: (1) scale parameter described as 'PNG pixel scale 1-4 (default: 2)', range is in description, not in schema minumum/maximum. (2) args parameter described as 'Arguments object for the layout helper function', vague; should explain per-helper expected properties. (3) elements parameter lacks itemSchema, LLM cannot infer valid Excalidraw element structure.
No error handling or recovery guidance. If render_diagram fails (e.g. invalid element, unsupported format), what should the LLM do next? No guidance. If compute_layout gets an invalid helper name, should it retry, check available helpers, or ask the user? Silent failure risk.
render_diagram is a write operation (creates files) but the tool definition does not declare this. No mention of idempotency, side effects, or destructiveness. LLMs need to know: can this be retried safely? What happens if called twice with the same args? Should it overwrite or error?
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). compute_layout is read-only but this is not declared. render_diagram is destructive (overwrites files) but not annotated. Annotations help LLMs plan safely and reason about side effects.
render_diagramcompute_layout
Add error handling descriptions: 'On error (invalid format, write failed), returns {success: false, error: 'user-friendly message'}. Common errors: path not writable, format not recognized, elements invalid. Retry with corrected input.'
Declare tool mutations and idempotency. For render_diagram: 'This tool writes files to disk. If the output path exists, it will overwrite. Idempotent: calling twice with the same input produces the same output.' For compute_layout: 'This tool does not modify state. It returns coordinates based on input; repeated calls with identical input always return identical results.'
Add toolAnnotations to the tool definitions: render_diagram → {destructiveHint: true, idempotentHint: true}, compute_layout → {readOnlyHint: true}. This enables LLMs to reason about side effects.
Add parameter validation rules in descriptions. For output: 'Must be a valid file path (relative or absolute) without extension; the tool appends .excalidraw, .svg, or .png based on formats.' For elements: 'Array of Excalidraw element objects; see https://github.com/excalidraw/excalidraw/blob/main/types.ts for the element schema.'
Link to external documentation for complex parameters. For compute_layout.args, reference: 'Full options per layout helper are documented in src/layout.mjs. Common patterns: {rows: number, cols: number, gap: number} for gridLayout; {spacing: number, vertical?: boolean} for chain.'