How to Build a Documentation Chatbot with MCP

A documentation chatbot that actually works — one that answers questions with citations, handles your entire docs site (not just one page), and stays up to date as your content changes — is harder to build than it looks.

The Model Context Protocol (MCP) has become the standard way to wire AI agents into external knowledge sources, making it the right foundation for a docs chatbot in 2026. This guide covers three approaches, from DIY to fully hosted, so you can pick the one that fits your stack and timeline.

What makes a good documentation chatbot

Before picking an approach, it helps to know what separates a working docs chatbot from one that halluccinates and frustrates users:

• Grounded answers — responses come from your actual docs, not the model's training data
• Citations — every answer links back to the source page so users can verify
• Multi-page retrieval — answers synthesize information from multiple pages, not just the top search result
• Freshness — the chatbot stays in sync as your docs change
• JS-rendered page support — if your docs use React, Next.js, or similar, a simple web scraper won't work

MCP solves the "how does the AI get the content" problem. The three approaches below all use MCP as the interface layer, but differ in how much infrastructure you build yourself.

Approach 1: DIY RAG pipeline

Best for: teams with existing infrastructure, specific compliance requirements, or deeply custom retrieval needs.

Build your own pipeline:

1. Crawl your docs — use a crawler that handles JS-rendered pages (Playwright, Puppeteer, or Jina Reader). Static HTML crawlers like Cheerio will silently miss content on SPA doc sites.
2. Chunk and embed — split content into ~500-token chunks with overlap, embed with a text embedding model (OpenAI text-embedding-3-small or similar), store in a vector database (Supabase pgvector, Pinecone, Weaviate).
3. Build the MCP server — expose a search_docs(query) tool that runs semantic search and returns top chunks. Return them as text with source URLs.
4. Wire up the chatbot UI — your frontend calls Claude (or another model) with the MCP tool available. The model calls search_docs, gets relevant chunks, synthesizes an answer.

// Minimal MCP tool for docs search
{
  name: 'search_docs',
  description: 'Search the documentation for answers to user questions. Returns relevant excerpts with source page URLs.',
  inputSchema: {
    type: 'object',
    properties: {
      query: { type: 'string', description: 'The user question to search for' }
    },
    required: ['query']
  },
  execute: async ({ query }) => {
    const embedding = await embed(query)
    const chunks = await vectorDB.search(embedding, { limit: 5 })
    return chunks.map(c => `[${c.title}](${c.url})\n${c.text}`).join('\n\n')
  }
}

Time to ship: 2–4 weeks for a basic version. More for freshness, re-crawling, and production hardening.

Ongoing cost: vector database hosting, embedding API calls, re-crawl infrastructure.

Approach 2: Hosted MCP service

Best for: teams who want a working chatbot in hours, not weeks, and don't want to maintain crawl infrastructure.

Services like AgentReady handle the crawl, chunking, embedding, and vector search for you. You connect your docs URL once and get back an MCP endpoint that any agent can query.

1. Submit your docs URL — the service crawls and indexes your site (handles JS-rendered pages automatically).
2. Connect the MCP server — add the MCP URL to your Claude Desktop, Cursor, or agent config. No code required.
3. Query immediately — ask ask_site(domain, query) and get a cited answer from your docs.

// Claude Desktop config — no code required
{
  "mcpServers": {
    "agentready": {
      "command": "npx",
      "args": ["-y", "@agentreadyweb/mcp"]
    }
  }
}

// Now ask Claude:
// "Search docs.myproduct.com for how to set up webhooks"
// → AgentReady queries the indexed content and returns a cited answer

Time to ship: Under an hour.

Trade-offs: Less customization; you rely on the service's crawl quality and uptime. Good services expose a refresh_site tool so you can trigger re-indexes after doc updates.

Approach 3: Hybrid — hosted retrieval, custom UI

Best for: teams that want a custom chatbot UI embedded in their product, without building retrieval infrastructure.

Use a hosted MCP service for retrieval, but build your own chat interface on top. Your frontend calls Claude (or another model) with the hosted MCP tools available. The model handles retrieval; you handle the UX.

// Next.js API route — calls Claude with AgentReady MCP tools
import Anthropic from '@anthropic-ai/sdk'

const client = new Anthropic()

export async function POST(req: Request) {
  const { question } = await req.json()

  const response = await client.messages.create({
    model: 'claude-sonnet-4-6',
    max_tokens: 1024,
    tools: [
      {
        name: 'ask_site',
        description: 'Search indexed documentation and return cited answers.',
        input_schema: {
          type: 'object',
          properties: {
            domain: { type: 'string' },
            query: { type: 'string' }
          },
          required: ['domain', 'query']
        }
      }
    ],
    messages: [
      {
        role: 'user',
        content: `Answer this question about our docs: ${question}`
      }
    ]
  })

  // Handle tool use in the response loop...
  return Response.json({ answer: response })
}

This pattern lets you embed a docs chatbot directly in your product — with your branding, your auth, and your UX — without running any retrieval infrastructure yourself.

Choosing between the three approaches

Common mistakes to avoid

• Using web_fetch or simple HTTP scraping — if your docs are built with React, Next.js, Vue, or any SPA framework, a plain HTTP fetch returns empty or skeleton HTML. You need a headless browser or a service that handles JS rendering.
• Not chunking properly — embedding entire pages produces poor retrieval quality. Chunk by section heading with 100-token overlap.
• Ignoring freshness — a chatbot trained on stale docs will confidently give wrong answers. Build in a re-crawl trigger on every doc deploy, or use a refresh_site hook.
• Skipping citations — users don't trust answers without sources. Always return the source page URL alongside the answer.

The MCP advantage over a standalone chatbot widget

Traditional doc chatbot widgets live in a sidebar on your docs site. MCP-powered documentation goes further: your docs become queryable from any MCP client — Claude Desktop, Cursor, Windsurf, or any agent a developer is using. Your users don't have to visit your docs site to get answers; the answers come to them, wherever they're working.

That's the compounding benefit of MCP: once your docs are indexed and exposed via an MCP tool, every new MCP client that ships is a new surface where your docs are available.