Agent-readable documentation: llms.txt, MCP, and why docs are becoming infrastructure

For most of the web's life, documentation was content: pages a human navigated, read, and closed. The reader is changing. A growing share of your docs traffic is now an AI agent — answering a question, writing code against your API, or trying to keep its own knowledge current. That reader doesn't want a styled page. It wants clean, structured, machine-addressable knowledge.

Two standards have emerged to serve that reader: llms.txt and MCP. They solve different halves of the problem, and together they mark a shift from docs as content to docs as infrastructure.

llms.txt: a clean front door for reading

llms.txt is a proposed convention: a markdown file at the root of your site (/llms.txt) that gives an LLM a curated, link-rich map of your documentation — the important pages, in plain markdown, without the nav bars, cookie banners, and JavaScript that pollute a scraped HTML page. Some sites also publish llms-full.txt, a single concatenated dump of the whole doc set for a model to ingest in one shot.

The point is legibility. An LLM landing on your rendered docs site has to reverse-engineer structure from markup. llms.txt hands it the structure directly: here are the sections, here's what each link is, here's the canonical text. It's the robots.txt/sitemap instinct, repurposed for models instead of crawlers.

What llms.txt is not: it's read-only, it's a snapshot, and it's pull-based. The model reads what you published. There's no way for it to ask a follow-up query, get fresh results, or write anything back.

MCP: a live, two-way interface

The Model Context Protocol (MCP) covers what llms.txt can't. Instead of a static file, MCP exposes your docs as a server with typed tools an agent calls at runtime: search, get_page, and — crucially — write tools like create_page and update_page. It's live (results reflect the current state, not last build), it's queryable (the agent searches for exactly what it needs instead of ingesting everything), and it's bidirectional (the agent can contribute, under enforced permissions).

A useful way to hold the two:

They're complementary, not competing. llms.txt is a great low-effort win for public docs discoverability. MCP is what you reach for when agents need to work with your knowledge, not just read a copy of it.

Why this makes docs infrastructure

When the consumer of your docs is a system, your docs inherit the expectations of a system:

• Canonical, structured source. Scraped HTML is lossy. Markdown with real structure is an API response. If your "source of truth" is a proprietary block format, every agent integration is a translation layer.
• Freshness as a property, not an afterthought. A wrong doc fed to an agent becomes a wrong action. Drift stops being cosmetic.
• Access control. A write-capable docs surface needs real, server-side scopes — not "the bot is logged in, so it can do anything."
• Uptime and addressability. If agents query your docs in their loops, your docs endpoint is now a dependency with the reliability expectations of one.

That's the category shift: documentation is moving from a content discipline to an infrastructure discipline. You version it, you monitor its coverage, you expose it over protocols, and you treat staleness as a defect.

Where tela sits

tela is built for the agent-as-reader world from the data model up. A few pieces line up directly with the above:

• Canonical markdown, always. pages.body is markdown — no block table, no proprietary intermediate format. What an agent reads is what the editor renders is what you can export. That's the clean, structured source the whole shift depends on.
• A built-in MCP server. The backend exposes search, get_page, create_page, update_page, and more at https://telawiki.com/api/mcp (or via tela-mcp on npm), with read/write scopes enforced per tool. Agents read and contribute as first-class clients. Many doc tools now ship MCP — the differentiators here are the canonical-markdown source and that the MCP tools share the exact code path as the app.
• Self-hostable, with a free cloud tier. You can own the data and the endpoint.
• Drift and coverage as features, not vibes. tela's Atlas can generate a cited wiki from your codebase and flag when it has drifted from source — exactly the "staleness is a defect" posture infrastructure-grade docs require.

What to do about it

If you maintain docs:

1. Publish an llms.txt for public docs — it's cheap and helps today.
2. Expose an MCP server if agents need live or write access to your knowledge.
3. Treat your source format as an interface — keep it canonical and structured, not locked in a format only your renderer understands.
4. Measure freshness. Coverage and drift checks turn "are our docs current?" from a guess into a signal.

The reader changed. Docs that stay readable-by-machines — clean source, live protocol, real permissions — become infrastructure the rest of your AI stack can build on. Docs that don't get scraped, badly, by everyone.