State of the Agent Internet: September 2026

Published 26 September 2026 by Council of AI (CSOAI Ltd, registered in England and Wales, no. 16939677). Figures as of 2026-09-26 10:34:15 UTC.

Measurement, not endorsement. This report gives aggregates only. It names no service, operator or issuer in a negative finding, and it scores, ranks or approves no company. An INCONSISTENT or FAILED result says that two public statements disagree, or that a check did not pass. It is not evidence of bad intent.

Summary

An agent that finds a service through a public catalogue can trust very little about it without checking. Discovery is abundant. Verification is the exception.

• The official MCP registry held 36,134 entries listing 22,151 distinct remote endpoints. Of the 22,196 endpoints in the two MCP catalogues we read in full, we observed 21,126, and 13,087 answered as MCP servers.
• 2,764 of 5,828 responding MCP endpoints contradict themselves across their own public documents on at least one point. Most of these are version strings. 256 disagree on something with more substance: tools, authentication, protocol or payment.
• Of 422 A2A agent cards served, 33 carry a signature and 13 verify under the rules of the spec version the card declares.
• Of 2,713 x402 payment hosts, 1,636 answered with HTTP 402 and 477 (17.58%) returned a fully conformant challenge.
• For tokenised assets, a third-party state proof of supply was possible on 40 of 113 issuer-listed deployments we read. The others rely on an operator's API, or could not be checked.
• Re-running signed model measurements on a second runtime, 46 of 140 cards reproduced item by item with the same counts, although 97.2% of individual item grades matched.
• We measured ourselves first and found 8 places where external indexes list us differently from what we publish. We published three corrections to our own figures on the day of this report.

Discovery: what the catalogues contain

On 26 September a census frame read five public catalogues, each paginated to its signalled end where it had one.

Smithery's anonymous interface stops after five pages and lists no endpoint URLs, so the read is PARTIAL and we give no combined population total. The registry grew from 35,873 entries in our read of the previous day.

Which MCP endpoints answer

The population is every remote endpoint listed by the MCP registry or the Docker catalogue: 22,196. We sent only discovery requests, never a tool call, never a credential and never a payment, at most one request per second per host, and honoured robots.txt. 10,039 endpoints were contacted on 26 September; for 11,087 the state observed on 25 September (under 48 hours old) is carried. 1,070 were not contacted, each with a recorded reason (934 because of robots.txt, 123 because the listed URL was a template). The read state is therefore PARTIAL.

Of the 7,282 endpoints that answered on 26 September, 392 answered the newest protocol request (2026-07-28); the rest answered only the earlier handshake.

Hugging Face Spaces

On 25 September we covered all 10,822 Spaces tagged mcp-server. We read each Space's runtime stage from the Hub first and contacted a Space only if it was running, so none was woken. 8,164 were not running: 3,059 in a runtime error, 3,008 asleep, 1,251 paused and 759 with a build error, among other stages. Of the 2,658 contacted, 2,232 answered MCP and 401 offered only legacy SSE. About one tagged Space in five was serving MCP at that moment. A tag is self-declared.

Does the listing match the server?

The question is whether one MCP service tells a relying agent one current contract. We compared what each service says about itself across its public surfaces (its registry entry, /.well-known/mcp.json, its server card and any x402 manifest) with its live discovery answer. A dimension is judged only where two or more surfaces speak to it. The plan was 5,828 endpoints, and every one was attempted (record v0.1.2).

• Endpoints with at least one inconsistent dimension: 2,764 of 5,828 (47.4%). The superseded records gave 2,778 and then 2,768; see Corrections.
• Inconsistent on VERSION only: 2,508. Inconsistent on another dimension: 256.
• 247 endpoints had a surface that did not answer, so this run is labelled PARTIAL.

The version dimension

2,632 of the 2,644 version contradictions compare the registry's server.version with the live serverInfo.version. The registry schema calls these the same field ("Equivalent of Implementation.version in MCP specification"), so we compare them. The most common live values among the contradictions are 1.0.0 (514) and 0.1.0 (382). A version contradiction is weak evidence that anything is wrong. It is strong evidence that a version string is not a reliable way for an agent to pin a contract.

A pattern, cause not measured: 43 endpoints on 14 hosts report the live version 1.27.0, and 42 of them contradict a registry that gives 9 different versions for them. Across live values from 1.24.x to 1.29.x, 243 of 251 contradict the registry. One possible explanation is that a library fills in its own version when a server sets none. That is a hypothesis; we have not measured it.

Timing: live answers and documents were read up to about 5.5 hours apart, so a deploy in between can show as INCONSISTENT. An inconsistent row says that two public statements disagree. It does not say which one is true.

Signed agent cards

The A2A card census covered all 443 registry listings (25 September). 422 served a card, and 33 of those (7.8%) carry a signature. Each card is judged by the rules of the spec version it declares (record v0.1.1):

