css-sota-mcp

An MCP server that answers what CSS you can actually ship today — from live Baseline data and MDN browser-compat-data, not from a model's training set.

Agents are confidently wrong about browser support. They will tell you anchor-name is fine, or that :has() needs a polyfill, depending on when their weights were frozen. This server replaces the guess with the current answer.

• Endpoint — https://css-sota-mcp.lusrodri.workers.dev/mcp (Streamable HTTP, no auth)
• Docs — css-sota-mcp.pages.dev

Tools

Tool	Answers	Source
search_css_features	"Which features exist for this, and are they safe yet?"	webstatus.dev
whats_new	"What can I start using that I couldn't before?"	webstatus.dev
get_feature	"Tell me everything about this one feature."	webstatus.dev + mdn/content
check_support	"Which browser versions support this exactly?"	bundled browser-compat-data
audit_css	"Does this stylesheet work for my users?"	bundled browser-compat-data

check_support and audit_css answer with no network call at all — the data they need is compiled into the Worker.

audit_css targets

Two target styles, because they answer different questions:

• A Baseline level — baseline-widely, baseline-newly. Asks "is this interoperable enough to ship?", judged against 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.

Connect

claude mcp add --transport http css-sota https://css-sota-mcp.lusrodri.workers.dev/mcp

<details> <summary>Claude Desktop</summary>

{
  "mcpServers": {
    "css-sota": {
      "type": "http",
      "url": "https://css-sota-mcp.lusrodri.workers.dev/mcp"
    }
  }
}

</details> <details> <summary>Cloudflare AI Playground</summary>

Open playground.ai.cloudflare.com, paste the endpoint into the MCP server field, and connect. The five tools appear immediately.

</details> <details> <summary>MCP Inspector</summary>

npx @modelcontextprotocol/inspector@latest

Set transport to Streamable HTTP and connect to the endpoint.

</details>

Limits on the hosted endpoint

The endpoint is public and unauthenticated on purpose: every tool is read-only over public datasets, so there is nothing to protect from disclosure. What is worth protecting is the account's request budget and the server's standing with the upstreams it proxies.

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.

Cloudflare's own guidance prefers keying rate limits on a user or tenant id rather than an IP, since an IP can be shared behind NAT or a privacy relay. This endpoint has no authentication and so no such id; the limit is set generously enough that the trade is a fair one.

If you expect sustained traffic above this, run your own instance — the whole thing is one Worker and deploys in a minute.

Layout

mcp/       The MCP server — a Cloudflare Worker
landing/   Documentation site — Vite, on Cloudflare Pages

How the data is put together

@mdn/browser-compat-data unpa