MCP adoption grows 11x — but what are AI agents actually doing with documentation?

1. MCP adoption has grown nearly 11x since July

Since July, the number of organizations connecting to GitBook’s MCP server has grown approximately 10.7x. October’s figures are already 51% higher than September’s, with several days of the month still to go.

Many organizations are also moving beyond the initial connection. In October, the number calling at least one MCP tool was equivalent to around 74% of those connecting during the month. That ratio doesn’t tell us how frequently individual organizations use MCP, but it suggests that a substantial number are putting their connections to work.

Adoption extends well beyond organizations with the largest documentation sites. Only around 3% of organizations connecting to MCP in October belong to our cohort of largest documentation publishers — organizations with at least 15,000 documentation page views in the previous 30 days.

For smaller teams without dedicated documentation resources or established tooling, connecting an AI assistant to their docs could make information easier to retrieve and content easier to update and manage.

Connections alone don’t show how deeply these organizations use MCP. They do suggest that direct AI access to documentation is attracting interest from organizations of very different sizes.

2. ChatGPT and Codex are gaining ground, but Claude still leads

Claude remains the dominant AI client connecting to GitBook through MCP, although ChatGPT and Codex are growing rapidly.

In September, ChatGPT accounted for a relatively small number of MCP connection events. By October 26, those connections had increased approximately 57x. Codex connections increased around 2.5x over the same period.

The starting points matter here. Claude still accounts for approximately 58% of connection events across the ten leading clients, compared with around 16% for Codex and 7% for ChatGPT. Claude also added more connection events between September and October than either OpenAI tool individually.

ChatGPT is catching up from a much smaller base, while Claude remains comfortably ahead.

Other clients, including Cursor and Grok, have also shown increased activity.

Documentation teams can’t control which AI tools their users or colleagues prefer. A developer working in Claude Code, another using Codex, and a support team using ChatGPT may all need access to the same product knowledge. Supporting that variety is easier when compatible tools share a consistent way to access documentation.

MCP provides a common interface for compatible AI tools to interact with external systems. For documentation teams, it reduces the need to treat every AI client as a separate integration.

There are limits to what these figures tell us. We’re measuring connection events, not unique users or organizations, and changes to how clients establish or maintain connections can affect the totals.

ChatGPT’s sudden spike deserves particular attention. It wasn’t preceded by a gradual increase, and external factors — such as changes to ChatGPT’s MCP support or connection behavior — may have contributed. We’ll revisit the figures next month to see whether the growth continues or proves temporary.

3. AI agents read far more documentation than they write

In October, approximately 78% of GitBook MCP tool calls used get_page, the operation that retrieves a documentation page’s content. Page retrieval calls outnumbered calls to create or submit and merge change requests by approximately 28 to 1.

Retrieval is also growing faster. Calls to get_page increased by approximately 52% compared with September, while those selected write-related operations grew by around 11%.

These figures come from GitBook’s organization-level MCP server, which allows connected AI tools to access and modify documentation. They don’t include every way AI agents interact with publicly published documentation, so we can’t assume the same proportions apply across the wider ecosystem. Within the workflows we can measure, retrieving existing knowledge accounts for far more activity than making changes.

Reading and writing aren’t necessarily separate activities, either. An agent tasked with updating a page might retrieve several related pages to understand the context before making a single edit. That could partly explain why retrieval calls outnumber writing operations so significantly. The data tells us which tools agents call, but not whether those calls are part of a larger editing workflow.

GitBook’s built-in Agent activity shows a similar pattern. Between September and October, the share of Agent tool calls dedicated to editing pages fell from approximately 44% to 28%. Calls to retrieve page content increased from around 25% to 33%, while calls to external MCP tools rose from roughly 10% to 16%.

Agents might be gathering more information before making changes, or organizations could be using them for different tasks. We’d need more detailed workflow data to distinguish between those explanations.

For documentation teams, this adds to the work of serving human readers. People still need to understand APIs, troubleshoot problems, and learn how features work, but an AI tool may now search the documentation on their behalf.

