NANDA audited: 13,605 agents claimed, 350 retrievable

MIT's Project NANDA calls itself the DNS for the internet of AI agents. We crawled its public index on August 19, 2026. The counter says 13,605 agents. The API will not hand you more than 350.

Every discovery layer for agents makes the same three promises: we will tell you who exists, we will tell you what they can do, and you will be able to verify both. NANDA makes them louder than most. It comes out of the MIT Media Lab, it has papers, it has a public index at index.projectnanda.org, and its pitch is explicitly a replacement for DNS.

We have audited discovery registries before — AGNTCY's Agent Directory Service in the OCI-artifact world, and the ERC-8004 registries on-chain. The method is always the same: read what the spec obliges, then measure what production actually serves. NANDA is the third. It is also the one where the gap between the two is widest.

What NANDA promises

The foundational paper is "Beyond DNS: Unlocking the Internet of AI Agents via the NANDA Index and Verified AgentFacts", submitted July 18, 2025 by Ramesh Raskar and seventeen co-authors. Its abstract commits to five guarantees: a quilt-like index that covers NANDA-native and third-party agents, rapid global resolution for newly spawned agents, sub-second revocation and key rotation, schema-validated capability assertions, and privacy-preserving discovery across organizational boundaries through verifiable, least-disclosure queries. It formalizes the AgentFacts schema, specifies a CRDT-based update protocol, and prototypes adaptive resolvers.

The project's own documentation compresses that into a comparison table against DNS. Where DNS takes minutes to hours to propagate, NANDA offers "sub-second global resolution." Where DNS "only proves domain ownership," NANDA offers "cryptographically signed capabilities." Where DNS "exposes lookup patterns," NANDA offers "privacy-preserving resolution."

Those are testable claims. So we tested them.

Finding 1: the index reports 13,605 agents and serves 350

The listing endpoint is GET /api/agents. It returns an agents array and a pagination object. That object is unambiguous:

{"page": 1, "limit": 100, "total": 13605,
 "totalPages": 137, "hasNext": true, "hasPrev": false}

We walked all 137 pages at limit=100. The walk returned 7,100 rows containing 300 distinct id values. Pages 1 through 5 each carried 50 fresh records plus the same fixed set of 50; from page 6 onward, every page returned only that fixed set of 50. Page 137, page 200 and page 500 return byte-identical payloads.

Changing the page size does not help. At limit=200 the server silently caps the response at 150 rows and 20 pages of walking yields 250 distinct records. Merging both crawls, the maximum we could ever retrieve was 350 distinct agents. Every response kept insisting the total was 13,605.

There is no second door. GET /api/agents/<id> returns {"success":false,"error":"Agent not found"} for ids copied verbatim out of the listing — we tried one from each of the four categories, all four 404. A ?search= parameter is accepted and ignored; so is ?category=; so is ?q=. All three return the same first page as a bare request.

So the practical state of the "phone book for the internet of AI agents" is this: a counter reporting five figures, a listing that returns three, and no way to look up a single name.

Finding 2: what the reachable records actually are

The 350 records we could reach break down as 250 in category skill, 50 mcp, 25 persona and 25 communication. Their status field mixes two vocabularies that never meet: 264 online and 36 offline on one side, 33 unverified and 17 verified on the other. One field, two orthogonal meanings, no discriminator.

The endpoint hosts are more revealing than the counts. Sixty records point at a single Railway deployment, bayarea-agent-production.up.railway.app. Another 111 point at four more Railway apps named test-london-chapter, test-bangalore-chapter, test-boston-chapter and test-tokyo-chapter. Five records advertise localhost as their endpoint. One advertises a bare IPv4 address. The lastSeen field — formatted as 8/2/2026, a locale-dependent string rather than a timestamp — is identical for 185 of the 350.

Twenty-three records embed a full metadata object inline, and those objects carry _id, __v and userId: raw MongoDB document internals, including the owner's user identifier, projected straight into a public API response.

Finding 3: 193 of 264 AgentFacts documents are 404

AgentFacts is the layer that is supposed to make this trustworthy. Each index record can carry a factsUrl pointing at a self-hosted JSON document describing the agent. Of our 350 records, 264 advertise one and 86 advertise none.

We fetched all 264, once, with a 15-second timeout. Fifty-seven answered HTTP 200. One hundred ninety-three returned 404. Nine failed TLS validation, four refused the connection, one no longer resolves in DNS. Fifty-six of the 57 live responses parsed as JSON.

Then we validated them against the published schema. agentfacts-format/agentfacts_schema.json is a JSON Schema draft-07 document with $id: https://agentfacts.org/schema/v1, fifteen top-level properties, and nine of them required: id, agent_name, label, description, version, provider, endpoints, capabilities, skills. Fifty-one of the 56 live documents carry all nine. That is the one number in this audit that looks healthy.

