Server has 4 tools with basic schemas and descriptions, but significant quality gaps. All tools have descriptions (10-30 chars, below 50-char baseline for LLM optimization). Input schemas present but minimal, only file_key and node_id parameters with basic string types. No output schemas documented. No error handling guidance, no parameter constraints (enums, ranges), no idempotency hints. Tools lack context about when to use each vs. alternatives (e.g., get_hero_section vs. get_text_blocks). No mention of API rate limits, authentication failures, or invalid node_id handling. Descriptions are too terse to guide LLM tool selection effectively.

• Expand each tool description to 80 - 150 characters. Include WHAT it does, WHEN to use it (vs. similar tools), and what structure it returns. E.g., 'Returns all text nodes (name, text, fontSize) from a Figma node. Use this to extract copy for JSX generation. Call get_page_structure first to find node IDs.'
• Document output schemas explicitly. Add a 'Returns' section to each tool docstring showing the exact structure: e.g., 'Returns: {pages: [{page: string, frames: [string]}]}'.
• Add error handling with recovery hints. Wrap API calls in try-except, catch httpx.HTTPStatusError, and return actionable messages: 'Invalid file_key. Verify the Figma file is shared with the API token.' or 'Node not found. Call get_page_structure to list available nodes.'
• Enhance parameter descriptions with format and constraints. E.g., 'file_key (string, 24 chars): Figma file ID from the URL (e.g., https://figma.com/file/ABC123/...). node_id (string): Figma node ID, found in the Figma URL or via get_page_structure.'
• Add a discovery tool or clarify tool selection. Consider a single 'get_design_data' tool that accepts a 'data_type' enum (page_structure, hero_section, text_blocks, colors) to reduce ambiguity and redundant calls.