This Gmail MCP server has 6 tools with basic schemas and descriptions, but suffers from significant quality gaps. All tool descriptions are present and reasonable in length (35-95 chars, within baseline 34-392), but parameter descriptions are minimal or missing entirely. Most critically, output schemas are completely undocumented, the rubric requires documented return types for A+ tools (100% baseline). Input schemas are visible and mostly complete, but lack proper format/constraint documentation. Error handling is minimal: most functions return generic dicts without guidance for LLM recovery. Tool names are clear (verb-noun pattern), but the email-centric domain leaves composition fragmented, no batch send, no template support, and read-email lacks pagination hints. The server implements logging and prompts but relies on deprecated patterns (server-side logging) and lacks current-spec features like tool annotations, error reporting, or structured output hints.

• Add output schema documentation to every tool. Example: 'Returns: {status: string ("success"|"error"), message_id?: string, error_message?: string}'.
• Expand parameter descriptions to 50-100 chars with format/constraints. Replace 'The ID of the email to read' with 'Gmail message ID (24-char hex string, obtainable from get-unread-emails)'.
• Add pagination to get-unread-emails: add limit (1-100, default 20) and offset/page_token params. Document return structure: {messages: [{id, from, subject, date}], total_count, has_more}.
• Add tool annotations: mark read-email, get-unread-emails, open-email with readOnlyHint=true; mark send-email, trash-email, mark-email-as-read with destructiveHint=true (or false for mark-email if safe); document idempotence for mark-email-as-read.
• Enhance tool descriptions to 80-150 chars with WHEN/WHY: 'Send an email to a recipient. Use this after drafting content with the draft-email prompt. Returns message ID for tracking.'
• Add error recovery hints: 'If recipient email is invalid, the Gmail API returns 400. Verify the email format (user@domain.com).' Include enum constraints for any fixed-set parameters.
• Rename send-email parameter recipient_id → recipient_email and update description to specify email format (RFC 5322).
• For trash-email, consider adding a confirm_delete boolean param (default false) to implement confirmation-request pattern, or document that users should call read-email first to preview before trashing.
• For open-email, document that this opens the browser and may fail in headless/server environments. Consider adding error handling: 'If no browser available, return URL (https://mail.google.com/#all/{email_id}) instead of opening it.'

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

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry