Documentation has a maintenance problem. You write a guide, publish it, and within three months it’s outdated. The API changed. The config format was refactored. A dependency was replaced. The screenshots show a UI that no longer exists.

The solution isn’t “write better docs” or “build a docs culture.” Teams have been trying that for decades. The solution is to make documentation aware of the code it describes — so when the code changes, the docs know about it.

This is what AI-native documentation means. Not “AI writes your docs” (that produces generic, soulless content). Instead: AI monitors your codebase, detects when documentation drifts from reality, and either flags it for a human or proposes specific updates. The human stays in the loop for judgment; the machine handles the surveillance.

The Staleness Problem, Quantified

Audit the documentation of any active software project and you’ll find a large share of pages carrying at least one factual inconsistency with the current codebase. The most common problems:

Outdated API signatures — parameters added or removed but docs not updated
Wrong configuration examples — default values changed, old format still documented
Dead links — pages restructured, internal references not updated
Missing features — new capabilities added with no documentation at all

Manual review catches these slowly, if at all. A team of 20 engineers might do a “docs audit” once a quarter, spending a week fixing what they find. By the time the audit is done, new drift has already started.

What AI-Native Actually Means

An AI-native documentation platform has three properties:

1. Machine-readable content. The documentation is stored in a format that AI tools can read, query, and modify programmatically. Markdown in a git repo qualifies. Proprietary rich-text in a SaaS database does not.

2. Code-to-docs linkage. The platform knows (or can discover) which documentation pages describe which parts of the codebase. When auth.go changes, the platform can identify that docs/authentication.md might need updating.

3. Structured tool access. AI agents can interact with the documentation through a defined protocol — not by scraping HTML or reverse-engineering APIs, but through explicit, documented tools.

DocPlatform ships the first and third today — markdown synced to git, plus a built-in MCP server. The second, code-to-docs linkage, is something you build on top with conventions: when docs and code live in connected repositories, an AI agent with access to both can make the connection itself.

MCP: The Protocol

MCP is an open standard developed by Anthropic for connecting AI models to external tools and data sources. Instead of each AI tool building custom integrations with every platform, MCP defines a standard interface: tools (actions the AI can take), resources (data the AI can read), and prompts (templates for common workflows).

DocPlatform ships with a built-in MCP server — no plugins, no separate service. When you enable it, any MCP-compatible AI client can interact with your documentation through 26 purpose-built tools.

The 26 Tools

Here’s a selection of what DocPlatform’s MCP server exposes — the full 26-tool reference lives on the MCP page. Every tool is namespaced docplatform_* so it never collides with other MCP servers in your client.

Read Operations

docplatform_search — Full-text search across the workspace, with fuzzy matching and relevance-ranked results. An AI agent uses this to find the page that describes a specific feature before checking if it’s still accurate.
docplatform_read_page — Retrieve the full content of a specific page by path: markdown content plus metadata.
docplatform_get_context — The RAG workhorse: returns a page together with its parent, siblings, and the targets of its wikilinks in one call, so the agent gets surrounding context without five round-trips.
docplatform_list_pages / docplatform_get_tree — Enumerate a workspace’s pages and its navigation tree. Useful for AI agents doing bulk audits.

Write Operations

docplatform_write_page — Write a page: creates it if it doesn’t exist, updates it if it does. The page is indexed for search and, with git sync configured, committed to git.
docplatform_update_page — Modify an existing page’s content (fails rather than creates — for when the page must already exist).
docplatform_move_page — Relocate a page to a new path in the tree.
docplatform_delete_page — Remove a page.

Analysis Operations

docplatform_validate_links — Verify internal links and wikilinks. Returns broken targets with their source pages. An AI agent can run this after a restructuring to catch dead references.
docplatform_quality_scan — Scan content for quality issues — the raw material for an agent-generated audit report.

Collaboration Operations

docplatform_get_activity — The recent-activity feed: who changed what, and when. The starting point for staleness analysis.
docplatform_list_comments / docplatform_add_comment — Read and join page discussions, so an agent can flag a finding directly on the page it concerns.

