Connect GitBook to ChatGPT: Manage Content and Team Collaboration

If you need to connect GitBook to ChatGPT to automate documentation updates, retrieve architectural decisions, or manage team wikis, you need a Model Context Protocol (MCP) server. This server acts as a translation layer between ChatGPT's tool calling capabilities and GitBook's REST API. You can either build and maintain this infrastructure yourself - writing schemas, handling cursors, and managing auth states - or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses Claude, check out our guide on connecting GitBook to Claude or explore our broader architectural overview on connecting GitBook to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling enterprise knowledge base is an engineering challenge. You have to map highly nested JSON schemas to MCP tool definitions, deal with strict rate limits, and enforce boundaries so an AI agent does not accidentally overwrite production documentation. Every time the upstream API changes, you have to update your server code, redeploy, and test the integration. This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for GitBook, connect it natively to ChatGPT, and execute complex documentation workflows using natural language.

The Engineering Reality of the GitBook API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools using the JSON-RPC 2.0 protocol, implementing it against vendor APIs is painful. If you decide to build a custom MCP server for GitBook, you own the entire API lifecycle.

Here are the specific integration challenges that break standard CRUD assumptions when working with GitBook:

The Deeply Nested Content Hierarchy

GitBook does not use a flat file structure. Content is buried behind a strict hierarchy of Organizations, Sites, Collections, Spaces, and Pages. An LLM cannot simply ask the API for "the deployment guide." To read a page, the AI agent must first know the space_id. To know the space_id, it often needs to traverse from the organization_id. If your MCP server does not expose these discovery endpoints clearly with injected required parameters, the LLM will hallucinate IDs and fail to retrieve any content.

Mutating Content via Change Requests

Writing to GitBook is not as simple as sending a PUT /pages/:id request. In enterprise environments, directly modifying live spaces is dangerous. GitBook encourages the use of Change Requests - essentially pull requests for documentation. To update a document programmatically, your MCP server must expose endpoints to create a change request, optionally create a review, and track its status. Translating an LLM's desire to "update the API key rotation policy" into a multi-step change request workflow requires precise schema definitions.

Document AST and Block Formats

GitBook's internal content representation often relies on a custom block format or specific markdown variants. When an LLM extracts page content, it receives structured JSON representing the document's AST (Abstract Syntax Tree) or markdown. If you do not explicitly instruct the LLM on how to parse and reconstruct this format, the context window will fill with useless metadata, and the AI will fail to extract the actual knowledge.

Handling 429 Rate Limits

GitBook enforces strict rate limits to protect its infrastructure. If an AI agent enters a loop attempting to scrape thousands of pages across dozens of spaces, the API will reject the requests with an HTTP 429 Too Many Requests status.

It is critical to understand how Truto handles this: Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API like GitBook returns an HTTP 429, Truto passes that error directly to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller - in this case, your AI application or the framework wrapping the LLM - is entirely responsible for detecting the 429 and executing exponential backoff or retry logic.

How to Create the GitBook MCP Server

Instead of writing and hosting the JSON-RPC server yourself, you can generate one dynamically using Truto. When you connect a GitBook account to a Truto tenant, Truto derives tool definitions directly from the integration's documented endpoints.

There are two ways to generate an MCP server in Truto: via the UI or via the API.

Method 1: Creating via the Truto UI

For ad-hoc agent testing or internal administrative workflows, the dashboard is the fastest path:

1. Log into your Truto dashboard and navigate to the integrated account page for your active GitBook connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Define a human-readable name for the server.
5. Select your desired configuration. You can filter the available tools by HTTP method (e.g., allowing only read operations) or by tag.
6. Click Save, and immediately copy the generated MCP server URL. This URL contains a cryptographically hashed token that authenticates the server - do not expose it publicly.

Method 2: Creating via the API

If you are building an AI product and need to provision MCP servers for your end-users dynamically, you should use the Truto API.

The API validates that the GitBook integration has documented tools available, generates a secure token, stores it in distributed KV storage for low-latency lookups, and returns a ready-to-use URL.

Execute a POST request to /integrated-account/:id/mcp:

curl -X POST https://api.truto.one/integrated-account/YOUR_INTEGRATED_ACCOUNT_ID/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "GitBook Documentation Agent",
    "config": {
      "methods": ["read", "write"]
    }
  }'

