# css-sota-mcp — full reference

> A free, open-source MCP (Model Context Protocol) server that answers what CSS you can actually
> ship today — from live Baseline data on webstatus.dev and MDN browser-compat-data, not from a
> model's training set.

Canonical page: https://css-sota-mcp.pages.dev
Source: https://github.com/LuSrodri/css-sota-mcp (MIT, © Lucas Santos Rodrigues)
Registry name: `io.github.LuSrodri/css-sota-mcp`

## What it is

Agents are confidently wrong about browser support. They will say `anchor-name` is fine, or that
`:has()` needs a polyfill, depending on when their weights were frozen. css-sota-mcp replaces that
guess with the current answer: live Baseline status from webstatus.dev, and MDN browser-compat-data
for every property, value, selector, at-rule and function.

It is a single Cloudflare Worker built on the MCP TypeScript SDK v2. It is stateless — no Durable
Object, no KV, no session affinity — so any isolate can answer any request.

## Endpoint

```
https://css-sota-mcp.lusrodri.workers.dev/mcp
```

Transport: Streamable HTTP. No authentication, no API key, no account. Every tool is read-only over
public datasets, so there is nothing to protect from disclosure.

There is also `GET /health`, which returns the bundled data versions (`browser-compat-data` and
`web-features`), the compat key count and the feature count.

## Connecting

Claude Code:

```bash
claude mcp add --scope user --transport http css-sota https://css-sota-mcp.lusrodri.workers.dev/mcp
```

`--scope user` registers the server once for every project on the machine. Leave it out and it is
added to the current project only.

Claude Desktop: remote servers go in through **Settings → Connectors → Add custom connector**, not
through `claude_desktop_config.json` — that file only takes local stdio servers. Paste the endpoint;
the connector asks for no client id and no secret.

Cloudflare AI Playground: open https://playground.ai.cloudflare.com/, paste the endpoint, connect.

MCP Inspector: `npx @modelcontextprotocol/inspector@latest`, set transport to Streamable HTTP,
connect to the endpoint.

## The six tools

Pick by question, not by name.

### search_css_features

"Which features exist for X, and are they safe yet?"

Searches every CSS feature by keyword, Baseline status and the date it became interoperable.
Live from api.webstatus.dev, cached one hour.

### whats_new

"What can I start using that I couldn't before?"

Everything that reached Baseline in a date window, newest first, grouped by month.
Live from api.webstatus.dev, cached one hour.

### get_feature

"Tell me everything about this one feature."

Baseline dates, the version each browser shipped it in, spec links, Web Platform Tests scores, usage
share, and the reference prose straight from MDN's Markdown source. Live from api.webstatus.dev plus
mdn/content, cached one hour and twenty-four hours respectively.

### check_support

"Which browser versions support this exactly?"

Per-browser versions for any property, value, selector, at-rule or function — including vendor
prefixes and partial implementations. Answers from data compiled into the Worker, with no network
call at all.

### audit_css

"Does this stylesheet work for my users?"

Scans real CSS and reports every feature that misses the target, with the line it is on, what is
wrong, and the minimum version that would work. Answers with no network call. Source is capped at
400 000 characters.

Two target styles, because they answer different questions:

- **A Baseline level** — `baseline-widely`, `baseline-newly`. Asks "is this interoperable enough to
  ship?", judged against the `web-features` Baseline status.
- **An explicit browser list** — `chrome 120, safari 17.4, firefox 128`. Asks "does this work for
  *my* users?", judged against per-browser versions.

Browserslist queries (`last 2 versions`, `>0.5%`) are **not** accepted. Resolving them needs usage
data this server does not carry, and approximating them would produce confidently wrong audits —
exactly the failure mode the server exists to fix. The tool says so rather than guessing.

### dont_make_me_think

"How should this UI be designed — and is this page any good?"

Named after Steve Krug's rule: a page should be self-evident. Two modes.

`mode: "guidelines"` returns the principles to design against — Nielsen's 10 heuristics, Hick's and
Fitts's laws, WCAG 2.2, neurodiversity-inclusive design, motion and microinteractions (including
when Lottie or Rive earn their bundle cost), SVG craft and animation, light-first theming,
lightness, responsiveness. 37 principles across 9 topics, each with its rationale, actionable rules
and a source. Filter with `topic`.

