MCP for documentation: how Claude, Cursor & ChatGPT can read and edit your docs

If you spend any time in Claude, Cursor, or ChatGPT, you have already noticed something: the more accurate the model is about your product, the more useful it becomes. Ask it about a generic library and it nails the answer. Ask it about your SDK and the hallucinations show up.

The Model Context Protocol (MCP) is the fix. And documentation is one of its most natural use cases.

What MCP actually is

MCP is a protocol that lets an AI client (Claude, Cursor, ChatGPT, VS Code, Windsurf, Continue, GitHub Copilot, etc.) connect to an external server and call structured tools. Think of it as the contract that bridges “the LLM wants information” and “your system has the information”.

Three pieces:

• MCP server — runs alongside your data and exposes a set of named tools (search_documentation, get_entry, update_entry, …) with typed inputs and outputs.
• MCP client — the AI app the user is in (Claude, Cursor, etc.). It discovers the server, sees the tool catalog, and decides when to call each one.
• Transport + auth — OAuth (RFC 9728), API keys, scoped permissions. The server controls what the client can do.

The protocol is open. Anthropic published it, then OpenAI, Microsoft, and the IDE ecosystem adopted it. As of mid-2026 every major AI client speaks MCP.

Why it matters for documentation specifically

Until MCP, the only way to ground an LLM in your docs was retrieval-augmented generation: chunk your content, embed it, hope the right chunk is in the prompt window. That works, but the LLM has no agency. It can’t act on the docs.

With MCP, the LLM can:

• Search your documentation in real time, not from a cached snapshot.
• Read a specific page when it needs the full context, not just a chunk.
• Edit documentation directly — “add a note about rate limits to the /refunds endpoint” — and the page updates.
• Publish changes when scope allows, gated by your permission policy.

The user doesn’t have to leave Claude or Cursor, copy a URL, open a CMS, paste, save, deploy. The AI does the round-trip for them.

For technical writing teams, this is the difference between “AI helps you write” and “AI maintains the docs alongside you”.

The GitDocAI MCP server

GitDocAI ships a built-in MCP server. When you publish a documentation, the server is live at a per-doc endpoint and exposes around 47 tools covering the full read / edit / publish lifecycle.

A few highlights:

• search_documentation(query) — semantic search across the whole doc, returns ranked entries with snippets.
• get_entry(entry_id) — fetch the full markdown of a specific page.
• update_entry(entry_id, append | replace, content) — modify a page, draft saved for review by default.
• create_entry(section_id, title, content) — add a new page under a section.
• list_sections(), list_entries(section_id) — explore the doc structure.
• publish_documentation() — promote pending changes to the live site (requires the mcp:publish scope).

Every call goes through your permission model. You issue an API key prefixed gdk_* from the dashboard and pick the scope tier when you generate it:

Scope	Lets the agent…
mcp:read	Search and read your docs. Can’t change anything.
mcp:edit	Read, plus draft edits to pages. Drafts wait for review.
mcp:publish	Read, edit, and push edits live. Full lifecycle.

mcp:edit strictly contains mcp:read, and mcp:publish strictly contains mcp:edit. Pick the lowest tier that does what you need.

What it looks like in practice

A typical session inside Claude:

1. You connect Claude to the GitDocAI MCP server using your gdk_* API key. One-time setup.
2. You say: “add a Webhook Events section to the /refunds endpoint docs.”
3. Claude calls search_documentation("refunds endpoint"), finds the page, calls get_entry(refunds), drafts the new section in markdown, then calls update_entry(refunds, append, ...).
4. The draft lands in your dashboard as a pending change. Your team reviews and publishes — same workflow as a PR.

Same flow works in Cursor (write a feature, ask Cursor to update the corresponding docs), in ChatGPT (a custom assistant for your support team that answers questions and files draft edits when it spots gaps), in VS Code (jump from code to the matching doc page without leaving your editor).

How to wire it up

If you have a documentation on GitDocAI:

1. Open your doc → MCP tab in the dashboard.
2. Generate an API key with the scope you want.
3. Copy the MCP endpoint URL.
4. In your AI client of choice, add an MCP server with that URL and the API key as auth header.

Three minutes total. The tool catalog appears in the client, and your agent has access from the next message.

If you do not have a documentation yet, start with a GitHub repo — GitDocAI generates the first draft, hosts it, and the MCP server comes up automatically once it is published.

What MCP changes for the way you ship docs

A small but real shift: the docs are no longer just a page you publish for human readers. They become an interface other systems can call. Every endpoint you document, every parameter, every example becomes addressable knowledge.

That has knock-on effects. Your docs need to be more structured (LLMs read better when content is decomposed). Your edits need to be reviewable (drafts queue up faster than a human can land them). Your update workflow needs to support partial writes (append and replace rather than wholesale replaces).

GitDocAI handles all three by design. The MCP server is not bolted on after the fact — the documentation model was built so AI clients could safely read and write it.

If you want to see it work end to end, the four-tab carousel on the home page walks through the same flow described above. The third tab — “For AI agents” — is the MCP session, recorded against a real Acme SDK documentation.

And if you’re ready to plug your own docs into Claude, Cursor, or ChatGPT, the MCP server is included on every plan — including Free.