Loading ToolBench
Hand-drawn input for Claude Code: a persistent canvas for sketching and annotating.
claude-draw has 4 tools with complete input schemas and detailed descriptions (avg 180 chars, well within 10-1024 range). Naming is clear and verb-forward (request_, collect_, draw_, open_). However, output schemas are not documented, responses are inferred from descriptions only. Parameters are well-described with types and constraints (e.g., wait_seconds 0-300, expires_seconds 0-21600), but no enum constraints or validation guidance. Error handling is minimal, no recovery hints or error categorization. Tool composition is sound (each does one thing), but no idempotency guarantees stated.
Pick up the answer to a request_drawing that came back "pending". Returns the drawing if it has arrived, otherwise waits a short while and says it is still being drawn. Call it when the user says they have sent something, or before you act on anything you asked them to mark up. Answers are kept, so a drawing sent while you were doing something else is never lost.
Check whether the drawing daemon is running, whether a canvas page is connected, and whether anything is waiting to be drawn or waiting to be collected. Gives the URLs to open the canvas on this machine or another device, and the pairing code another device needs.
Open the canvas page in the default browser on this machine, and report both the local and network URLs.
Ask the user to draw or annotate something. Opens on any device with the canvas page open (phone, tablet, this machine). Pass image_path to have them mark up a screenshot or image; omit it for a blank sketch. Waits a short while for the answer and then hands the turn back with outcome "pending" rather than blocking the conversation: the request stays live on the canvas, the user carries on drawing while you carry on talking, and collect_drawing picks the answer up whenever it lands. Use this whenever a visual or spatial question would be faster pointed at than described: "which element", "where should it go", "what should this look like".
Output schemas not documented. Tool descriptions infer response structure (e.g., 'returns the drawing if it has arrived'), but no formal schema for response fields, types, or error cases. LLMs cannot plan downstream operations without knowing what fields to extract.
No error handling guidance. Descriptions lack recovery hints (e.g., 'If daemon is not running, call open_canvas first'). No error categorization (retryable vs. fatal). LLMs cannot self-correct on failure.
No idempotency guarantees stated. request_drawing and collect_drawing may have side effects (creating files, advancing state), but descriptions do not clarify whether repeated calls with same input are safe. Agents may retry incorrectly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Parameter constraints lack enum or validation hints. wait_seconds and expires_seconds have numeric ranges (0-300, 0-21600) but no guidance on what happens if LLM passes invalid values. No validation error examples.
draw_status and open_canvas lack use-case clarity. Descriptions explain what they do but not WHEN an LLM should call them vs. alternatives. No dependency hints (e.g., 'Call draw_status first to check if daemon is running before request_drawing').