Your readers increasingly do not read documentation — their AI does. The Docs MCP makes your published documentation and API reference a first-class source for it: any MCP-compatible client can connect to your site, search it, walk its table of contents and read whole pages, with the same fidelity your readers get in a browser and none of the guesswork of a scrape.
It is not a separate product you host, and there is nothing to export. It is your documentation site, answering a second kind of request.
What your readers get
A reader adds one URL to their AI client:
https://YOUR-DOMAIN/mcpwhere YOUR-DOMAIN is your published documentation site’s domain. From that one endpoint their AI can do nine things, all of them reads:
| What their AI can do | Tool | Returns |
|---|---|---|
| Get oriented before spending anything | get_site_overview | Your site’s name and description, and the documentation sets available |
| See what documentation exists | list_documentation_sets | Each set’s name, type (documentation or api), base path and description |
| Walk a set’s table of contents | get_documentation_set | The hierarchical menu — section headers as plain nodes, leaves carrying a page id, path and URL, with the HTTP method on API endpoints |
| Search your documentation | search_docs | Ranked matches with a path, a snippet and a score — no full content |
| Search your API reference | search_api | The same, over API reference pages |
| Read the pages it found | get_pages_by_id | Up to 25 pages per call, by page id |
| Read a page it has a URL for | get_pages_by_path | Up to 25 pages per call, by site path |
| Pull a whole API contract | get_openapi_spec | The complete OpenAPI specification for an API set — large, and flagged as such |
| Learn the response shapes | describe_schema | JSON Schema for every object the tools above return |
Nothing on this surface writes, and nothing reaches beyond published documentation and API reference pages. The parameters, the return envelopes and the per-call limits are in the Docs MCP tool reference.
One detail is worth knowing because it changes how a model behaves: when it fetches an API reference page, the content it gets back ends with the operation’s structured contract — method, endpoint, parameters, security and responses — in a fenced YAML block below the prose. A model asking about one endpoint gets the documentation and the exact contract in a single call, without pulling your whole specification. API reference pages explains where that content comes from.
It is on your domain, not ours
This is the part that surprises people, so it is worth being precise. The endpoint is on your domain, but you host nothing new.
Your published site worker already serves your documentation. It also answers /mcp and the two OAuth discovery documents by proxying them to Leed’s public API worker, stamping a trusted identifier for your workspace and your visitor-facing origin onto the request as it goes. Leed’s worker owns the protocol, the sign-in flow, search and the request log; your site worker fills in page content from the same static assets it serves to browsers.
flowchart LR
Client["Reader's AI client"] -->|"POST https://YOUR-DOMAIN/mcp"| Edge["Your published site worker"]
Edge -->|"MCP switched off"| Off["403 mcp_not_enabled<br/>never leaves your domain"]
Edge -->|"on: injects workspace id + your origin"| Leed["Leed public API worker"]
Leed --> Search["Search index<br/>keyword · semantic · hybrid"]
Leed --> Log[("Request log<br/>every call, every denial")]
Leed -->|"paths + metadata"| Edge
Edge -->|"fills in page content"| Assets[("Your published pages")]
Edge -->|"one response"| Client
Two consequences fall out of that shape. Readers never leave your domain, so the sign-in screens, the emails and the endpoint all carry your name rather than Leed’s. And the responses that cross between the two workers carry paths and metadata rather than content blobs — content is filled in at the edge, from the same published files your site already serves.
How a visitor gets in
Your readers are not Leed users and never create an account. Their client walks a standard OAuth flow and the human part of it is short:
- Their AI client opens a page on your site and asks for their email address, with a bot check.
- They receive a six-digit code by email and type it on the same page — a code rather than a magic link, so the flow survives corporate link scanners.
- First-time visitors give their name, and optionally a phone number, job title and company. Returning visitors with a complete profile skip this.
- Access is granted and the browser hands control back to their AI client, which refreshes quietly from then on.
The full flow, screen by screen — including what a denied visitor sees and how long access lasts — is the reader sign-in flow.
Always current, nothing to sync
The Docs MCP serves what you have published. Publish an update and the next call returns it — there is no export, no re-index step and no separate copy of your documentation to keep in step. A reader’s AI that answered from last month’s page answers from today’s the moment you publish, without either of you doing anything.
That is the practical difference between this and handing someone a folder of markdown: a snapshot goes stale from the instant it is taken, and nobody finds out until the answer is wrong. Publishing a documentation set covers what “published” means here, and it is the only thing that gates what the MCP can see.
Why turn this on
- AI-ready documentation. Your customers’ assistants answer from your actual published docs — current, complete and correctly scoped — instead of a training snapshot or a scrape of whatever a crawler happened to reach.
- Search built for a model, not a person. Results come back ranked, with snippets and scores and no page furniture. The model fetches only the pages it needs, so its answer cites the right page instead of paraphrasing your home page.
- Gated, not public. Unlike publishing markdown to the open web, every identity is verified and your access rule is enforced on every renewal, so a churned customer loses access without you doing anything.
- A demand signal you cannot get any other way.
The demand signal
Every tool call and every denied sign-in writes a row to the request log: which tool ran, its full inputs — including the search text — how many results came back, which verified visitor made the call, which surface it came from, and when. A denied attempt records the email address and domain that was turned away, even when nothing else about that person is captured.
Read the zero-result searches. A search_docs call that returned nothing is a documentation gap phrased in your user’s own words, by a machine that was actively trying to answer their question and could not. That is a better backlog than any survey, and it arrives continuously.
Where the traffic shows up alongside human and public-agent visits is in analytics for AI and MCP clients.
Who is allowed in is your decision
Two toggles, both on by default, in Settings → System Settings → General.
Open access to any verified identity decides whether anyone who verifies an email gets in, or only your current customers. Capture leads from non-customers decides what happens to the people who are turned away — whether they are captured as leads first, or refused before a code is ever sent.
Out of the box the shipped behavior is the permissive one: anyone who verifies an email address is granted access, and every verified visitor is captured. If your documentation is meant for customers only, that is a setting to change before you announce the endpoint. Both toggles, their exact effects and every combination are in configuring the Docs MCP, and the readers those captures become appear with everyone else in contacts.
Scope: documentation and API reference only
Leed has three MCP surfaces and they do not overlap.
| Surface | Serves | Who signs in |
|---|---|---|
| Docs MCP | Your documentation and API reference | Your readers, with an email code |
| Site AI agent | Your published posts and articles | Nobody — it is public and read-only |
| Operator MCP | Your whole workspace | Your own team, through their Leed account |
A page id that belongs to a blog or marketing page returns a per-item error from get_pages_by_id rather than content, even to a fully authorized reader. That is the scope boundary doing its job, not a bug — and what a documentation set is defines which pages fall inside it.
What to tell your readers
One line in your documentation is usually enough:
Connect your AI to these docs: add https://YOUR-DOMAIN/mcp as an MCP server in
Claude, Claude Code, ChatGPT, Cursor or any MCP-compatible client, and verify
with your work email.Put it somewhere a developer will meet it early — a getting-started page, or the introduction to your API reference. Readers who use MCP daily will not think to try it on a documentation site unless you say so.