Loading ToolBench
MCP server for Day3 email marketing platform, providing tools to manage campaigns, automations, audiences, and sending infrastructure
This server demonstrates strong fundamentals with well-named tools, detailed descriptions, and comprehensive schemas. All 6 tools follow verb_noun naming conventions (day3_context, day3_list_campaigns, day3_get_campaign, day3_create_campaign, day3_update_campaign, day3_preview_campaign). Tool descriptions average ~150-180 characters, falling within the production baseline of 194 chars. All tools have complete input schemas with type definitions and parameter descriptions. However, output schemas are not documented in the source code provided, the server describes what tools return in text but does not show structured output schema definitions in JSON Schema format. This is a notable gap for LLM composition and downstream tool chaining. Additionally, error handling strategies are not visible in the provided code snippet, making it impossible to assess whether error responses include actionable recovery guidance. The code shows proper API-level scope checking (requireScope, keyHasScope), which is good for security, but the mechanism for communicating these permissions to agents is unclear.
Everything needed before writing an email: the workspace's audiences, senders, verified sending domains, plan and sending status, and what this API key is allowed to do. Call this first — the ids it returns are the ones the other tools take.
Create a draft campaign in Day3 from Day3 Markdown. Returns the campaign's id and a URL where a human can open it in the composer. Creating a draft never sends anything.
Read a campaign including its body as Day3 Markdown. Use this before editing, so changes made in the Day3 composer since you last wrote are picked up rather than overwritten.
List campaigns newest first, optionally filtered by status.
Render the campaign exactly as it will arrive — theme, merge tags and compliance footer included. Returns the plain-text rendering plus a URL that opens the HTML in a browser. Set include_html to also get the raw HTML document (large).
Output schemas not documented. While all tools have complete input schemas, return types and field structures are not defined in JSON Schema format. LLMs cannot plan downstream operations or extract required fields without knowing the shape of responses (e.g., does day3_create_campaign return campaign_id, url, status, or all three?).
Error handling strategy not visible. The code shows validation and error-throwing (ApiError, requireScope) but does not document what errors these tools return, whether they are retryable, or what recovery guidance is provided. LLMs need explicit error classification and actionable next steps.
Missing confirmation/dry-run pattern for destructive operations. day3_create_campaign and day3_update_campaign modify state (campaigns are created and updated). The tools lack a dry-run or confirmation step, increasing risk of accidental campaign creation or overwrite by agents.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
Update fields on a draft or scheduled campaign. Only the fields you pass are changed. Passing `markdown` replaces the whole body.
Parameter descriptions for create_campaign and update_campaign contain embedded example values. The 'markdown' parameter description mentions 'see the server instructions for the dialect', but no example or reference is embedded in the param definition. While better than literal examples, a link or more explicit guidance would help.
list_campaigns limit parameter defaults to 20 but is uncapped at the high end (max 50). This is acceptable, but the description should explicitly state 'default 20' to match the schema constraints shown in the rubric.