Loading ToolBench
Google Workspace Gmail API abilities for MCP. Service account only, inbox management, send/receive emails.
Server has 10 Gmail tools with basic schemas and descriptions. Naming follows verb_noun pattern (gmail/configure, gmail/list, etc.), which is good. However, descriptions are generic and lack LLM-optimization guidance. Most parameter descriptions are minimal (10-30 chars), below the 72-char baseline. No output schemas documented. Error handling and recovery guidance absent. Security concern: gmail/configure accepts service_account_json as a string parameter, violating secret-injection pattern. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Schemas present but sparse, many lack constraints, enums, or format specifications.
Configure Gmail API service account credentials and impersonation email
Create a new Gmail label
Delete a Gmail message permanently
Delete a Gmail label
Retrieve a specific Gmail message with optional mark-as-read
List messages from Gmail inbox with optional filtering and detail fetching
List all Gmail labels with optional type filtering
Credentials exposed as tool parameter: gmail/configure accepts service_account_json as a string input, violating secret-injection pattern. Credentials will appear in agent logs and traces.
No tool annotations despite clear risk levels. Tools marked WRITE and DESTRUCTIVE lack readOnlyHint/destructiveHint annotations. LLMs cannot distinguish safe from dangerous operations.
Parameter descriptions too brief (10-30 chars vs 72-char baseline). Examples: 'Email address to impersonate for domain-wide delegation' (54 chars) lacks format/constraint details. 'Whether to fetch full message details' (38 chars) lacks context on performance impact.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Modify Gmail message labels and read status
Reply to a Gmail message with optional reply-all
Send an email message via Gmail
No output schemas documented. Tools return data but LLMs cannot plan downstream calls without knowing response structure. E.g., gmail/list returns messages but field names/types unknown.
Missing error handling and recovery guidance. No indication of retryable vs fatal errors, or what LLM should do on failure. E.g., gmail/send could fail due to invalid recipient, rate limit, or auth, each requires different recovery.