Ship a Docs MCP Your AI Tools Actually Use

Your most active reader never loads the page

You have analytics on your documentation. Page views, time on page, search queries, maybe a thumbs-up widget at the bottom. You use them to decide what to write next.

Meanwhile, a developer asks their AI editor how your API works. The editor answers. The developer never visits your site. Your analytics record nothing, because nothing happened — from your dashboard's point of view, that reader does not exist.

If the answer was wrong, you find out weeks later as a support ticket that does not mention the documentation at all.

The short version: AI assistants are reading your docs on your users' behalf, and that traffic is invisible to every tool you currently have. Turning your docs site into an MCP server makes it visible: the question asked, the passage that answered it, how confident the retrieval was, and whether the question was answerable at all. This post covers how to set that up and, more importantly, how to read what comes back.

Why page views stopped describing usage

Page views measure one thing: a human decided to open a URL. That was a decent proxy for value when opening the URL was the only way to get the content.

It is a bad proxy now, for a specific reason. The AI-mediated read is inverted relative to the human read. A human lands on your page and scans for the part they need. An assistant retrieves a passage and never sees the page around it. Which means:

• Your careful page structure does not help the assistant, but your section headings do
• A page nobody visits can still be answering questions constantly
• A popular page can be the source of consistently bad answers, and nothing in your analytics will say so
• The questions people ask an assistant are phrased nothing like the queries they type into site search

That last point is worth sitting with. Site search shows you the keywords people guessed might match your headings. An assistant log shows you the question in the words they actually think in. Those are different datasets, and only one of them tells you what to write.

What you get instead

An MCP server sits in front of your documentation and answers structured queries. Because every request goes through it, every request can be recorded.

For each one, MCP Studio captures:

• The question, as asked
• The passage returned — page, section, and the excerpt itself
• A retrieval confidence score for how well the content matched
• Whether it was answerable at all, or whether the search came back empty
• The source it came from, when you have several indexed

Aggregate that and you get things a docs team has historically had to guess at: which questions recur, which pages carry the load, which pages get retrieved but answer badly, and which questions your corpus simply does not cover.

That last category is the valuable one. A content gap is a question that got asked and returned nothing useful — and until now, that event left no trace anywhere.

Set it up

You need an MCP Studio account (the free tier is enough to start) and your documentation URL. No engineering support required unless you want to index a private repo.

1. Open the wizard. Go to MCP Studio and create a server. Name it for the product, not the format — acme-api rather than docs-mcp, because you may end up with several.
2. Add your docs site as a source. Paste the URL. If your site is large, point at the section rather than the root: the crawler indexes up to 5,000 pages per source, and you would rather spend that budget on reference content than on blog archives.
3. Add your API reference as a separate source. This is the step people skip and later wish they had not. Keeping reference separate from guides lets you measure them independently, and reference lookups behave very differently from conceptual questions.
4. Add the changelog, and the docs repo if you have one. The repo catches content that exists in markdown but never made it to the published site, which is more common than anyone admits.
5. Pick your tools. Turn on search_docs, ask_question, find_api_reference, and get_changelog. The first two produce the query log you will actually analyse; the second two let you tell a navigation problem apart from a coverage problem.
6. Deploy, then publish the config to your developers so they can add it to their own editors.

The config to hand your users

Put this in your documentation, on a page called something like "Use these docs in your AI editor". It is the single highest-leverage page you will add this quarter, because it converts invisible readers into measurable ones.

{
  "mcpServers": {
    "acme-docs": {
      "url": "https://appatools.com/mcp-studio/api/mcp/acme-docs-h8w2v5"
    }
  }
}

Reading the dashboard without fooling yourself

Once requests start arriving, the dashboard fills in. Here is how to read it in the order that actually leads to decisions.

Start with the unanswerable questions. These are queries where retrieval found nothing with meaningful confidence. Each one is a person who asked your documentation something and got nothing. Sorted by frequency, this list is your writing backlog, already prioritised by demand rather than by whoever complained loudest.

Then look at low-confidence answers on high-traffic pages. This is the dangerous quadrant. The page gets retrieved constantly and the retrieval is weak, which means it is producing confident-sounding answers built on a poor match. These pages usually do not need more content — they need clearer section headings and shorter, more self-contained passages, because retrieval works on chunks and a chunk that only makes sense in the context of the whole page will always score badly.

Then check the per-source grades. If you indexed guides, reference, and changelog separately, you can see which is pulling its weight. A reference section with poor grades is usually a formatting problem, not a content problem: tables and parameter lists chunk badly unless each row carries enough context to stand alone.

Finally, look at question phrasing. Compare the words in the query log to the words in your headings. Where they diverge, your headings are written in your team's vocabulary rather than your users'. That is a cheap fix with a disproportionate effect on retrieval.

History is not lost if you start on the free tier

One practical note, because it changes how you should sequence this.

Per-request telemetry is written on every request regardless of which analytics tier you are on. The tier controls what the dashboard shows you, not what gets recorded. So you can deploy now, accumulate a few months of real usage, and turn on a higher tier later to find the whole history waiting rather than an empty chart.

Deploy first. Decide about tiers once you have data to look at.

What this changes about the job

Documentation teams have always been asked to justify their work with metrics that do not measure the work. Page views measure curiosity. Time on page measures confusion as readily as engagement. Thumbs-up widgets measure who happened to feel strongly.

"This question was asked 340 times last month and our docs answered it 60% of the time" is a different kind of sentence. It survives a budget conversation. It also, more usefully, tells you exactly what to write on Monday.

And once you rewrite that page, the number moves. You can point at the before and after. That has been the missing piece in docs work for a long time — not more analytics, but analytics that connect a specific change to a specific outcome.

Turn your docs into an MCP server →

Keep going

• MCP for technical writers — the short version, with the common objections answered
• Tutorial: a docs MCP for writers — the same setup as a step-by-step procedure
• How to know if your docs MCP is actually accurate — a five-dimension rubric, with a real scored test
• The metrics that matter for a docs MCP — which numbers to watch and which to ignore
• What is a docs MCP server? — the conceptual background
• Monitor quality and impact in the dashboard — every panel explained