Gmail MCP server has solid tool coverage (14 tools) with consistent naming (verb_noun pattern) and complete input schemas. Descriptions are present but often generic (avg ~80 chars, below 194-char baseline). Parameter descriptions lack detail on constraints, formats, and dependencies. Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. Missing tool annotations (readOnlyHint, destructiveHint). Composition is good: tools are single-responsibility and chainable. Security: credentials handled server-side via OAuth2, but no audit logging visible.

• Document output schemas for all tools. Example: search_emails returns {messages: [{id, from, subject, snippet, date}], total_count}. Include all fields agents need for chaining.
• Add constraint details to parameter descriptions. E.g., 'max_results: integer, 1 - 100, default 20' and 'query: Gmail search syntax (see https://support.google.com/mail/answer/7190)'. Use enums for fixed sets (e.g., reply_all: true|false).
• Add tool annotations: mark search_emails, get_email, list_drafts, list_labels, find_unsubscribe_link with readOnlyHint=true; mark send_email, send_draft, trash_email, batch_trash, create_filter with destructiveHint=true; mark create_draft with idempotentHint=false (drafts are mutable).
• Add error recovery guidance. E.g., send_email: 'If recipient is invalid, the error will include the invalid address. Verify the email format and retry.' batch_trash: 'If some messages fail, the response includes per-message status. Retry failed IDs separately.'
• Add confirmation/dry-run to send_email, send_draft, create_filter. E.g., send_email: 'To preview without sending, use create_draft first.' Or add a confirm_send parameter (default false) that returns a confirmation token requiring a second call.

Inferred effective spec: <=2025-11-25.

• Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)