Loading ToolBench
MCP server for email operations over IMAP with DKIM/SPF/DMARC validation, policy enforcement, and multiple transport options (TCP, HTTP REST API, WebSocket)
Email MCP has 8 tools with reasonable naming (verb-first: List, Fetch, Search, Set, Send, Delete, Move, Get) and descriptions present for all. However, critical gaps exist: parameter descriptions are minimal or missing (Search criteria lacks detail on valid IMAP operators; SetFlags operation enum is present but flags array items lack type specificity); output schemas are entirely undocumented (no response structure defined for any tool); error handling is absent (no guidance on retryability, user-fixable vs fatal errors); security concerns around credential handling and policy validation are not surfaced in tool descriptions. The Send tool has complex policy validation (DKIM, disposable domains, trusted senders) but these constraints are not documented as parameter validation rules. Overall, definitions are skeletal, sufficient for basic discovery but insufficient for reliable LLM-driven composition.
Delete a message by moving it to Trash or permanently removing it
Fetch a complete email message by UID with full headers, body, and attachments
List all available MCP tools with their schemas and descriptions
List all mailboxes with status information including message counts, unseen counts, and special-use attributes
Move a message from one mailbox to another
Search for messages in a mailbox using IMAP search criteria
Send an email message with policy validation (DKIM enforcement, disposable domain blocking, trusted sender verification)
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., what does FetchMessage return? Does it include attachment metadata? What fields does ListMailboxes expose?). This violates pattern:tool and forces agents to guess response structure.
Search tool's 'criteria' parameter is an object with description 'IMAP search criteria (e.g., {"unseen": true, "from": "[email protected]"})' but lacks formal schema. No enum, no nested property definitions, no validation rules. LLMs cannot determine valid keys or value types, they will hallucinate criteria.
Send tool has complex server-side policy validation (DKIM enforcement, disposable domain blocking, trusted sender verification, allowed_from_addrs) but these constraints are NOT documented in parameter descriptions. LLMs will not know why a Send call fails or what 'from' addresses are valid. Violates pattern:param-validation-rules.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
Set or clear flags on a message (e.g., mark as read, flag, delete)
No error handling guidance. Tools do not document retryability, user-fixable errors, or recovery steps. E.g., if DeleteMessage fails, should the agent retry? Ask the user? Or is it fatal? No guidance means agents will guess wrong.
SetFlags 'flags' parameter is an array of strings with description 'Flags to set (e.g., ["\\Seen", "\\Flagged"])' but array items lack type definition and valid enum values are not documented. LLMs will not know the complete set of valid IMAP flags or their syntax.