MCP Server Cards on 808 Sites: 32 Pass, and 52 of 65 Partials Fail E1

Of 808 hosts in our scan corpus, 32 pass check P2, the MCP server card check. Another 65 answer HTTP 200 at the card path and earn only partial credit, and 52 of those 65 also fail our soft-404 check. The stored evidence for a pass and for a partial is the same two words, "HTTP 200", so the status code alone cannot tell you which one you have.

Quick summary

Short answer for a site owner: a 200 at /.well-known/mcp/server-card.json proves nothing until you have fetched the file and parsed it. If you run an MCP server, publish the card and confirm it is JSON. If you do not run one, there is nothing to fix, and publishing an empty card to turn a line green would be wrong. Run npx aiscan-cli yoursite.com (or paste the address at aiscan.site, free, no account) and read the P2 line and the E1 line together. If you would rather check by hand, the curl commands are near the end.

What P2 grades

P2 sits in the capabilities group of the rubric. It requests one path on the host, /.well-known/mcp/server-card.json, and records the HTTP status as evidence. The check is optional and in the bonus tier with weight 5. Its remediation text says to publish the file "if you expose an MCP server", and it cites the Model Context Protocol specification. The check page is on the capabilities checks docs.

Three outcomes exist in the 2026.08.2 rubric:

• Pass: the file answers and the scanner is satisfied with it. The check earns 5 of 5.
• Partial: the file answers 200 but fails something the scanner looks at in the body. The check earns 2 of 5.
• Info: no card. No penalty, because most sites do not run an MCP server.

How the card itself is specified is a separate question. The format is still a draft, and Publish an MCP Server Card So Agents Can Find Your Tools covers the draft, the seven live files we read by hand in September and the stack-specific file locations. This post asks a different question: across everything we have scanned, how often does the card path answer, and what does an answer mean?

How we counted

We took the latest site-scope scan for each host on rubric 2026.08.2, excluded aiscan.site, and read check P2 and its evidence string from each stored report. That gave 808 hosts on 5 Nov 2026. The population is sites people chose to scan, not a sample of the web. It leans toward sites that care about agent readiness, which means the true adoption rate on the open web is almost certainly lower than 4%. Every figure here is an aggregate. No scanned host is named, and we did not fetch any third-party card to fill gaps.

The counts for P1, P3 and E1 come from the same scans, the same day. Each row of the tables below is one host counted once.

The full distribution

The 711 info hosts split into 601 with HTTP 404 and 110 with some other result: a block, a rate limit or a server error. We did not break those 110 down further for this post.

The mean scores are correlation, not effect. A site that publishes a card is usually a site that has done other agent-readiness work, and a card adds at most 5 points. Treat the gap between 93 and 54 as a description of who publishes, not of what the card earns.

Pass and partial are indistinguishable in the evidence

All 97 hosts that answer 200 carry the same evidence string, HTTP 200. The scorer gives 5 points to 32 of them and 2 points to the other 65. Something about the response decides which, and the stored report does not keep it. We cannot say whether the 65 partials returned HTML, malformed JSON, a wrong content type, or JSON missing fields the scorer wants.

That is the same gap that the OAuth discovery study hit on 4 Nov, where 50 hosts answered 200 without passing P4, and the same one the Web Bot Auth study found on B3, where pass and partial also read HTTP 200. Three optional well-known checks now share the pattern. What we can do is look at what travels with the split.

Eight in ten partials fail the soft-404 test

Check E1 requests a path that cannot exist and expects a real 404. A host that answers 200 to a made-up URL fails it. Here is E1 by P2 outcome:

Across the corpus, 86 hosts fail E1. Fifty-three of them (61.6%) are in the 97 hosts that answer the card path with a 200. Those 97 are 12.0% of the corpus. A host that answers the card path with a 200 is nearly twelve times as likely to fail E1 (53 of 97, 54.6%) as a host with no card (33 of 711, 4.6%).

The reading that fits: most partials are not cards at all. They are sites that return a 200 page, usually the front-end shell, for any path you ask for. The scanner sees a 200 at the card path, cannot find a card in the body, and awards the 2 points. The pass group looks nothing like this: 30 of its 32 hosts pass E1.

We have not seen the bodies, so this is an inference from co-occurrence. It is a strong one, but a host can answer 200 to everything and also publish a real card, which may be what the one pass that fails E1 is.

The same hosts pass the other well-known checks

Two neighbouring checks probe other well-known paths. P1 requests /.well-known/api-catalog (the RFC 9727 API catalog) and P3 requests the agent skills index. P1's stored evidence is the status at its path, for example 200 at /.well-known/api-catalog. Here is what each P2 group does on the two checks:

Only 89 hosts in the whole corpus pass both P1 and P3. Sixty-two of them are P2 partials, 20 are P2 passes and 7 are hosts with no card. Of the 62 partials that pass both, 51 fail E1 (82.3%).

