Appa Tools documentation for MCP Studio, including setup, guides, concepts, and API-related reference content.

Skip to main content

A docs MCP for writers

Turn your documentation into an MCP server, publish it to your developers, and use the dashboard to find the questions your content fails to answer.

Build absolutely anything...with the right context.

AudienceTechnical writers and documentation engineers
PrerequisitesAn MCP Studio account and your documentation URL
TimeAbout 15 minutes, plus a few weeks of traffic before the analytics are worth reading
Want the argument first?

This tutorial is the procedure. Ship a docs MCP your AI tools actually use explains why page views stopped describing usage, and MCP for technical writers is the overview.

Step 1 — Create the server​

  1. Open the wizard and start a new server.
  2. Name it after the product, not the format. acme-api rather than docs-mcp, because you may end up running several.

Step 2 — Add sources, separately​

This is the step that determines whether your analytics are useful, so do not collapse everything into one source.

SourceWhy separate
Documentation siteYour conceptual and how-to content
API referenceReference lookups behave very differently from conceptual questions
Changelog or release notesTells you how often people ask what changed
Docs GitHub repoCatches content that exists in markdown but never shipped to the site

Indexing them separately lets you grade each one independently in the dashboard. Merged into a single source, a weak API reference is hidden by strong guides.

Scope large sites

Each source indexes up to 5,000 pages. If your site is larger, point at the section rather than the root so the page budget goes to reference content rather than blog archives.

Step 3 — Select tools​

ToolWhat it tells you
search_docsThe workhorse; its query log is the raw material for every later decision
ask_questionCaptures questions in your users' words, not your headings' words
find_api_referenceSeparates reference lookups from conceptual ones, distinguishing a navigation problem from a coverage problem
get_changelogShows whether your release notes are doing their job

Step 4 — Deploy and publish​

Deploy, then add a page to your documentation telling developers how to connect. Something like "Use these docs in your AI editor".

This page is the whole point of the exercise. It converts invisible AI-mediated readers into measurable ones.

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

Step 5 — Read the dashboard in the right order​

Give it a few weeks of real traffic first. Then work through the dashboard in this order, because it moves from clearest signal to most interpretive.

1. Unanswerable questions​

Queries where retrieval found nothing with meaningful confidence. Each is a person who asked your documentation something and got nothing back.

Sorted by frequency, this is your writing backlog, already prioritised by demand rather than by whoever complained loudest.

2. Low-confidence answers on high-traffic pages​

The dangerous quadrant: retrieved often and matching weakly, which means confident-sounding answers built on a poor match.

These pages usually do not need more content. They need clearer section headings and shorter, self-contained passages, because retrieval works on chunks and a chunk that only makes sense in the context of the surrounding page will always score badly.

3. Per-source grades​

If you followed step 2 and indexed separately, you can see which source pulls its weight. A reference section with poor grades is usually a formatting problem: tables and parameter lists chunk badly unless each row carries enough context to stand alone.

4. Question phrasing​

Compare the vocabulary in the query log to the vocabulary in your headings. Where they diverge, your headings are written in your team's language rather than your users'. Cheap to fix, disproportionate effect on retrieval.

A note on tiers and history​

Per-request telemetry is written on every request regardless of your analytics tier. The tier controls what the dashboard displays, not what gets recorded.

So deploy now on whatever tier you are on. Turning on a higher tier later backfills the new views with the history you already accumulated rather than starting from an empty chart. See Action and Predictive analytics for what each tier adds.