← Blog

August 4, 2026 · 7 min read

doc2mcp vs GitMCP vs Context7 vs AgentReady: Choosing the Right Docs-to-MCP Tool

With AWS MCP Server going GA this week and WebMCP in Chrome 149 origin trial, the "docs to MCP" category has gone from a niche experiment to a real product space. Four distinct tools now handle the same root problem: how do you make documentation queryable by AI agents? They make very different tradeoffs. Here's how to choose.

The four tools at a glance

ToolApproachBest for
doc2mcpLive pass-through fetchSingle-page docs, quick demos
GitMCPGitHub repo → MCPOpen-source projects with README/wiki
Context7Curated library indexPopular frameworks (React, Next.js, etc.)
AgentReadyIndexed RAG, any URLAny public docs site, with a directory

doc2mcp

doc2mcp takes a docs URL and creates a hosted MCP server that fetches pages in real time when an AI agent queries them. It's the fastest path from URL to working MCP endpoint — paste a URL, get a connection string, done.

The tradeoff: because it fetches live, there's no semantic search. The AI gets the raw page content and has to figure out what's relevant itself. This works fine for single-page API references or small sites, but it breaks down on documentation with hundreds of pages — the AI can't know which page to fetch for a given question.

Use it when: you need a quick demo, you're working with a very small docs site, or the documentation is structured as a single long page.

GitMCP

GitMCP converts a GitHub repository into an MCP endpoint. It reads the README, wiki, and any markdown files in the repo, and exposes them through a standard MCP interface. The connection string is derived from the GitHub URL — github.com/owner/repo becomes an MCP endpoint automatically.

The tradeoff: it only works with GitHub repositories. If your documentation lives on a rendered docs site (ReadTheDocs, GitBook, Mintlify, Docusaurus), GitMCP reads the source markdown, not the rendered output — which misses generated content, auto-generated API references, and anything that doesn't exist as a committed markdown file.

Use it when: your project is open-source, your docs are primarily README-driven, and your audience is developers who are already in GitHub context.

Context7

Context7 takes a different approach: it's a curated index of popular libraries and frameworks, maintained by the Context7 team. You don't add your own docs — you connect to Context7 and query their library index. It covers React, Next.js, Vue, Tailwind, Prisma, and other widely-used frameworks.

The tradeoff: you can't add arbitrary sites. If your product isn't in Context7's curated index, you're out of luck. It's also optimized for library documentation, not product docs, API references, or internal wikis.

Use it when: you're a developer working with mainstream libraries and want accurate, up-to-date answers about React hooks or Next.js config options.

AgentReady

AgentReady crawls any public URL, indexes every page into a vector store, and serves the indexed content through a unified MCP endpoint. Unlike live-fetch tools, queries use semantic search to find the most relevant content across all indexed pages — so asking "how do I configure RLS in Supabase?" returns the relevant rows from the Supabase docs, not the homepage.

There's also a public directory of 130+ already-indexed sites that anyone can query immediately. Stripe, Vercel, Supabase, React, Tailwind, Anthropic, and others are already there — no indexing required.

The tradeoff: indexing takes 30–90 seconds and the index is a snapshot. If the documentation changes, you re-submit the URL to get a fresh index. For most documentation that changes weekly or less, this isn't a problem. For changelogs or frequently updated references, it's worth keeping in mind.

Use it when: you're indexing a multi-page docs site, you want accurate semantic search across hundreds of pages, or you want your users' AI agents to get cited answers about your product.

Live-fetch vs. indexed RAG: the core split

The fundamental divide is between live-fetch (doc2mcp, and to some extent GitMCP) and indexed RAG (AgentReady, Context7). The difference matters most at scale:

With live fetch, the AI sends a request, gets a full page back, and tries to extract relevant content from it. That works for small, well-structured docs with a clear URL per topic. It doesn't work well when the AI doesn't know which URL to fetch — it would need to retrieve and read the entire documentation site to answer a question.

With indexed RAG, the query is converted to a vector, matched against pre-indexed content, and the most relevant chunks are returned — regardless of which pages they came from. A question about a niche configuration option gets the right answer even if it's buried in page 47 of 300. This is why RAG was invented.

The decision tree

Start with what you're trying to query:

A GitHub repo with README-driven docs: try GitMCP first. It's zero-config.

A mainstream library (React, Next.js, Tailwind, etc.): check if Context7 already covers it. If yes, it's the fastest path.

Any other public docs site with multiple pages: AgentReady. Paste the URL, get a semantic search endpoint in 60 seconds. Check the directory first — it may already be indexed.

A single-page reference or quick demo: doc2mcp is fast and frictionless.

What about running your own MCP server?

All four tools are hosted services. If you need private docs, on-premise deployment, or custom retrieval logic, you'll want to run your own — see our TypeScript MCP server tutorial or Python MCP server tutorial. For public documentation where you just want accurate AI agent answers as quickly as possible, one of the four tools above is almost always the better starting point.