Stitch MCP has well-structured tool definitions with consistent naming (verb_noun pattern), complete input schemas using Zod, and descriptions for all tools and parameters. However, descriptions are often generic and lack actionable context for LLM selection. Output schemas are not documented, responses are inferred from code but not formally specified. Error handling returns basic messages without recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Parameter descriptions lack format constraints and dependency hints. Average tool description ~120 chars (below 194 baseline); parameter descriptions average ~60 chars (below 72 baseline).

• Add formal output schemas to all tools. Document return type as JSON with typed fields (e.g., {screen_id: string, project_id: string, status: 'success'|'pending'}).
• Integrate tool annotations: mark create_project, generate_screen, edit_screen, generate_variants, generate_and_fetch_code, scaffold_project_files with destructiveHint=true; mark list_projects, get_screen_code, get_screen_image with readOnlyHint=true.
• Enhance error messages with recovery guidance. E.g., 'Error generating screen: Invalid project ID. Call list_projects() to see available projects.' Categorize errors as retryable (network timeout) vs user-fixable (invalid projectId) vs fatal (quota exceeded).
• Expand tool descriptions to 150-250 chars. Include WHEN to use (e.g., 'Use this to create a new design from scratch; use edit_screen to modify an existing design'), prerequisites, and what the LLM should do next with the returned IDs.
• Add format constraints to parameter descriptions. E.g., 'filePath: Absolute or relative path (e.g., src/components/MyComponent.html). Must end in .html. No path traversal (../) allowed.'