Docs for LLMs: What Stripe, Twilio and Vercel Built for Agent Readers

On documentation sites hosted by Mintlify, AI agents made 257 million requests in August 2026 against 131 million human page loads. That is a 66% agent share. Docs for LLMs used to be a side project for one curious engineer. At Stripe, Twilio and Vercel it is now a product surface with its own URLs, servers and written instructions aimed at the model.

Short answer. Docs for LLMs means serving the same documentation in forms a coding agent can read cheaply and correctly. That means plain Markdown at a predictable URL, an index file such as llms.txt, a docs search server over the Model Context Protocol, and installable skills. Stripe, Twilio and Vercel ship most of these today, and each made different trade-offs.

This piece is written for the practitioner who owns developer docs or developer marketing at a B2B software company. That person decides what ships next quarter and needs a concrete inventory rather than a trend piece.

Developer documentation now has two audiences, and one of them is an agent

A developer used to read your docs in a browser, copy a snippet, and adapt it. In 2026 the more common path runs through a coding agent. The developer asks Claude Code or Cursor to add payments, and the agent fetches your docs, reads them, and writes the integration.

That shift changes what a docs page is for. A human tolerates navigation chrome, tabbed code samples and JavaScript-rendered content. An agent pays for every token of it, and it can miss content hidden inside a tab it never clicks. Stripe states this reasoning plainly on its own building with LLMs page, which recommends plain text over scraping its HTML and JavaScript-rendered pages.

The scale of the shift is visible in the one public dataset that exists. Mintlify's March 2026 analysis of roughly 790 million requests across its hosted docs found Claude Code alone sent 199.4 million requests, more than Chrome on Windows at 119.4 million. That single comparison explains why the companies below stopped treating agent readers as an edge case.

My position is simple. If your API has a public docs site and you have not shipped a Markdown version of it, you are already serving your largest reader badly. The work is small relative to what it fixes.

The docs for LLMs inventory: what each company has shipped

The table below records what each company publishes, checked against its own pages on 27 October 2026. "Not found" means the feature did not appear on the pages opened for this piece. It does not prove the feature is absent elsewhere on the site.

Character counts were measured on fetches made on 27 October 2026 and will move as each index is regenerated. Twilio's site-wide llms.txt at twilio.com/llms.txt is a separate, larger file covering marketing pages; the docs figure here is for twilio.com/docs/llms.txt.

Stripe: Markdown everywhere, plus instructions to the model

Stripe's approach is the most complete of the three. Any docs URL returns Markdown when you append .md, and Stripe hosts an llms.txt index telling tools how to fetch those plain-text pages. The Stripe MCP server at mcp.stripe.com exposes documentation search alongside tools that read and write against the Stripe API.

Two details stand out. First, a machine-readable skills index at docs.stripe.com/.well-known/skills/index.json listed 10 installable skills when checked, from stripe-best-practices to upgrade-stripe. Second, Stripe requires human confirmation before certain write actions such as refunds and outbound payments, and those approvals expire after 24 hours. Stripe also ships a terminal path: CLI version 1.43.3 or later can read the docs with stripe docs.

Twilio: a search-then-retrieve docs server with no login

Twilio made a narrower and, for documentation purposes, cleaner choice. Its docs MCP server exposes exactly two tools. One, twilio__search, takes a natural-language query and returns ranked operations and docs. The other, twilio__retrieve, returns the full parameter and response schema for the operations the agent picked.

The server needs no authentication and no installation, because it indexes only public specifications, docs and support articles. It is read-only and does not execute API calls. Twilio labels it Public Beta and lists setup commands for Claude Code, Codex, Cursor, Replit and Figma Make. That breadth of client instructions is itself a distribution decision.

Vercel: content negotiation and a graph of the docs

Vercel is the only one of the three that documents HTTP content negotiation on its docs. Its agent resources page, last updated 15 September 2026, says every docs page is available as Markdown through the Accept: text/markdown header or the .md extension. The same page lists View as Markdown and Copy page actions for humans pasting into a chat.

