AI agents read and act on the web without a human loading the page. People ask ChatGPT, Claude, or Perplexity to find them something, compare options, even order it, and the agent goes and reads sites directly. If an agent can't read yours, you're not in the answer.
Being readable takes three small, machine-readable pieces. None of them are hard. The knowledge is just scattered across half-finished specs, so I packaged the setup from my own production site into an MIT template you can copy in about 30 minutes: agent-ready-starter.
This post is the whole method. You don't need the template to follow it.
The three layers
Discovery: llms.txt. A plain-text file at your site root that tells agents what you are, what matters, and where your machine-readable stuff lives. Think robots.txt, but for comprehension instead of permission. Must be served as text/plain, not swallowed by your app's catch-all route (that's the most common failure I see: the file "exists" but arrives as HTML).
Capability: an OpenAPI spec. A standard description of what an agent can call. It doesn't need to be exhaustive. For a static portfolio it can be ~25 lines documenting one read-only JSON file. The description fields matter more than the schemas; that's the part agents actually read. Host it anywhere sensible (/openapi.yaml, /openapi.json, an api subdomain) and link it from llms.txt.
Integration: an MCP endpoint. MCP (Model Context Protocol) lets an agent call your site as a tool, live, inside its runtime. This is the layer people find confusing, so the honest guidance: it's optional. A static site with llms.txt and a spec is legitimately agent-ready. Add MCP when someone would plausibly plug your data into their agent. The template ships a minimal one-tool stdio server plus a smoke test that proves an agent can spawn it, list its tools, and call one.
The 30-minute path
bashgit clone https://github.com/HitmanLoges/agent-ready-starter
cd agent-ready-starter
cp config.example.json config.json # fill in your site, one endpoint
node scripts/generate.mjs # writes public/llms.txt + openapi.yaml
deploy those two static files to your domain root
cd mcp && npm run smoke # proves an agent can discover → understand → call
You're done when the smoke test passes and the checklist in the README is all ticks.
Check where you stand first
I also put up a free checker: agentreadycheck.com. Paste a URL, it scores the three layers and gives a one-line fix per gap.
Two honesty rules baked into it, learned from real feedback in week one:
Blocked is not broken. If your bot protection answers before your site does, the checker says "couldn't check", never "fail". Security guards doing their job are not a gap. It probes with an identifiable user agent (AgentReadyCheck/1.0) so you can allowlist it. I will never tell you to weaken your guards to satisfy a probe.
Declared beats default. If your llms.txt says the spec lives on an api subdomain as openapi.json, the checker follows your declaration instead of insisting on /openapi.yaml at root.
If you run a shop, you're closer than you think
Shopify storefronts now expose a UCP (Universal Commerce Protocol) endpoint by default, with a merchant profile at /.well-known/ucp. Agents that speak UCP can already search your catalog and check out. What most shops are missing is the plain readability layer on top: the llms.txt that lets a generic agent find any of it. Same three layers, you just get the third one free.
What this doesn't do
It makes your site legible to machines. It doesn't promise you'll "rank #1 in AI search", and anyone promising that is selling you something. The specs are young and moving; treat this as cheap, sturdy plumbing, not magic.
Repo: github.com/HitmanLoges/agent-ready-starter. MIT, no SaaS, no lock-in. Extracted from my own live setup. If the 30-minute path snags on your stack, open an issue; I'm fixing those same-day right now.
Top comments (3)
I wonder if we'll see the same pattern we saw with SEO. First, everyone focuses on accessibility. Then accessibility becomes table stakes. Once every site has llms.txt, OpenAPI specs, and MCP endpoints, the differentiator may shift from being accessible to being preferred. Being readable is important. Being recommended may be something else entirely.
Agreed, and I think the arc runs tighter than SEO's did. Readable is the entry ticket; preferred gets decided by signals agents can verify for themselves: does the declared endpoint actually answer, does the spec match reality, is the data fresh. Commerce is already halfway there, a UCP endpoint rejecting a malformed initialize protocol-correctly is itself a verifiable sign of a working integration. My bet is "recommended" ends up earned by uptime and schema honesty more than by copywriting. For now most sites still fail step 0, which is why the checker only scores the table stakes.
That's a great point. Reliable infrastructure may become a trust signal in its own right. What's interesting is that two businesses can expose equally valid endpoints and schemas, yet one still gets recommended more often than the other. My guess is recommendation systems eventually combine both layers. Technical confidence that the information is reliable and commercial confidence that the business is the right choice.