Practical Workflows

These tools compose into real workflows. Here’s what they look like in practice.

Stale Docs Detection

A scheduled agent run (a cron job driving an MCP-connected assistant):

1. Agent calls docplatform_get_tree to enumerate all documentation pages
2. Calls docplatform_get_activity to see what changed recently — pages
   with no activity while their subject area kept moving are candidates
3. For each candidate, calls docplatform_read_page and compares the
   content against the current code (the agent has repo access too)
4. Findings are flagged with docplatform_add_comment on the affected
   page — a human reviews and decides

This turns documentation maintenance from a quarterly fire drill into a continuous process.

PR-Triggered Doc Updates

When a pull request changes a public API:

1. CI pipeline extracts the diff
2. AI agent calls docplatform_search to find pages referencing the changed API
3. Agent reads each match with docplatform_read_page and drafts the update
4. With git sync configured, the agent's docplatform_write_page edit
   becomes a commit — reviewable in the same PR cycle as the code change

No more “file a follow-up ticket to update the docs.” The docs update is part of the same workflow.

New Feature Documentation

When a feature is merged without documentation (it happens):

1. Agent detects new exported functions/endpoints with no matching doc page
   (docplatform_search comes back empty for the new names)
2. Agent calls docplatform_write_page with a scaffold: function signature,
   parameter descriptions, a placeholder example
3. A human flesh-out pass follows — the draft is tracked in page history
   and, via git sync, reviewable as a commit

The human still writes the narrative. But the skeleton — the accurate function signatures, the parameter types, the return values — comes directly from the code. No copy-paste errors, no forgetting to update when the signature changes.

What This Is NOT

Let’s be clear about the limits:

This is not “AI writes your docs.” AI-generated documentation that’s never reviewed by a human is worse than no documentation. It’s confidently wrong, generically worded, and teaches people to distrust your docs. The MCP tools create drafts and suggestions — humans review and approve.

This is not a replacement for technical writers. Good documentation requires judgment: what to explain, what to skip, what order to present concepts in, how to write an example that actually helps. AI doesn’t have that judgment. It has pattern matching.

This is not magic. Staleness detection works because documentation pages and code files can be linked through path conventions and repository structure. If your docs and code have no relationship structure, the agent can’t infer one.

What it IS: a surveillance system for documentation quality. It watches, flags, suggests. Humans decide.

Why This Matters Now

Three things converged to make this possible:

MCP standardization. Before MCP, every AI tool needed custom integrations. Now there’s a single protocol. Claude, Cursor, VS Code with Copilot — they all speak MCP. Build one integration, work everywhere.

AI models that can reason about code. Current models can read a code diff and understand what changed semantically — not just syntactically. “This function now accepts an optional timeout parameter” is something a model can reliably extract from a diff.

Documentation platforms that store content as code. Markdown in git repos means AI agents can read and write documentation using the same tools they use for code. No proprietary APIs, no screen scraping.

DocPlatform sits at the intersection of all three. Content in git (machine-readable), MCP server built in (structured tool access), and code-aware tooling (linkage between docs and codebase).

Getting Started

The MCP server is included in every DocPlatform installation. Create an API key (Workspace Settings → API Keys), then point your AI client at the docplatform binary. In Claude Desktop, add to claude_desktop_config.json:

{
  "mcpServers": {
    "docplatform": {
      "command": "docplatform",
      "args": ["mcp", "--workspace", "my-docs", "--api-key", "dp_live_abc123"]
    }
  }
}

For remote setups there is also a Streamable HTTP transport (docplatform mcp-server, serving /mcp on port 8081 by default). For the full setup guide, including authentication and workspace scoping, see the MCP documentation.

If you want to see how the MCP tools work in practice, our earlier post on using MCP with documentation walks through specific examples.

The future of documentation isn’t AI replacing writers. It’s AI keeping the lights on — catching staleness, flagging drift, maintaining links — so writers can focus on the work that actually requires human judgment.

Install DocPlatform and connect your first AI agent to your docs.

The Future of Docs Is AI-Native