The agent-readiness of the vibe-coded web

Why we measured

Coding agents are becoming a real audience for web apps: they select tools, read docs, and — increasingly — call endpoints on a user's behalf. But nobody knew how much of the independent, AI-built web is actually prepared for that audience. Directories of MCP servers exist; a measured rate over a defined population didn't. The gallery is a defined population: live, machine-verified, individually checkable. So we checked.

What we found

Of 2,614 published apps (scanned July 15, 2026):

• 31.0% (810 apps) declare at least one AI interface.
• 30.6% (801) serve a real llms.txt — not an SPA fallback page; we verified the body is actual text.
• 1.4% (37) expose an MCP-shaped endpoint at /api/mcp or /mcp — an SSE stream, a JSON-RPC body, or a JSON 405. Several are auth-gated, which still counts: the interface exists.
• 26 serve a .well-known manifest (mcp.json or the older ai-plugin.json); 29 apps have both llms.txt and MCP.

Readable is not callable

The 30% figure looks like the agent-ready web has already arrived. It hasn't — read the two numbers as two different phenomena. llms.txt spread the way meta tags did: as SEO. The advice mill now tells every maker that AI crawlers are the new Google, scaffolds and AI site-builders emit llms.txt by default, and so a third of the vibe-coded web became machine-readable almost without anyone deciding to. It costs nothing and asks nothing: a static text file.

A callable interface is a different commitment: an endpoint, a schema, auth decisions, something to maintain. That's why it sits at 1.4%. Readable gets you found; callable gets you used. An agent can quote a readable app to its user — it can only actually operate a callable one. The 22× gap between the two is the frontier, and it's where the next year of the agent web will be decided.

Who's ready

Readiness follows how task-shaped a category is. Developer tools lead at 42% — closest to the ecosystem, first to adopt its conventions. Games sit at 13% — reasonably so: a game's value is the experience of playing it, not a result an agent could fetch for you. The gradient in between tracks the same logic: the more your app is a means to an outcome, the more an agent interface makes sense.

Methodology

The probe runs in our isolated checker (the same infrastructure that liveness-checks every URL on a rolling cycle) and is deliberately conservative: GET-only, no JSON-RPC handshakes, no auth attempts. llms.txt counts only if the body is genuine text (length, no HTML, markdown-ish structure) — SPAs that return index.html for every path are excluded. MCP counts only on an SSE content type, a jsonrpc body, or a JSON-typed 405/406. This undercounts: an MCP endpoint that answers GET with a plain 404, or one mounted on a nonstandard path, is invisible to us. Treat every number here as a floor.

A baseline, not a snapshot

These numbers are now a column in the catalog (agent_interfaces — public, in the CC0 dataset), and the probe re-runs monthly, so this is issue #1 of a series. Our predictions, on the record: llms.txt crosses 50% within six months on scaffold defaults alone; MCP stays under 5% until agents start visibly routing usage to callable apps — at which point it jumps.

If you make one of the 2,614: adding llms.txt takes one prompt in your coding agent, and if your app is task-shaped, an MCP endpoint takes an afternoon. Your app becomes discoverable — and operable — by every Claude Code, Cursor, and Codex session that asks our index what exists.

The per-app data is public in awesome-vibe-coded-apps, and your app can join the census: /submit