Loading ToolBench
MCP Email Server providing tools for reading and sending emails via IMAP/SMTP protocols. Supports inbox management, email composition, attachments, and real-time new email notifications.
The Email MCP server has 6 tools with mostly complete schemas and descriptions, but several critical gaps limit quality. Tool naming is generally clear and follows verb_noun conventions (send_email, get_inbox, get_email_contents, mark_email_read, get_attachment, introduction). Descriptions are present for all tools and most parameters. However, descriptions are often terse (10-40 chars) lacking actionable context for LLMs. Error handling guidance is minimal, tools return generic error strings without recovery suggestions. The 'introduction' tool is unusual and not a production pattern. Parameter descriptions could be more detailed about formats, constraints, and dependencies. No tool annotations (readOnlyHint/destructiveHint) are visible despite clear WRITE vs READ_ONLY semantics. Output schemas are not documented, LLMs cannot plan downstream chaining or understand return field structures.
Get the content of an email attachment as a base64-encoded string.
Get the full content of a specific email.
Retrieve emails from the inbox via IMAP.
Returns information about this MCP server, including its description, supported tools, and notifications.
Mark an email as read on the IMAP server.
Send an email via SMTP. Your email address: (from config) (contacts list from config) You can use contact names instead of email addresses for the 'to', 'cc', and 'bcc' fields.
Descriptions are too terse and lack actionable guidance. Examples: 'Retrieve emails from the inbox via IMAP' (35 chars), 'Get the full content of a specific email' (40 chars). Baselines: 194 chars average for A+ tools. These descriptions do not tell LLMs WHEN to call the tool vs alternatives, WHAT the return structure is, or HOW to handle common failures.
No output schemas documented. The code shows CallToolResult returns but LLMs cannot see what fields are in the response, making it impossible to plan tool chaining or extract required IDs. For example, get_inbox likely returns email IDs needed for get_email_contents, but this is invisible to the agent.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | - | v1 |
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). The server clearly distinguishes WRITE operations (send_email, mark_email_read) from READ_ONLY (get_*), but these hints are not declared in the tool definition. This forces LLMs to infer safety properties from descriptions.
'introduction' tool is not a production pattern. It appears to return metadata about the server itself, not perform a user-facing action. Remove it or rename to 'describe_server' and clarify when an LLM should call it. This adds noise to the tool palette.
Error handling lacks recovery guidance. When send_email fails, the code returns 'Failed to send email: {error}' with no context on whether the error is retryable, user-fixable, or fatal. Pattern: 'Invalid recipient email, did you mean one of: [resolved_contacts]?' or 'SMTP server unreachable, retrying in 30s.'
Parameter descriptions lack format and constraint information. Example: 'body_format' description says 'Body format: text, markdown, or html' but does not state what 'text' means vs plain text vs MIME, or which is default/recommended. Missing: range/enum constraints, format patterns, example valid values.