Loading ToolBench
MCP server for email management with support for sending emails, listing accounts, and reading email content from a docker-mailserver instance
This MCP server has significant definition quality gaps. The tool names are reasonably descriptive (list_available_accounts, send_email, list_emails_metadata, get_emails_content) and follow verb-noun conventions. However, the schema and parameter documentation is severely deficient. While parameter schemas are present in the code, parameter descriptions are minimal (e.g., 'The name of the email account to send from' is adequate but terse). More critically, there are no documented output schemas, the responses are accessed as result.content[0].text with no structure specified to the LLM. The send_email tool modifies state but lacks explicit documentation that it is a WRITE operation with side effects. Error handling is entirely absent, no recovery guidance, no actionable error messages. The implementations shown are wrappers around an external 'mcp-email-server' package, so the actual tool logic is opaque and cannot be fully evaluated from the provided source.
Retrieve the full content of specified emails by ID
List all available email accounts configured in the mail server
List email metadata (headers, subject, sender, date) for a specified account
Send an email from a configured account to specified recipients
No documented output schemas. Tools return result.content[0].text with no structure visible to the LLM. The agent cannot know what fields or format to expect, forcing unstructured text parsing and context waste.
Parameter descriptions are present but minimal and generic. Example: 'List of recipient email addresses' for the 'recipients' param lacks format guidance (is each a bare email or an object with name+email?), validation constraints, or examples of invalid input.
No error handling guidance. If send_email fails (e.g., invalid recipient, account not found, SMTP failure), the agent receives no actionable recovery hint. The code has no visible error classification (retryable vs. fatal) or user-fixable guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
send_email is a destructive/state-changing operation (WRITE risk). The tool description must explicitly warn that it modifies state and has irreversible consequences. No idempotency guarantee is documented.
list_emails_metadata has a 'limit' parameter with no bounds documented. What is the max? What happens if limit=999999? No minimum/maximum constraints are visible in descriptions or schema validation.
account_name appears in all tools but is never described as an enum or validated set. The agent doesn't know which accounts exist without calling list_available_accounts first. No guidance on whether account names are case-sensitive or accept partial matches.
get_emails_content accepts 'email_ids' but there is no documentation of what format email_ids should be (opaque strings? integers? UUIDs?) or where to obtain them. The tool chain is broken, list_emails_metadata returns metadata but doesn't document what ID field to extract.