caniemail-ai-tooling

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.

Your client	Use	Why
An agent that runs commands on your machine: Claude Code, Codex CLI, OpenClaw, Cursor, Zed	the skill	It carries the authoring rules too, so the agent writes compatible markup first instead of only checking it afterwards.
A desktop chat app that spawns MCP servers, such as Claude Desktop	the MCP server	A desktop chat has no shell, but it does start MCP servers on your machine over stdio.
A hosted session, a browser chat or a cloud agent	the MCP server, hosted by you	A cloud session cannot reach a process on your machine, and there is no public instance.

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.

Tool	Use it to	Typical cost
lint_email	Check a draft before sending. Returns only findings, with positions, affected clients and workarounds.	about 10k tokens for a realistic newsletter against all 48 clients
check_feature_support	Decide how to build something. One feature, a verdict per client.	about 200 tokens
search_features	Find a slug by keyword. Agents can't guess that flexbox is css-display-flex.	a few hundred tokens

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.

Verdict	Meaning
supported	Use it.
unsupported	Will not render. Use a fallback.
mitigated	Works with a documented workaround. The note is the answer.
untested	No data. Not evidence of support, and not evidence against it.

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.

	caniemail package	This project
Untested cells	Reported as partial, which is 900 of its 1,637 partial verdicts	Reported as untested
Version order	Re-sorted, so 280 cells use the wrong version (outlook.macos picks 2016 over 16.80)	Taken as authored
Missing data, 16% of pairs	Throws RangeError, so ['*'] always fails	Answers untested
Parses per document	48, one per client	1
Features found on the test corpus	267	392
CSS inside @media	Not seen	Seen
Line numbers inside <style>	Relative to the block	Relative to the document
Runtime dependencies	28 MB	None
Dataset	Bundled, 68 days behind the site when last checked	Fetched live, with a snapshot as fallback

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.