gdocs-mcp

Why it exists

Google Docs is where writing goes to be reviewed. Not written — that happens in an editor, in a repo, wherever the work actually lives — but reviewed, by people who are never going to install anything and should not have to. So anything an agent does to help with real writing has to reach into a Google Doc eventually.

Most of the servers that do this treat a document as flat text: pull the whole string down, push a new string back. That holds up until the document has something in it. Tracked changes disappear. Comment threads are orphaned. Edits are addressed by integer index into a structure that shifts underneath you the moment you write to it.

This one is built on the assumption that an agent already knows how to edit: find a unique snippet of text and rewrite it, the way editing a local file works. Indices are never exposed at all. And the part that makes review genuinely possible — pending suggestions read as before → after diffs, accepted or rejected cleanly, including the overlapping clusters that have to resolve together or not at all.

The more useful half is what it admits it cannot do. Google’s API has no way to write in suggestion mode, so every edit the server makes is direct and live, and the tools that write say so rather than letting you find out. Every limitation is documented as the API constraint it is, with the workaround next to it. A tool that hides its edges has not removed the surprise, only moved it somewhere later and more expensive.

It also stops where it should. Wiring chapter files up to document tabs, walking a review, merging the result — that is the job this was built for, and it is deliberately not a feature. The server ships primitives; the agent composes them.