Loading ToolBench
Better MCP server for Email (IMAP/SMTP) with composite tools optimized for AI agents
The server defines 8 tools with partial structure, but critical quality gaps significantly impact usability. Tool descriptions range from adequate to vague. Input schemas are visible but incomplete, most parameters lack type constraints, validation rules, and detailed descriptions. Output schemas are not documented. Parameter descriptions are generic ("Email account identifier", "Message ID to retrieve") without format guidance, constraints, or dependency hints. No tool includes error recovery guidance or handling documentation. Naming is mostly action-verb-based (send, delete, move, mark, read) but some are ambiguous (config, folders). The server does not expose parameter validation, idempotency hints, or permission scoping. Risk levels are declared but not reflected in tool annotations or confirmation patterns. Critical tools like 'delete' and 'send' lack dry-run or confirmation workflows.
Configuration and status management for email accounts
Delete emails from a folder
List, create, and manage email folders/mailboxes
Mark emails as read, unread, flagged, or unflagged
Move emails between folders
Read and retrieve email messages by ID
Search for emails across folders with advanced filtering
No input schemas with formal type definitions and enums. Parameters listed but not strongly typed. LLMs will hallucinate invalid values (e.g., passing arbitrary action names to 'config', inventing flag names for 'mark').
No output schemas documented. LLMs cannot reason about what fields to expect or how to chain results to downstream tools. E.g., does 'search' return message IDs for use in 'read', or full email objects?
Destructive tools ('delete', 'send') marked with risk levels but no confirmation/dry-run pattern. Agents can irreversibly delete emails or send unintended messages without safety gates.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Send emails via SMTP
Parameter descriptions are generic and lack format/constraint guidance. E.g., 'messageId' has no format hint (is it an RFC 2822 ID, a numeric index, or a server-specific string?). 'query' in search tool has no syntax documentation.
Tool 'config' and 'folders' use generic names (nouns, not action verbs). 'config' does not clearly indicate read vs write. 'folders' conflates multiple operations (list, create, delete, rename) into one tool.
No error recovery guidance. Tools lack descriptions of what happens on failure and how to proceed. E.g., 'send' does not document SMTP retry behavior; 'delete' does not guide recovery for already-deleted messages.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) or idempotency documentation. LLMs cannot determine which tools are safe to retry without side effects.
Search tool lacks pagination parameters (limit, offset, page) and no guidance on result set size. Agents may attempt to retrieve thousands of emails in one call, exhausting context.
Ambiguous parameter relationships and missing dependencies. E.g., 'folders' tool accepts 'action' but no guidance on which other parameters are required per action (create requires 'folder_name'?). Multi-step operations not documented.
No permission/scope declarations. Tools do not declare what credentials or access levels they require (read:email, write:email, delete:email). Agents cannot be configured with least-privilege access.