The schema's last commit is dated June 17, 2025. It has not been touched since.

Finding 4: nobody signs, and three agents priced themselves anyway

Search the schema for signature, proof, jws or any key material: there is nothing. AgentFacts as published has no place to put a signature. Consistent with that, zero of the 56 live documents carry a signature field of any kind. "Cryptographically signed capabilities" is, in the deployed corpus we measured, a property that does not exist.

What the corpus does have is improvisation. Forty-seven documents carry a chapter object and an attestation block that the schema never defines — attested_by as a did:key, a facts_digest as sha256:…, a lifecycle string and a revoked boolean. Thirty-four go further with verifiable_receipts: a ledger URI, a behavioral_merkle_root, a receipt count, a reputation score, and a self-declared scoring method nanda-rep/0.2 served under the media type application/vnd.nanda.receipts-ledger+json. Half the trust layer the papers describe has been reinvented by one operator, in free-form JSON, outside the schema.

Now search the schema for price, payment, cost or fee. Also nothing. Fifteen properties, and not one of them can say what a call costs. This is the same hole we found in AGNTCY's OASF record: a discovery layer whose object model has no economic dimension at all.

Three agents in the index filled it themselves.

Three independent operators, three incompatible shapes, one shared conclusion: a directory entry that cannot say what a call costs is incomplete, and they will patch it locally rather than wait.

Finding 5: the v2 index is a different system

While index.projectnanda.org serves the corpus above, a second index has been quietly built and deployed. github.com/projnanda/nanda-index-v2 is a Fastify and PostgreSQL service, Apache-2.0 since July 20, 2026, 74 commits, six contributors, last commit July 29, 2026. It is live: https://api.nandaindex.org/health answers {"status":"ok","db":"ok"} and its OpenAPI document identifies it as "NANDA Index Server" version 2.0.0, described as "GARR v2".

The design is a repudiation of v1. The README states it plainly: "NANDA Index does not host agents. It tells you where to find them." One index record per organization, three hops — requester to index, index to registry or card host, card host to runtime — and a fixed media-type vocabulary of six values: application/ai-catalog+json, application/vnd.ans-registry+json, application/vnd.dns-aid+json, application/a2a-agent-card+json, application/mcp-server-card+json, application/agentskill+zip. AgentFacts is not among them. The index no longer resolves to AgentFacts at all; it resolves to A2A Agent Cards, MCP server cards and AI Catalog entries.

We read the whole table. GET /api/v1/index ignores limit and offset — every variant returns the same array — and that array holds 251 records, all active, created between June 17 and August 5, 2026. By media type: 177 agentskill+zip, 32 ai-catalog+json, 20 mcp-server-card+json, 18 a2a-agent-card+json, 4 vnd.dns-aid+json.

The registry URLs are where it gets interesting. One hundred eighty of the 251 records point at ai-catalog.outshift.io — AGNTCY's public catalog host, the one we crawled for the ADS audit. Their identifiers are urn:ai:org.agntcy:cid:… content addresses and their tags are OASF 1.0.0 skill paths. Fourteen more point at mcp.run, fourteen at skills.claude.ai, fourteen at NANDA's own agentcards.host39.org. The federated quilt, today, is largely one mirror of somebody else's catalog.

Two details deserve naming. First, 249 of the 251 records are flagged domain_verified: true, including records for stripe.com, adobe.com, cloudflare.com, salesforce.com and redhat.com whose publisher is declared as "Cisco agntcy" and whose registry URL is Outshift's host — all created within a few seconds of each other on June 26, 2026. Resolving urn:ai:domain:stripe.com returns that record with the verified flag set. Second, the ARD descriptor served in production at GET /api/ard announces its own identity as did:web:localhost:3001, with urn:air:nanda-index:localhost:3001 as identifier and http://localhost:3001/docs as documentation URL — the descriptor is built from a config value that was never set for production.

Signing in v2 exists, but it is bespoke. server/src/services/signing.ts implements its own canonical-JSON serializer, signs the result with raw Ed25519 (or RSA-SHA256) and stores base64 in a signature_value or signature field. No JWS, no COSE, no JCS. Compare A2A v1, which signs Agent Cards with JWS per RFC 7515 over JCS per RFC 8785 — two registered standards, off-the-shelf verifiers in every language. NANDA's canonicalizer is 30 lines and its cross-implementation contract is a comment.

None of the six NANDA media types appear in the IANA application registry, which we downloaded the same day. Neither does application/vnd.nanda.receipts-ledger+json. Neither does application/ai-registry+json or application/ai-skill+md, the two ARD types the service maps onto. That is not fatal — plenty of live formats are unregistered — but a project positioning itself as the successor to DNS has not yet done the paperwork DNS did.

Finding 6: where NANDA's payments went

