Claude Code can write campaign copy directly to a shared Google Doc through an MCP server and pull client comments back out. Your client reviews in the doc they already use, while your working copy stays in your repo. Setup takes a Google Cloud project and an OAuth client. You then run one claude mcp add command.
Why sync instead of export
Export-and-email review creates competing versions of the same copy. Once everyone involved has a separate file, nobody can be sure which one is authoritative.
If you're a Head of Growth coordinating paid media and outbound, you've felt the downstream effects. The same coordination problem reaches creative work. The client approves v3 of the landing page copy over email, but the doc your paid media contractor pulled from still says v2. Every round of revision that crosses tool boundaries adds another chance for misalignment, and the coordination tax compounds across channels. With a two-way sync, Claude Code drafts the copy, pushes it to a shared Google Doc, and reads client comments back into your local files.
Choose your Google Docs MCP connector
Four connector paths exist, and their auth flows differ. Don't mix steps between them.
- Google's official Workspace MCP server. This first-party option has a Docs endpoint at https://docsmcp.googleapis.com/mcp/v1. It is still in Developer Preview and requires a Claude Enterprise, Pro, Max, or Team plan. Setup routes through the claude.ai GUI (Settings → Connectors), and no claude mcp add CLI command is documented for it.
- taylorwilsdon/google_workspace_mcp. This community server uses the MIT license, covers Google Docs and other Workspace services, and has a documented CLI setup for Claude Code.
- a-bonus/google-docs-mcp. Another actively maintained community option for Docs, Sheets, Drive, Gmail, and Calendar. It uses an npx-based stdio setup.
- Composio's hosted Google Docs toolkit. Composio manages OAuth, so you don't need a Google Cloud project to start. The tradeoff is that tool calls route through Composio's infrastructure.
For an agency or growth team handling client documents, the community server is the pragmatic pick. It's self-hosted, and the CLI setup is documented.
Once you've chosen a connector, the setup follows five steps:
- Create a Google Cloud project and allow access to the Workspace APIs the server needs, including Docs, Drive, and any other services you'll use. The server's README walks through this.
- Create an OAuth client and configure the consent screen. You supply your own credentials. Request the narrowest scopes you can. Google classifies https://www.googleapis.com/auth/drive.file as non-sensitive because it only touches files shared with the app. By contrast, https://www.googleapis.com/auth/documents can edit all docs and is classified as Sensitive. Over-scoped tokens are a top MCP risk, so inspect what any server requests before granting it.
- Start the server locally, then register it with Claude Code:
claude mcp add --transport http workspace-mcp http://localhost:8000/mcp
- Authenticate. Run /mcp inside a Claude Code session and follow the browser sign-in prompts. On Claude Code v2.1.186+, claude mcp login handles this from the command line, with a --no-browser flag for headless machines.
- Verify with claude mcp list. A ✔ means connected; a ! means it still needs auth.
Once the server shows as connected, Claude Code can use its Workspace tools in the current environment.
To share the setup with your team, add it to a .mcp.json file at the project root and check it into version control:
{
"mcpServers": {
"workspace-mcp": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}
Before committing that file, audit every listed server. Claude Code prompts everyone who clones the repo to approve them. Also check your OAuth app status. If it remains in "Testing" mode in Google Cloud, refresh tokens expire every 7 days and cause invalid_grant errors. Publish the app or plan on weekly re-authentication.
The MCP workflow in practice
Claude Code drafts campaign copy as Markdown in your local knowledge base. You tell it to push the draft to the shared doc: create_doc starts a new one, while modify_doc_text inserts or replaces text in an existing one. The client comments and edits in Google Docs as usual. For the next revision, Claude pulls the doc with get_doc_as_markdown, which returns content with inline comment annotations, or lists feedback with list_document_comments. It edits locally, you review the diff, and it pushes the revision back up.
Use direct in-place API edits for small changes, such as appending a paragraph or updating one line. For substantial revisions, use pull-edit-push: export to Markdown, edit locally, and push the full draft back. Pushed content arrives as text, so headers and bold may need a manual formatting pass. Local editing also lets you inspect the changes before they reach a client-facing document.
In practice, the cadence depends on how your team reviews. A typical loop looks like this: push a draft Monday, pull comments Wednesday, revise and push again by Thursday. For fast-moving campaigns where ad copy, outbound sequences, and landing pages need to stay aligned, a tighter daily pull keeps everyone working from the same version.
Know these limitations before deployment:
- API-created comments render unanchored. Comments Claude posts appear in the doc's comment list but aren't visibly attached to specific text in the Docs UI. The Google Drive API causes this limitation across every connector.
- Comment author details are incomplete. The Drive API returns a display name but not the author's email, so you must map feedback to specific client stakeholders yourself.
- Client suggestions are readable; Claude's suggestions mostly aren't writable. Reading tracked changes works via suggestionsViewMode=SUGGESTIONS_INLINE. Writing suggestions from Claude back into the doc is still Developer Preview with 8 unsupported request types. As a workaround, give the authenticated account Commenter/Suggester access instead of Editor. That way its changes land as reviewable suggestions rather than silent direct edits.
- Docs Claude reads are an injection surface. Hidden instructions in white text or comment fields can try to redirect Claude's actions through indirect prompt injection. Claude Code requires approval for network-request tools by default. Don't run --dangerously-skip-permissions outside a sandbox.
Triggering the pull is still manual: you open a session and ask. Claude Code's scheduled tasks can automate the check, though recurring tasks expire after 7 days. Deciding which client comments are actionable edits versus stray musings remains a human call.
FAQs
What is an MCP server? MCP (Model Context Protocol) is an open standard that lets AI assistants connect to external tools through a consistent interface. An MCP server is the bridge program: it exposes tools Claude can call, such as reading a doc or posting a comment.
Can Claude Code write directly to a Google Doc? Yes, with the right connector. Anthropic's built-in Google Drive connector is read-only for document body content, so it won't work for this. The community servers (taylorwilsdon, a-bonus), Composio, and Google's official Preview server all support direct writes. Expect some formatting cleanup after large pushes, and prefer pull-edit-push for full-draft revisions.
How do client edits in a synced Google Doc get reflected back into the system? Claude Code calls the MCP server to fetch the doc and its comments, then writes them into local Markdown files. Comment listings include the comment text and the quoted passage it refers to, along with whether the comment is resolved. Tracked-change suggestions can be read back inline through the Docs API. You review the pulled feedback, Claude applies the edits locally, and the revision pushes back to the same doc.
Coordinate your campaign workflows with Understory
This setup solves one piece of a larger coordination problem. A CTA may say one thing in the ad and another on the landing page, while an offer expires Tuesday in email and Thursday on paid social. A synced doc keeps your LinkedIn ads using the same approved language as your outbound sequences, with landing pages aligned to both.
Understory handles that full coordination across strategic paid media on LinkedIn and Google, Clay-powered outbound sequences, and professional creative aligned to both channels. RemoFirst replaced their entire internal SDR team by consolidating paid and outbound execution under one allbound partnership. Instead of managing four vendors who never talk to each other, their growth team focuses on strategic decisions while Understory coordinates the campaign stack.
Whether you're syncing docs or scaling campaigns, the principle is the same: one source of truth, one coordinated team. Book a consultation to see how allbound coordination works for your SaaS growth team.