An agent could retrieve a page to understand an API before writing code, investigate a technical problem, or gather context before making a change. That information can influence what happens next even if nobody visits the documentation site directly.

Outdated instructions may find their way into the agent’s work. A missing explanation leaves it without context, while poorly structured or hard-to-find information makes retrieving the right content more difficult.

Whether agents are answering questions, writing code, or updating documentation, they need access to accurate information about what’s already there. For teams building AI workflows, improving the documentation those tools rely on may be just as useful as making documentation faster to write.

4. More teams are turning documentation quality findings into fixes

Keeping documentation accurate takes ongoing work. Links break as content moves, product changes make instructions obsolete, and users’ questions expose gaps that weren’t apparent when a page was written. Finding and fixing those problems often depends on someone noticing an issue, reporting it, and making time to investigate.

Our recent research into documentation quality explored how these problems emerge and why reader activity can help teams identify them.

AI tools that rely on the same documentation can encounter those problems too. In October, we saw early evidence that more organizations are acting on documentation quality findings.

The ratio of organizations resolving at least one finding to organizations receiving findings increased from approximately 9% in September to 24% in October. Among our largest documentation publishers, that ratio rose from approximately 33% to 57%.

The number of findings resolved per 100 findings created also increased, from approximately 1.6 in September to 6.6 in October.

These are early adoption figures for recently launched quality-monitoring features. GitBook introduced content-gap findings in August and link-related findings in September. Resolutions can also happen weeks after a finding is created, so monthly figures don’t tell us what proportion of issues eventually get fixed.

That said, the increase suggests that more teams are acting on documentation quality findings as they come up. And over time, these tools could make it easier to incorporate quality checks into regular maintenance workflows.

And that’s ultimately the goal of the quality monitoring features we mentioned above support this work. Content gaps helps teams identify missing or problematic information, while Broken links surfaces issues with links into and out of your docs content. Style guide helps contributors maintain consistent writing standards. Together with GitBook Agent, these tools help teams identify an issue and prepare a fix for human review.

The aim is to reduce the need for someone to find every problem manually. Teams can identify issues as they arise, investigate them, and use AI to help make the necessary changes.

Resolving more findings doesn’t automatically mean documentation quality has improved. We’ll need longer-term data to understand whether these workflows lead to better outcomes for readers and agents. For now, the figures offer an encouraging early sign that organizations are putting quality monitoring to use.

As both people and AI tools rely on documentation, continuously spotting and fixing problems could become one of the most useful parts of maintaining it.

Making existing documentation more useful

October’s findings show rapid growth in MCP adoption and a wider mix of AI clients connecting to GitBook. Those tools retrieve information far more often than they change it. At the same time, more teams are using automated quality monitoring to identify and address documentation problems.

We can’t assume these behaviors are directly connected. Together, though, they give documentation teams a reason to pay closer attention to the knowledge they already maintain: how easily it can be found, whether it’s accurate, and how well it answers the questions people and agents bring to it.

Producing more content won’t necessarily address those needs. AI tools can make knowledge easier to access and use, but they can’t reliably compensate for missing or inaccurate source information.

In future editions of Documentation signals, we’ll track how MCP adoption develops, whether the balance between reading and writing changes, and how organizations respond to documentation quality issues.

About the data

Documentation signals is a monthly analysis of aggregated, anonymized usage data from GitBook. Its findings describe activity across organizations and documentation hosted on GitBook; they don’t represent the documentation industry as a whole.

This edition analyzes activity from July through October 2026, with particular attention to changes between September and October. October figures are provisional and cover activity through October 26.

The analysis includes organization-level MCP connections and tool calls, GitBook Agent activity, and documentation quality findings and resolutions. Metrics describe observed events or monthly unique organizations, depending on the chart. Connection events and tool calls shouldn’t be interpreted as numbers of individual users.

Some metrics were introduced during the reporting period, and others reflect the rollout of new features. Where relevant, we’ve noted these limitations and distinguished observed changes from possible explanations.

To protect customer privacy, we report percentages, relative changes, and aggregated trends rather than raw activity volumes.