The authors are unusually explicit about why: a single border-radius on an ordinary newsletter used to arrive twelve times — two clients that drop it, six selectors that use it — and the response for an 11KB email came to 286KB. Grouping by property, severity and message, and moving fix snippets into the separate fix tool, brought that to 40KB. The same economy shapes the source positions: the first occurrence is full, the rest are line numbers, because a real newsletter can produce over a thousand of them. Then the diff tool closes the loop — it says which issues the fix resolved and which it introduced, which is the step that usually goes missing.
An email QA server that takes HTML, MJML, Maizzle or React Email, compiles it, and returns compatibility, quality and deliverability reports across 21 email clients including Gmail, Outlook, Apple Mail, Yahoo, Samsung, Thunderbird, HEY, Proton Mail, AOL, Fastmail and Superhuman.
- Compatibility at either depth: a quick CSS analysis returning per-client scores and one finding per problem, or a full preview that transforms the HTML per client and adds dark-mode simulation, inbox preview and email size (analyze_email, preview_email).
- Findings that carry their location — line, column, offset and length for the first occurrence, plus the line numbers of the rest — so an assistant edits the exact source rather than searching for it. Positions are reported for HTML input only, because a compiled template's line numbers would point into generated output.
- A quality audit past the CSS: spam scoring, link validation, accessibility, images, inbox preview, Gmail clipping by size and template variables, with a skip parameter to drop individual checks (audit_email).
- A closed fix loop: a structured fix prompt carrying the original code, the detected CSS or structural issues and fix snippets, then a comparison of two versions showing score changes, issues resolved and issues newly introduced per client (fix_email, diff_emails).
- Domain-side deliverability read straight from DNS — SPF, DKIM, DMARC, MX and BIMI — returning a score out of 100 and the issues behind it, with no key needed (check_deliverability).
- Rendered evidence rather than described evidence: real browser screenshots across the 21 clients in light and dark variants, hosted on a CDN, and a shareable analysis link a recipient opens without an account (capture_screenshots, share_preview).
- The supported clients with their IDs, engines and dark-mode support — which is what the client filters on the other tools take, and an unknown ID is rejected by name rather than returning an empty pass (list_clients).
Nothing for the analysis and the DNS checks — `npx -y @emailens/mcp` and they work. Screenshots and shareable links need an EMAILENS_API_KEY, free to obtain, with sharing on the paid Dev plan. A hosted endpoint at https://emailens.dev/api/mcp needs no Node.js at all, but does require the key as a Bearer token.
One command — npx -y @emailens/mcp