MDX Documentation Platforms That Output Structured Data for LLMs

Documentation has gained a new kind of reader, and that reader doesn't click, bounce, or file a support ticket when something is wrong. When the content is wrong, outdated, or buried in page structure that an agent can't parse, nothing in the usual analytics stack shows it. The developer on the other end simply gets a wrong answer, and the team producing the docs has no idea it happened. That blind spot is forcing a second look at how documentation platforms are judged, and the question has shifted from "does this tool make writing easy" to "does this tool make the output usable by a machine that will never tell you when it fails." A second force is pushing in the same direction: AI-assisted coding has sped up how fast products ship, and manual documentation cycles can't keep pace on their own. Teams need a publishing layer that supports automated maintenance, where docs get written and updated by agents through ordinary pull requests, without waiting on a human writer's backlog. GitBook's 2026 overview describes documentation as now functioning as "a central knowledge layer, powering developer portals, support automation, and AI assistants trained on product knowledge. That's a different job than the one documentation platforms were originally built for, and it's the reason the rest of this piece treats structured output as a core evaluation criterion.

Structured LLM Output: llms.txt, llms-full.txt, MCP, and Clean Markdown Delivery

"AI-ready" has become a label platforms attach to themselves with little agreement on what it requires. That label covers four distinct capabilities, each solving a different problem, and a platform should be judged on all four, not on the marketing term alone.

llms.txt is a Markdown file placed at the root of a domain, proposed as a standard by Jeremy Howard of Answer.AI in September 2024. The standard moved to version 2 in August 2026, which clarified how subpath files work (a file at /docs/llms.txt, for instance) and added link relations that improve discoverability. That update matters most for large, multi-product documentation sites, where a single root-level file can't meaningfully summarize everything underneath it.

llms-full.txt solves a different problem. Instead of an index, it embeds the full content of indexed pages directly in one file, built for agents that would rather ingest everything in a single fetch than make repeated round-trips back to the server. Both llms.txt and llms-full.txt can be scoped to subpaths rather than only the site root, so an agent working on a narrow task can request just the relevant slice of documentation.

MCP, the Model Context Protocol, takes a different approach again: it exposes documentation as a live, queryable source rather than a static file, so an AI client pulls current information at the moment it's needed instead of relying on a cached crawl that might be stale. Tool outputs can carry prompt injection risks, and over-permissioned integrations widen the blast radius of a bad actor. Teams running MCP servers should enforce OAuth 2.0 with scoped tokens and log every tool invocation, treating it with the same discipline as any other API surface exposed to outside callers.

Clean Markdown delivery, sometimes called content negotiation, rounds out the set. It serves the human-facing version of a page as HTML, but if an AI agent requests the same content, it gets a clean Markdown version instead. That distinction cuts token consumption sharply, and the stakes of that are not abstract. Agents need the smallest possible unit of docs that will help them complete their task." A related artifact, skill.md, names what the documentation can help an agent actually accomplish, and that matters once AI systems rely on the docs to complete multi-step work, not just answer a question.

The MDX Format as the Right Authoring Layer for Structured Agent Output

MDX combines Markdown prose with JSX components in a single file, so a team can write for a human reader and still produce clean output for an agent, with no lossy conversion step in between. Full CMS-generated HTML goes the opposite direction: it can carry anything, but the layout markup, scripts, and styling baggage add noise that inflates token count and makes it harder for an agent to find the actual semantic structure, the headings and code blocks, buried inside it.

MDX sits in the middle and keeps what matters on both sides. Because MDX files live as plain text in Git, the whole docs-as-code workflow, pull requests, CI checks, review, applies to them the same way it applies to application code. That detail is also what makes agent-driven authoring possible, since an AI coding tool can open a pull request against an MDX file using the identical workflow a human contributor would use.

MDX alone doesn't solve everything, though. Fern's guide to the format flags a specific risk: when API documentation lives purely as handwritten MDX prose, every change to an endpoint, a parameter, or a response shape has to be manually carried over into the docs. The fix is to stop treating reference documentation as prose to be written by hand and instead generate it from a typed source of truth, an OpenAPI or AsyncAPI spec, so the reference content can't drift from what the API actually does. MDX handles the narrative layer, and the spec handles the reference layer. That division of labor is the standard to check for when comparing platforms in the next section.

How Leading MDX Documentation Platforms Handle Structured LLM Output

Here the four criteria, llms.txt, llms-full.txt, MCP, and clean Markdown delivery, start to separate platforms meaningfully, since teams vary sharply in how much of this ships natively versus how much falls on the team to build and maintain itself.

One class of platform generates llms.txt, llms-full.txt, and skill.md automatically, with documentation served to AI agents as Markdown so parsing costs fewer tokens. These features ship across all plans, including the free starter tier, according to a technical documentation software guide covering this category. The same platforms typically add MCP support so AI coding tools can query documentation live, and pair that with an AI traffic dashboard that breaks out visits by agent (ChatGPT, Claude, Perplexity), shows which pages agents actually read, and flags where they stop reading. OpenAPI and AsyncAPI specs generate interactive API references directly in these systems, removing the manual-coordination risk described in the previous section, and bi-directional Git sync keeps the published site and the underlying repository in lockstep, with preview deployments so a team can review a change, human or agent-authored, before it goes live.

