A powerful Gmail MCP server for AI agents — search, read, send, organize emails via Claude Desktop, Claude Code, Cursor, and more.
Gmail MCP server has 22 well-named tools with consistent verb_noun patterns (search_emails, get_email, send_email, etc.). All tools have descriptions (avg ~120 chars, within baseline 34-392 range). Input schemas are present and mostly complete with type definitions and parameter descriptions. However, several critical gaps reduce the score: (1) Output schemas are NOT documented, no response structure definitions visible in tool registrations; (2) Parameter descriptions lack actionable constraints (e.g., 'query' param in search_emails has no format guidance, 'maxResults' lacks rationale); (3) Error handling is minimal, no recovery guidance, no categorization of retryable vs fatal errors; (4) Some parameters accept 'string or array' without formal union types (send_email 'to' field); (5) No dry-run or confirmation pattern for destructive operations (delete_label, trash_email); (6) Batch operations lack per-item success/failure reporting. Naming is strong (90/100), descriptions adequate (70/100), schemas incomplete (55/100).
Search emails with multiple criteria and optionally apply a bulk action to all matching results. Useful for inbox cleanup, bulk labeling, or archiving by rule.
Apply the same label modifications to multiple emails at once (up to 1000 IDs).
Move multiple emails to Trash at once by adding the TRASH label and removing INBOX.
Create a draft email (not sent). Optionally attach it to an existing thread for a draft reply.
Create a new Gmail label (folder).
Delete a user-created Gmail label. System labels (INBOX, SENT, etc.) cannot be deleted.
Output schemas not documented. No response structure definitions visible for any tool. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns.
Parameter descriptions lack actionable constraints. 'query' in search_emails has no format guidance (Gmail syntax not explained). 'maxResults' lacks rationale for defaults. 'to' in send_email accepts 'string or array' without formal union type definition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Extract unique email addresses from messages matching a Gmail query. Useful for building contact lists.
Re-format and filter a list of email objects (previously fetched) into a custom structure. Supports field selection, filtering by field value, and sorting.
Forward an existing email to new recipients, optionally adding a note above the original message.
Download an email attachment by message ID and attachment ID. Returns base64-encoded content with metadata. Use get_email first to find attachment IDs.
Get the full content of an email by its ID, including body text and attachment info.
Analyze recent sent emails to find your most frequently contacted email addresses. No extra API scope needed.
Get the authenticated user's Gmail profile: email address, total messages, total threads, and history ID.
Get all messages in an email thread by thread ID.
List all Gmail labels (system and user-created), including their IDs needed for modify operations.
Mark one or more emails as spam (moves to Spam folder).
Modify a single email: add/remove labels, mark as read/unread, archive, or move to trash.
Reply to an existing email. Automatically sets In-Reply-To and References headers and keeps the thread.
Search Gmail using Gmail query syntax (e.g. 'from:[email protected]', 'is:unread', 'subject:invoice'). Returns message summaries.
Compose and send a new email.
Move an email to Trash (recoverable for 30 days).
Restore an email from Trash back to the inbox.
No error handling guidance. Tools lack recovery hints (e.g., 'User not found. Try search_users() first.'). No categorization of retryable vs fatal errors. Batch operations (batch_modify_emails, batch_trash_emails) do not specify per-item success/failure reporting.
Destructive operations lack confirmation/dry-run pattern. delete_label, trash_email, and advanced_filter (with action='trash') can permanently remove data without a confirmation step or dry-run option to prevent accidental agent errors.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). MCP spec supports tool annotations to signal operation safety; none are declared. Agents cannot infer which tools are safe to retry or which modify state.