Loading ToolBench
Design and generate responsive email templates with AI — MCP server for Claude, Cursor, VS Code Copilot. Brand-aware, MJML-powered, no API keys needed.
The server defines 7 tools with reasonable coverage for email design workflows. Naming follows verb-noun conventions (compile_mjml, setup_brand, generate_email, validate_email, refine_email, export_email, screenshot_to_email), all start with action verbs. Descriptions are present for all tools and range from 100-200+ characters, providing context on what each tool does. However, several parameter descriptions are vague or missing detail. Input schemas are visible and typed, but output schemas are not documented in the source provided. Error handling is not evident from the code samples, no recovery guidance, categorization, or actionable error messages visible. The preview server (src/preview/server.ts) implements an HTTP preview interface alongside STDIO, but this is supplementary; the core MCP transport remains STDIO-only.
Compile MJML markup into responsive, production-ready HTML email. Returns the compiled HTML along with file size and any validation warnings.
Export a generated email as HTML, MJML, or both. Supports exporting specific versions from the refinement history.
Generate a professional email template from a natural language prompt. Returns expert system prompts, brand context, layout instructions, and a user instruction for the AI to produce MJML. After generating MJML, call compile_mjml to get the final HTML.
Iterate on a previously generated email. Provide natural language feedback to modify the design. Supports section-level targeting (header, hero, body, cta, footer) and version history for undo.
Convert a design description (from a screenshot or mockup) into a branded MJML email. Describe the layout, colors, sections, and content — the AI will generate matching MJML. Supports multiple screenshots for long emails (pass an array of descriptions).
Output schemas not documented. Tools like compile_mjml, generate_email, validate_email, export_email return results but the structure and fields are not visible in provided source. LLMs cannot plan downstream tool calls or extract required fields without documented output schemas.
Missing error handling guidance. No evidence of error responses that tell the LLM what to do next (e.g., 'Invalid MJML: line 5, missing closing tag. Check the MJML syntax' or 'Brand not found. Call setup_brand() first'). Agents will struggle to recover from failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
Save a brand profile with colors, fonts, tone, and identity. Provide a website URL to auto-extract brand colors, fonts, and logo — or specify them manually. This brand context is used by generate_email to create on-brand emails.
Validate a compiled HTML email for best practices: size limits (Gmail clipping), dark mode support, accessibility (alt text), link integrity, unsubscribe link, and text-to-image ratio.
Parameter descriptions are inconsistent in specificity. 'layoutVariant' in generate_email has description 'Specific layout variant to use (optional)', this does not explain what variants are available or how to discover them. 'descriptions' in screenshot_to_email lacks guidance on expected format (length, detail, structure). Users and LLMs need explicit format constraints.
Enum constraints incomplete. 'emailType' accepts [welcome, newsletter, promotional, transactional] but screenshot_to_email's emailType description says 'Type of email (optional)' without stating the enum values or noting that it's optional. Agents may hallucinate invalid types like 'marketing' or 'sales'.
Idempotency not documented. Tools like refine_email and export_email involve state mutation (storing versions, exporting). No indication of whether they are idempotent. Agents may not know if retrying a call twice will create duplicate versions or return the same result.
Missing tool composition patterns. No tools for listing brands, listing generated emails, or discovering available layout variants. Discovery is documented as a pattern (list_*, describe_*) but absent here. An agent cannot discover what brands exist or what layout variants are available without manual intervention.