The API will return a JSON payload containing the server details:

{
  "id": "mcp_abc123xyz",
  "name": "GitBook Documentation Agent",
  "config": {
    "methods": ["read", "write"]
  },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/t_5f8a9b2c1d4e..."
}

That url is the only piece of infrastructure you need to connect ChatGPT to GitBook.

Connecting the MCP Server to ChatGPT

Once you have your generated Truto MCP URL, you must register it with ChatGPT so the LLM is aware of the tools. You can do this natively through the ChatGPT interface, or via a standard configuration file if you are using an API-driven agent framework.

Method A: Via the ChatGPT UI

OpenAI natively supports connecting remote MCP servers in ChatGPT desktop and web clients for premium users.

1. Copy the Truto MCP server URL generated in the previous step.
2. In ChatGPT, navigate to Settings -> Apps -> Advanced settings.
3. Toggle the Developer mode switch to enable MCP support.
4. Under the MCP servers or Custom connectors section, click to add a new server.
5. Provide a name (e.g., "GitBook Knowledge Base").
6. Paste the Truto MCP URL into the Server URL field.
7. Save the configuration.

ChatGPT will immediately ping the endpoint via the initialize JSON-RPC method, retrieve the list of GitBook tools, and make them available in your chat sessions.

Method B: Via Manual Config File (SSE Transport)

If you are running an AI agent framework (like LangChain, LangGraph, or an external desktop client that relies on local config files), you must wrap the remote HTTP endpoint in a Server-Sent Events (SSE) client. The standard @modelcontextprotocol/server-sse package acts as a local bridge that translates standard local execution into remote HTTP calls.

Create or update your mcp_config.json file:

{
  "mcpServers": {
    "gitbook-truto": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/t_5f8a9b2c1d4e..."
      ]
    }
  }
}

When your agent boots, it will execute the npx command, establish the SSE connection to Truto, and pull down the GitBook tool schemas.

Security and Access Control

Giving an LLM direct access to your corporate wiki introduces operational risk. If an agent hallucinates a tool call, it could delete spaces or alter critical compliance documentation. Truto provides four distinct configuration layers to lock down the MCP server:

• Method Filtering (methods): Restrict the server to safe operations. Passing ["read"] ensures the LLM can execute get and list methods, but hard-blocks create, update, and delete operations at the proxy level.
• Tag Filtering (tags): Scope access to specific functional areas. If your integration defines resource tags, you can restrict the MCP server to only expose tools tagged with ["content"], completely hiding administrative tools related to users or billing.
• Secondary Authentication (require_api_token_auth): By default, possessing the MCP token URL is sufficient to execute tools. Setting this flag to true forces the client to also provide a valid Truto API token in the Authorization header, adding a strict identity check before any tool executes.
• Time-to-Live (expires_at): Provide temporary access by passing an ISO datetime string during creation. Once the timestamp is reached, cloud infrastructure automatically purges the token from KV storage, immediately revoking the LLM's access.

GitBook Hero Tools for ChatGPT

The Truto GitBook integration exposes dozens of endpoints as tools. Instead of overwhelming the LLM with generic CRUD operations, you should guide the model to use the highest-leverage workflows. Here are the core "hero tools" that unlock GitBook for ChatGPT.

list_all_git_book_spaces

Spaces are the fundamental containers for documentation in GitBook. Before an LLM can read pages or propose edits, it must discover the available spaces associated with an organization.

Contextual usage: Use this tool to map out the documentation architecture. The response will provide the space_id values required by downstream tools.

"I need to find the documentation for our new microservices architecture. Please list all spaces in our GitBook organization, identify the one related to engineering or backend services, and return its ID."

get_single_git_book_space_content_by_id

Once the LLM identifies a space, it needs to understand the table of contents. This tool retrieves the content structure for a specified space, revealing how pages and groups are organized.

Contextual usage: This is critical for context gathering. An LLM should call this tool to find specific page IDs before attempting to retrieve raw text.

"Using the engineering space ID you just found, get the content structure of that space. Tell me the titles of all the top-level pages, and find the specific page ID for the 'Authentication Service' documentation."

list_all_git_book_pages

This tool returns an array of page objects from a specific space. It differs from retrieving the raw space content by providing deeper metadata about the pages themselves.

