Google Workspace CLI vs MCP for Claude Code — Which Gives You Better Gmail and Docs Access?
The open-source GWS CLI gives bash-level Gmail, Drive, and Docs access inside Claude Code — no MCP overhead. Here's when to use each approach.
Two Ways Into Google Workspace — and One Is Carrying Dead Weight
You have two options for giving Claude Code access to your Gmail, Drive, Docs, Sheets, and Calendar. You can install an MCP server, or you can use the Google Workspace CLI — bash-level GDocs/Sheets/Gmail access without MCP overhead. The choice sounds like a plumbing decision. It isn’t. It determines how much of your context window you burn on every single request, and whether your agent can actually do useful work inside Google’s ecosystem without slowing to a crawl.
Most people default to MCP because it’s the obvious path. Anthropic built MCP. Claude Code has native MCP support. There are pre-built MCP servers for Google Workspace. Install one, authenticate, done. But “done” is doing a lot of work in that sentence.
The GWS CLI is an open-source project — there’s a GitHub repo you can read right now — that gives Claude Code a bash-command interface to Gmail, Drive, Docs, Sheets, Calendar, and Slides. One tool. No MCP config. No server process. Just terminal commands that Claude can call the same way it calls any other shell utility.
That difference in architecture has downstream consequences worth thinking through carefully.
What Actually Matters When Connecting Claude to Google
Before comparing the two approaches, you need a clear set of criteria. Otherwise you’re just swapping opinions about tooling.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
Token cost per operation. Claude Code has a context window, and everything you load into it costs tokens. An MCP server for Google Workspace doesn’t just give Claude access to Gmail — it loads the entire capability surface into context. Every endpoint, every method, every schema. You pay that cost whether you use it or not. The GWS CLI, by contrast, is a single bash tool. Claude calls it when needed. The rest of the time, it’s not in context at all.
Maintenance surface. MCP servers are processes. They have versions, dependencies, authentication flows that can drift, and they need to stay running. The GWS CLI authenticates once — you go through Google Cloud Console, create a project, set up an OAuth consent screen, create a Desktop App credential, download the JSON to ~/.config/gws/, and you’re done. After that, it’s just a binary on your machine.
Capability breadth vs. depth. MCP servers tend to expose a wide surface area. That’s their design. The GWS CLI is narrower but goes deep on the operations that actually matter: search, list, upload, download, move, copy, share across Drive; full read/write on Gmail; calendar operations; Docs and Sheets manipulation; Slides creation. It also ships with over a hundred pre-built multi-step workflow recipes — things like creating docs from templates, reading sheet data and generating a report, finding free time and scheduling a meeting.
Fit with skills architecture. If you’re building Claude Code skills — the .claude/skills/<skill-name>/skill.md pattern where YAML front matter keeps initial load to roughly 100 tokens — you want your integrations to be similarly lightweight. An MCP server that loads a large capability surface conflicts with the progressive context loading model. A bash tool doesn’t.
Reliability at this stage of the ecosystem. MCP is still maturing. Servers break. Authentication tokens expire in ways that are hard to debug. The GWS CLI is simpler infrastructure, which means fewer things can go wrong.
The MCP Approach: What You’re Actually Getting
MCP is the right answer to a specific problem: you need Claude to have structured, typed access to a service’s full API surface, and you want that access to be composable with other MCP servers in a standardized way.
For Google Workspace specifically, an MCP server will give you everything. Every Gmail endpoint. Every Drive operation. Every Calendar method. If you need to do something unusual — batch operations, admin-level access, service account flows — MCP is probably where you end up.
The cost is real, though. Loading an MCP server for Google Workspace means Claude is aware of a large number of tools at all times. That awareness isn’t free. In practice, users who’ve built Claude Code operating systems with multiple MCP servers report that the token overhead compounds quickly. You’re paying for capability you’re not using on most requests.
There’s also a setup asymmetry worth acknowledging. MCP servers for Google Workspace require OAuth flows, credential management, and often a local server process. When something breaks — and things break — the debugging surface is larger. You’re troubleshooting the MCP server, the OAuth state, the underlying API, and Claude’s interpretation of the tool schema, all at once.
For teams building agents that need to orchestrate across many services simultaneously, platforms like MindStudio offer a different path: 200+ models, 1,000+ pre-built integrations, and a visual builder for chaining agents and workflows, which sidesteps the MCP configuration problem entirely for many use cases.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
MCP makes sense when: you need the full API surface, you’re building something that will be maintained long-term by engineers comfortable with the tooling, or you need the standardized composability that MCP is designed to provide.
The GWS CLI Approach: What You’re Actually Getting
The GWS CLI is a bash-command interface. Claude Code calls it the same way it calls any shell command. That simplicity is the point.
Setup is more manual than installing an MCP server, but it’s a one-time cost. You go to Google Cloud Console, create a new project, navigate to APIs & Services, configure the OAuth consent screen (internal audience if you’re just using this for yourself), create a Desktop App credential, download the JSON file, and save it to ~/.config/gws/. Then you run gws auth login and authenticate. After that, every Google Workspace operation is a bash command.
What you can do with it is genuinely broad. Search, list, upload, download, move, copy, share anything in Drive. Full Gmail access — read, send, label, archive, search. Calendar operations. Docs and Sheets read/write. Slides creation. And those hundred-plus workflow recipes cover the patterns you’ll actually use: creating docs from templates, reading sheet data and generating reports, finding free time and scheduling meetings, labeling and archiving emails.
The token efficiency argument is concrete. When Claude is running a skill — say, a morning planning skill that checks your calendar and surfaces priority emails — it doesn’t need to load the entire Google Workspace API surface. It calls gws gmail list --unread --today and gets back structured JSON. That’s it. The rest of your context window is available for the actual reasoning work.
There’s a practical demonstration of what this looks like in use: you can take a YouTube video URL, drop it into Claude Code, say “create me a resource guide,” and the GWS CLI will create an actual formatted Google Doc — not raw markdown dumped into a file, but a real document with headers, links, and images — via bash command rather than API call. The output is a properly formatted Google Doc with a real document ID you can share.
One thing to be aware of: the GWS CLI is under active development and not yet at v1.0. The GitHub repo says explicitly that breaking changes should be expected. Some users report needing to reauthenticate more often than they’d like. This is real infrastructure risk, and you should factor it in. That said, the project auto-updates when Google Workspace adds new API endpoints or methods, which means the capability surface grows without you doing anything.
For the Claude Code skills architecture pattern specifically — where skills reference external tools via bash commands rather than loading full API clients — the GWS CLI fits naturally. Your skill.md file can reference specific GWS commands for the operations it needs, rather than relying on an MCP server being available and loaded.
Verdict: Which One to Use and When
The honest answer is that these tools solve different problems, and the right choice depends on what you’re actually building.
Use the GWS CLI if:
Not a coding agent. A product manager.
Remy doesn't type the next file. Remy runs the project — manages the agents, coordinates the layers, ships the app.
You’re building a personal AI operating system — the kind where you want Claude Code to help you plan your day, triage your inbox, create documents, and manage your calendar, all within a single session. The token efficiency matters here because you’re running many small operations across a long session. You want the integration to be lightweight and always available, not a process you have to manage.
You’re building Claude Code skills that need Google Workspace access. The bash-command model fits the progressive context loading architecture. Your skill.md can specify exactly which GWS commands to run, and Claude only loads what it needs.
You’re working primarily in Google’s ecosystem and want one tool that covers everything. The GWS CLI’s breadth across Gmail, Drive, Docs, Sheets, Calendar, and Slides means you’re not stitching together multiple integrations.
You want low maintenance overhead. Authenticate once, use forever (mostly). No server process to keep running.
Use MCP if:
You need the full API surface for a specific service, including endpoints the GWS CLI doesn’t expose. Admin operations, batch processing, service account flows — these are MCP territory.
You’re building something that will be maintained by a team and needs the standardized composability that MCP provides. MCP’s value proposition is that tools from different servers can be composed in a consistent way. If you’re building infrastructure that other people will extend, that matters.
You need to integrate with services that don’t have a CLI equivalent. MCP’s ecosystem is broader than what any single CLI can cover.
You’re comfortable with the token overhead because your use case genuinely needs the full capability surface loaded at all times.
The hybrid case:
Nothing stops you from using both. For Google Workspace specifically, you might use the GWS CLI for the 90% of operations that fit its model, and fall back to direct API calls (stored as a reference markdown file in your project, so Claude doesn’t have to re-research the endpoints) for the edge cases. This is actually the pattern that makes sense for most Claude Code operating systems: use the lightweight tool by default, have the full API documentation available as a reference file when you need something unusual.
The reference file approach is worth calling out explicitly. Rather than loading an MCP server to get access to API documentation, you can scrape the relevant endpoints once, store them as a .md file in your project’s references folder, and have Claude read that file when it needs a specific endpoint. Processing a local markdown file is faster and cheaper than making API calls or HTTP requests to fetch documentation on demand. This is how you get the capability of MCP without the overhead.
If you’re building agents that go beyond Google Workspace — connecting to CRMs, databases, or custom APIs — the Claude Code agentic workflow patterns post covers how to structure those integrations without letting context overhead accumulate. And if you want to see how the GWS CLI fits into a broader automation architecture, the Google Workspace CLI setup and automation guide walks through the full configuration in detail.
The Underlying Principle
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
There’s a pattern here that extends beyond this specific comparison. Every integration you add to Claude Code has a token cost. MCP servers are convenient because they abstract away the details, but that abstraction has a price. Bash tools, local markdown reference files, and direct API calls with stored documentation are less convenient to set up but cheaper to run.
The engineers who get the most out of Claude Code operating systems tend to be the ones who think carefully about what actually needs to be in context at any given moment. The GWS CLI wins for Google Workspace not because it’s technically superior to MCP in every dimension, but because it fits the mental model of “load what you need, when you need it” better than a server that loads everything upfront.
Tools like Remy apply the same principle at a different layer: rather than generating code speculatively, you write a spec — annotated markdown — and the full-stack application gets compiled from it. The source of truth is precise; the derived output follows. The direction of travel in AI tooling is toward more deliberate, less speculative context loading, whether that’s in how you structure your Claude Code integrations or how you think about building applications from them.
The GWS CLI is a good tool for a specific job. Use it for that job. Don’t use it as a reason to avoid MCP everywhere — MCP has legitimate use cases. But if you’re building a personal AI operating system and you want Claude Code to work fluidly inside Google Workspace without burning your context window on capability you’re not using, the bash-command approach is the right call.
For the self-evolving memory system pattern — where Claude Code hooks capture session logs and build a wiki that grows over time — the GWS CLI is a natural fit for the ingestion layer. You can pipe meeting transcripts, email threads, and document content directly into your Obsidian vault’s raw folder, and let Claude organize the relationships from there.
The choice between GWS CLI and MCP is ultimately a choice about what kind of overhead you’re willing to carry. For most personal productivity use cases inside Google Workspace, the CLI carries less.
