Loading ToolBench
Gmail MCP server for Bun and Cloudflare Workers with OAuth2 support and streamable HTTP transport
This server demonstrates solid definition quality with consistent naming patterns, mostly complete parameter schemas, and reasonable descriptions. All 10 tools follow verb_noun conventions (get_*, list_*, search_*, create_*, update_*, send_*). Schemas are well-structured with type definitions, descriptions, and constraints (min/max items, enums for format). However, descriptions vary in depth and some parameter docs could be more prescriptive. Output schemas are not explicitly documented in the source code provided. Error handling guidance is minimal. The server supports batch operations (modify_thread, search_threads pagination) and includes natural identifiers (email addresses) alongside IDs. No secrets in parameters. Tool compositions are logical and support chaining (search_threads returns threadId for get_thread, get_thread returns messageId for get_message).
Create a draft. For replies: ALWAYS include threadId (from search_threads) to keep draft in conversation. Use email addresses from search results, not guesses. Requires at least one recipient (to/cc/bcc).
Fetch a single message by id. Use format to control headers/body and return a web link when available.
Get the connected Gmail account email. Returns only the email address for identity confirmation.
Fetch a thread by id with ordered messages and a thread web link. Use format to control bodies, and message ids for get_message.
Get inbox stats + highlights for a time range (default: 7 days). Returns counts (unread, inbox, sent, starred, important) plus previews of recent unread and starred threads.
Output schemas not documented in source code. LLMs cannot infer response structure or plan downstream tool calls without explicit documentation of return types and field names.
Parameter descriptions lack prescriptive guidance on valid formats and constraints. For example, 'query' in search_threads shows examples but doesn't explain that the field accepts Gmail search syntax. 'format' enum is documented but 'metadataHeaders' lacks guidance on which headers are valid.
modify_thread tool description is vague about which actions are mutually exclusive. It says 'archive, star, markRead, trash, or raw label IDs' using 'or' but the schema shows all are optional, suggesting they can combine. This ambiguity could lead to unexpected behavior.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | 1.25.3+ | v1 |
List Gmail labels with ids, names, types, and counts. Use label ids with search_threads and other filters.
Batch add/remove labels on threads (up to 100). Actions: archive, star, markRead, trash, or raw label IDs.
Search threads by Gmail query and/or labelIds. Results ordered by newest MESSAGE (not thread creation). For latest email: use limit=1 with no query. Returns subject, sender, Date header, internalDate, labelIds + label names, message count, unread status, and web links. Use get_thread to read full message bodies.
Send a draft by draftId. Optionally replace contents before sending. Returns sent message metadata.
Replace a draft message by draftId. Accepts raw or structured fields and returns updated draft metadata.
Error handling and recovery guidance is not visible in the source code. Tools lack explicit error categorization (retryable vs user-fixable vs fatal) and recovery hints. For example, search_threads might fail if labelIds don't exist, but there's no guidance on how to recover.
Draft creation and sending tools (create_draft, update_draft, send_draft) lack confirmation or dry-run capability. These are irreversible operations but no pre-execution validation or confirmation pattern is documented. Agents could accidentally send emails.