Loading ToolBench
Email search and management tool using MCP protocol
This Gmail MCP server has well-structured tool definitions with complete JSON schemas and reasonable descriptions, but falls short of production-grade quality in several areas. All 13 tools are explicitly registered with proper inputSchema objects including types and required fields. Descriptions are present for all tools (average ~120 chars) and most parameters. However, there are critical gaps: (1) output schemas are completely undocumented, LLMs cannot plan downstream calls or extract structured data; (2) no error handling guidance, tools return failures silently without recovery steps; (3) weak composition guidance, several write operations lack confirmation/dry-run patterns that would prevent accidental data loss; (4) some parameter descriptions are sparse or lack constraints; (5) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) to signal operation severity. The tool naming is generally strong (verb_noun pattern, clear distinctions), but the schema and output documentation lag significantly behind production expectations. This server would benefit from: explicit output schemas for all tools, error recovery guidance, confirmation steps for destructive operations, and tool-level annotations.
Apply a label to an email
Apply a label to multiple emails using their sequence IDs (from search results)
Count emails received for each day in a date range
Create a new Gmail label/folder
Delete a Gmail label/folder entirely. Cannot delete system labels.
Forward an email with its attachments to new recipients. Required fields: email_id and recipients (to). Optional: subject_prefix, additional_message, and CC recipients.
No output schemas documented for any tool. LLMs cannot predict what fields will be returned, making downstream tool composition impossible and forcing agents to guess at response structure.
Missing error handling guidance and recovery instructions. Tools provide no direction on retryability, user fixability, or next steps when operations fail (e.g., 'email not found', 'invalid recipient', 'label already exists').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Get the full content of a specific email by its ID
List all available Gmail labels/folders
Move an email to a specific folder/label
Remove a label from an email
Rename an existing Gmail label/folder. Cannot rename system labels.
Search emails within a date range and/or with specific keywords
CONFIRMATION STEP: Actually send the email after user confirms the details. Before calling this, first show the email details to the user for confirmation. Required fields: recipients (to), subject, and content. Optional: CC recipients.
Destructive operations (delete-label, send-email, forward-email) lack confirmation/dry-run patterns. No dry-run mode, no confirmation step, no undo mechanism. Agents cannot safely preview consequences before irreversible actions.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe read operations from dangerous writes without explicit hints, leading to unsafe planning and over-cautious retry strategies.
Parameter descriptions for label-manipulation tools are sparse (typically 1-2 sentences with no constraints, format hints, or dependency documentation). E.g., 'Name of the label to create' lacks guidance on valid characters, length, uniqueness, or reserved names.
Missing pagination guidance and result limits. search-emails has a limit default (20) but no documentation on the field names or structure of returned results, and no next_cursor/offset patterns for large result sets.
send-email description includes 'CONFIRMATION STEP' as a placeholder warning rather than implementing a proper confirmation or dry-run tool. This shifts responsibility to the LLM to remember to ask the user, which is error-prone.