Gmail MCP server has 15 tools with complete input schemas and descriptions, but quality is inconsistent. Tool names follow verb_noun convention (send_email, read_email, delete_email). Descriptions are present but generic, most are 20-50 chars, below the 50-200 char baseline for LLM optimization. Parameter descriptions exist but lack actionable constraints (e.g., no format specs, no enum values for visibility fields). Output schemas are not documented. Error handling is absent from visible code. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Composition is reasonable, tools are single-purpose, but some parameter relationships are undocumented (e.g., labelIds vs addLabelIds vs removeLabelIds in modify_email).

• Expand all descriptions to 50-200 chars. Include WHAT the tool does, WHEN to use it, and any prerequisites. E.g., 'Modify email labels and properties' → 'Add or remove labels from an email message. Use this to organize, archive, or mark emails. Requires a valid messageId.'
• Document output schemas for all tools. For search_emails, specify: returns array of {messageId, from, to, subject, snippet, date}. For list_labels, specify: returns array of {id, name, messageListVisibility, labelListVisibility}.
• Add enum constraints to visibility parameters. E.g., messageListVisibility: enum ['show', 'hide'] with description 'Whether the label appears in the message list view.'
• Add tool annotations. Mark delete_email, delete_label, delete_filter with destructiveHint=true. Mark read_email, search_emails, list_labels with readOnlyHint=true. Mark send_email with idempotentHint=false (not idempotent).
• Document parameter relationships in modify_email: 'labelIds replaces all labels; addLabelIds and removeLabelIds modify existing labels. Do not combine labelIds with add/removeLabelIds.'