Loading ToolBench
MCP server for Gmail operations including search, read, and reply to emails via Google Gmail API
This Gmail MCP server exhibits significant definition quality gaps across multiple dimensions. Tool naming is generally clear and action-oriented (search_emails, get_email_content, reply_to_email), but parameter descriptions are inconsistent or missing. Input schemas are present but incomplete for several parameters. Output schemas are undocumented. Error handling is minimal and non-informative. The server also includes an out-of-domain tool (get_weather, get_weather_forecast) that violates single-responsibility principle. Schema validation is weak, with no input sanitization against injection attacks despite handling user-controlled search queries.
Retrieve the full content of a specific email by message ID
Get current weather information for a specified city
Get weather forecast for a specified city and number of days
Send a reply to an email message with proper threading and headers
Search for emails using a query string and return matching email metadata
No output schema documentation. Tools return plain strings rather than structured objects with typed fields. LLMs cannot reliably extract data for downstream calls or chaining.
Missing parameter descriptions for some inputs. 'query' in search_emails lacks detail on allowed syntax, wildcards, or Gmail search operators. LLM must guess at valid query formats.
No input validation or sanitization. Search query is passed directly to Gmail API without escaping, risking injection attacks if the LLM is prompted with malicious input.
Error messages are unhelpful to LLMs. Responses like 'Error searching emails: {e}' (generic exception string) give no guidance on recovery. Should indicate retryable vs. fatal failures and suggest next steps.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Weather tools (get_weather, get_weather_forecast) are out-of-domain. A Gmail MCP server should not provide weather data. This violates single-responsibility principle and dilutes focus.
No pagination or result limits. search_emails defaults to max_results=5 but does not document what happens if more results exist. No cursor, offset, or 'total available' field returned.
Incomplete parameter descriptions for city in weather tools. No validation range, format requirements, or examples. LLM must guess at input format (just city name? Country code? Coordinates?).
No confirmation or dry-run pattern for destructive operation (reply_to_email). Agents can accidentally send emails without a verification step. Consider adding a 'preview' mode or confirmation requirement.
Gmail OAuth credentials (credentials.json, token.json) are file-based in the repo directory. No discussion of secret injection patterns or environment variable alternatives. Risk of credential exposure in version control.