12,429 addresses were contacted once. 5,785 answered. 152 said who pays them.
Report 0 counted declarations and promised that the third count, how many actually answer, would appear as report 1 or not at all. It is here. Every https endpoint the official registry declared was contacted exactly once, read only. No tool was called on any server. The run took a full day and finished the list rather than finishing when I got bored.
What happened when I knocked
Held and pending are kept apart on purpose. "I could not measure this" and "I measured this and the condition was not met" are different sentences, and collapsing them is how a survey turns its own blind spots into other people's failures.
Read these before quoting the headline
95 of the 918 pending rows were my fault
Corrected 2026-08-24. What this card said first is kept at the bottom, because it was wrong in a way worth showing.
Every one of the 918 was contacted again. 33 answered server/discover under the current 2026-07-28 revision. 62 more answered initialize once I announced 2025-11-25 instead. That is 95, or 10.3 percent of the bucket. The remaining 820 spoke no MCP at any of the four versions tried, and 0 were unreachable.
The real defect was worse than the one I published. This walk did not merely speak an older revision — it announced protocol version 2024-11-05, which most of the registry has dropped. 137 of the 206 initialize refusals were HTTP 400, the response the spec prescribes for a version a server does not support. I counted a correct refusal as "did not speak MCP". All 62 were recovered at 2025-11-25; not one needed a version older than that.
So the headline moves. Measured goes from 5,785 to 5,880 — 46.5 percent to 47.3 — and pending drops from 918 to 823.
152 disclosures, seven different field names
Of the 5,785 that answered, 152 disclosed compensation somewhere a machine can read. That is 2.6 percent. The seven names in use are payment (104), pricing (27), payments (15), compensation (5), capabilities.payment (4), capabilities.pricing (1), and one A2A payments extension.
The other 5,633 servers are not accused of anything. There is no agreed place to put this, so silence here is the absence of a convention, not evidence of a hidden hand. What the number measures is that the convention does not exist yet — and that an agent choosing between these servers has nothing to read.
9,109 hosts, and the largest carries 1,312
gateway.pipeworx.io declares 1,312 of the 12,429 addresses, and all 1,312 answered. The top ten hosts carry 19.7 percent of everything. Meanwhile 8,691 hosts carry exactly one endpoint each.
Counting servers is not counting operators. 3,755 distinct hosts and 2,852 distinct organisations account for the 5,785 that answered. Anyone building a trust argument on "how many servers support this" is quoting a number that one operator can move by a tenth on their own.
Answering is not behaving well. This measures whether an address speaks the protocol, nothing else. The five conditions are a separate measurement and this report does not apply them to anybody.
596 servers published an agent card; 4,762 did not, and 427 could not be read. That last number is mine, not theirs — a fetch that failed on my side is recorded as not read, not as absent. The three are never added together.
1,108 servers required a session id. That is the old revision's mechanism, so this number will mean something different after a walk on the current one.
My own five endpoints are in the data and marked as mine. All five answered. They are not excluded from the totals and they are not allowed to be quoted as an independent result.
Reproduce it, and tell me where I am wrong
sha256 of the JSON linked at the top, computed over every field except the hash itself.
The first walk wrote all 12,429 rows and none of them were used. Eighteen minutes in, my own name resolution died. From that minute onward 11,307 consecutive rows were recorded as not reached, with 0 successes among them, and the tool wrote each one as a fact about somebody else's server. It looked like a finding. It was a picture of my own laptop.
Nothing was salvaged. The 1,122 rows written before the resolver died are probably fine, and they were thrown away too: choosing which rows to keep after seeing the data is exactly the move this survey exists to avoid. Run 2 added a control probe that aborts the walk when the control stops answering, and started again from zero.
The same disease showed up a second time, in the regression test for a different system, which spent several hours testing a stale copy of the file it was supposed to be checking and reporting that everything passed. An instrument that measures itself will always say it is fine.
If you get a different number, I would like to know. Send your count and your stop reason, and if you are right this page gets corrected with both numbers left visible. The wrong one is not deleted.