If a site genuinely publishes an API catalog, an agent skills index and a server card, all three pass and the host is clean on E1. Twenty hosts do that. If a site answers 200 for everything, the same three lines go green by accident, and E1 fails. Fifty-one hosts do that. The scorer rewards both, with different amounts of credit on P2. Neither pattern is visible from the P2 line alone.

Two practical consequences follow for anyone reading a scan:

1. A partial on P2, together with a pass on P1 and P3, is a reason to run the made-up-path test before you celebrate.
2. A clean E1 changes the reading of everything else on the well-known probes. The soft-404 line is the one to fix first.

Does a server card travel with OAuth metadata?

A site that runs a real MCP server with authentication has a reason to publish both a card and RFC 9728 protected-resource metadata, which P4 checks. Here is how P4 sorts:

Six in ten card publishers also pass P4, against two in ten of the partials. That is the most believable sign in the data that the passing cards belong to real servers: the people who wrote them also wrote the OAuth documents a client needs next. The partials look more like the catch-all hosts of the section above.

Platform split

The platform field is the scanner's detection, and unknown is the largest bucket. Counts are hosts.

Several of these cells hold fewer than a dozen hosts, so the shares are leads, not findings. One pattern is strong enough to mention. Among the 12 Astro hosts that answer 200, 10 pass. The stored data does not say why. WordPress hosts that answer 200 mostly score partial, 15 of 18. That fits a theme or plugin that renders a page for unknown well-known paths instead of returning a 404, though we have not confirmed which software in each case.

For 39 of the 97 answering hosts the scanner flags the site as an app (19 passes, 20 partials). App detection does not separate pass from partial.

What this means for the P2 line on your own scan

Read the line in one of these four ways:

The partial-with-clean-E1 row is the smallest group: 10 hosts of 65. These are the hosts where the 2 points mean something. Everyone else in the partial column should expect the partial to disappear as soon as the soft 404 is fixed, or to turn into a pass only if they then publish a real card.

Check it yourself

AIScan is the quickest way. Run npx aiscan-cli yoursite.com, or paste your address at aiscan.site. Read three lines together: P2 (the card), P1 and P3 (the neighbouring well-known files) and E1 (correct 404 handling). The capabilities group is explained on the checks page.

If you would rather check by hand:

# 1. What does the card path return, and as what?
curl -s -o /tmp/card.json -w '%{http_code} %{content_type}\n' https://yoursite.com/.well-known/mcp/server-card.json

# 2. Is the body JSON?
python3 -m json.tool /tmp/card.json > /dev/null && echo "valid JSON"

# 3. Does a path that cannot exist return 404?
curl -s -o /dev/null -w '%{http_code}\n' https://yoursite.com/.well-known/zz-not-a-real-file

The first line should read 200 application/json, the second valid JSON, and the third 404. If the third prints 200, your host answers every path with a page, and none of your well-known files can be trusted by a client until that is fixed. If the first line prints 200 text/html, the 200 is your site's shell and not a card.

Who should publish one

Publish a card if you run a remote MCP server that you want clients, registries and scanners to find without being handed the URL. Publish an MCP Server Card So Agents Can Find Your Tools walks through the registry route and the self-hosted file, on Astro, Docusaurus, Hugo, Lovable and Next.js. If your server also authenticates clients, add the protected-resource metadata described in OAuth Discovery for AI Agents. If you run no MCP server, an info line is the right result.

What AIScan cannot see here

• The body. The card's JSON, its fields, its $schema, its tool list and its content type are not in the stored report. Validity is outside this study.
• Why the scorer chose 2 over 5. Pass and partial share an evidence string. The reason lives in code we did not read for this post.
• Servers without a card. A site can run a live MCP server and publish no card. P2 shows info for those hosts, and so does the 88% in this study.
• Intent. A catch-all host may have no idea it answers 200 for the card path. The scan reports a behaviour, not a decision.
• Change over time. This is one snapshot of the latest scan per host. Scans of the 97 answering hosts range from 28 Aug to 5 Nov 2026, so a host fixed last week may still show its old line if nobody has rescanned it.

Your next action

Run the scan and read P2 and E1 together. If E1 fails, fix the soft 404 first, because it undermines P1, P2, P3 and P4 at once. Then decide whether you run an MCP server at all. The check details are on the capabilities page, and the rest of the agent-readiness walkthroughs are collected at aiscan.site/guides.

Sources and dates

• AIScan scan database, rubric 2026.08.2, latest site-scope scan per host, 808 hosts, queried 5 Nov 2026.
• Model Context Protocol specification, cited by check P2.
• RFC 9727, the API catalog that check P1 requests.
• Related AIScan studies: OAuth discovery metadata (4 Nov 2026), Web Bot Auth directories (31 Oct 2026) and Agent Discovery Files Census (31 Oct 2026).