MCP Documentation: Connect Your Docs to AI Agents
Every space you publish on OpenDocs is instantly queryable by AI agents through the Model Context Protocol — no scraping, no stale exports, no separate pipeline to maintain.
What is the Model Context Protocol?
The Model Context Protocol (MCP) is an open standard for connecting AI assistants to the tools and data they need to do useful work. Before MCP, giving an AI agent access to your documentation meant one of two things: pasting text into a prompt by hand, or building a custom scraper that broke every time your site changed. MCP replaces that with a clean, structured interface. A server exposes a small set of tools; a client calls those tools; the agent gets exactly the content it asked for, in a format it can actually use.
The easiest way to think about it is as a USB port for AI context. A USB port does not care what you plug into it — a keyboard, a drive, a camera — because both sides agree on the same connector. MCP is that shared connector for AI applications and data sources. A client that speaks MCP can talk to any MCP server, and a server that speaks MCP can serve any MCP client. There is no per-integration glue code to write on either side.
The client side is where the ecosystem is growing quickly. Claude Desktop and Claude Code both act as MCP clients, and a widening range of other MCP clients and agent frameworks now support the protocol. That matters for documentation because it means the docs you already publish can become a live data source for whichever assistant your team, or your customers, happen to use — without you writing a bespoke integration for each one.
What the OpenDocs MCP server exposes
Four tools, secured by an OpenDocs API key, that let an agent discover, navigate, read, and search your published documentation.
list_spaces
Returns the published spaces your API key can reach. An agent uses it to answer a question like “Which documentation sets does this account publish?” before deciding where to look.
get_page_tree
Returns the full navigation structure of a space as a tree. An agent uses it to answer “Where in the docs would I find the section on webhooks?” and to plan which page to open next.
get_page
Returns the full content of a single page as clean plain text. An agent uses it to answer “What are the exact steps to rotate an API key?” by reading the real page, not a summary of it.
search_pages
Runs a keyword search across a space and returns matching pages. An agent uses it to answer “Does anything in these docs mention rate limits?” without knowing the page tree in advance.
Why this beats scraping and exports
The old ways of feeding documentation to an AI agent all share the same flaw: they produce a copy, and copies go stale. An export is a snapshot of your docs at the moment you ran it. A scraper is a fragile approximation of what a browser sees, littered with navigation chrome, cookie banners, and layout markup that the model has to wade through. Both drift out of date the moment you publish an edit, and both put the burden of keeping things fresh on you.
Serving your documentation over MCP removes the copy entirely. The agent reads your live published content at query time, so it always sees the current version — the instant you publish a change, the next query reflects it. There is no export to regenerate and no scraper to babysit.
Because the content comes through a purpose-built interface rather than an HTML scrape, it arrives structured and clean. get_page_tree hands the agent a real navigation hierarchy instead of a flat wall of links, and get_page returns plain text without the surrounding page furniture. The agent spends its context on your actual words, not on stripping out markup.
Finally, access is controlled by an API key. A public scraper reaches whatever a browser can reach; the OpenDocs MCP endpoint serves only the spaces you have published, and only to a client holding a valid key. You decide what an agent can see, and you can stop serving it by rotating the key — something no scraped copy will ever respect.
What teams build with it
Support agents that answer from your help center
Point a support assistant at your published help center over MCP. When a customer asks a question, the agent searches your pages, reads the relevant one, and answers from the documentation you actually maintain — not from a training snapshot that predates your latest release.
Coding assistants that read your API guides
A developer working in Claude Code can have the assistant pull your API guides directly through MCP while they build. The assistant reads your authentication flow, endpoint reference, and examples in place, so its suggestions match how your API really works.
Internal assistants that search company SOPs
Publish your standard operating procedures to a restricted space and let an internal assistant query them over MCP. Staff ask in plain language; the agent searches the SOPs, opens the right page, and returns the exact procedure — access controlled by your API key.
How it fits your workflow
The point of the OpenDocs MCP server is that it needs no separate workflow at all. You write documentation the way you already do — in the block-based visual editor, or in Markdown synced from a GitHub repository through GitHub Sync — and you publish it the way you already do. The MCP endpoint simply serves what you have published. There is no second system to keep in step, because the docs your readers see and the docs your agents query are the same docs.
That single-source-of-truth property is what makes it reliable. When a writer fixes a step in the visual editor, or an engineer pushes a Markdown change through git, the published page updates — and the next MCP query returns the corrected content. Your human readers and your AI agents see updates at the same moment, because they are reading the same published pages.
Getting started is deliberately simple: generate an API key in your OpenDocs settings, then point your MCP client at the OpenDocs MCP endpoint using that key. Because OpenDocs uses the streamable HTTP transport, any MCP-compatible client that speaks MCP over HTTP can connect. From there, the four tools are available to whatever agent you have configured.
An honest note on where MCP stands
MCP is a young standard, and the ecosystem around it is still evolving. Clients, transports, and conventions are maturing quickly, and some of the tooling you will find is early. We would rather tell you that plainly than oversell it. What we can commit to is that OpenDocs tracks the standard as it develops, so the MCP server keeps working with the clients that matter as the protocol settles.
It is also worth being clear about a related but separate idea. You may have seen llms.txt discussed as a way to make a site friendlier to language models. That is a static convention — a text file listing your content — and it is a genuinely useful emerging standard, but it is not the same thing as an interactive query protocol. OpenDocs does not currently generate llms.txt files for published sites. What OpenDocs ships today is a working MCP server that agents can query in real time.
Frequently asked questions
What is the Model Context Protocol (MCP)?
The Model Context Protocol is an open standard for connecting AI assistants to external tools and data sources. Instead of copying text into a prompt or scraping a website, an MCP-compatible client can call structured tools that an MCP server exposes. OpenDocs runs an MCP server so AI agents can list, browse, read, and search the documentation you publish.
Which AI clients can connect to the OpenDocs MCP server?
Any MCP-compatible client can connect. That includes Claude Desktop, Claude Code, and a growing ecosystem of other MCP clients and agent frameworks. OpenDocs uses the streamable HTTP transport, so a client that speaks MCP over HTTP can point at the OpenDocs MCP endpoint and start calling tools.
Is my private documentation exposed to AI agents?
No. The MCP endpoint requires an OpenDocs API key, and it only serves spaces you have published. Nothing is public by default, and an agent cannot reach content you have not published. You control access through your API key and through which spaces are published.
Does MCP access cost extra?
MCP access is secured with an OpenDocs API key. API access and full API docs are Enterprise features. For what is included on each plan and current pricing, see the pricing page.
How is MCP different from llms.txt?
An llms.txt file is a static convention: a plain text file that lists your content so a model can read it. MCP is an interactive query protocol: an agent calls tools in real time to browse a page tree, read a specific page, or search across pages. The two are complementary, but they solve different problems. OpenDocs ships an MCP server today; it does not currently generate llms.txt files.
What tools does the OpenDocs MCP server expose?
Four tools: list_spaces returns the published spaces available to your API key, get_page_tree returns the navigation structure of a space, get_page returns the full content of a page as plain text, and search_pages runs a keyword search across a space. Together they let an agent discover, navigate, read, and search your published documentation.