Server has 6 tools with schemas and descriptions present, but quality is inconsistent. Tool names lack clear action verbs (e.g., 'set_tool_category' is vague about what 'set' does). Descriptions are present but generic, most lack WHEN to use guidance or prerequisites. Parameter descriptions exist but are sparse (avg ~50 chars vs baseline 72). Output schemas are documented in code but not exposed to LLM context. Error handling returns error objects but lacks recovery guidance. No tool annotations (readOnlyHint, destructiveHint). Critical gap: 'generate_object' and UI generation tools accept free-form 'schema' and 'model' parameters without validation or enum constraints, inviting hallucinated values.

• Rename 'set_tool_category' to 'activate_tool_category' or 'switch_tool_category' to clarify the action. Add description: 'Activate a tool category to control which tools are available. Use this before calling tools from a specific domain (e.g., activate figma before extract_figma_design).'
• Add enum constraint to 'model' parameter: enum: ['gpt-4o', 'gpt-3.5-turbo', 'gpt-4-turbo']. Document in description: 'LLM model to use. Only OpenAI models currently supported.'
• For 'schema' parameter in generate_object, either (a) constrain to enum of schema templates, or (b) add validation inside handler and return actionable error: 'Invalid Zod schema. Expected object with keys mapping to Zod types (e.g., {name: z.string(), age: z.number()}). See Zod docs.'
• Enhance error responses with recovery guidance. E.g., 'Figma file not found. Verify the URL is correct and your token has access. Try extract_figma_design with a different file URL.' Include retry hints for transient failures.
• Add tool annotations to all tool registrations: readOnlyHint: true for all current tools. If set_tool_category modifies state, use destructiveHint: false (it's safe to retry). Example: server.tool(name, schema, handler, {readOnlyHint: true}).