Phase 2 of the project's published roadmap is "Agentic Commerce": knowledge pricing mechanisms, economic protocols, resource markets. There is a repository for it. projnanda/nanda-payments, MIT-licensed, created September 4, 2025, is an MCP server for "NANDA Points" — an internal ledger with wallets, balances, service charges and receipts, backed by MongoDB.

It ships a payment protocol called x402-NP. The name is borrowed; the mechanics are not. Instead of the x402 envelope, it returns a JSON-RPC error -32402 carrying a price in NP, and expects the retry to arrive with three custom headers: X-PAYMENT-AGENT, X-PAYMENT-TX-ID, X-PAYMENT-AMOUNT. Settlement is a row update in the points database. The string USDC does not appear anywhere in the repository. Its last commit is dated September 22, 2025.

The active work moved to projnanda/nandatown, an Apache-2.0 alpha simulator whose pitch is "you have an agent protocol; Nanda Town tells you whether it actually works." It has a payments layer with a quote/pay/verify_payment/refund interface and three reference plugins: prepaid credits, per-tick streaming, and an escrow. Its hackathon problem set includes one titled "Streaming pay-per-second payments with mid-stream cancellation," which notes that "x402-style HTTP-payment proposals are explicitly per-request." That is a fair observation, and it is being explored in a simulator rather than on a rail.

So NANDA's money layer today is a frozen points ledger and a test rig. Its index, meanwhile, contains three agents settling real USDC on Base through fields the index cannot read.

What it means for LLM4Agents

LLM4Agents sells inference to autonomous buyers and gets paid per call in stablecoins over x402. Discovery is upstream of that: before an agent can pay us, it has to find us. NANDA is one of three or four candidate answers to "where do agents look," alongside AGNTCY's directory, the MCP registry, and plain .well-known fetches.

Three conclusions follow from what we measured.

Registry population is not distribution. A five-figure counter over a three-figure reachable set is a reminder to weight registries by what they resolve, not by what they claim. The cost of a NANDA v2 record is one HTTP POST and a DNS TXT record; the expected traffic is close to zero today. Register, monitor, do not build on it.

The price field is never going to arrive. Three discovery schemas audited, zero economic fields among them. This is not an oversight to be fixed upstream; it is a structural choice. Directories describe capability, and the price of a capability is dynamic, per-caller and per-moment. Which is precisely the argument for the 402: the quote belongs in the response to the call, not in a directory entry that goes stale. Our job is not to lobby for a price key. It is to make sure that every path that discovers us ends at an endpoint that answers 402 with a complete accepts array.

Liveness is the real trust signal. Seventy-three percent of the AgentFacts URLs registered in a public index are dead. No signature scheme fixes that. A directory entry pointing at a 404 is worse than no entry, because it burns a request and teaches the crawler that this registry is noise. Whatever we publish, we have to keep alive — and measure that we are keeping it alive.

Staying on the frontier

Concrete steps, in the order we would take them.

1. One capability document, four projections. Maintain a single internal description of what the gateway offers — models, limits, prices, endpoints — and generate from it an A2A Agent Card, an MCP server card, an AgentFacts document and an AI Catalog entry. Every registry audited this year consumes one of those four shapes. Hand-maintaining four files is how you end up with 193 dead URLs.

2. Put the payment pointer in the document, the way the three agents did. Not as a price the registry will parse, but as a machine-readable hint: the x402 resource URL, the supported networks and assets, the facilitator, and the extensions we honor. agent-guild's document is the best example in the corpus of what that looks like in practice, and it proves that consumers are already reading it.

3. Sign with standards, not with a canonicalizer. If we sign our cards, sign them with JWS over JCS, exactly as A2A v1 specifies. That gives any counterparty an off-the-shelf verifier and lets us rotate keys without shipping a library. It also positions us to be verifiable in NANDA's v2 world, whose signing service will need to interoperate with the same cards.

4. Treat every registry entry as a monitored dependency. A weekly job that fetches our own entry from each index and each facts URL, asserts HTTP 200 and schema validity, and alerts on drift. The failure mode we found in the wild is silent: the entry stays listed forever after the host goes away.

5. Emit receipts before anyone demands them. The x402 offer-receipt extension already defines signed offers and receipts. The improvised verifiable_receipts block we found in the NANDA corpus shows there is demand for exactly this and no agreement on the shape. Publishing receipts in a specified format is cheap now and becomes leverage the moment reputation systems need something to consume.

6. Watch the pointer indexes, not the flagship. NANDA v2, AGNTCY's AI Catalog, the MCP registry and DNS-based discovery are converging on the same three-hop pattern: a thin pointer layer, a per-organization catalog, a per-agent card. That is where the traffic will eventually route. The place to be listed is the layer that resolves, and today that means having our own catalog at a stable, verified domain — the second hop — rather than betting on any single first hop.