The Canvas MCP server defines 7 tools with explicit schemas and descriptions visible in src/canvas_mcp/server.py. Tool names follow verb_noun convention (canvas_create, canvas_update, canvas_list, etc.), which is correct. However, there are significant quality gaps: (1) Parameter descriptions are minimal or missing, canvas_update's 'components' array items lack detailed field documentation beyond brief property names; canvas_data's 'value' parameter has no description at all (only 'description: "Value to set at the path"' is generic). (2) Output schemas are entirely undocumented, tools do not declare what they return, forcing LLMs to guess at response structure. (3) Error handling descriptions are absent, no recovery guidance for common failures (e.g., 'surface_id not found'). (4) Some descriptions are instructional but lack clarity on return structure (e.g., canvas_show says 'Returns surface info, then you MUST call atv_cast_url' but atv_cast_url is not a registered tool in this server, creating a broken chain). (5) Tool descriptions are reasonable length (50 - 200 chars) and explain WHEN to use tools (good), but lack WHAT fields are returned and HOW the LLM should proceed. Per-tool analysis below shows most tools score 50 - 65 due to schema and error-handling gaps.

• Add complete output schema documentation to all tools. Example: 'canvas_create returns { surface_id: string, device_id: string, created_at: ISO8601_string, url: string }'. This enables LLM planning.
• Document all A2UI component properties in canvas_update. Replace generic 'items' schema with explicit field documentation: id (string, unique identifier), component (enum: 'view', 'text', 'button', ...), children (array of component ids), text (string, label or content), style (object with keys: color, size, position, etc.).
• Add description to canvas_data 'value' parameter. Specify format: 'The value to set at the JSON Pointer path. Can be string, number, boolean, object, or array. For nested paths like /user/address/city, structure must match the target location.'
• Document error scenarios for each tool with actionable recovery steps. Example for canvas_show: 'If surface_id not found, call canvas_list first to retrieve valid surface IDs.' For canvas_close: 'This is destructive and cannot be undone. Consider archiving instead if supported.'
• Resolve tool-chain dependency: either expose atv_cast_url as a tool in this server, or remove the reference from canvas_show and document the expected downstream process outside the tool.
• Add pagination support to canvas_list (if results can be large). Include limit, offset/cursor parameters and return total_count so LLMs can fetch in batches.
• Consider adding idempotentHint and destructiveHint tool annotations (spec 2026-07-28 feature) to clarify which operations are safe to retry (canvas_create, canvas_update) vs destructive (canvas_close).

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry