MCP server for Google Docs with verified writes — every mutation returns before/after proof.
SaferSkills independently audited verified-googledocs-mcp (MCP Server) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
<!-- mcp-name: io.github.michaelrobertsutton/verified-googledocs-mcp -->
An MCP server for Google Docs whose writes carry proof. Every mutating tool re-reads the affected content from the document after it writes and returns evidence of what actually changed: before/after excerpts, the match count, and the document revision before and after. A tool never reports success for an edit that did not land.
Status: all 14 tools are implemented, covered by an offline unit suite, and exercised against the real Google Docs and Drive APIs — every tool and every error code passes the live acceptance gate. Install with uvx verified-googledocs-mcp. See Status.Driving Google Docs from an agent through a general Workspace MCP server tends to fail in quiet, expensive ways:
findAndReplace meant for one tab silently edits every tab in the document.Each of these has a procedural workaround: tell the agent to scope to a tab, retry with normalized quotes, re-read after every write, never trust a resolve result. Those instructions work until someone forgets one. This server moves the discipline into the protocol, where it is deterministic.
Every mutating tool runs the same pipeline: read the tab, locate the target, apply the edit under a revision precondition, read the tab again, and return evidence built from the second read. The return value is a claim about the document's state after the call, backed by a server-side re-read, not an echo of the API response.
// replace_text(doc_id, tab_id, find="teh", replace="the", expected_matches=1)
{
"applied": true,
"match_count": 1,
"rung": "exact", // which normalization rung matched
"before": "...±200 chars around the edit, pre-write...",
"after": "...the same span, re-read after the write...",
"revision_before": "ALm37BX...",
"revision_after": "ALm37Cy...",
"audit_logged": true
}When something is wrong, the tool fails loud and diagnosed, with a typed error the agent can act on in one round trip rather than guessing:
{
"error_code": "MATCH_COUNT_MISMATCH",
"message": "expected 1 match(es) but found 3 at rung 'exact'",
"diagnostics": { "expected": 1, "actual": 3, "spans": [ /* every location */ ] },
"retryable": false
}tab_id. There is no whole-document replace, so a one-tab edit can never leak into a cover letter or an appendix tab.expected_matches defaults to 1. If the real count differs, the tool makes no edit and returns every match location.writeControl.requiredRevisionId from the pre-read, so a document that changed underneath the operation is rejected by the API rather than edited blind. Section ranges from find_sections are stamped with the revision they were computed at and refuse to apply once stale.audit_logged: false).The guarantee is not one universal payload — it is a per-family invariant. Each family re-reads the document after the write and proves the property that family is responsible for. Every mutating tool also carries revision_before, revision_after, and audit_logged.
| Family | Tools | Proves |
|---|---|---|
| Text edit | replace_text | match_count equals expected_matches; rung names the normalization pass that matched; before/after are ±200-char excerpts of the edited span, the after re-read post-write |
| Markdown range | replace_range_markdown, replace_tab_markdown, append_markdown | structural_match (the written markdown round-trips), input_blocks vs post_blocks counts, and a structural_diff list naming any mismatch |
| Structural | insert_image | inline_object_confirmed — a post-write scan found the inline object at the anchor paragraph |
| Comment state | add_anchored_comment, reply_to_comment, resolve_comment | the re-queried resolved flag, reply_count, content, quoted_text, and author — a resolve that didn't land returns COMMENT_STILL_OPEN, never success |
The read and sync tools (read_document, list_tabs, find_sections, list_open_items, get_comment_thread, diff_tab_vs_file) make no changes and carry no applied/evidence payload.
The five mutating tools (replace_text, replace_range_markdown, replace_tab_markdown, append_markdown, insert_image) accept dry_run=true. No API write is issued; the response carries applied: false, an empty revision_after (no write, so no new revision), audit_logged: false, and — for replace_text — a predicted after excerpt computed by splicing the replacement into the pre-read. Use it to confirm a locate resolves to the right span before committing the edit.
Fourteen focused tools, each described by when to reach for it, replace the slice of a 150-tool Workspace server that document workflows actually use.
| Tool | What it does |
|---|---|
read_document | Read a tab as markdown or as structured positions and style runs |
list_tabs | List tab IDs, titles, and nesting |
find_sections | Find headings and return their ranges, stamped with the document revision |
| Tool | What it does |
|---|---|
replace_text | Find/replace within a tab, with the normalization ladder and match guard |
replace_range_markdown | Replace a section range with markdown |
replace_tab_markdown | Replace a whole tab's content with markdown |
append_markdown | Append markdown to a tab |
insert_image | Insert an image at a quoted anchor or heading |
| Tool | What it does |
|---|---|
list_open_items | Open comments and pending suggested edits in one call |
get_comment_thread | Read a comment's full reply chain |
add_anchored_comment | Add a comment anchored to quoted text |
reply_to_comment | Reply to a comment |
resolve_comment | Resolve a comment, re-query it, and confirm it actually closed |
| Tool | What it does |
|---|---|
diff_tab_vs_file | Diff a tab's markdown against a local file |
Built incrementally; each tool ships with its verification and tests rather than as a stub.
| Area | State |
|---|---|
OAuth (verified-googledocs-mcp auth), token cache | done |
read_document, list_tabs, find_sections | done |
| Verification kernel (locator, error envelope, audit) | done |
replace_text (verified) + enforcement middleware | done |
Comment tools + list_open_items | done |
Markdown write tools + diff_tab_vs_file | done |
| Live acceptance gate (all 14 tools, all 12 error codes) | done — report |
| PyPI packaging + publish workflow | done; first release v0.1.0 |
| MCP registry listing | published with v0.1.0 |
The server talks to Google with your own OAuth credentials, so setup is a one-time Google Cloud step, then registering the server with your MCP client.
~/.config/verified-googledocs-mcp/credentials.json. (Override the location with VERIFIED_GOOGLEDOCS_MCP_CREDENTIALS.)uvx verified-googledocs-mcp authThis opens a browser and completes consent. Because the app is unverified and in Testing, Google shows a "Google hasn't verified this app" screen — click Advanced → Go to verified-googledocs-mcp (unsafe) and continue. This is expected for a personal Desktop client; you are granting access to your own app, running locally as you. It then caches a refreshable token at ~/.config/verified-googledocs-mcp/token.json. Auth runs only here, never inside the server, because MCP clients start the server headless.
uvx verified-googledocs-mcp # downloads + runs in one step
# or: pip install verified-googledocs-mcpThen register the server with your MCP client.
From source. To run from a local clone instead:
git clone https://github.com/michaelrobertsutton/verified-googledocs-mcp
cd verified-googledocs-mcp
uv run verified-googledocs-mcpA project-local .mcp.json is included in the repo. Clone and open the project and Claude Code picks it up automatically — no manual config required:
git clone https://github.com/michaelrobertsutton/verified-googledocs-mcp
cd verified-googledocs-mcp
claude # .mcp.json is loaded automaticallyUse it across all your projects (user scope). Register it once at user scope:
claude mcp add verified-googledocs-mcp --scope user -- uvx verified-googledocs-mcpThis writes to ~/.claude.json and makes the server available in every Claude Code session on this machine. If uvx is not on Claude Code's PATH, use the full path (find it with which uvx).
Most clients use the standard mcpServers config block. Add the following to your client's config file:
{
"mcpServers": {
"verified-googledocs-mcp": {
"command": "uvx",
"args": ["verified-googledocs-mcp"]
}
}
}PATH note for headless clients: Claude Desktop and similar clients launch the server as a subprocess with a minimal PATH that may not include Homebrew or user-local bins. If uvx is not found, use its full path ("command": "/opt/homebrew/bin/uvx"). Find it with which uvx. On Apple Silicon the Homebrew prefix is /opt/homebrew; on Intel Mac it is /usr/local.
Startup-timeout note. The first uvx launch downloads the package and its dependencies, which can exceed a client's MCP startup timeout and surface as a failed connection. Pre-warm the cache once in a terminal by running the auth command (uvx verified-googledocs-mcp auth) — you do this anyway, and it installs the package into the uvx cache so the client's launch is fast.
From source. If you prefer to run from a local clone instead of PyPI:
{
"mcpServers": {
"verified-googledocs-mcp": {
"command": "/opt/homebrew/bin/uv",
"args": ["run", "verified-googledocs-mcp"],
"cwd": "/path/to/verified-googledocs-mcp"
}
}
}Logs / stderr. The server logs to stderr, which MCP clients capture rather than show inline. If a connection or a tool call fails, check the client's MCP logs — for Claude Desktop on macOS, ~/Library/Logs/Claude/mcp*.log. An AUTH_EXPIRED envelope there means the token is missing or expired; re-run the auth command.
The server uses the documents and drive scopes (comments require Drive). The credentials path is overridable with VERIFIED_GOOGLEDOCS_MCP_CREDENTIALS.
This is a single-user, local server. It runs as you, over stdio, launched by your MCP client; there is no network listener, no hosted service, and no shared credentials. It acts entirely with your own Google authority.
documents and drive. The full drive scope is broader than editing alone needs, but the comment and suggestion tools (listing, replying to, and resolving comments on documents you already have) operate through the Drive API on arbitrary existing files, which the narrower drive.file scope cannot reach. drive is the minimum that covers the full tool set; if you don't need the comment tools, a fork could drop to a narrower scope.~/.config/verified-googledocs-mcp/credentials.json; the cached token (including the refresh token) is written to ~/.config/verified-googledocs-mcp/token.json with owner-only permissions (0600, under a 0700 directory). Treat both as secrets: a leaked refresh token grants your full drive+documents access until you revoke it in your Google Account's security settings. Neither file is ever committed (both are gitignored).~/.local/state/verified-googledocs-mcp/audit.jsonl (also 0600). Each line records the timestamp, document ID, tab ID, tool name, and the evidence payload — which includes before/after content excerpts. To log the metadata without the excerpts, set the environment variable VERIFIED_GOOGLEDOCS_MCP_AUDIT_EXCERPTS to a falsey value (0, false, no, or off); the before/after fields are then replaced with "[redacted; N chars]" and every other field is kept. Override the log location with XDG_STATE_HOME.Failures return a typed envelope (error_code, message, diagnostics, retryable):
| Code | Meaning |
|---|---|
ZERO_MATCH | Target not found after the full normalization ladder; diagnostics include the nearest near-miss |
MATCH_COUNT_MISMATCH | Found a different count than expected_matches; no edit made; all locations returned |
REVISION_CONFLICT | Document changed between read and write; retry after re-reading |
STALE_RANGE | A find_sections range was used after the document moved on; re-run find_sections |
TAB_NOT_FOUND | Unknown tab_id; available tabs listed |
STRUCTURAL_BOUNDARY | Match crosses a paragraph or table-cell boundary |
UNSUPPORTED_MARKDOWN | Markdown outside the supported subset; the offending construct is named |
QUOTE_NOT_FOUND | Comment anchor text not found; nearest candidates returned |
COMMENT_STILL_OPEN | A resolve was requested but re-query shows the comment open |
INVALID_INPUT | Empty or contradictory arguments |
IMAGE_SOURCE_UNSUPPORTED | Image source is a local path; a fetchable URL is required |
AUTH_EXPIRED | No valid token; run verified-googledocs-mcp auth |
uv run --extra dev pytest # unit tests (offline) + coverage
uv run --extra dev ruff check src tests # lint
uv run --extra dev ruff format src tests # format
uv run --extra dev mypy src # type checkUnit tests run against synthetic Docs API fixtures and an in-memory MCP client, so the full suite is offline (it never runs the live tests). The live acceptance suite (under tests/live/) runs with pytest --run-live against a real scratch document and needs OAuth credentials; it is the pre-release gate and never runs in CI — see docs/acceptance-report.md.
See docs/architecture.md for the module map and the verification pipeline, PRD.md for the full specification, docs/cutover.md to migrate off a general Workspace MCP server, and CONTRIBUTING.md to build on it.
MIT, © 2026 Michael Sutton.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.