MCP Server

What MCP is#

The Model Context Protocol is an open standard for exposing tools, resources, and prompts to AI agents over a typed RPC interface. The Docsbook MCP server exposes 80 tools — 62 named tools plus one registration tool per webhook event — covering the full product surface.

Endpoint#

https://docsbook.io/api/mcp/server

Authentication is OAuth 2.0 Authorization Code with PKCE. Bearer tokens are returned to the client and refreshed transparently.

Install in your AI client#

The Docsbook MCP server is a remote HTTP server with OAuth — every modern MCP client can connect to it using the same endpoint.

Claude Code#

claude mcp add --transport http docsbook https://docsbook.io/api/mcp/server

The first call opens a browser tab for OAuth. After consent, the tools become available inside Claude Code.

Cursor#

Cursor has no mcp add command, but it accepts a one-click install link:

cursor://anysphere.cursor-deeplink/mcp/install?name=docsbook&config=eyJ1cmwiOiJodHRwczovL2RvY3Nib29rLmlvL2FwaS9tY3Avc2VydmVyIiwidHlwZSI6Imh0dHAifQ==

Or add the server to ~/.cursor/mcp.json (or use Settings → MCP & Integrations → New MCP server):

{
  "mcpServers": {
    "docsbook": {
      "url": "https://docsbook.io/api/mcp/server"
    }
  }
}

Reload Cursor — OAuth opens in the browser on first use.

Codex CLI#

codex mcp add docsbook --url https://docsbook.io/api/mcp/server

Or edit the config directly — Codex stores MCP servers in ~/.codex/config.toml:

[mcp_servers.docsbook]
url = "https://docsbook.io/api/mcp/server"

Windsurf#

Edit ~/.codeium/windsurf/mcp_config.json and refresh the Cascade panel:

{
  "mcpServers": {
    "docsbook": {
      "serverUrl": "https://docsbook.io/api/mcp/server"
    }
  }
}

Cline#

Open Cline → MCP Servers → Configure MCP Servers and paste:

{
  "mcpServers": {
    "docsbook": {
      "url": "https://docsbook.io/api/mcp/server",
      "transportType": "http"
    }
  }
}

Gemini CLI#

gemini mcp add --transport http docsbook https://docsbook.io/api/mcp/server

The default scope is the current project — add --scope user to install it globally. Or add it by hand to ~/.gemini/settings.json (note the key is httpUrl; url there means SSE):

{
  "mcpServers": {
    "docsbook": {
      "httpUrl": "https://docsbook.io/api/mcp/server"
    }
  }
}

GitHub Copilot (VS Code)#

code --add-mcp '{"name":"docsbook","type":"http","url":"https://docsbook.io/api/mcp/server"}'

Or create .vscode/mcp.json inside your workspace, then enable the server from the Copilot Chat MCP picker (note the key is servers, not mcpServers):

{
  "servers": {
    "docsbook": {
      "type": "http",
      "url": "https://docsbook.io/api/mcp/server"
    }
  }
}

ChatGPT#

ChatGPT supports remote MCP through Connectors (Pro / Business / Enterprise plans).

1. Open ChatGPT → Settings → Connectors → Advanced → Developer mode.
2. Click Create and paste the URL: https://docsbook.io/api/mcp/server.
3. Authorize in the browser when prompted.

What the tools are for#

Your documentation is not a cost centre. It is a channel with three jobs: get found (by Google, and by the AI assistants your buyers now ask instead of Google), convert the reader (a visit that ends with nothing is a lost customer who never complained), and prove what worked (so the next edit is a decision, not a guess).

There are only four ways a docs tool makes money, and every tool below serves one of them:

A tool that serves none of these returns context, not a decision. Pageviews: 12,340 is context. 31% of your readers left with nothing is a decision.

Getting found#

Buyers increasingly ask an assistant before they ask a vendor. If the assistant answers from a competitor's docs, you never enter the shortlist and the loss appears in no dashboard.

Not losing the reader#

get_visit_outcomes (PRO) is the headline number of the whole product: it classifies every visit as success / dead end / bounce / partial and reports the dead-end rate and self-serve resolution rate. A dead end is a reader who searched, asked the AI, or opened several pages — and still left with nothing. Everything below answers "…and where exactly?"

Demand you are not serving#

Every row here is a support ticket you can pre-empt by writing one page.

Selling through the assistant#

The chat is not a support widget. It is the only place where a prospect states their objection in plain language.