Vercel also publishes discovery files beyond llms.txt: a sitemap.md with page summaries, a taxonomy.json and a graph.json described as the complete cross-site documentation graph. Its compact llms.txt tags every link with a ?from=llms-txt parameter. That is a small, telling choice, because it lets Vercel measure how many agent fetches arrive through the index.

Neon and Cloudflare: the infrastructure underneath

Neon's documentation engineer Philip Olson described the rebuild in April 2026. Hand-maintained llms.txt and per-page text files drifted out of sync, so Neon moved to a post-build script that converts MDX to Markdown, about 1,400 files in a few seconds. It added middleware that detects agents by user-agent and Accept header, plus 404 pages that answer in Markdown when an agent asks for it.

Cloudflare took the problem to the network edge. Its Markdown for Agents feature, announced on 12 February 2026, converts HTML to Markdown when a client sends Accept: text/markdown. Cloudflare says Claude Code and OpenCode already send that header. The feature launched in beta at no cost for Pro, Business and Enterprise plans.

What the published agent traffic data says about docs

Almost no company publishes how much of its own docs traffic comes from agents. Stripe, Twilio and Vercel do not, on any page opened for this piece. The only large public dataset comes from Mintlify, a docs platform that hosts other companies' documentation, so it measures many sites rather than any one brand.

Its 2026 State of Knowledge Report covers 1 February to 31 August 2026. It reports 257 million agent web requests and 131 million human page loads in August alone. Dividing one by the other gives roughly 2 agent requests for every human page load. That ratio is our calculation, and it compares requests with page loads, which are not the same unit.

Claude Code and Cursor carry almost all identified agent traffic

In the March data, Claude Code and Cursor together accounted for 95.6% of identified agent traffic. Chat assistants barely registered: ChatGPT sent 1.8 million requests and Google NotebookLM 1.4 million. The readers of your docs are coding tools doing a task, not chatbots answering a trivia question.

That has a practical consequence. Test your docs by asking Claude Code and Cursor to build a real integration from a clean repository. Watch which pages they fetch and where they fail. That test tells you more than any generic score of AI readiness.

Three Mintlify numbers that are not one series

The 45.3% March share, the 66% July share and the 66% August share are easy to read as a trend line. They are not one series. The March figure classified requests by user-agent header. The later reports count server-side fetches of machine-readable pages, llms.txt and known AI user agents, against human page loads captured in the browser.

Mintlify says so itself: because the two collection methods differ, it describes direct comparisons as estimates. Its monthly chart starts at 20.8% in February, while its July post cites 15.2% for the start of 2026. Treat the direction as credible and the exact slope as unknown. If you need your own number, the method for reading it from server logs is in the guide to measuring AI agent traffic in your logs.

The llms.txt index is now a design choice, not a file

All three companies publish an llms.txt file, the proposed convention for a plain-text index that tells language models where the useful pages are. They have built very different things under the same name. Size is the clearest way to see it.

Vercel's index opens with a one-line summary and roughly 28 links, sorted into sections such as "How agents should use Vercel" and "Agent setup". It is a router. It points agents at llms-full.txt, sitemap.md and an OpenAPI description rather than trying to contain the docs.

Twilio's docs index goes the other way. At about 381,000 characters, it lists product pages section by section, from Authy to Flex. An agent that reads it whole spends a large slice of its context window on the table of contents. My view is that Vercel's design is the right one, and that a single index above about 100,000 characters is a sign the file has not been designed at all.

Stripe writes instructions directly to the model

Stripe's file does something neither of the others does. Under a heading titled "Instructions for Large Language Model Agents: Best Practices for integrating Stripe", it addresses the reader as a model. It tells the agent to default to the latest API version and to prioritise the Checkout Sessions API.

It goes further than preference. The file says to "never recommend the Charges API", and to always use the Accounts v2 API for new Connect platforms unless the user explicitly asks for v1. Whether the debate over llms.txt as a search signal matters is a separate question, covered in the evidence on llms.txt adoption and Google. For coding agents the case is different, because the agent was going to read the file anyway.

