MCP write support — allow agents to create/edit GitBook pages via MCP/API (currently only read is supported)

[aldibit]

GitBook recently shipped a read-only MCP server (see #990) that exposes documentation to AI assistants. But there's no way for external agents (Claude, Cursor, Copilot, custom scripts, etc.) to write back to GitBook via MCP or the API.
I'd like to request writable MCP tools and/or API endpoints that allow agents to:

• Create new pages or sections
• Edit existing page content
• Open a Change Request with proposed edits (rather than writing directly to main, keeping the human-in-the-loop review flow)
• Optionally: merge or close Change Requests

What's the desired outcome?

Teams should be able to hook AI agents like Claude into their documentation workflows (e.g., an agent that reads a GitHub issue or release note and automatically drafts a GitBook page update as a Change Request for a human to review and merge). The Change Request model is a perfect fit here imo: agents propose, humans approve.

This is complementary to the built-in GitBook Agent. It would allow external agents and custom workflows to participate in the same documentation lifecycle via open APIs/MCP tools, not just GitBook's own AI.

Without write access, the MCP server is limited to read/Q&A use cases and can't participate in the authoring loop, which would be really helpful for automatable processes, like release notes drafting.

[addisonschultz]

Hi @aldibit - we’re looking into ways we can make this experience better! For now, we do have a skill.md file your agent can follow to help you write docs in GitBook (and use Git Sync too)

https://gitbook.com/docs/creating-content/ai-coding-assistants-and-skillmd

[bombino]

More importantly, there's no way via MCP to read internal book pages, only published pages, as best as I can tell. This is by far our #1 feature request.

The SKILL.md approach only works if employees have access via GitHub, which, for us, is complicated due to the number of Spaces/Books, git repositories, and number of people who would need to be on GitHub (which we don't normally use).