Contextual usage: Best used when the agent needs to iterate over multiple pages to compile a report or audit documentation statuses.

"Fetch all the pages inside the 'Q3 Product Launch' space. Identify any pages that are marked as draft or have empty descriptions, and list their titles."

get_single_git_book_page_by_id

This is the core data extraction tool. It retrieves the actual content object for a specified page within a space.

Contextual usage: The LLM must pass both the space_id and the id (page ID). Instruct the LLM to carefully parse the returned markdown or document AST format to extract the human-readable text.

"Retrieve the content for the 'Authentication Service' page using its ID. Read the technical specifications and summarize the exact JWT validation steps our system requires. Output the summary in a bulleted list."

create_a_git_book_change_request

To safely mutate documentation, the LLM should generate change requests rather than overwriting live pages. This tool opens a new change request within a space.

Contextual usage: The LLM should supply a descriptive subject and the required space_id. Once created, the LLM can use subsequent tools to add page updates to this specific change request.

"We are deprecating the v1 API. Please create a new change request in the Developer Docs space titled 'Deprecate v1 API Endpoints'. Return the change request ID so we can start adding documentation updates to it."

list_all_git_book_organization_members

GitBook is also a collaboration platform. This tool lists all members of an organization, returning their roles and profile data.

Contextual usage: Useful for IT administration workflows, auditing access, or assigning reviewers to change requests.

"List all the members in our GitBook organization. I need to audit our access list - please identify anyone who has 'admin' privileges and format their names and emails into a Markdown table."

To view the complete inventory of available GitBook tools, exact JSON schemas, and query parameter requirements, review the GitBook integration page.

Workflows in Action

Connecting GitBook to ChatGPT moves your team beyond simple keyword searches. By chaining MCP tools together, AI agents can execute complex, multi-step operations that traditionally required significant manual effort.

Workflow 1: Developer Onboarding Knowledge Extraction

When a new engineer joins a team, they spend days hunting through nested wiki pages to understand system architecture. You can instruct ChatGPT to autonomously navigate the GitBook hierarchy and compile a comprehensive onboarding brief.

"I am a new backend engineer. Please find our 'Platform Architecture' GitBook space, read the table of contents to find the pages on 'Database Migrations' and 'Event Streaming', extract the raw content from both pages, and synthesize a single, concise onboarding guide summarizing how data flows through our system."

Execution Step-by-Step:

1. list_all_git_book_spaces: The agent fetches all spaces to locate the space_id for "Platform Architecture".
2. get_single_git_book_space_content_by_id: The agent reads the structure of the space to extract the page IDs for "Database Migrations" and "Event Streaming".
3. get_single_git_book_page_by_id: The agent calls this tool twice, once for each page ID, to retrieve the raw document content.
4. Synthesis: ChatGPT parses the JSON responses, normalizes the formatting, and outputs a clean, unified summary directly in the chat window.

Workflow 2: Automated Documentation Audits and Change Requests

Stale documentation is a massive liability. You can deploy ChatGPT to audit existing pages and automatically draft change requests to update outdated terminology.

"We recently rebranded our core feature from 'AutoSync' to 'LiveSync'. Search the 'User Guide' space for all pages containing the word 'AutoSync'. For any page that needs updating, create a single change request titled 'Rebrand: Update AutoSync to LiveSync', and outline the specific pages that need to be modified in the change request description."

Execution Step-by-Step:

1. list_all_git_book_spaces: The agent finds the space_id for "User Guide".
2. list_all_git_book_pages: The agent retrieves the list of pages within the space.
3. get_single_git_book_page_by_id: The agent iterates through the pages, reading their content to detect the deprecated "AutoSync" string.
4. create_a_git_book_change_request: The agent provisions a new change request in the target space, detailing the necessary text replacements required for the rebranding effort. A human documentation manager can then review and merge the request in the GitBook UI.

Scaling Documentation Workflows with MCP

Exposing your internal knowledge base to an LLM transforms documentation from static text into an interactive, queryable system. But building the infrastructure to support tool calling, handle pagination cursors, and manage complex hierarchical API relationships drains engineering velocity.

By leveraging a dynamic MCP server architecture, you remove the burden of schema maintenance and auth management. Truto abstracts the GitBook REST API into a set of highly reliable, LLM-ready tools, ensuring your agents have secure, context-rich access to your team's most valuable knowledge.