Loading ToolBench
fastmail-mcp has 3 tools with mixed quality. The `execute` tool has comprehensive validation and a detailed description of its JMAP capabilities, but uses a generic verb that masks its true function. The `compose_email` and `read_email` tools are Apps (UI widgets) rather than traditional tools, they lack explicit input schema documentation in the source and their descriptions are verbose and UI-focused rather than LLM-optimized. Schema details for Apps are present in the code but descriptions could be more concise. Error handling is present for the JMAP execute tool but minimal for the Apps. Overall, the server demonstrates solid engineering (validation, auth, tracing) but falls short of production-grade tool design patterns.
Open an interactive email compose form. Optionally pre-fill fields (to, cc, bcc, subject, body). The form allows the user to edit and send or save as draft.
Execute arbitrary JMAP method calls. Validates the request structure, injects account ID, executes the JMAP call, and returns cleaned responses.
Display the full content of an email in a rich reader view widget shown to the user. Fetches the email by ID and renders it with headers, body, and action buttons (reply, forward). The full email is displayed to the user as an interactive widget; the assistant receives only a brief confirmation with metadata.
Tool 'execute' uses a generic verb ('execute') that masks the actual function (JMAP method dispatcher). The name does not convey the tool's specific purpose. Should be 'call_jmap' or 'run_jmap_method' to clarify it dispatches JMAP calls.
Apps (compose_email, read_email) lack explicit input parameter type definitions visible in the tool registration. The schema appears to be documented in comments within src/apps.ts but not in a machine-parseable JSON Schema format that the MCP protocol requires.
Description for 'read_email' (60 chars) is below the baseline of 194 chars average for A+ tools and does not explain WHEN to use it vs. other email access patterns. The description mentions 'rich reader view widget' and 'brief confirmation', UI-focused language that does not help an LLM select this tool in planning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
'compose_email' description (110 chars) is verbose and UI-centric ('Open an interactive email compose form') rather than action-centric. Should clarify: 'Create and send an email. Accepts optional pre-filled fields (to, cc, bcc, subject, body) for quick composition.'
Parameter descriptions for Apps (compose_email, read_email) are minimal. E.g., 'to': 'Recipient email address(es), comma-separated' lacks guidance on format (single email vs. CSV), optional flag, and valid format constraints.
Error handling for 'execute' tool provides validation errors (e.g., 'unknown method', 'duplicate callId') but does not guide LLM on recovery. Per pattern:recovery-guide, errors should say 'what to do next', e.g., 'Invalid method "Email/delete". Allowed: [list]. Use Email/set with destroy=true instead.'
The 'execute' tool accepts arbitrary JMAP method calls with an allowlist, but the description does not warn that some JMAP methods are destructive (e.g., Email/set, Mailbox/set, EmailSubmission/set). Agents calling execute risk accidental data loss without understanding consequences. Per pattern:command-tool, state explicitly if a tool modifies state.
No output schema documented for any tool. Users and LLMs cannot predict what fields 'execute' returns from a JMAP batch call, forcing them to guess at result structure.