Loading ToolBench
Message Control Protocol for Claude to send and read emails
Claude Email MCP has 3 tools with critical definition gaps. Tool names are reasonably clear (verb-noun pattern), but descriptions are extremely sparse (10-20 chars each, well below the 34-char p10 baseline), parameter descriptions are missing or vague, and critical input schema details are absent or improperly formatted. Output schemas are not documented. Error handling provides no recovery guidance. The server appears to be a Serverless/AWS Lambda deployment (not a native MCP server), and there is no evidence of MCP protocol implementation, tool handlers are written as AWS Lambda handlers with queryStringParameters and event.body, not MCP tool handlers. This is not an MCP server; it is a collection of Lambda functions that could potentially be wrapped in MCP, but the source code shows no MCP transport layer, message routing, or protocol compliance.
Handler for getting email drafts
Handler for getting unread emails
Handler for sending emails or saving drafts
Descriptions are critically sparse, getDrafts and getUnreadEmails are 10 characters each ('Handler for getting...'), far below the 34-char p10 baseline. Descriptions lack WHEN to use the tool, WHAT it returns, and prerequisites. This violates the critical check that every tool must have a meaningful description so LLMs can determine when to select it.
Input schema for getDrafts and getUnreadEmails is incomplete and improperly formatted. The 'source' parameter in getDrafts is described as a string but is treated as an enum (must be 'zoho' or 'local'), no enum constraint is declared. The 'content' parameter in getUnreadEmails is described as a string but semantically is a boolean ('If true, fetches full content'). Parameter types and constraints are inconsistent with descriptions, forcing the LLM to guess at valid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 24 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
sendEmail parameter 'to' is described as 'string or array' but JSON Schema cannot express union types this way. The handler accepts both formats but the schema is ambiguous. LLMs cannot parse 'string or array' from a JSON Schema, they need either two separate parameters (to_single, to_multiple), oneOf schema, or explicit array notation with items.
Output schemas are completely undocumented. Handlers return objects like {drafts, count, source} for getDrafts and {emails, count} for getUnreadEmails, but the response format is not declared anywhere. LLMs cannot infer what fields to extract or how to chain results to downstream calls without seeing a schema.
Error handling provides no recovery guidance. Handlers return responses.serverError(error.message) which likely produces a generic 500 error. LLMs receive no hint about whether to retry, call a different tool, or ask the user for help. There is no error classification (retryable vs user-fixable vs fatal).
This is not an MCP server. The source code shows AWS Lambda handlers (exports.handler with event, context parameters) and DynamoDB/SES service clients, not MCP tool registration, message routing, or protocol implementation. There is no evidence of a Streamable HTTP server, STDIO transport, or MCP Server class. The package.json lists serverless, aws-sdk, and axios, not mcp or @modelcontextprotocol/sdk. This appears to be a Lambda-based email API that could be wrapped in MCP, but the MCP integration is not present in the provided source.
Irreversible operations (sendEmail) have no confirmation step or dry-run mode. An agent can send an email in one call with isDraft=false. There is no pattern to prevent accidental email sends, agents make mistakes and should have a way to confirm or review before execution.
Parameter dependencies are not documented. getDrafts has a 'source' parameter that changes behavior (Zoho vs local DynamoDB), but the description does not explain what each source returns or when to use each. sendEmail has parameters cc and bcc that are silently ignored if the source cannot support them, no validation or user feedback.