Why the numbers moved: A2A spec section 8.4.3 (step 3) says to remove properties that hold default values before verifying. Our first prober did not. Of the 25 signed cards that declare 1.x, 8 verify under the spec's procedure, 7 fail and 10 are uncheckable. 6 of the failures verify over the card as served, with defaults left in: the signing tools skipped the step the spec requires. 3 cards that declare 0.x verify under 0.x rules, which define no canonicalisation, but would get another result under 1.x rules. 9 of the uncheckable cards point to no key at all.

Our reading is that signing tools and the spec's verification procedure currently disagree. That is a finding about a canonicalisation gap, not about bad actors. A verified card proves only that the key it points to signed its bytes. It does not prove who the agent is.

On-chain agent registrations

The ERC-8004 identity registry lets anyone register an agent on-chain. We read every agent id on three chains with read-only calls: 505,635 ids (51,458 on Ethereum, 95,776 on Base, 358,401 on BNB Smart Chain). An id is not an operator; one operator can hold many.

• 52,469 ids have no registration file at all.
• We fetched registration files for the top fifth by a published feedback signal (101,127 ids). 231,014 ids were outside that plan or refused, 13,788 files could not be read, and 187,513 files declare no MCP, A2A or web endpoint.
• 13,210 ids declare an endpoint. Of 2,144 distinct declared MCP endpoints, we contacted 2,113: 580 answered as MCP, 1,092 answered but not as MCP and 393 were unreachable.
• Of 4,389 declared A2A endpoints, 886 served a card and 3,407 had none at the well-known path. 5 served cards carry a signature, and 4 verify.

This census is PARTIAL: registration files were fetched only for the plan, and within a fetch budget.

Payment doors (x402)

Each day we read both public x402 Bazaar indexes to the end (17,548 and 6,909 resources) and send one GET to each distinct host. Nothing is paid. On 26 September there were 2,713 hosts:

• 1,636 answered HTTP 402; 1,527 sent a PAYMENT-REQUIRED header; 555 declared x402Version: 2 in the body.
• 477 (17.58%) were fully conformant: a 402, the header, version 2 in the body and a Bazaar extension block.
• 1,013 pass on the header alone but not in the body. 19 were unreachable.
• The day before there were 2,735 hosts and 470 conformant: 26 hosts were added, 48 dropped, 3 became conformant and 4 lost conformance.

Context from others (their findings, not ours)

We did not measure settlement volume or who pays whom. Two published on-chain analyses did. Visa and Artemis ("Agentic Payments from the Ground Up", July 2026) report that x402's raw totals of about 135.7 million US dollars settled across 178.3 million transactions fall to about 15.0 million dollars across 109.6 million once activity resembling wash trading, testing or internal transfers is filtered: roughly 89% of the dollars and 39% of the transactions. TRM Labs (9 September 2026) examined 52.7 million dollars settled across 198.9 million x402 transactions on Base, Solana and Polygon, found 25.62 million dollars likely to be commerce, and attributed 0.6% to 7.5% of that to AI agents. The two use different methods and windows, and their figures should not be combined. Visa and Artemis · TRM Labs. Our own measurement says nothing about whether any door would deliver after payment.

Tokenised assets across ledgers

The question: where an issuer publishes a list of where its asset lives, can a third party read each ledger, and with what strength of evidence? From 280 tokenised-asset candidates in public value sources we took the top fifth (56) to read first. Value decides only what we read first; it is not a measurement and not a ranking. 21 selected assets have an issuer-list reader wired; 41 do not and are UNMEASURED. We read 113 issuer-listed deployments on 26 September.

