Loading ToolBench
A TypeScript MCP server for the Buttondown API that enables email draft management, scheduling, and analytics retrieval
The server defines 4 tools with explicit names, descriptions, and Zod schemas. All tool descriptions are present and meet the 10-1024 character guideline. However, several patterns are incompletely implemented: (1) Parameter descriptions exist but lack actionable constraints (e.g., 'scheduledTime' accepts 'ISO 8601 datetime format' but no validation examples or error handling shown); (2) No documented output schemas, responses are JSON.stringified plain objects with no field-level typing visible to LLMs; (3) Confirmation pattern for write operations (create_draft, schedule_draft) relies on a 'confirmed' boolean parameter rather than a structured Multi-Round-Trip Request (MRTR) pattern; (4) Error responses lack recovery guidance, e.g., invalid draftId returns only JSON error, not 'Did you mean...' suggestions; (5) list_emails returns formatted output but no pagination support despite potentially large result sets. Tool naming is clear and verb-prefixed. Composition is reasonable, tools are separate concerns. However, output structures are ad-hoc and would benefit from explicit schema documentation.
Create a new email draft in Buttondown with the specified content and optional title. This tool requires explicit user confirmation before proceeding as it will create a new draft in your Buttondown account.
Retrieve analytics data for a specific email draft from Buttondown
List all emails, optionally filtered by status (draft, scheduled, sent)
Schedule an existing email draft to be sent at a specific time. This tool requires explicit user confirmation before proceeding as it will modify the draft's status and schedule.
No documented output schemas. Tool responses return ad-hoc JSON objects (e.g., list_emails returns {total, emails: [...]} but fields like 'analytics' subobject are not explicitly typed for LLM consumption). LLMs cannot reliably parse or chain downstream tools without knowing the response structure.
Confirmation pattern uses a simple boolean parameter ('confirmed') rather than a structured Multi-Round-Trip Request (MRTR) pattern. This forces the agent to supply 'confirmed=true' after preview, but does not provide an intermediate user-facing dialog. Modern MCP supports result.input_required for explicit user confirmation without re-calling the tool.
list_emails has no pagination support (limit, offset, page_size, next_cursor). If Buttondown has hundreds of emails, response will bloat context window.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Error handling lacks recovery guidance. When invalid draftId is passed to get_analytics or schedule_draft, response will likely be a raw API error. No suggestion of 'Try list_emails first to find a valid ID' or alternative suggestions.
scheduledTime parameter description says 'ISO 8601 datetime format' but does not include validation examples or error handling. No indication of timezone handling (UTC assumed? local?), or what happens if a past datetime is provided.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema registration. Modern MCP servers should declare tool safety properties via annotations.