Loading ToolBench
A comprehensive Model Context Protocol (MCP) server for full-featured IMAP email management with advanced search, bulk operations, and secure credential storage
The server provides 21 tools with mostly complete schemas and descriptions. All tools have names that follow verb_noun conventions and include descriptions. However, there are gaps in schema completeness, parameter constraints, and error handling guidance. Most parameter descriptions are present but lack specificity around ranges, formats, and constraints. Output schemas are not documented. Authentication parameters (login tool) expose credentials as parameters rather than using server-side injection, which is a security issue. Error handling lacks recovery guidance. The server follows basic tool composition patterns with clear single-responsibility tools (read, write, delete operations are separate), but lacks idempotent hints and confirmation steps for destructive operations.
Create and append an email to the specified folder (e.g., Drafts).
Copy multiple emails to another folder using their UIDs.
Delete multiple emails using their UIDs.
Set or unset flags for multiple emails using their UIDs.
Mark multiple emails as read using their UIDs.
Mark multiple emails as unread using their UIDs.
Credentials exposed as tool parameters. The 'login' tool exposes username, password, and server as parameters. These will be logged in agent traces and potentially exposed in prompt history. This violates the secret-injection pattern.
No output schemas documented. Tools return results but there is no documentation of what fields the response contains, their types, or structure. This forces LLMs to guess at response structure and makes chaining tools difficult (e.g., list_emails returns UIDs but it's not explicit whether to use them for read_email).
Missing parameter constraints and format specifications. Parameters like 'content_format' (appearing in list_emails, filter_emails_by_sender, etc.) are described as an enum-like choice but lack formal enum constraints in the schema. Parameters like 'limit' lack min/max bounds. The 'flag' parameter in bulk_flag_emails should be an enum.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Move multiple emails to another folder using their UIDs.
Delete a specific email by its UID.
Extract attachments from a specific email.
Filter emails by sender address.
Filter emails by subject line (partial match).
Get the most recent emails from the current folder.
List attachments for a specific email without extracting them.
List recent emails from the current folder.
List all stored account names.
Log in to an IMAP server.
Log in using stored account credentials.
Log out of the IMAP server.
Mark a specific email as read by its UID.
Mark a specific email as unread by its UID.
Read a specific email by its UID and return full content.
Destructive operations lack confirmation/dry-run support. Tools like 'delete_email', 'bulk_delete_emails' have no confirmation mechanism or dry-run mode. Agents can irrevocably delete emails without a safety check, risking data loss.
Error handling lacks recovery guidance. Tool descriptions do not include error cases or how to recover from them. For example, if login fails, the agent doesn't know whether to retry, ask for new credentials, or check the server hostname.
Missing tool annotations. No destructiveHint, idempotentHint, or readOnlyHint annotations are present. This prevents agents from knowing which tools are safe to retry (idempotent) or which ones have irreversible side effects.
Parameter descriptions lack format/constraint details. For example, 'to_addresses' in append_email is described as 'comma-separated' but lacks format specification. 'folder' parameters don't specify valid folder names or how to discover them. 'flag' in bulk_flag_emails lacks description of valid IMAP flag names.
No pagination guidance in list operations. Tools like 'list_emails', 'filter_emails_by_sender', 'get_recent_emails' return limited results but don't document pagination mechanism, whether there's a next_cursor, or how to fetch more items if there are thousands of emails.
Tool composition: Some tools are missing contextual information needed for chaining. For example, read_email requires a UID but there's no clear documentation that list_emails returns UIDs, forcing the agent to infer the connection.
Missing default folder guidance. Tools reference 'INBOX' and 'Drafts' as examples but don't clarify how to discover valid folder names or whether the current folder is stateful across tool calls.