Server has 37 tools with significant quality gaps. Most tools lack input parameter schemas (only 2 of 37 have visible schemas: get_node_info and get_nodes_info). Descriptions are present but generic (avg ~50 chars, well below 194-char baseline). No output schemas documented. Parameter descriptions missing entirely for most tools. Error handling is minimal, tools return raw JSON or generic error strings without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Composition is reasonable (verb_noun naming, single responsibility), but schema and parameter documentation are critically deficient.

• Add explicit input schemas to all 35 tools missing them. Use Zod (already imported) to define parameter types, descriptions, and constraints. Example: server.tool('set_fill_color', '...', z.object({ nodeId: z.string().describe('Node ID'), color: z.string().regex(/^#[0-9A-F]{6}$/).describe('Hex color code') }), ...)
• Expand tool descriptions to 100-200 characters. Include WHAT the tool does, WHEN to use it, and what it returns. Example: 'Set the fill color of a node. Use after selecting a node or when you have its ID. Returns the updated node with new fill properties.' Current: 'Set the fill color of a node in Figma' (35 chars).
• Add tool annotations via the MCP SDK. Mark read-only tools with readOnlyHint: true, destructive tools with destructiveHint: true, and idempotent tools with idempotentHint: true. This enables LLMs to reason about retry safety and side effects.
• Document output schemas in tool descriptions or via a separate schema registry. Specify which fields are returned (e.g., 'Returns: { nodeId, name, type, x, y, width, height, fill, stroke }') so LLMs know what to extract for downstream calls.
• Enhance error handling: catch specific error types, return actionable messages with recovery hints (e.g., 'Node not found. Try scan_nodes_by_types() to find available nodes.'), and categorize errors as retryable or fatal.