How to Add MCP to Your Existing Docs Site Without Rebuilding Anything

The most common question teams ask when they hear about MCP for documentation: "Do we need to migrate to a new platform?"

The answer is no. MCP is a protocol, not a platform. You can add it to any existing docs site — Notion, GitBook, Mintlify, Readme.io, Docusaurus, a custom Next.js site, even a static HTML site — without changing how you write, publish, or host your content.

Here's the full picture of your options, from zero-code to full DIY.

Option 1: Use a hosted MCP service (zero code, under an hour)

A hosted MCP service crawls your existing docs site and exposes the content as an MCP server. You don't change your docs pipeline at all — the service reads your site the same way a browser would, indexes it, and gives you an MCP endpoint.

How it works with AgentReady:

1. Submit your docs URL — AgentReady crawls it using a four-layer pipeline (llms.txt → HTTP → __NEXT_DATA__ extraction → headless browser for JS-rendered pages)
2. Your site gets indexed in ~60 seconds
3. Add the MCP server to Claude Desktop, Cursor, or any MCP client:

// Claude Desktop — ~/.claude/claude_desktop_config.json
{
  "mcpServers": {
    "agentready": {
      "command": "npx",
      "args": ["-y", "@agentreadyweb/mcp"]
    }
  }
}

// Then ask Claude:
// "What does docs.yourproduct.com say about authentication?"
// → AgentReady returns a cited, multi-page answer

What it handles that a plain web scraper won't:

• React / Next.js / Vue docs that render content client-side
• Sites protected by bot detection (Cloudflare, etc.) — the headless layer handles these
• Multi-page synthesis — answers draw from across your entire site, not just one page
• Freshness — call refresh_site after a deploy to re-index without re-submitting

Best for: any team that wants MCP today without an engineering sprint.

Option 2: Add an llms.txt file (five minutes)

Before crawling your full site, add an llms.txt file at your domain root. This is a plain-text index that tells AI crawlers exactly which pages to read and in what order — the same concept as robots.txt but for LLMs.

# https://docs.yourproduct.com/llms.txt
# AgentReady reads this first to discover pages

> YourProduct Documentation

## Getting Started
- [Quickstart](https://docs.yourproduct.com/quickstart): Get up in 5 minutes
- [Authentication](https://docs.yourproduct.com/auth): API keys and OAuth
- [SDKs](https://docs.yourproduct.com/sdks): Official client libraries

## API Reference
- [REST API](https://docs.yourproduct.com/api): Full endpoint reference
- [Webhooks](https://docs.yourproduct.com/webhooks): Event types and payloads

AgentReady's crawler checks for llms.txt first. If it finds one, it crawls exactly those pages in priority order, which produces faster indexing and better answer quality than a generic sitemap crawl.

This is not a substitute for MCP — it's a signal layer that improves how well MCP services (and any AI crawler) can read your site. Add it alongside either of the other options.

Option 3: Build a thin MCP wrapper around your existing search

If you already have an Algolia, Meilisearch, or Elasticsearch index powering your docs search, you can wrap it in a lightweight MCP server without re-indexing anything.

// Thin MCP wrapper over existing Algolia index
// No re-crawling, no new infrastructure — just a new interface

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import algoliasearch from 'algoliasearch'

const client = algoliasearch(process.env.ALGOLIA_APP_ID!, process.env.ALGOLIA_API_KEY!)
const index = client.initIndex('docs')

const server = new McpServer({ name: 'your-docs', version: '1.0.0' })

server.tool(
  'search_docs',
  'Search the documentation. Use this to answer any question about the product.',
  { query: { type: 'string' as const } },
  async ({ query }) => {
    const results = await index.search(query, { hitsPerPage: 5 })
    const text = results.hits
      .map((h: Record<string, unknown>) => `[${h.title}](${h.url})\n${h.content}`)
      .join('\n\n')
    return { content: [{ type: 'text' as const, text }] }
  }
)

await server.connect(new StdioServerTransport())

Trade-off: keyword search quality. Your existing Algolia index finds exact matches well but struggles with semantic queries like "how do I handle rate limit errors gracefully?". A vector-based approach (like AgentReady's RAG) handles those better. Use this option if you already have high-quality search and just want MCP discoverability quickly.

Option 4: Full DIY RAG + MCP

Build your own crawler, chunker, vector store, and MCP server. This gives you full control but takes 2–4 weeks and ongoing maintenance. It's the right call for enterprises with compliance requirements or highly specific retrieval needs.

The full guide is in How to Build a Documentation Chatbot with MCP.

Decision guide

What you don't need to change

Regardless of which option you choose, you keep:

• Your existing docs platform (GitBook, Mintlify, Docusaurus, custom)
• Your content workflow — writers keep using whatever they're using
• Your docs URL and hosting
• Your existing search widget

MCP sits alongside your existing setup as a new access layer. It doesn't replace anything — it adds a queryable interface for AI agents that didn't exist before.