Loading ToolBench
Gmail MCP server for managing emails, labels, and Gmail operations through the Model Context Protocol
Gmail MCP server has 10 tools with complete input schemas and descriptions, but quality is inconsistent. All tools have descriptions (10-50 chars, mostly short), and schemas are present with typed parameters. However, descriptions lack actionable context for LLM selection, they state WHAT but not WHEN or WHY. No output schemas documented. Error handling is absent from tool definitions. Destructive operations (delete_email, delete_label) lack confirmation patterns. Parameter descriptions are minimal (e.g., 'ID of the email message to delete' for delete_email). No guidance on dependencies or prerequisites. Naming is clear and verb-first, but some tools conflate concerns (modify_email handles both add and remove label operations via separate params, creating ambiguity).
Creates a new Gmail label
Delete an email message permanently
Deletes a Gmail label
Gets an existing label by name or creates it if it doesn't exist
Retrieves all available Gmail labels
Modify email labels by adding or removing label IDs from a message
Retrieve and read a specific email message by ID
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., messageId from send_email, labelId from create_label). Responses are unstructured.
Destructive operations (delete_email, delete_label) lack confirmation or dry-run patterns. Agents can permanently delete without safeguards, risking data loss.
Tool descriptions are too brief (10-50 chars) and lack actionable context. They state WHAT but not WHEN to use or prerequisites. E.g., 'Retrieve and read a specific email message by ID' does not explain when to call read_email vs search_emails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Search for emails using Gmail search query syntax
Send an email message with optional CC, BCC, and thread reply support
Updates an existing Gmail label
modify_email conflates add and remove operations via separate parameters (addLabelIds, removeLabelIds, labelIds). Ambiguous which takes precedence; LLMs may pass conflicting params. Should split into add_label and remove_label tools.
No error handling guidance in tool definitions. LLMs cannot determine if errors are retryable, user-fixable, or fatal. No recovery hints (e.g., 'If email not found, try search_emails first').