Two well-defined tools with strong schemas, detailed descriptions, and proper annotations. Both tools have comprehensive input schemas with typed parameters and clear descriptions. Tool names are action-verb based and specific. However, output schemas are not explicitly documented in the visible code, and error handling recovery guidance is minimal. The tools handle complex domain concepts (email compatibility, CSS analysis) with appropriate parameter constraints (enums for format/clients, size validation). Descriptions are detailed and appropriately scoped (194 and 242 chars respectively, within the 10-1024 baseline). Both tools properly use zod for schema validation and include tool annotations (readOnlyHint, idempotentHint, destructiveHint). The email domain requires context about clients and formats, which is well-captured in descriptions and parameter docs.

• Document the output schema explicitly in tool registration. Add a 'returns' or 'outputSchema' field showing the structure of compatibilityPayload (warningCount, findings/warnings, etc.), including field types and descriptions. This tells LLMs what to expect and prevents parsing errors.
• Add recovery hints to parameter descriptions: 'Optional client ID filter (e.g. ["gmail-web", "outlook-windows"]). Call list_clients to see valid IDs. Invalid IDs will be rejected with an error listing the correct options.'
• Register a list_clients tool that returns { clients: Array<{id: string, name: string, category?: string}> } so agents can discover available email clients without hardcoding or guessing.
• Expand format parameter description to include compilation behavior: 'Source format: "html" (default, no compilation), "jsx" (React Email), "mjml", or "maizzle". Non-HTML formats are compiled to HTML before analysis. Compilation may fail if the source is malformed, errors will indicate the syntax issue.'
• For both tools, document the 'detail' parameter interaction more explicitly: 'detail="summary" (default) returns ~10x fewer tokens by collapsing per-client warnings. Use "full" for per-client fix snippets, but expect larger responses for complex emails.'
• Add explicit limits to descriptions: preview_email should mention HTML size cap, and analyze_email should indicate expected warning counts for typical emails (e.g., 'Usually returns 5 - 50 findings for production emails, up to 500+ for heavily styled templates').