Loading ToolBench
MCP server for Gmail integration providing email sending and fetching capabilities
The server defines 2 tools with visible schemas and descriptions, but suffers from significant gaps in parameter clarity, error handling guidance, and LLM-optimized documentation. Tool names follow verb-noun convention (send_email_tool, fetch_recent_emails), which is positive. However, parameter descriptions lack actionable constraints (no regex patterns, format specs, or range limits documented), and error messages are generic ('Failed to send email: {e}') rather than recovery-oriented. Output schemas are documented as strings rather than structured JSON, forcing the LLM to parse unstructured text. The send_email_tool exhibits good parameter granularity (separate attachment_path, attachment_url, attachment_name) with clear priority logic, but the description exceeds 1024 characters and buries the priority rule in a collapsed format. fetch_recent_emails defaults are reasonable (folder='INBOX', limit=10) but lack documentation of result limits or pagination guidance.
Fetch the most recent emails from a specified folder. Parameters: - folder: The email folder to fetch from (default: "INBOX"). - limit: Maximum number of emails to fetch (default: 10). Returns: - A formatted string containing details of the recent emails.
Send an email via Gmail SMTP. Parameters: - recipient: The email address to send the email to. - subject: The email subject. - body: The email body text. - attachment_path: Optional direct file path for an attachment. - attachment_url: Optional URL from which to download an attachment. - attachment_name: Optional filename for the attachment. Priority: 1. If attachment_url is provided (and attachment_name for filename), download the file. 2. Else if attachment_name is provided, try to load it from the 'available_attachments' directory. 3. Otherwise, use attachment_path if provided.
Error messages are non-actionable. 'Failed to send email: {e}' and 'Failed to fetch emails: {e}' expose raw exception text without guidance on next steps (retry, check credentials, validate input). LLMs cannot reason about recovery from unstructured error strings.
Output schema is unstructured string, not JSON. fetch_recent_emails returns a formatted text block; send_email_tool returns a success/error message string. LLMs cannot reliably extract structured data (email IDs, dates, metadata) from free-text output, forcing token-wasteful parsing or information loss.
Parameter descriptions lack format constraints and validation hints. 'recipient: The email address to send the email to' does not state format requirements (RFC 5322 email regex), allowed domain restrictions, or what constitutes a valid email. 'limit: Maximum number of emails to fetch' lacks bounds (1 - 100? 1 - 1000?). LLMs cannot self-validate and may pass invalid inputs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
send_email_tool description exceeds recommended length (1024 chars recommended max; this is ~450 chars in body alone, plus headers and priority section). The priority logic (download URL → pre-staged → file path) is buried in a collapsed list format, not prose. Description should be 10 - 1024 chars with clear, scannable structure.
Credentials (SMTP_USERNAME, SMTP_PASSWORD) are correctly stored as environment variables, but no permission scoping is declared. Tools do not state what permissions they require (e.g., 'read:email', 'send:email') or what user/agent invoking them should be authenticated as.
No idempotency or confirmation logic. send_email_tool is destructive (sends email) but has no dry-run, confirmation, or undo mechanism. Agents retrying on ambiguous failures may send duplicate emails. No unique identifier tracking to detect replayed requests.
fetch_recent_emails returns only basic metadata (from, subject, date, id) but no pagination support (no limit enforcement documented, no offset/cursor for iterating large inboxes, no total count). Requesting all emails from a large folder risks context window exhaustion with no guidance.
No input validation or sanitization shown. file paths passed to send_email_tool (attachment_path) are opened directly without path traversal guards. A malicious prompt could pass '../../../../etc/passwd' or similar. LLM prompt injection could bypass validation if no server-side checks exist.
Parameter attachment_url is downloaded without size/format validation or timeout. Large or malicious URLs could cause DoS (downloading multi-GB files, hanging connections). No Content-Type or virus scanning mentioned.
No rate limiting or quota enforcement visible. An agent in a retry loop could attempt hundreds of sends or fetches per minute, overwhelming SMTP/IMAP servers. No LLM-facing guidance on retry strategies or backoff.