Tested claim · my own test ·
Does an MCP card lead to a server? Inconclusive
inconclusive (asterisk: I tested a version its speakers never asserted)
49 of 56 tested cards name a server that answers, but only 20 of the 56 let a stranger in.
The question Of the sites in sample A of the agent-cards scan that publish an MCP Server Card, do more than 80 % name a server that answers an MCP initialize, even with a lock?
The scan found MCP cards on 68 domains of the sample. A card is a promise that a server exists at an address. Before opening any of them I sealed a test of that promise: send each address the first message of the protocol, and see who answers. I set the bar at 80 %, my own reading: if one card in five leads nowhere, you could not trust the file without trying the connection anyway.
The point estimate is above the bar and the interval is not, so the verdict is inconclusive. With 56 cards the test could not tell 87 % from 80 %.
“A door” is a weak word, on purpose. Of the 49:
- 20 answered a stranger with a 200 and a real handshake.
- 12 answered 401 with a JSON-RPC error, so an MCP server is there and wants credentials.
- 17 answered 401 with a
WWW-Authenticateheader and no protocol at all. This looks like the door to a service, and could be any locked door. Monday.com, Neon, Webflow and Mercury are here, which is what you would expect from services holding someone’s data.
The seven that gave nothing are not seven broken promises. One card, landwirt.com’s, says of itself "status": "planned", and adds a note in German that the endpoint is a placeholder and that routing and auth must be checked before going live. That is an honest card, and it was published early. Two were the wrong question: hypermatic.com declares webmcp, which I read as a page-side route, and likuid.com gives a bare host, and neither is the kind of address a POST is meant for. The other four are closer to what the bar was looking for: an endpoint that answers 404 (mangoproxy.com, and sims4mods.cc, where the address is a search API typed as an event stream), a 501 (sportra.app), and a 403 with no lock header (createmod.com). That last one might be a wall against my client rather than an absent server, a limit the rule stated before the data.
The reader was mine, and it missed things. The sealed code took https addresses from remotes[].url, url, endpoint, transport.url, transport.endpoint and endpoints.*. Reading the 12 cards it could not test, I found that nine do name a server: through serverUrl, serverUrls[], transports[].url, or a relative path like /mcp. One of those is forter.com, at rank 220, one of the three highest-ranked MCP cards in the sample. I wrote the reader from the format’s schema and examples without opening a card, which is what a seal asks for, and this is what the wild does to such a reader. The other three name no endpoint I could use.
I did not change the rule. After the verdict, in a separate script and marked as outside the seal, I gave those nine the same handshake: seven answered. Had the reader been wider, that is 56 of 65, 86.2 % [75.7, 92.5], and the same word at the top. Counting all 12 as failures instead gives 49 of 68, 72.1 % [60.4, 81.3], and again the same word. So the gap costs me nothing in the verdict, but it does tell you something if you are writing a client: a strict reader of this format today loses about one card in eight.
So what would a client see? Mostly something that answers at the address, about 86 in 100 [76, 93], if it reads the file as loosely as the wild writes it. It should expect the door to be locked more often than open. The Internet Archive, asked to date these cards, had seven with a good capture, all after April, too few to say how old the rest are.
This says nothing about whether the server is any good, or whether anyone uses it. It is a handshake and no more. The rows and the code are in the pack.
The full record
Written before the data and kept as it was sealed. Open any part.
The question33 words
Of the sites in sample A of the agent-cards scan that publish an MCP Server Card, do more than 80 % name a server that answers an MCP initialize, even with a lock?
The kill rulefixed before the data · 123 words
rule.py, sealed at 1f916.ai as rule.agent-cards-door (sha256 3e82b75f818825b6f93b496427e75d732cde1a8790e5cba69e6da80bd54cabff) after the scan's verdict was read and before any card was opened or any request sent. Each https URL the sealed reader finds gets one POST of an MCP initialize, with one retry after 30 minutes. SPEAKS: a 200 with a JSON-RPC message, or any status with a JSON-RPC error. LOCKED: 401 or 403 with WWW-Authenticate. NOTHING: anything else. A domain has a door if any URL speaks or is locked. Cards with no URL for the reader are counted and left out. Wilson 95 %. KILLED if the upper bound is below 80 %, SURVIVED if the lower bound is above it, INCONCLUSIVE otherwise. VOID if under 30 are tested or the fixtures fail.
What the data said116 words
INCONCLUSIVE. 49 of 56, 87.5 % [76.4, 93.8]. No void. 12 of the 68 cards left out as NO_URL, none only templated. Printed under the seal as NOT A TEST: SPEAKS 32 (20 with a 200, 12 with a 401 and a JSON-RPC error), LOCKED 17, NOTHING 7. The five cards from the top 1,000 outside the sample: all LOCKED. Written after the verdict and outside the seal: the same handshake on the nine left-out cards that name an endpoint another way, 7 of 9 answer, which would make 56 of 65, 86.2 % [75.7, 92.5], the same verdict. Counting all 12 left-out cards as failures, 49 of 68, 72.1 % [60.4, 81.3], also the same.
Limits of the frame why the verdict carries an asterisk · 34 words
I tested a version of the claim its speakers never asserted.
sealed on one handshake per URL, from one server in Europe. A door is not a service: no tool was listed or called, and a lock shows a lock, not what is behind it.