MCP Tools Handle Everything — Except Your User Docs

Last week I watched a developer on DEV Community describe how he built a complete invoice management platform in a single day using Claude Code and MCP servers. Database setup, email integration, deployment — all handled from the terminal without switching tools. The whole thread was developers nodding along, sharing their own stories of shipping MVPs in hours instead of weeks.

Nobody mentioned documentation.

Not API docs — those get auto-generated from your OpenAPI spec. Not code comments — your IDE copilot handles those. I mean the actual help pages your users land on when they click “Help” or Google “how do I do X in your app.” The pages that determine whether someone sticks around after signup or bounces.

The Orchestration Gap

MCP has changed what it means to build software. Your .claude/mcp.json might look something like this:

{
  "mcpServers": {
    "postgres": { "command": "npx", "args": ["@anthropic/mcp-postgres"] },
    "github": { "command": "npx", "args": ["@anthropic/mcp-github"] },
    "sentry": { "command": "npx", "args": ["@anthropic/mcp-sentry"] },
    "stripe": { "command": "npx", "args": ["@anthropic/mcp-stripe"] }
  }
}

From one terminal, your AI agent queries the database, opens a PR, checks error logs, and verifies payment webhooks. The 2026 workflow isn’t “AI writes code” — it’s “AI runs work.” You’re orchestrating, not typing.

But open your project’s /docs folder. If it exists at all, it’s probably a README that hasn’t been updated since your last funding round. Your users are navigating your app with a help center that’s three features behind, or worse, they’re filing support tickets for things that should be self-service.

Why User Docs Always Lose

The reason is obvious once you think about it: every other part of the development pipeline has been automated or AI-assisted. CI/CD runs on push. Tests run on commit. Deploys happen on merge. Even your changelog can be generated from conventional commits.

User-facing documentation has none of this. It requires someone to:

1. Open your app and walk through each feature
2. Take screenshots of every relevant screen
3. Write step-by-step instructions in plain language
4. Organize those instructions into a navigable site
5. Keep all of the above updated when the UI changes

That’s a full day of work for a small app. For a growing product with weekly releases, it’s a part-time job that nobody signed up for. So it doesn’t get done. Or it gets done once and rots.

Indie developers and small teams feel this the most. You’re shipping fast because MCP and AI agents removed the friction from building. But the friction of documenting what you built is exactly where it was five years ago. Your development velocity outpaced your documentation velocity, and the gap is widening with every feature you ship.

The 40% Problem

Here’s something that should change how you think about docs: AI agents now account for over 40% of documentation traffic, according to Document360’s 2026 trends report. Your docs aren’t only for humans anymore. They’re the interface between your product and every AI assistant your users talk to.

When someone asks ChatGPT “how do I export data from [your app]” and the answer is “I couldn’t find documentation for that feature,” you’ve lost a user without ever knowing it. Your help docs are becoming the API that AI agents call on behalf of your users. Except unlike your actual API, they’re not versioned, not structured, and probably not accurate.

What the Fix Looks Like

The same pattern that made MCP useful for development works for documentation: give AI tools access to your running application and let them do the tedious work.

This is the approach tools like KodaDocs take — it runs as an MCP server inside Claude Code, points a headless browser at your running app, captures screenshots, and generates a complete help site. Your MCP config picks up one more entry:

{
  "kodadocs": {
    "command": "uvx",
    "args": ["kodadocs"]
  }
}

Then you tell Claude to generate docs for your app running on localhost:3000. It crawls routes, screenshots each page, and produces a VitePress site with annotated screenshots and step-by-step guides. The output is a static site you can deploy anywhere — Cloudflare Pages, Vercel, Netlify, GitHub Pages.

The important part isn’t the specific tool. It’s the pattern: treat documentation the same way you treat every other part of your pipeline. Automate the mechanical parts (screenshots, route discovery, site generation) and spend your time on the parts that need a human brain (architecture decisions, onboarding flow, edge case explanations).

Closing the Loop

If you’re already running MCP servers for your database, your GitHub repos, and your error tracking, adding documentation generation to that workflow is a ten-minute setup. The hard part was always the screenshot-taking, the page-building, the keeping-things-current. That’s exactly the kind of repetitive, structured work that AI agents are good at.

Your users are already asking AI assistants about your product. Whether those assistants find helpful, accurate documentation or a 404 is up to you.

The code is at github.com/kodadocs/kodadocs if you want to try it. Or check out kodadocs.com for the hosted version. Either way, stop letting docs be the one thing in your workflow that’s still stuck in 2020.