Start free trial

Documentation MCP server

One surface for agents
to read and write

Most documentation tools bolt MCP onto something else — an index, a published site, a CMS.

In Git2Docs, MCP is the authoring layer: the surface agents write through and the surface agents read from are the same one, and everything crossing it passes the same check.

How it works

One server on both edges, and a gate in front of everything that publishes.

01 Your repository GitHub · GitLab · Bitbucket 02 Coding agent + Git2Docs skill supplies repo facts 03 Generates v1 of the docs 04 Coding agent validates docs against code + live deployment changes file · over MCP affected pages regenerate, then validate again read-only clone nothing is ever written back to your repository
  • A coding agent running the Git2Docs skill reads your repository and supplies the facts a parser can't derive.
  • Git2Docs clones the repository read-only — it never writes to it — and generates the first version of the docs.
  • A coding agent validates those pages against the code and the running system.
  • It returns a changes file over MCP, and Git2Docs regenerates what it flagged.
  • The loop repeats until there is nothing left to find.

For comparison

How Git2Docs approach is superior to other solutions

PATTERN 1 · RETRIEVAL ONLY Source code copied by hand drift starts here Human editor or CMS publish → index Published docs MCP · read Agent PATTERN 2 · AUTHORING ONLY Source code no path from source CMS publish Published docs search / separate index Agent MCP · write nothing checks the write
  • A retrieval-only server sits on the read edge, with docs authored somewhere else and nothing tying them to source.
  • An authoring-only server sits on the write edge into a CMS, with a separate read path and no check between the write and publication.
  • Git2Docs puts one server on both edges and a validation gate in front of publication, so an agent's writes re-enter through the same check that generated content does.

The Git2Docs architecture advantage

Six consequences, each of which follows from the shape of the workflow rather than from any individual feature.

01

Nothing is written back to your repository

Git2Docs clones read-only. Documentation is generated and corrected on our side, never by opening pull requests or committing into your tree — so adopting it changes nothing about who can write to your code, and the security review is a short one.

02

There is no hand-copy step to drift

In the common pattern a person reads the code and writes prose somewhere else. From that moment the two diverge, silently, and no process holds them together for long — the gap is structural, not a discipline problem. Generating from committed source removes the step instead of policing it.

03

The agent fills in what a parser can't

Some truths aren't in the syntax — a deployment name, a namespace, a compatibility guarantee. A coding agent running the Git2Docs skill supplies them as anchored facts, each tied to the line of source that proves it, so they are checkable like everything else rather than taken on trust.

04

What the agent reads is what the agent wrote

When authoring and retrieval are different systems, the agent reads a copy — processed, indexed, possibly lagging. Any delay or transform between the two is invisible drift you can't measure. One surface means there is no copy to fall behind — and it is the same surface your customers reach through the support chatbot, so people and agents are answered from identical content.

05

Corrections close the loop without a queue

An agent that finds a mismatch while validating returns a changes file over MCP, and the affected pages regenerate. No ticket, no separate editor login, no pull request waiting on someone who wasn't going to get to it this sprint — and the regenerated pages are validated again before anyone reads them.

06

Accuracy becomes measurable at all

You can only count the claims that contradict your code if the docs are tied to the code in the first place. An architecture where documentation originates away from source has nothing to compare against — which is why the industry measures freshness, traffic and search relevance instead of accuracy. This shape is what makes the two numbers on our features page possible.

The honest part

A loop this closed needs a checkpoint

If an agent writes a page over MCP and another agent reads that page back as ground truth, nothing in between has checked whether it was true. Removing the human authoring surface removes the human who used to notice. That is a real risk, and it is created by the architecture we are recommending — so it is ours to answer.

01 Pull the claims every documented CLI, API and config claim — for the exact release you're on 02 Check them each claim checked against the actual source, and run against the live deployment 03 Report mismatches a finding names the claim, the page, and the code that contradicts it 04 Fix and regenerate the affected pages are rewritten, the old validation goes stale, the loop re-arms validate again · until it's zero FINDINGS PER ROUND 33 8 2 0 findings per validation round, same repository the loop ends when nothing is left to find
Validation is scoped to the documentation as it stands. Apply a round of fixes and regenerate, and the previous result goes stale — so the number you are looking at always describes the docs you have now, not the docs you had last week.

How to tell which pattern a docs MCP server uses

Four questions that place any documentation MCP server — including this one — into one of the rows above.

Does it expose write tools, or only read tools?

List the server's tools. Read-only means the docs are authored somewhere the agent can't reach, and every correction it finds has to leave the loop to get fixed.

Is there a human authoring surface behind it?

If there's an editor the team is expected to work in, the MCP server is an interface onto that editor — and the editor, not the server, is where content originates.

Can a page tell you which commit it came from?

Provenance only exists if the content was generated from committed source. A page written by hand or by an agent into a CMS has no commit to point at.

Ask it about something that doesn't exist.

Request a parameter you invented. A server wired to checked content says it doesn't exist. One wired to unchecked content will often explain how to use it and cite a page. Thirty seconds, and it fails loudly.

Start here

Anchor your facts before the first generation

The exact names, namespaces and compatibility claims no extractor can read — stated once, each proved against a line of source, so the docs are grounded from the start rather than corrected afterwards.

01 Install the skill the git2docs skill, in your coding agent no token · no MCP yet 02 Run one prompt in your repo, before the first generation bootstrap docsync-context 03 It proves each fact every claim tied to the file and line that shows it's true name → src/config.ts:42 04 Review and commit it reports what it anchored — read it like any other change docs/docsync-context.yaml grounded from the first generation
01

Install the git2docs skill in Claude Code. It needs no token and no MCP connection.

02

Run this in your repo:

Use the git2docs skill to bootstrap docs/docsync-context.yaml for this repo.
03

The agent proves each fact against a file and a line, writes the file, and reports what it anchored. Review it like any other change and commit it.

FAQ

Questions this architecture raises

What is a documentation MCP server?
A documentation MCP server exposes a product's documentation to AI agents over the Model Context Protocol, so an agent queries the docs directly instead of scraping a website or answering from training data. Most are read-only: the agent can retrieve documentation but not change it. A read-and-write server also lets the agent author and correct documentation through the same interface.
Can agents write documentation through MCP, not just read it?
Through the Git2Docs MCP server, yes. Documentation authoring runs through MCP, so an agent that finds an inaccuracy while reading can correct it through the same interface rather than filing it for a human. The write passes the same validation gate that generated content does before it publishes.
What stops an agent from writing something wrong?
A validation gate sits in front of publication. Every write is checked against the source code it describes and against the running system before it becomes a published page, and writes that contradict the code are reported as findings instead of being published silently.
Does the agent read the same content it writes?
Yes. The read path and the write path are the same surface, so there is no separate index that can lag behind what was authored. A correction an agent makes is immediately what the next agent reads.
Why does it matter where the MCP server sits?
Because it determines whether accuracy can be measured. Documentation generated from committed source can be compared against that source, and mismatches counted. Documentation authored on a separate surface has nothing to compare against, so freshness and relevance get measured instead of accuracy.

Connect your docs to your agents

Generate documentation from your repository, measure it against your code, and serve it to people and agents from one surface. Free for 30 days, no card.

Start free trial See all features