Loading ToolBench
Send and receive emails from any agent. Stdio bridge to the MCP Emails server. Read, search, send, organize, draft and schedule email from Claude Desktop, Cursor, Cline, Windsurf and any other stdio MCP client.
This MCP server has 48 tools with a critical deficit: NO visible input schemas in the source code provided. Tool descriptions are present but extremely generic and lack the specificity required for LLM selection. Naming is inconsistent with single-responsibility principle, many tools bundle multiple concerns (e.g., 'email_search_and_move', 'email_search_and_delete', 'approval_schedule' conflates scheduling with approval). The codebase shows Supabase function references and fixture files (apps/mcp-app/harness/fixture-server.mjs) but actual tool registration code with schemas is not visible in the source excerpt provided. Parameters, constraints, output schemas, and error handling guidance are completely absent from the visible code. This makes it impossible to verify schema quality, parameter descriptions, or output field definitions, all critical for production-grade tools.
Decide on approval for an outbound email (approve/reject)
Schedule an email pending approval to send at a specific time
Update an email pending approval (subject, body, recipients)
Execute a bulk operation (move, delete, flag) on multiple emails
Search email contacts
Consolidated draft management tool
Create a new draft email
NO INPUT SCHEMAS VISIBLE. This is a HARD BLOCK for production readiness. Without schemas, LLMs cannot validate parameter types, constraints, or enums before calling tools.
Tools violate single-responsibility principle. 'email_search_and_move', 'email_search_and_delete', 'approval_schedule', and 'bulk_execute' bundle unrelated concerns. Should split: search_emails → move_emails (separate); approve_email → schedule_email (separate). Compound names with 'and' signal poor composition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
Delete a draft email
Save a draft from the draft editor UI
List draft emails
Read and retrieve a draft email with full content
Create a draft reply to an email
Send a draft email
Update an existing draft email
Archive an email
Download email attachments
Compose and send an email with optional scheduled send
Copy email to a folder
Copy multiple emails to a folder
Delete an email permanently
Delete multiple emails permanently
Extract and parse email content
Flag or unflag an email
Forward an email
List emails with filtering and pagination
Move email to a folder
Move multiple emails to a folder
Get original email headers and raw content
Read, search, and extract email content including attachments, original headers, and parsed content
Read multiple emails in batch
Reply to an email
Search emails with advanced filters
Search and delete emails in one operation
Search and move emails in one operation
Send an email message
Consolidated folder management tool
Create a new folder
Delete a folder
List email folders
Rename a folder
List connected email inboxes
Consolidated schedule management tool
Cancel a scheduled email
Schedule an email to be sent at a specific time
List scheduled emails
Consolidated signature management tool
Get email signature
Set email signature
Consolidated 'catch-all' tools (folder, draft, schedule, signature) have generic names that do not indicate specific actions. A tool named 'folder' could mean list/create/delete, LLMs cannot infer intent. Each action should have its own verb: folder_list, folder_create, folder_delete are clearer.
Descriptions are present but generic and lack actionable guidance. All 48 tools have description strings 20-70 chars with no mention of prerequisites, when to call, or what happens. E.g., 'Move email to a folder' omits: which folder types are valid? What happens if folder doesn't exist? Can I move to a system folder?
NO visible parameter descriptions or constraints. Tools like email_search likely accept 'query', 'folder', 'limit', 'offset', etc., but source shows no descriptions, enums, or type info. LLMs cannot infer if 'limit' accepts 1 - 100 or 1 - 10000, or if 'folder' is an enum or free text.
NO documented output schemas. Unclear what fields tools return (e.g., does email_read return 'body' or 'content'? 'from' or 'sender'?). Without output schema docs, downstream tools cannot reference returned IDs, and agents lose context between calls.
Destructive operations (email_delete, email_delete_batch, email_search_and_delete, folder_delete, draft_delete) have no visible confirmation or dry-run support. Pattern requires irreversible tools to support user confirmation or dry-run mode.
NO error handling guidance visible. No indication of how LLMs should recover from failures (e.g., 'folder not found' → try list_folders first). Error responses must guide the LLM to next steps, not return bare error codes.