TL;DR: MCP Server Cards went Final on October 6. We counted every remote MCP server in the registry on October 12, and again eight days later with the same method. The share of hosts with a valid card rose from 1.9% to 2.7%. The registry added 18% more hosts in eight days. Hosts with a valid card? 66% more. Nearly four times faster. We checked twice. Most cards still leave browsers out, but the number that don't nearly doubled.
In Plain English
What a Server Card is. A small public file that tells an AI app who an MCP server is and how to connect, before it connects. Think of it as the server's business card, pinned to the door.
What two counts found. Still very few servers have one, but more each week. Of the cards that exist, most are missing something browsers need to read them.
What you can do. Paste your server's address into Server Card Check. It tells you, rule by rule, what passes and what to fix.
The facts follow below.
The count, twice
SEP-2127 merged as Final on October 6. It gives every MCP server a card: a JSON document with the server's name, version, description and connection details. Clients find it at <server-url>/server-card, or through an AI Catalog at /.well-known/ai-catalog.json.
We read the whole MCP Registry and kept the latest version of every server with a remote endpoint. Then we checked each address the way a client would, read-only: GET and OPTIONS requests, nothing that changes state. Twice, with the same scripts.
| What we counted | Oct 12 | Oct 20 |
|---|---|---|
| Registry entries read | 145,157 | 162,532 |
| Endpoints checked | 26,105 | 29,838 |
| Something answered at a card location | 3,609 | 4,184 |
| …a web page, not a card | 637 | 733 |
| Schema-valid cards | 2,194 (8.4%) | 2,539 (8.5%) |
| Valid, by distinct host | 352 of 18,268 (1.9%) | 586 of 21,526 (2.7%) |
| Valid, by registry namespace | 344 of 15,926 (2.2%) | 528 of 18,856 (2.8%) |
Entries are not servers. 8.5% looks healthy until you see where it comes from. One gateway publishes a card for each of its registry entries: 1,791 on October 12, 1,872 now. Its cards are real, but they are one deployment. Count by host, by publisher, or leave that gateway out, and the answer lands in the same place: under 3%.
What moved. In eight days the registry added 12% more entries and 18% more hosts. Hosts with a valid card went from 352 to 586, up 66%. 246 hosts gained one, 197 of them on servers that weren't in the registry a week earlier. 12 lost theirs. Leaving the large gateway out, valid cards went from 403 to 667.
Valid is not the same as working
A card can pass the schema and still let its users down.
-
Web pages where the card should be. 733 endpoints answer the card's address with
200 OKand an HTML page, usually a catch-all route. A client asked for JSON and got a website. 37 of last week's are gone; 133 new ones appeared. - Browsers left out. The spec says hosted cards MUST send CORS headers and lists four. By the method we used on October 12, the number of JSON cards sending all four rose from 179 to 324 (6.0% to 9.4%). We checked that the yardstick hadn't moved: both versions of the checker, run on the same 200 endpoints in the same minute, agreed on every card. Under the stricter rule the checker uses now, the figure is 298.
-
Repeat visits. 553 cards answer a repeat request with
304 Not Modified, up from 433. The rest send the whole card every time.
We checked ours too, on October 12. Our card at context.faf.one passed the schema and failed two CORS rules. It's fixed, and the fix is the worked example below.
How to make yours pass
The most common failures on October 20, across the 1,579 JSON cards outside the large gateway:
| Failure | Cards | Fix |
|---|---|---|
ETag not exposed (MUST) |
1,174 | Send Access-Control-Expose-Headers: ETag on the GET |
Preflight doesn't allow If-None-Match (MUST) |
1,172 | Answer OPTIONS with Access-Control-Allow-Headers: Content-Type, If-None-Match
|
No ETag, no 304 (SHOULD) |
1,005 | Send an ETag; answer a matching If-None-Match with 304
|
| Not schema-valid (MUST) | 912 | Run the checker; it names the field |
| Wrong content type (SHOULD) | 888 | Serve it as application/mcp-server-card+json
|
$schema missing or wrong (MUST) |
791 | Use the v1 Server Card schema URL exactly |
description too long or empty (MUST) |
722 | 1 to 100 characters |
And the web pages: serve the JSON at /server-card, or return 404 there. Not a 200 with your homepage.
A worked example: ours. Our card carries a generated_at time that changes on every request, by design, so a strong ETag would never repeat. The card now sends a weak ETag, hashed without that one field. Weak validators mean "the same meaning", and that's what a client needs to get a 304. One field left out of a hash; two new tests.
npx mcp-server-card-check https://your-server.example/mcp
Server Card Check is the census's checker, made into a tool: MIT-licensed, vendor-neutral, 39 checks, each marked MUST or SHOULD and linked to the spec section it comes from. Read-only by default. It runs in the browser, from the command line, or as a library, and exits 1 on any MUST failure, so it fits in CI.
A shared test
MCP's official conformance suite doesn't test Server Cards yet. There's an open proposal for that scenario (conformance #550), and the offer to help write it stands. A shared test is better than anyone's private one, including ours.
Method
Registry read at 12:02 UTC on October 20; checks ran until 15:14 UTC, with no errors. 304 addresses were templates (such as {tenant}) and were skipped. The checker was v0.4.1. Its rules changed between the two counts (it was reviewed independently twice in between), so every figure compared here was counted by the October 12 method, and that method was re-checked against both versions. Both summaries are in the repository, with the scripts, so every number on this page can be reproduced.
We'll count again while it's moving.
Checked yours?
If you run a remote MCP server, paste its address into the checker. No card yet? The report tells you what a valid one needs. Have one? It takes ten seconds to see if browsers can read it.
Originally published at faf.one on October 13, 2026, and updated on October 20 with the second count.
Top comments (0)