DEV Community

Loghan Lewis
Loghan Lewis

Posted on

Make your site agent-ready in ~30 minutes (llms.txt + OpenAPI + MCP)

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

  1. 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).

  2. 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.

  3. 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 (0)