MCP Server Caniemail

An agent skill and an MCP server that check HTML email against caniemail.com.

    Install         Quickstart         Tools         Verdicts         How it works    

Why this project?

Email clients are not browsers. Outlook on Windows renders with Microsoft Word, and the gap between "works with a workaround" and "nobody has ever tested this" decides whether an email ships broken. caniemail.com has the data, and this puts it where an agent can use it while it writes.

• Lint a draft. Pass HTML and CSS, get back only what breaks, with line and column for every use.
• Check one feature. Per-client verdicts for css-display-flex cost about 200 tokens instead of a 620KB dataset.
• Find the slug. Search "rounded corners" and get css-border-radius.
• Read the workaround. A mitigated verdict carries the note that says how, such as VML RoundRect for corners in Outlook.
• See the data's age. Every result names its source (live, cache or bundled snapshot) and when each feature was last tested.

Which one to use

The skill and the MCP server share one core and answer identically. Pick by where your agent runs.

Install

Skill

Install it into .agents/skills/ in the current project, or add -g for ~/.agents/skills/:

npx skills add shbernal/caniemail-ai-tooling

The skill has no dependencies, so there is nothing to install after it.

MCP server

Add this to your client's MCP config:

{
  "mcpServers": {
    "caniemail": {
      "command": "npx",
      "args": ["-y", "mcp-server-caniemail"]
    }
  }
}

Its only dependencies are the MCP SDK and zod. Set CANIEMAIL_OFFLINE=1 in its environment to skip the network and use the bundled snapshot.

Quickstart

1. Install the skill or the server as above.
2. Ask your agent for an email, and name the clients that matter: "Build an order confirmation email. It has to work in Outlook on Windows and Gmail."
3. The agent drafts the markup, calls lint_email against those clients, and rewrites whatever comes back unsupported.

The skill also ships a CLI, which is what the agent runs and works the same by hand:

node skill/scripts/caniemail.mjs lint --html draft.html --clients 'outlook.windows,gmail.*'

Client lists take family.platform globs: outlook.windows, gmail.*, *.ios, or * for every client.

The tools

Three tools, deliberately not one. A single "give me the caniemail data" tool would return 620KB of JSON, about 300 features across 48 clients, and fill an agent's context before it did anything useful.

A fourth, list_email_clients, is rarely needed, because the client roster is already in the other tools' descriptions.

Four verdicts, not a boolean

The dataset distinguishes four states, and collapsing them gives confidently wrong advice.

About a sixth of the matrix is untested, and some entries have not been retested in five years. Every result carries last_test_date, and check_feature_support adds a staleness note when the data is old.

Why not the caniemail package?

This started as a wrapper over the caniemail npm package. It stopped being one because the package gives wrong answers on exactly the parts of the data an agent needs most.

docs/why-not-a-wrapper.md has the full account of each defect. The package stays a devDependency, because a differential test suite checks every fixture against it.

How it works

flowchart LR
    A[Agent] -->|CLI| S[skill]
    A -->|stdio| M[MCP server]
    S --> C[core]
    M --> C
    C --> D[detect: markup to features, one parse]
    C --> R[resolve: feature and client to verdict]
    R --> L[(caniemail.com, then cache, then snapshot)]

One core, core/caniemail-core.mjs, does all the work. The skill and the MCP server each carry a byte-identical copy of it, so they cannot drift apart.

Detection answers "what does this markup use?" without asking about any client. Resolution answers "does this client support it?" against the raw dataset, keeping all four verdicts and never re-sorting versions.

The dataset comes from caniemail.com at runtime and is cached for a day. A response that doesn't look like the dataset is rejected, and the core falls back to the cache, then to the snapshot in core/data/caniemail.json. The MCP server revalidates every 15 minutes, so an editor left open for a week does not keep reporting its first load as live.

Scope

Rendering only, meaning whether markup displays correctly in a given client. Deliverability, SPF, DKIM, DMARC, BIMI, list management and choosing an ESP are different problems, and caniemail data cannot answer them.

More

• CONTRIBUTING.md for setup, tests, and the vendoring rule.
• CHANGELOG.md for what changed in each release.
• docs/releasing.md for how both surfaces get published.
• skill/SKILL.md for the authoring rules the skill gives an agent.

The caniemail dataset is a separate work, MIT, © 2019 Rémi Parmentier. The caniemail npm package, used here only as a development-time reference, is MIT, © Andrew Powell.