A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
7 ★ · emailens/mcp · read from the GitHub search API · (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list · type: MCP server
Harvest history
first seen 2026-10-09 · last seen 2026-10-16 · seen 32× · listed by 7 sources
Score
score 703 · 7 ★ · 7 sources · mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository emailens/mcp;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
MCP server for email compatibility analysis. Analyze, preview, diff, and fix emails across 21 email clients, plus capture real screenshots and create shareable links with an optional API key. Send **HTML, MJML, Maizzle or React Email**. Set format and the template is compiled before analysis, so what gets checked is the HTML your readers actually receive. Why your assistant needs this: across the 298 CSS and HTML features we track, only 6 are fully supported in every major email client (see the data). Ask Claude to check your email before you send it. Built on @emailens/engine. Also available as a GitHub Action. Install Setup Claude Desktop Add to claude_desktop_config.json: Claude Code With API Key (optional, unlocks screenshots + sharing) Get your free API key at emailens.dev/settings/api-keys. Remote (no install) Use the hosted endpoint: no npm or Node.js needed. API key required. Tools Local Tools (no account needed) preview_email Full email compatibility preview: transforms HTML for 21 clients, analyzes CSS, generates scores, simulates dark mode, checks inbox preview and email size. | Parameter | Type | Required | Description | |---|---|---|---| | html | string | Yes | Email HTML source | | clients | string[] | No | Filter to specific client IDs | | format | enum | No | "html", "jsx", "mjml", "maizzle" | analyze_email Quick CSS compatibility analysis; returns per-client scores and one finding per problem. Faster than audit_email when you only need CSS compatibility. | Parameter | Type | Required | Description | |---|---|---|---| | html | string | Yes | Email HTML source | | format | enum | No | Input format | | detail | enum | No | "summary" (default) or "full" | | clients | string[] | No | Only report these client IDs | | targetingPolicy | enum | No | "progressive" (default), "strict", or "lenient" | **One finding per problem, not one per client.** The engine reports per client because a score is per client, and per selector because a fix is per selector. On an ordinary newsletter border-radius arrives twelve times (two clients that drop it, six selectors that use it) with the same sentence in every copy. That was 286KB of JSON, about 73,000 tokens, for an 11KB email. Findings group by property, severity and message, listing the clients affected, with positions merged across all of them. The same email now returns 40KB. Fix snippets are not included; they were 93KB of that 286KB, and fix_email produces them for the issues you decide to act on. hasFix tells you one is available; fixType tells you whether the repair is markup or CSS. Pass detail: "full" for the engine's per-client shape with snippets, and clients: ["gmail-web", "outlook-windows"] to report only what you care about: the fastest further saving, roughly halving the response for two clients. Scores stay whole-email either way: narrowing the report does not change what the email is worth elsewhere. An unknown client ID is rejected by name; an empty result would read as "this email is fine for that client". **Source positions.** For HTML input, every warning carries loc (line, column, offset, length) for the first occurrence, plus alsoAtLines for any others, so an assistant can edit the exact source and knows where the rest are. audit_email positions its other findings the same way. Later occurrences are line numbers rather than full positions on purpose: this response is read by a model paying for every token, and a real newsletter can produce over a thousand occurrences; carrying them all in full nearly doubles the payload. Positions are reported for html input only. JSX, MJML and Maizzle are compiled before analysis, so a line number would point into generated output rather than