• The level depends on the pair of reader and ledger, not only on the ledger: the same chain can appear at two levels for different assets.
• Issuer lists: 14 assets publish a readable deployment list. 3 are bank deposit-token services on private, permissioned ledgers, with nothing a third party can read. 1 has no public deployment list, and 3 list pages could not be read.
• Issuer claims against ledgers: 4 assets consistent, 2 inconsistent, 15 uncheckable. The inconsistencies fall into two classes: 3 deployments that an issuer lists as deprecated still show issued supply ("deprecated" is the issuer's word; we do not assess its meaning), and 1 contract, on a ledger the issuer does not list and at an address it lists elsewhere, answers with the product's symbol. Whether that contract is the issuer's is not established.
• These reads measure issued supply only. They say nothing about reserves, backing, net asset value, ownership or redeemability, and there is no cross-asset total. Nothing here is investment advice.

The same model on two runtimes

A published score is only useful if it belongs to the model rather than to the machine it ran on. We re-ran signed measurement cards on a second runtime with the same model digest, the same instrument and the same item bank: the first runs were on an RTX 3090, the re-runs on Kaggle 2×T4 (ollama 0.33.0, temperature 0, seed 0).

In batch 2, 8,624 of 8,870 item grades matched (97.2%) and 7,404 raw outputs were byte-identical. Yet only 49 cards had the same grade on every item, and 46 of those also had the same counts. Two runs can reach the same score with different item grades, so we now admit a reproduction only at the item level: same instrument, model and bank, same counts, and the same grade on every item. The 37 cards that meet that rule with at least 30 graded items are released for quoting; the rest are not.

The second runtime is not deterministic either: a repeat on the same T4s was not byte-identical for 20 model-axis pairs. The 3090's GPU driver and its ollama version at run time were not recorded, and two runtimes cannot separate hardware effects from the software stack. A third runtime would be needed.

Ourselves first

Before measuring anyone else, we measured how external indexes list us: 138 cells, one for each of our offerings in each index that could list it.

• 37 consistent, 8 inconsistent, 55 not listed (recorded only after a complete read of an open directory), 37 uncheckable and 1 not declared.
• The 8 inconsistencies are ours to fix: 6 x402 listings whose URL query string differs from our manifest, 1 directory tool list that differs from what our MCP server serves, and 1 registry package version that lags the package index.
• 40 registry endpoints are listed under our own names, and 39 of them point at a host that does not resolve. They are counted as unreachable in the census above, like anyone else's.
• We also record 118 public signals about ourselves each day (downloads, citations, index listings): 103 were measured. 50 are our own activity, 15 come from outside and 43 cannot be separated, so download counts are context, not users.

What we did not measure

• Whether any service, agent, card or payment door is safe, correct, maintained, or does what it says.
• Anything behind authentication. We sent no credential, called no tool and paid for nothing.
• Smithery beyond the entries its anonymous interface serves; any combined population total.
• Reachability from any other network location, or at any other time.
• Which of two disagreeing public statements is true.
• Identity: a verified signature proves who holds a key, not who an agent is.
• Payment settlement, delivery after payment, price or volume.
• Reserves, backing, net asset value, holders or redeemability of any asset; the 41 selected assets with no reader wired; permissioned ledgers.
• A third runtime for the reproduction study, the 3090's driver, or its ollama version at run time.
• Traffic or ranking in any index that lists us.

Corrections

We published three corrections to our own published figures on 26 September 2026. Each superseded record stays published byte for byte beside its correction.

1. Contract parity v0.1 to v0.1.1. Four misreads in the producer were fixed. Endpoints with any inconsistency went from 2,778 to 2,768.
2. A2A card census v0.1 to v0.1.1. The spec's default-value removal (section 8.4.3) was not applied in v0.1. Verified cards went from 18 to 13, failed from 3 to 8.
3. Contract parity v0.1.1 to v0.1.2. Three method defects were fixed: an asymmetric authentication rule, a tool list read as a contradiction when only part of it is public before authentication, and a surface that did not answer being counted as silence. Endpoints with any inconsistency went from 2,768 to 2,764, and the run is now labelled PARTIAL.

A fourth change corrected a label only: the MCP endpoint census v0.2 had said EXHAUSTED while 1,070 endpoints were not contacted. Record v0.2.1 says PARTIAL. No count changed.

Two notices were cancelled. We had prepared private notes to two service operators about findings in our data, one about an agent-card signature and one about an authentication declaration. The corrections above showed both findings were wrong, so neither was sent. No notice from that queue has been sent.

Our full corrections ledger is at /corrections.

How to verify

The numbers on this page

Every figure above is in numbers.json, with the record it was recomputed from and that record's sha256. The file is signed in numbers.signed.json and timestamped in numbers.json.ots.

1. Fetch the key: did:web:csoai.org#board-attestation-1 in csoai.org/.well-known/did.json (Ed25519, x = k2fPWb6ctyu8l5at8FYgHsHFit_qoT-DssW3VNbCAXA).
2. Canonicalise payload from the signed file as JSON with keys sorted, no whitespace, UTF-8. Its sha256 must equal signature.payload_sha256.
3. payload.artifact.sha256 must equal the sha256 of numbers.json as downloaded.
4. Verify signature.sig_ed25519 (hex) over the canonical payload bytes with the key.
5. Timestamp: ots upgrade numbers.json.ots && ots verify numbers.json.ots. At publication the proof is a pending calendar commitment, not yet a Bitcoin attestation; upgrade it later to check.

The records behind them

Most source records are public on Hugging Face with the same sha256 (the appendix links each one), so every count can be recomputed from the published rows. The same signature check applies to each *.signed.json beside them. The cross-runtime, self-parity and public-signal records are not yet published; their sha256 is given so a later publication can be checked against it.

The measurement index

One index binds the day's measurement capsules together. Index sha256 ee3d921750d40456eb58ed24d2a9ba141d6fc1d16510ddd338166c4f5620b72a; index root 85533b833d36f8a4165da34206ee6e39f7434c646c8a2c381d251391ceec366d, an RFC 6962 Merkle tree hash over the sorted capsule ids of all 8 batches (13,184 capsules); root over the batch roots aba3b220f3fc7cc6b056e1620b8cc5f40d282b1841af39856e2152c8349cf5ef. The index signature verifies under the same key; its timestamp is a pending calendar commitment. The index and its capsule batches are not yet published.

Ask for a re-check, or object

If a figure here is wrong, or a row about your service is out of date, email nicholas@csoai.org or use /dispute to object to, dispute or request a correction of anything we publish. Corrections are dated in the ledger.

Appendix: every number and its source

Paths are relative to the measuring host's data volume. "Public copy" links go to a file with the same sha256.