Loading ToolBench
MCP server for Gmail integration via Chrome extension, enabling Claude to read, search, compose, and manage emails
This Gmail MCP server has mixed definition quality. Naming is generally verb-forward and clear (list_emails, read_email, send_email, etc.), following conventions. Descriptions are present for all 17 tools and most are adequate (50-150 chars), though some lack actionable guidance on when to use them vs. alternatives. Input schemas are visible and mostly well-formed with required fields and type declarations. However, several critical gaps emerge: (1) Most parameter descriptions lack constraint details (format, range, enums). (2) Output schemas are NOT documented anywhere in the provided code, critical for tools like search_emails, get_email_attachments, which return complex data structures. (3) Error handling is minimal, no actionable recovery guidance in tool descriptions. (4) Dangerous operations (send_email, reply_email, delete_emails) have confirmation parameters but descriptions don't guide LLMs on *how* to ask users for confirmation. (5) Some tools lack descriptions of their return structure or what fields the agent should expect. The server handles a sensitive domain (Gmail) well in terms of irreversible operation warnings, but lacks production-grade polish on output documentation and error guidance.
Archive email(s)
Delete email(s)
Download an email attachment
Create a draft email to show user before sending. This is safe to use without confirmation.
Create a draft reply to show user before sending. This is safe to use without confirmation.
Get the currently active Gmail account
Get list of attachments in an email
Output schemas not documented. Tools like search_emails, read_email, get_email_attachments return complex structures (email objects, attachment lists, etc.) but the response schema is not defined anywhere in source code. LLMs cannot plan downstream calls without knowing what fields to expect.
Parameter descriptions lack constraint details. For example, search_emails accepts 'options' with nested properties (dateFrom, dateTo, limit) but descriptions lack format specs (date format is YYYY-MM-DD but this is stated in the outer description, not in dateFrom/dateTo param descriptions). The 'query' parameter accepts Gmail syntax but doesn't enumerate supported operators in the description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Add labels to emails
List all Gmail labels (system and custom labels)
List emails in Gmail inbox
List all available Gmail accounts
Mark email(s) as read or unread
Read a specific email content
Reply to an email. IMPORTANT: This will immediately send the email. Always ask user for confirmation before using this tool. Consider using draft_reply first to show the user what will be sent.
Search emails in Gmail using query and filters
Send a new email. IMPORTANT: This will immediately send the email. Always ask user for confirmation before using this tool. Consider using draft_email first to show the user what will be sent.
Set the active Gmail account for operations
Irreversible operations (send_email, reply_email, delete_emails) have 'confirmed' parameters but descriptions do NOT guide LLMs on how to request user confirmation. The tool tells the agent 'ask the user first' but provides no mechanism or example. Agents may pass confirmed=false and expect a response guiding them what to do next; the tool likely just fails silently.
No error handling guidance. Descriptions do not explain what errors the tools can raise or how to recover. E.g., 'delete_emails' with permanent=true is destructive, but no description warns of the consequences or suggests asking for confirmation.
Tool composition gaps. 'draft_email' and 'draft_reply' create drafts but do not return the draft ID or any reference. If an agent calls draft_email, then wants to send it, there is no tool to 'send_draft(draftId)'. The agent must use send_email with the full composed message, duplicating work.
'gmail_add_labels' description does not specify what happens if a label does not exist. Does the tool create it? Fail? Silently skip? This ambiguity forces LLMs to guess or call gmail_list_labels first to discover valid labels.
Parameter naming inconsistency: 'accountEmail' is optional in list_emails, read_email, etc., but the description says 'specific Gmail account to use (email address)'. This suggests the server supports multi-account operations. However, there is also set_active_gmail_account / get_active_gmail_account. When should an agent use the accountEmail param vs. setting the active account? No guidance provided.