What tools can convert documentation into MCP servers for AI agents?

[gautammanak1]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Code Search and Navigation

Body

I recently built doc2mcp, a tool that converts documentation URLs into hosted MCP (Model Context Protocol) servers.

The goal is to make documentation directly accessible to AI coding agents without requiring custom parsers or additional infrastructure. By providing a documentation URL (such as Stripe, GitHub, Mintlify, OpenAPI, or Markdown docs), the tool generates a hosted MCP endpoint that can be queried by compatible AI tools.

Features:

Convert docs to MCP in under a minute
Hosted endpoints with no deployment required
Compatible with Cursor, Claude, and Windsurf
CLI support: npm i -g doc2mcp
Automatic synchronization when documentation changes

Website: https://doc2mcp.site/

I'm interested in feedback from developers using MCP or AI coding tools. Suggestions and feature requests are welcome.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[xniperbuilds]

Neat idea — the "no custom parser" angle is the real sell here, most people building MCP integrations spend half their time on the ingestion layer.
A few things I'd want to know before actually plugging this into a workflow:
Sync behavior — when docs change, how does it detect that? Polling? Webhook? And what's the lag between a docs update and the MCP endpoint reflecting it? For something like Stripe's changelog that matters a lot.
Private/auth-gated docs — any support for docs behind a login, or is it public URLs only right now?
Rate limits / uptime — since it's hosted, if your endpoint goes down, every agent that depends on it breaks silently. Is there an SLA or at least a status page?
The CLI (npm i -g doc2mcp) is a good call — lowers the barrier a lot compared to a dashboard-only flow.
What's the current stack under the hood? Curious whether you're chunking and embedding the docs or doing something closer to raw retrieval.

[gautammanak1]

Really appreciate this — you nailed the thesis. The ingestion layer is exactly where the effort went, and "no custom parser per source" is the whole point. Going through your questions one by one:

Sync & freshness

It's scheduled re-crawl with content-hash diffing — not webhooks (yet). Every page is stored with a content hash; a cron re-crawls on an interval and only regenerates the toolkit when the hash actually changes, so static docs never churn the live endpoint.

Plan	Re-crawl cadence
Free / Starter	Manual sync (on demand)
Pro	Every 24h
Team	Every 6h

You can also trigger a manual sync anytime and it runs immediately (jobs go through a QStash-backed queue). So worst-case lag = your plan's interval. For something like Stripe's changelog, the 6h Team cadence — or a manual/webhook trigger — is the right fit. The sync endpoint already accepts an external POST, so docs-platform webhooks (Mintlify / GitBook publish events → near-zero lag) are the next step.

Private / auth-gated docs

Public URLs right now. There's token-gated output — private projects on Pro/Team keep the generated MCP behind per-user tokens — but ingesting docs that sit behind a login isn't supported yet. Header/cookie auth + SSO-protected portals are on the roadmap.

Rate limits, uptime & SLA

Hosted on Vercel + Supabase (Postgres). MCP reads are unlimited; the metered limits are conversions/month and pages/site per plan. Team includes a 24h support SLA.

You're right that a silent outage is the scary failure mode for a dependency like this. The endpoints are stateless reads off Postgres, so the blast radius is mostly upstream availability — but honestly, a public status page + endpoint health checks aren't live yet. They're the immediate next item on the reliability list, not something I'll pretend already exists.

Stack & retrieval

Next.js (App Router) on Vercel · Postgres (Supabase) via Drizzle · background jobs via QStash.

On retrieval specifically — it's deliberately not vector embeddings yet. The pipeline is:

1. Crawl → normalize each page to structured markdown (tagged api / auth / workflow / page).
2. Heading-aware chunking — split at ATX headings, carry the full breadcrumb path (e.g. Auth > Bearer tokens > Refresh), ~1.5k chars with 150-char overlap and code-fence-aware splitting so snippets never break mid-block.
3. Lexical / BM25-style ranking — search_documentation returns one result per section (snippet + breadcrumb + source URL), deduped, with a small boost for API pages.
4. ask_documentation synthesizes a cited answer over the top sections.

Tool	Returns
search_documentation	Ranked sections — snippet + breadcrumb + URL
get_documentation_page	Full text of one page
ask_documentation	Synthesized answer with citations
read_full_documentation	Whole corpus, for broad context

I went lexical-first on purpose: it's deterministic and the citations are exact, which matters far more than fuzzy recall for API docs. Embeddings / hybrid retrieval is the planned upgrade for long-tail and synonym queries where lexical falls short.

What you flagged → roadmap

• Webhook-driven sync (Mintlify / GitBook) for near-zero lag
• Auth-gated docs ingestion (headers / cookies / SSO portals)
• Public status page + endpoint health checks
• Embeddings / hybrid retrieval alongside lexical

And yeah — the CLI was a deliberate bet for exactly the reason you mentioned: npm i -g doc2mcp → convert → install into your editor, no dashboard required.

Happy to go deeper on any of these. If there's a specific docs site you'd want as an MCP, drop it and I'll convert it so you can poke at the live endpoint.

[xniperbuilds]

This is a genuinely thorough breakdown — the content-hash diffing for avoiding unnecessary regeneration is a smart call, and I like that you're being upfront about what isn't live yet (status page, auth-gated ingestion) rather than glossing over it.
The lexical-first retrieval decision makes a lot of sense for this use case. Exact citations matter way more than fuzzy recall when someone's agent is trying to use the correct API parameter. The breadcrumb carry (Auth > Bearer tokens > Refresh) is particularly useful — that's the kind of context that usually gets lost in naive chunking.
A few follow-up thoughts:
The webhook sync path (Mintlify/GitBook publish events → POST to your sync endpoint) seems like it should be relatively straightforward given the infrastructure is already there. Is the blocker implementation time or something on the docs-platform side?
For auth-gated ingestion — header/cookie auth would cover a decent chunk of cases. Most internal doc portals are sitting behind a simple bearer token or basic auth anyway. SSO/SAML is the harder problem; I'd ship the simpler case first.
One thing I'd watch: the ask_documentation synthesis layer. If that's calling an LLM over the top sections, that's a potential latency spike + cost center that scales with corpus size and query volume. Worth being deliberate about caching repeated queries before that hits at scale.
The four-tool split (search_documentation, get_documentation_page, ask_documentation, read_full_documentation) is clean. Agents can be surgical or broad depending on what they actually need.
Solid project — following to see where the hybrid retrieval lands.