Affinity Gemini MCP has significant definition quality gaps. Tool names lack clear action verbs (e.g., 'tools/list', 'resources/read' are generic; 'create-isometric-artwork' mixes hyphens inconsistently). Descriptions exist but are often vague or example-heavy, violating the 'no examples in descriptions' rule. Parameters lack type information in schemas, most show only string types with no enums, ranges, or validation constraints. The 'tools/call' tool is a meta-tool that accepts arbitrary arguments, making it impossible to validate or guide LLM usage. Output schemas are not documented. Error handling is minimal, no recovery guidance or error classification. The bridge pattern (forwarding to Affinity via HTTP) obscures actual tool capabilities, making it impossible to verify schemas match reality.

• Replace tools/call with explicit tool definitions. Instead of a generic 'call any tool' endpoint, register each Affinity tool as a separate MCP tool with its own schema, description, and error handling.
• Add enum constraints to parameters. For 'category' in generate-icon-set, define: {"enum": ["finance", "weather", "media_player", "settings", ...]} instead of 'e.g. finance'.
• Document output schemas for all tools. Example: create-isometric-artwork should return {"artboardId": string, "layerCount": number, "success": boolean}.
• Standardize naming to verb_noun format (e.g., list_tools, read_resource, create_isometric_artwork). Avoid REST-style slashes and inconsistent hyphenation.
• Add error classification and recovery guidance. When a tool fails, return {"error": "Invalid theme", "valid_options": ["cyberpunk_city", "fintech_blockchain", ...], "retry": true}.