`mode: "review"` checks HTML and CSS — or a fetched `url` — and reports what violates which
principle, with the line and the evidence.

It reads source; it does not render it. A Worker has no layout engine, so the review cannot measure
computed contrast, real target sizes, or where focus actually lands. It catches what is visible in
the markup: missing `alt`, blocked zoom, animation with no reduced-motion path, a removed focus
ring, a dark-only palette, vague link text, a nav past Hick's range. A clean result is a floor, not
a pass, and the tool says so in its own output.

## Baseline, defined

- **Widely available** — interoperable across Chrome, Edge, Firefox and Safari, desktop and mobile,
  for at least 30 months.
- **Newly available** — interoperable across all four, but recently so.
- **Limited availability** — at least one major engine is still missing it.

`web-features` encodes these as `"high"` / `"low"` / `false`; api.webstatus.dev and all Baseline
documentation say `widely` / `newly` / `limited`. This server normalises to the latter, so its two
halves never disagree.

## Data sources

| Source | How it is read | Behind |
| --- | --- | --- |
| webstatus.dev | Fetched per request, cached 1 hour | `search_css_features`, `whats_new`, `get_feature` |
| `@mdn/browser-compat-data` + `web-features` | Compiled into the Worker | `check_support`, `audit_css` |
| mdn/content | Fetched per request, cached 24 hours | `get_feature` reference prose |
| UX guidelines | Compiled into the Worker | `dont_make_me_think` |

`@mdn/browser-compat-data` unpacks to about 20 MB, far past a Worker's bundle budget. At build time
the CSS slice plus the `web-features` catalog are extracted, every unread field is dropped, and
per-browser support is encoded positionally. The result is roughly 1 MB of JSON — 120 KB gzipped —
shipped inside the Worker. It is regenerated on every build, test and deploy, so it always matches
whatever version npm resolved.

MDN reorganised its CSS reference under `Web/CSS/Reference/…`. Compat data records the slug a page
had when the entry was written, so building a raw GitHub path from `mdn_url` 404s. `get_feature`
resolves the canonical slug through MDN first, then reads the source.

## Limits on the hosted endpoint

| Limit | Value | On exceeding |
| --- | --- | --- |
| Requests per client IP | 120 / minute, per Cloudflare location | `429` with `Retry-After: 60` |
| Request body | 1 MB | `413` |
| `audit_css` source | 400 000 characters | schema validation error |

120/minute is sized against real usage rather than a round number: an agent working through a task
calls a handful of tools per turn, so a burst of twenty is unremarkable and 120 leaves room for a
shared address running several clients. For sustained traffic above this, self-host — the whole
thing is one Worker and deploys in a minute.

## Self-hosting

```bash
git clone https://github.com/LuSrodri/css-sota-mcp
npm install
npm run deploy --workspace mcp
```

Needs Cloudflare credentials, either `wrangler login` or `CLOUDFLARE_API_TOKEN` and
`CLOUDFLARE_ACCOUNT_ID`. The build command is not optional: the generated data directory is
gitignored and imported statically, so a build that skips it fails to bundle.

## Frequently asked

**What is css-sota-mcp?** A free, open-source MCP server that tells an AI coding agent which CSS
features are safe to ship, answering from live Baseline data and MDN browser-compat-data rather than
from training data.

**Does it need an API key?** No. The hosted endpoint is public and unauthenticated.

**How is it different from Can I Use?** Can I Use is a site a human reads, one feature at a time.
This is a tool an agent calls mid-task: give `audit_css` a whole stylesheet and a target and it
reports every feature that falls short, with line numbers.

**How current is the data?** The three webstatus.dev tools are never more than an hour behind the
Baseline dashboard. The bundled data is regenerated on every build and deploy.

**Which clients work?** Any that speak Streamable HTTP — Claude Code, Claude Desktop, the Cloudflare
AI Playground, the MCP Inspector, and others.

**Can I self-host it?** Yes, MIT-licensed, one Cloudflare Worker.