Loading ToolBench
A Node.js application for summarizing emails using the ModelContextProtocol (MCP). Connects to Gmail, Outlook, and Yahoo email accounts via IMAP to fetch and manage emails.
The server defines 2 tools with partial schema visibility. Naming follows verb_noun pattern (search-emails, mark-emails-as-read), which is good. However, descriptions are present but generic/brief, and critical schema details are incomplete or ambiguous. The input schemas visible in the source show parameter definitions but lack complete type documentation in several areas. Parameter descriptions exist but are sometimes vague (e.g., 'Optional subject to filter emails by subject or sender' is unclear about behavior). No output schemas are documented. The schema for 'search-emails' shows a complex 'dateRange' object structure but lacks clarity on required vs. optional fields. The 'mark-emails-as-read' tool description is minimal (18 chars) and does not explain consequences or use cases. Error handling is not visible in the provided code. Overall, this server falls into the 'Fair' (C-D range) category with basic tool structure but significant documentation and schema gaps.
Mark specified emails as read in the user's inbox.
Get emails from the user's inbox. Can specify the mailbox (INBOX by default), a subject (string), date range (ISO format: YYYY-MM-DDTHH:mm:ss), and sender emails (list of strings) to filter emails.
Missing output schemas: Neither tool documents what it returns. LLMs cannot plan downstream calls or extract required fields without knowing response structure.
Minimal description for mark-emails-as-read (18 chars): 'Mark specified emails as read in the user's inbox.' Does not explain when to use it, whether it supports dry-run, or what happens if an email ID is invalid. Descriptions under 20 chars must score ≤20; this 18-char description cannot exceed 35.
Ambiguous 'subject' parameter in search-emails: Description says 'Optional subject to filter emails by subject or sender. Only sent if user provides a subject to search EXPLICITLY!' This is confusing, does it filter by subject line, sender address, or both? The phrase 'Only sent if user provides' is a condition that belongs in tool logic, not the parameter description.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Incomplete schema for dateRange: The 'dateRange' parameter is an object with 'start' and 'end' fields (ISO strings), but it is unclear whether dateRange itself is required or optional. The description says 'Must be provided on date time ISO string format' but the wrapper object may or may not be required, this ambiguity will cause LLMs to guess.
No error guidance: If mark-emails-as-read fails (e.g., invalid ID, permission denied), there is no visible error handling or recovery guidance. LLMs need to know 'is this retryable?' or 'should I ask the user for different IDs?'
Credentials passed via headers (EMAIL-USERNAME, EMAIL-PASSWORD) in server.ts: Although the actual handler code is commented out, the fact that headers are declared in CORS config and the pattern is present indicates a security vulnerability. Credentials should never be transmitted as headers, they should be injected server-side or use secure credential exchange.
No pagination support in search-emails: The tool returns email results but has no limit, offset, or page parameters. Large mailboxes could return thousands of emails, exhausting context windows. Description does not mention result limits.
Parameter 'senders' array lacks item format specification: The schema shows items: {type: 'string'} but does not clarify whether these should be email addresses (user@example.com) or display names (John Doe). This forces LLMs to guess.