Loading ToolBench
MCP server for Gmail integration, enabling email management, sending, searching, and label manipulation through Claude
This server has 12 well-defined tools with complete JSON schemas and consistent descriptions. However, several critical issues prevent a higher score: (1) Output schemas are completely undocumented, no response structure definitions are visible in the code, only input schemas; (2) Error handling lacks recovery guidance (no pattern:recovery-guide implementation); (3) Tool descriptions are functional but generic, averaging ~120 chars, below the ideal 150 - 250 char range for LLM optimization; (4) No pagination support documented despite tools returning potentially large lists (gmail_list_messages, gmail_search_messages); (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite the tool definitions including risk metadata; (6) Parameter descriptions are adequate but lack constraint details (e.g., maxResults lacks min/max bounds, format enum values not fully specified). Strengths: all 12 tools have names starting with action verbs, all required parameters are marked, input schemas are structurally sound with type definitions, and no sensitive credentials exposed as parameters.
Create a draft email without sending it.
Delete or trash a message.
Get a specific attachment and save it to the user's Desktop.
Get the full content of a specific message by ID.
Get a specific thread by ID.
List all labels in the user's mailbox.
List messages in the user's mailbox with optional query. Supports filtering by query (q) and including spam/trash.
Output schemas are completely undocumented. The code registers tools with inputSchema but contains no documented return types, field structures, or response documentation for any of the 12 tools. LLMs cannot plan downstream calls or extract data when they don't know what fields to expect.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite the evaluation metadata marking tools as READ_ONLY, WRITE, and DESTRUCTIVE. The server exposes risk context but does not communicate it to the MCP client via annotations. This prevents clients from implementing safety policies.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
List starred messages in the user's mailbox.
Modify the labels on a message.
Search messages using Gmail's query format.
Send an email to a recipient.
Star a message by adding the STARRED label.
Pagination not documented or supported. gmail_list_messages and gmail_search_messages accept maxResults but do not advertise cursor-based pagination, offset, or next-page tokens. The code does not show pagination implementation, risking context window exhaustion if a user has many matching messages.
Error handling lacks recovery guidance (pattern:recovery-guide). The implementation does not show error responses that guide the LLM on what to do next. For example, if gmail_get_message fails with 'Message not found', the response should suggest calling gmail_search_messages to locate it.
Parameter constraints missing. maxResults in gmail_list_messages has no min/max bounds (should be 1 - 500 or similar per Gmail API). format in gmail_get_message lists values as 'full, minimal, raw, metadata' in description but not as an enum constraint. Descriptions should specify ranges and enums formally.
Descriptions are generic and below the LLM-optimized target length (150 - 250 chars). Average description length is ~120 characters. For example, 'List messages in the user's mailbox with optional query...' (90 chars) lacks guidance on when to use this vs gmail_search_messages, what it returns, or common query patterns.
No confirmation step for destructive operations. gmail_delete_message with permanent=true permanently deletes data. The pattern:confirmation-request pattern recommends a dry-run or confirmation step to prevent agent mistakes, but none is visible in the code.