A pricing objection stated in your docs chat is worth more than a page view: the reader qualified themselves and told you exactly what stops them buying.

Acting on the finding#

Diagnosis without a fix is a report. These close the loop inside one connection.

Knowing without looking#

A dashboard only works if someone opens it. A webhook works always. Registering any webhook is Business-only.

Reach and ownership#

The combinations that pay#

No single tool above is the product. These loops are.

Loop 1 — "Which page is costing me customers?"#

get_visit_outcomes      → the rate: 31% of visits end with nothing
get_dead_end_pages      → which pages those visits died on
get_rage_signals        → what the reader was trying to do there
get_change_history      → has this page been "fixed" before, and did it work?
search_docs → write_docs → ship the fix
get_metric_timeseries   → did the rate move after the commit?

The rate alone is unactionable, the page list alone lacks a cause, and a fix without get_change_history repeats a failed edit with full confidence. Only the sequence produces a change you can defend.

Loop 2 — "Is my navigation lying to readers?"#

get_route_patterns   → a frequent 3-page route that keeps ending badly
get_reverse_funnel   → the route successful readers actually take
update_navigation    → promote the working entry point
get_forward_funnel   → confirm completion on the declared route improved

A route that fails while its individual pages score well is a navigation defect — get_content_health would keep pointing at healthy pages forever.

Loop 3 — "Where are the deals leaking?"#

get_chat_intent          → 40 pricing-stage conversations, a competitor named in 12
get_chat_conversations   → those topics have near-zero click_through
set_chat_system_prompt   → handle that objection, route to a demo
write_docs               → a comparison page that answers it once and for all
get_chat_intent (later)  → did the objection stop recurring?

The only loop in any docs product that starts at a stated objection and ends at a shipped answer. click_through is what separates "the assistant answered" from "the assistant sold".

Loop 4 — "Am I visible to AI, and did it bring anyone?"#

update_geo + update_aeo   → structure content for citation
get_analytics (ai_bots)   → confirm crawlers are actually reading it
get_search_rankings       → track classic-search position alongside
get_analytics (referrers) → referrals arriving from AI assistants
get_visit_outcomes        → and whether those arrivals end in success

The last step is the one everybody skips. Traffic from an AI answer that dead-ends is worse than no traffic — you earned the visibility and burned the impression.

The self-healing loop#

Run Loop 1 on a schedule from CI:

weekly:  get_content_health  → take the worst 3
         get_change_history  → skip anything already tried and failed
         search_docs → write_docs → open a PR
         get_metric_timeseries → report the movement on the PR

Documentation that repairs itself and shows its work — "saw the problem" and "fixed the problem" without leaving the connection.

Reading the numbers honestly#

Every analytics response carries its own caveats in a metrics field. Three matter enough to repeat:

• Visitors are hashed IPs. Office NAT merges several readers into one; mobile networks split one reader into many. Report trends, never headcounts — get_retention is the most affected.
• Rates are withheld below 30 visits, and thin days are flagged thin. A 100% dead-end rate over four visits is noise.
• terminal_success is not a failure. A page people leave from after copying a snippet is the best page you have. Every ranking tool exempts these — do not re-introduce the mistake by hand.

Searching and editing documentation content#

There are two ways to work with your docs content from an agent:

• Hosted, via MCP tokens — search_docs (Free plan and up, read-only, works with any connected token regardless of its scope), get_doc_outline (Free+, read-only; lists every markdown page's title, heading count, and size before searching or writing), and write_docs (Free+, requires a token authorized with read-write scope; commits one or more files as a single atomic git commit). These run against the Docsbook-hosted repository directly, no local checkout needed.
• Local, via markdown-lsp — for an agent working directly on your checked-out files, markdown-lsp exposes richer LSP-style doc_* tools (outline, fuzzy headings, full-text, link references, resolve links) by running npx markdown-lsp <subcommand> ./docs on the agent's machine. See Source of Truth for the tool list and rationale.

Use search_docs/write_docs when the agent only has an MCP connection (no local checkout); use markdown-lsp when the agent already has the repo on disk and wants deeper graph navigation.

Plan gating#

Each tool declares a minimum plan. The server returns a structured error when a tool is called below the required tier.

Related#

• MCP tools reference — every tool with its parameters and minimum plan.
• Chat Hooks — Configure pre/post-LLM hooks via MCP.
• Docs Skills — Discover SKILL.md files through find_skill.
• Webhooks — Register event handlers from MCP.