Why docs for LLMs is technical marketing, not documentation hygiene

Developer marketing has always worked through the docs. A clean quickstart wins the evaluation that a homepage cannot. What changes with agents is who runs the evaluation. When a developer asks an agent to add payments, the agent reads, decides and writes the code, and the developer reviews the result.

Stripe's instruction block is the clearest case of what that means. Telling a model which API to recommend is product positioning delivered at the point of implementation. It steers new integrations toward the surface Stripe wants to support, and it does so inside thousands of coding sessions Stripe will never see.

Twilio's setup instructions tell the same story from the distribution side. Listing one-line install commands for Claude Code, Codex, Cursor, Replit and Figma Make is a channel strategy. Each is a place where a developer might choose a messaging provider, and Twilio wants its schemas already loaded when that choice happens. The wider pattern of agents becoming the evaluating user is covered in the analysis of product-led growth when agents are the users.

I would go one step further than most docs teams. The agent-facing surfaces deserve the same review as your pricing page. A wrong sentence in an llms.txt instruction block is repeated in every session that reads it, and nobody files a support ticket to tell you.

A build order for agent readable developer documentation

The companies above did not ship everything at once. Neon's account shows the realistic order: a hand-written index first, then drift, then automation. The table below sets out a sequence for a team starting from an ordinary HTML docs site, ordered by how much each step fixes against what it costs.

The Accept header comes before the MCP server for a reason. An MCP server only helps agents whose users installed it. Markdown served on the URL the agent was already fetching helps every agent that sends the header, with no setup on the developer's side. Cloudflare's 80% token reduction on one page is a single measurement, not a benchmark, but the direction matches Mintlify's own controlled tests.

Mintlify reports that across 2,400 tests on 20 docs sites, agents hit an average of 2.23 missing pages per task reading HTML, against 0.11 with Markdown plus llms.txt. That is about 95% fewer dead ends by our arithmetic. It is vendor research with an obvious interest in the result, so treat it as directional. If you build a docs MCP server, read how much of the API surface typical MCP servers actually cover before deciding its scope.

Where the evidence for agent-readable docs is weakest

The case above rests on thinner evidence than its confidence suggests. Three weaknesses deserve stating plainly before you commit a quarter of docs engineering to it.

The traffic data is one vendor's view of its own customers

Every traffic figure in this piece comes from Mintlify, which sells docs hosting with agent features built in. It discloses its method, but not the number of sites in most cuts. Its industry table rests on small samples: the 70% August agent share for fintech and payments docs covers 6 sites. A request is also not a reader. One agent task can fetch dozens of pages that a human would skim once.

The other side of this is fair to state. Agents also undercount: Mintlify notes that Codex sends no identifying user-agent, so some agent traffic sits in the human or other columns. The true share could be lower or higher, and nobody outside a few platforms can check.

Markdown can drift from the HTML, and search engines may object

Serving a second version of every page creates a second thing to keep correct. Neon's first attempt failed for exactly this reason. Neon also reports a scan of over 250 docs sites in which only 3% set a Vary: Accept header on HTML, the header that stops a shared cache from serving Markdown to a browser.

Search engines are a further open question. SEO practitioners have raised cloaking concerns about serving bots different content from humans, and Google's John Mueller has publicly criticised serving Markdown to AI crawlers. The risk is lowest when the Markdown is generated from the same source as the HTML. Crawler access policy is a separate decision, set out in the robots.txt decision for AI crawlers.

Frequently asked questions

How to test your own docs this week

Open a clean repository and ask Claude Code and Cursor to build your product's most common integration from your public docs alone. Record every page each agent fetches, every 404, and every place the generated code uses a deprecated endpoint. That list is your backlog, ranked by real failures rather than by a checklist.

Then request three of your own docs pages with curl, once plainly and once with an Accept: text/markdown header. If both return the same HTML, you have found the cheapest fix available, and every agent your customers use will benefit from it on the day it ships.

Related reading