How to Make Your Docs Usable Inside Coding Agents
For Open-source maintainers · Based on Rachel Lee's Agentic Web Publishing Framework
// TL;DR
Open-source maintainers can use Rachel Lee's Agentic Web Publishing Framework to make their documentation and API reference usable inside coding agents like Claude and Copilot. Instead of forcing developers to fetch docs one chunk at a time, you expose search and listing tools over HTTP MCP, serve your full corpus via MCP Resources for context priming, and add Web MCP tools to your HTML pages so in-browser agents can navigate directly. The result: developers get accurate, low-friction access to your library inside the agents they already code in, without you rebuilding the docs site.
Why do open-source docs need agentic publishing?
Developers increasingly write code inside agents — Claude, Copilot, and similar harnesses — rather than tabbing over to your documentation site. Rachel Lee's first principle, 'Meet Them Where They Are,' applies directly: your audience is already working inside agents, so publish your docs into those surfaces instead of waiting for developers to come back to your site. The web's job has always been to reach people wherever they are, and for maintainers, agents are the new 'wherever.'
The alternative — hoping the agent scrapes your docs correctly or guesses at API signatures — produces hallucinated method names and outdated examples. Agentic publishing gives the agent a reliable, structured path to your actual content.
How do I expose my API reference and guides as MCP tools?
Audit your docs navigation and map each action to a tool. For a typical library that means `list_guides`, `list_api_methods`, and `search_docs`, each returning structured JSON. Host these over HTTP transport at a clean endpoint like `/mcp` so a developer can paste one URL into their agent harness settings — no JSON config editing, no command-line arguments. Write each tool a clear description, because the agent reads it to decide when to call the tool, and define an input schema with only the fields truly required.
Keep the tool count focused. Expose the same conceptual surface area as your docs navigation, not every internal function. Over-exposing bloats the agent's tool-selection reasoning.
Should I use MCP tools or MCP Resources for the full corpus?
Use MCP Resources — not tools — for bulk content priming. A common pitfall is injecting your entire documentation corpus into context one tool call at a time, which is an inefficient use of context. Instead, serve the full corpus via MCP Resources so agent harnesses can pre-prime context when a user switches into your library's mode. Note that Resources are currently poorly supported in some harness UIs despite being the correct vehicle — but building against the right abstraction now pays off as support improves.
How do in-browser agents use my docs pages directly?
Add Web MCP registration to your HTML pages so agents operating inside a browser can call your tools without DOM traversal or screenshot guessing. For your JavaScript-driven docs, use the imperative model: `navigator.modelContext.registerTool('navigate_to_section', description, inputSchema, callbackFn)` and `get_example`, reusing the same functions your UI already calls. Always check `if (navigator.modelContext)` before registering so non-agent browsers degrade gracefully. Web MCP is inspired by but not spec-compliant with MCP, so build for the abstraction rather than assuming the two specs converge.
How do I verify it all works?
Test across the client types that matter to you. Confirm your docs site still works normally in a browser. Install your HTTP MCP server in Claude Desktop and confirm `list_guides`, `list_api_methods`, and `search_docs` appear and return correct data. Then use the MCP B browser extension as a debugging harness to confirm your Web MCP tools are registered, visible, and callable on each page.
Start small: ship `search_docs` over HTTP first, then layer in Resources for corpus priming and Web MCP for in-browser agents. Your next step is to audit your docs navigation and list the three or four tools that mirror how developers actually search your reference.
// FREQUENTLY ASKED QUESTIONS
Do I need to rebuild my docs site to make it agent-accessible?
No. This framework wraps your existing content — one backend serves your normal docs site and your MCP tools simultaneously. You expose your existing navigation actions as MCP tools over HTTP and serve your corpus via Resources, without touching the site developers already use in a browser.
Why shouldn't I just let the agent scrape my docs?
Scraping produces hallucinated method names, outdated examples, and unreliable navigation via screenshots or DOM traversal. Exposing MCP tools and Web MCP gives the agent a structured, accurate path to your actual API reference and guides, reducing token cost and improving reliability compared to visual inference.
How do developers connect my MCP server to their agent?
With HTTP transport, developers paste one URL — your `/mcp` endpoint — into their agent harness settings and they're done. There's no JSON config file to edit and no command-line arguments, which is why HTTP is recommended over stdio for any public-facing docs server.