Loading ToolBench
Full-featured, multi-account MCP email server for Windows, macOS, and Linux—read, search, organize, and send email via IMAP and SMTP.
This server has 17 tools with consistent naming and description patterns, but significant gaps in schema documentation and parameter descriptions. Tool names follow verb_noun convention (list_, send_, forward_, etc.), which is good. However, parameter schemas are severely underspecified, most tools declare parameters with generic object types and descriptions like 'ListEmailMetadataQuery object' without revealing the actual structure. The server provides brief tool descriptions (20 - 100 chars), which are above the floor but lack the depth needed to disambiguate similar operations (e.g., move_emails vs archive_emails, both reversible, unclear when to use each). No input validation guidance, error handling patterns, or pagination details visible in tool definitions. Output schemas are not documented in the tool definitions. Security-sensitive tools like send_email_command and delete_emails_command lack explicit warning text about irreversibility or permission requirements. The implementation uses fastmcp and Pydantic, suggesting strong internal typing, but that structure is not exposed to the LLM in the tool schema.
Archive one or more emails, moving them to the archive mailbox.
Delete one or more emails from a mailbox.
Download and retrieve an attachment from an email.
Retrieve the effective email server configuration for all accounts.
Forward an existing email message to new recipients.
Return stable non-secret discovery capabilities for one configured account.
Retrieve the actual binary content of an attachment.
All parameter schemas are opaque object types with generic descriptions (e.g., 'ListEmailMetadataQuery object'). The actual structure of query and command objects is not visible in tool definitions. LLMs cannot determine what fields to populate.
No output schemas documented. Tools return unspecified results, LLMs do not know what fields to extract for downstream tool calls. This violates the chaining contract: if get_email_content_query returns results, tools downstream must document which fields they need.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Retrieve the full content (headers, body, attachments) of one or more emails.
List configured email accounts available to the MCP server.
Query and list email metadata with filtering and pagination capabilities.
List all mailboxes/folders available in an email account.
Mark one or more emails as read or unread.
Move one or more emails to a different mailbox.
Save an email message to a specific mailbox in the account.
Send an email message through a configured SMTP account.
Set IMAP flags (Seen, Flagged, Deleted, etc.) on one or more emails.
Set custom IMAP keywords/tags on one or more emails.
Destructive operations (delete_emails_command, send_email_command) lack explicit warning in descriptions and do not declare destructiveHint/idempotentHint annotations. LLMs cannot reason about side effects or retry safety.
No pagination parameters documented. list_email_metadata and list_mailboxes_query are listed tools but no limit, offset, page, or cursor parameters visible in schemas. Risk: returning large result sets that exhaust context or timeout.
Similar tool names without clear disambiguation: move_emails_command vs archive_emails_command (both appear reversible, unclear when to use each). mark_read_command vs effective_configuration naming inconsistency ('_command' suffix inconsistently applied).
Tool descriptions are generic and under 100 chars, lacking guidance on when to choose between overlapping tools. E.g., move_emails and archive_emails both say they move emails; no hint that archive is a semantic shortcut to the archive mailbox.
No error handling guidance in tool descriptions. Tools do not document what to do if an email is not found, attachment is missing, account is offline, or IMAP/SMTP fails.