Your documentation
is an MCP server
Publish your docs and any AI agent can search and read them as a live tool. No sidecar to run, no SDK to install, no per-site deploy, and no configuration — the endpoint exists because your docs do.
Publishing is the install step
There isn't a second thing to turn on. The moment a docs page is published, it is reachable through the same endpoint every other site uses — one route on the platform, with your domain passed as a header. I didn't build a per-tenant server; I made the one server tenant-aware.
# Ask your docs site what tools it offers
curl -sX POST https://spideriq.ai/api/v1/content/docs/mcp \
-H 'X-Content-Domain: your-domain.com' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
# → search_docs · get_doc · semantic_search_docs · ask_docsOne header, one site, published pages only
The header that names your domain is what scopes every answer. An agent pointed at your docs gets your docs — never a draft, never a section stub, and never another customer's page. That is enforced in the query, not in a policy document.
Published only
Read-onlyDrafts are excluded before the search runs. Nothing here can create, edit, or publish anything — authoring stays behind your authenticated tools.
Your site, not the platform's
ScopedEvery tool resolves against the domain in the header. I probed four docs sites on one endpoint and each returned only its own pages.
Two tools your agent can use today
search_docs runs full-text search across your published pages and returns ranked titles, paths and snippets. get_doc fetches any one of those pages back as clean Markdown. Between them an agent can find the right page and read it, which is the whole job most of the time — and neither costs you anything.
{"query": "navigation", "total": 14, "page_size": 3,
"results": [
{"title": "Navigation",
"full_path": "building-your-site/navigation"},
{"title": "Pages",
"full_path": "building-your-site/pages"}
]}
// Hand a full_path to get_doc and you get the page as Markdown.Two more when you enable Docs AI
The endpoint also carries semantic_search_docs, which matches on meaning rather than keywords, and ask_docs, which writes an answer grounded only in your pages with citations back to them. Both sit on the retrieval index behind the Ask-AI box, so both need Docs AI switched on for your site — until it is, they return a clear "unavailable" and the two free tools carry on working. I'd rather tell you which half is live than let you find out from an agent.
For agent builders: it's a config block
If you are wiring an agent that needs to know a product, you have probably been scraping the docs or pasting them into a prompt. Point it here instead and it reads the current page every time, because there is no copy to go stale.
{
"mcpServers": {
"their-docs": {
"command": "npx",
"args": ["-y", "mcp-remote",
"https://spideriq.ai/api/v1/content/docs/mcp",
"--header", "X-Content-Domain: their-domain.com"]
}
}
}For API companies: your reference, in their editor
Your customers write integrations against your docs, and they increasingly do it with an assistant sitting next to them. Today that assistant guesses from whatever it memorised months ago. Give it your reference as a tool and it answers from the version you shipped this morning — same protocol Claude, Cursor and the rest already speak, so there is nothing for your customers to adopt beyond a URL and a header.
For everyone else: the server you don't operate
The alternative to this is running your own. That means a process to keep up, a container to patch, a key to rotate, a protocol revision to track, and an index that drifts from the docs the moment someone edits a page. I took that whole list off the table by making the docs themselves the server. What you maintain is your documentation — which you were maintaining anyway.