Loading ToolBench
MCP server for IMAP/SMTP email access with environment-based configuration
Strong schema definitions with Zod validation and detailed parameter constraints. Tool naming is consistent (verb_noun pattern). Descriptions are present but vary in specificity. Tool annotations properly declared. Error handling guidance is present but inconsistent. Output schemas are implied through Zod definitions but not explicitly documented for agents. This server demonstrates good engineering discipline in input validation and composition, placing it in the B+ range despite some documentation gaps.
Connect to IMAP when needed, actively verify SMTP, then return structured status for both services.
Send a follow-up message in an existing thread using the In-Reply-To and References headers, with signature and optional quoted content.
Delete a message from a mailbox by marking it as deleted and expunging it.
Find messages from a sender that have no thread-header reply in the sent mailbox. Messages without Message-ID are returned separately as unknown.
Retrieve one message, including full bodies and attachment metadata. Set markSeen only when the message should be marked as read.
Retrieve multiple messages from one mailbox, including full bodies and attachment metadata. Fails if any requested UID is missing or the aggregate response-body budget would be exceeded.
Output schemas not explicitly documented for agents. Zod schemas define internal validation but lack explicit return type documentation in tool definitions. Agents cannot see what fields to expect in results, forcing them to reason about response structure.
Destructive operations (delete_message, move_message, send_email, etc.) lack explicit confirmation or dry-run capability. Agents can irreversibly delete or send emails without a confirmation step. No documentation of how to recover from mistakes.
Error handling responses are not explicitly specified. No documented examples of what errors return, how agents should interpret them, or what recovery actions are available. Error guidance is missing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List all available mailboxes (folders). Auto-connects to IMAP when needed.
Move a message to another mailbox by copying and deleting in the same IMAP connection to preserve the message and avoid duplicates.
Reply to a mailbox-scoped message with threading headers, optional reply-all recipients, signature, and quoted original content.
Download an attachment from a message and save it to a local directory allowed by MAIL_ALLOWED_ROOTS.
Search one or more mailboxes with combined filters. Defaults to INBOX and the detected sent mailbox. Returns message summaries unless includeBody is true; full-body hydration fails explicitly if a selected message disappears or the aggregate response-body budget would be exceeded.
Send a new email via SMTP and try to save a MIME-equivalent copy with the accepted Message-ID to the sent mailbox.
File path handling via MAIL_ALLOWED_ROOTS environment variable is not documented in tool descriptions. Agents cannot know what paths are valid or how to discover them. Requires explanation of the security boundary.
Mailbox/uidValidity coupling in multi-tool workflows not explained. Agents need to understand that mailbox names may have associated uidValidity values and how to use them across get_message, reply_to_email, delete_message, etc. Documentation missing.
Parameter descriptions lack guidance on when to omit vs include optional fields. For example, send_email signature object documentation doesn't clearly state that LLMs must provide at least text OR html. The refine() rules exist in schema but aren't exposed to agents.