Loading ToolBench
An MCP server for email management via IMAP and SMTP protocols
email-mcp-ts demonstrates solid fundamentals: all 10 tools have clear verb-noun names (get_, list_, search_, create_, delete_, move_, update_, reply_) and descriptions (avg 95 chars). Input schemas are comprehensive with Zod validation and proper type constraints (min/max, maxLength, array items). However, parameter descriptions are entirely absent, the schema shows constraints but LLMs cannot infer what 'mailbox', 'cursor', or 'inReplyTo' mean without text. Output schemas are undocumented; responses are JSON-stringified text blobs with no structured field definitions. Error handling is minimal, no recovery guidance, no categorization of retryable vs fatal errors. Security is reasonable (no secrets in params, rate limiting present) but lacks permission gates and audit logging. Composition is clean (single responsibility per tool, proper chaining via UIDs), but some tools like reply_email and create_draft could benefit from clearer parameter relationships.
Stores a draft in the resolved Drafts mailbox.
Deletes a message from IMAP.
Gets the full detail of one email by its IMAP UID.
Returns unread and total email counts for the configured mailbox.
Lists available IMAP folders.
Lists recent emails from the configured mailbox using cursor-based pagination.
Parameter descriptions completely absent. Schema defines constraints (maxLength, min, max) but LLMs cannot infer semantic meaning of 'mailbox', 'cursor', 'inReplyTo', 'contentBase64' without text descriptions.
Output schemas undocumented. All tools return JSON-stringified text blobs via content[0].text. LLMs cannot plan downstream calls or extract structured fields (e.g., email UIDs for chaining) without knowing response structure. Responses should document field types and names.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Moves a message to another IMAP mailbox.
Replies to a message, sends it via SMTP, and stores a copy in Sent.
Search emails by sender, subject, body text, and/or unread state with pagination.
Marks a message as seen, flagged, deleted, draft, or answered.
Error handling lacks recovery guidance. No tool documents what errors are retryable, what user action is needed, or what to try next. E.g., 'mailbox not found' should suggest available mailboxes; 'invalid email' should explain format requirements.
Destructive operations (delete_email, move_email, reply_email) lack confirmation or dry-run support. Agents can irreversibly delete or send emails without a safety gate. Consider adding a 'dry_run' parameter or separate 'confirm_delete' step.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Per current MCP spec (2026-07-28), tools should declare their risk profile. delete_email and reply_email are destructive; get_email and search_emails are read-only. Annotations guide agent planning.