GitBook occupies a related but distinct position. AI-assisted agents can draft updates from pull requests, so the docs stay aligned with shipped code.

Fern takes a narrower, API-first position. Its guide describes connecting MDX guides to automatically generated API reference documentation pulled from OpenAPI, AsyncAPI, openRPC, gRPC, or Fern's own definition format, combining narrative MDX writing with API endpoints, SDK snippets, and interactive examples that stay current because they're generated. What Fern's own materials don't spell out is whether llms.txt, llms-full.txt, or MCP server exposure come built in; teams evaluating Fern for that reason should check directly.

Docusaurus sits at the other end of the spectrum. Meta's open-source static site generator builds from Markdown or MDX files stored in a repository and gives engineering teams full control over the resulting site. The docs-as-code workflow is strong and the tool is widely used, but the structured-output layer that ships natively elsewhere becomes additional engineering work here. That tradeoff is reasonable for a team with the capacity to build it and a preference for open-source ownership over a managed platform: the output a platform produces by default and the output a team can eventually build are not the same starting point.

Production examples that show what structured output looks like at scale

Specifications read differently once real traffic runs through them. Two documentation domains show what llms.txt and llms-full.txt look like when a large, actively maintained product is behind them, and the differences between the two cases say something about how the two formats are meant to be used together.

Cloudflare runs both formats side by side, hosting a product-scoped llms.txt alongside a full llms-full.txt spanning six major product categories and a large number of individual products underneath them. That structure is the subpath architecture the llms.txt v2 specification, finalized in August 2026, was built to support, where a massive multi-product site doesn't have to compress everything into one undifferentiated root file.

Together, the two cases show the formats functioning as complements. llms.txt works for agents that want a map and will fetch details as needed; llms-full.txt works for agents that want to ingest an entire product's documentation in one pass and reason over all of it at once. Which format a given task calls for depends on how the agent plans to use the content, not on which one is "better."

One finding from production use cuts against intuition. Christopher Gales points out in the State of Docs Report that FAQs, a format many writers consider outdated for human readers, turn out to be close to ideal for machines. A clear question paired with a clear answer is about as parseable as content gets. That's a useful check against assuming that whatever reads best to a person also reads best to an agent; sometimes the format that feels dated to a human is the one a model processes most cleanly.

The legitimate objection: llms.txt is not a universal signal for AI discoverability

Not every claim made about llms.txt holds up once Google's own public statements are factored in, and that pushback deserves direct treatment. Five days later, Chrome Lighthouse added an "Agentic Browsing" category that audits specifically for the file's presence, an addition that sits in tension with what Google Search itself had just said. That split inside Google hasn't been resolved in the time since. Adoption of llms.txt across the broader web also remains low, so most sites that get cited by AI systems earn that visibility through entity clarity, schema depth, and content extraction quality, not the presence of a single file at the domain root.

None of that undercuts the case made in this piece, because the objection and the argument are pointed at two different problems. Google's statement concerns conversational search and AI Overviews, where a general-purpose crawler decides what to surface to a person who types a query into a search box. The case for llms.txt made here concerns agentic developer tooling: Cursor, Claude Code, Cline, Continue, and MCP servers, tools that a developer points directly at a documentation domain to complete a specific coding task. These are different consumption mechanisms built for different jobs, and a file's irrelevance to one doesn't make it irrelevant to the other. If your documentation needs to feed an AI agent accurately mid-task, the agentic-retrieval case is the one that applies, and llms.txt has active consumers and measurable adoption among the major AI coding tools that serve exactly that case.

MCP's security question deserves the same straight treatment. A conversational tool interface introduces real prompt injection risk through its outputs, and that risk should be engineered around with OAuth 2.0, scoped tokens, and invocation logging. Securing the surface is infrastructure work a team does once and maintains.

Evaluating a Platform Against These Criteria Before Committing

Testing a documentation platform against the four output criteria doesn't require migrating first. The second version drifts quietly, and nobody notices until an agent reads a page that no longer matches reality.

MCP deserves its own check: can an AI coding tool actually query the live documentation at request time, and does the platform handle authentication scoping, or is that left to the team to wire up separately? If the response is still HTML padded with layout markup, the platform hasn't solved content negotiation, no matter what its marketing claims.

The connection between MDX content and the API source of truth is worth auditing as carefully as any of the above. GitBook's agent-readiness checker offers one way to benchmark a documentation set against these criteria without committing to a migration up front, and it's a reasonable first step for a team trying to figure out how far off its current setup is before deciding whether to move.

AI traffic analytics belongs on this list as its own line item, not as an afterthought. Teams already committed to a platform without native structured output, Docusaurus being the clear example here, do have a short-term option: layering a retrieval tool such as Kapa on top of the existing documentation. That path works, but it adds a maintenance burden that platform-native support would have avoided from the start, and that ongoing cost should be weighed against the cost of switching platforms.

Watch the write path most closely going forward: platforms where an agent doesn't just read documentation but drafts updates from code changes and opens a pull request for a human to review. That capability closes the exact gap raised at the start of this piece, the widening distance between how fast products ship and how slowly documentation used to catch up. A platform that reads documentation to an agent is solving yesterday's problem. A platform where an agent can also write the next update is solving the one that's actually in front of teams now.