A CLI That Says More Than It Does
In early March, Google open-sourced a command-line tool called gws — Google Workspace CLI.
What it does: lets you operate Gmail, Google Drive, Calendar, Sheets, Docs, Chat, and Admin API directly from the terminal. Written in Rust. Hit 4,900 GitHub Stars in three days.
But the interesting part isn’t what services it covers. It’s why it exists, and what it means for the AI Agent ecosystem.
Before: Agents Needed Humans to Wire Up Every Service
If you’ve worked with Claude Code, Gemini CLI, or any AI Agent framework, you probably know about MCP (Model Context Protocol) — a standard protocol that lets AI Agents communicate with external tools.
The old workflow looked like this:
- Want your Agent to read Gmail? → Find a Gmail MCP Server → install it, configure OAuth → now the Agent can use it
- Want Calendar access? → Find another MCP Server → another setup
- Want to read GDrive files? → Yet another plugin
Each service required its own plugin, each with separate authentication setup. Fragmented, maintenance-heavy, and inconsistent in quality.
Now: One CLI Covers Everything — and It Has MCP Built In
Google Workspace CLI takes a different approach:
One tool for all Google Workspace services. No separate Gmail plugin, Calendar plugin, Drive plugin. One gws command handles everything.
The critical detail: gws has a built-in MCP Server.
This means it’s not replacing MCP — it’s treating MCP as the standard interface for Agents. When your Claude Code or any other Agent connects via MCP, it gets access to all Google services through a single endpoint.
| Old Model | New Model |
|---|---|
| Community volunteers write MCP wrappers | Vendors ship CLI + built-in MCP |
| One MCP plugin per service, each maintained separately | One CLI for all services from the same vendor |
| Agents use human-built tools via MCP | Agents get vendor-native CLI, MCP is just the interface |
| Fragmented, variable quality | Official maintenance, consistent quality |
More Token-Efficient Than Traditional MCP
Here’s a technical detail worth noting.
Traditional MCP Servers load their complete tool schemas into the Agent’s context window on every request. More tools mean bigger schemas and more tokens consumed.
CLI works differently. The Agent just needs to know a few command patterns, then executes them through the terminal. The CLI handles all the logic internally and returns the result.
In simple terms: MCP brings the tool into the Agent’s brain. CLI lets the Agent reach outside to operate the tool.
The latter uses fewer tokens, runs faster, and is more secure — because the CLI can enforce its own safety mechanisms (gws includes --dry-run for simulation and --sanitize for prompt injection prevention) without relying on the Agent to judge security boundaries.
40+ Built-in Agent Skills
gws also ships with 40+ Agent Skills — Markdown-formatted instruction manuals that tell Agents how to perform operations.
This design is clever. AI Agents excel at reading documentation and following instructions. Put well-written Markdown guides in front of them, and they’ll figure out the rest. No complex API bindings needed, no language-specific SDKs.
Think of it as: “Give the Agent a manual, and it can operate all of Google Workspace.”
Karpathy’s Prediction Is Coming True
Andrej Karpathy recently predicted that CLI would become the lingua franca of the Agent world — replacing fragmented GUI interactions and inconsistent API wrappers.
His logic: CLI is the most machine-friendly human-computer interface. Structured input, structured output, predictable, automatable. GUIs are built for humans. API wrappers are human-written bridges for machines. But CLI is natively machine-friendly.
Google Workspace CLI validates this prediction. And you can expect more vendors to follow:
- Notion CLI
- Slack CLI (already exists)
- GitHub CLI (
gh— already mature) - Stripe CLI
- Every SaaS service, eventually
When every service has its own CLI, Agents won’t depend on third-party wrappers anymore.
What This Means for Our Team
We actually use MCP — Gmail and Calendar are operated by our Agents through MCP Servers. Seeing gws drop, the first question was: “Should we switch?”
Short-term answer: No rush.
Why:
- gws is still v0.4.x — early version, stability needs observation
- Our existing MCP setup works fine — if it’s not broken, don’t fix it
- gws and MCP can coexist — it’s not an either-or choice
Medium to long-term, if gws stabilizes and its MCP Server matures, replacing our multiple Google MCP plugins with a single tool makes sense — fewer moving parts, lower maintenance cost.
So Is MCP Dead?
No. Quite the opposite.
MCP is transitioning from “community-built” to “vendor-native.”
gws shipping with a built-in MCP Server means Google endorses MCP as the standard Agent-tool interface. When big companies actively integrate a protocol, the entire ecosystem benefits.
MCP’s value isn’t about who writes the wrapper. It’s about providing a unified communication protocol. Whether the tool is community-built, vendor-shipped, or CLI-embedded, as long as it speaks MCP, any Agent can use it.
What’s actually changing is the supply model for tools. From “humans help Agents install plugins” to “vendors directly provide Agent-ready tools.”
Agents are evolving from “needs human help to set up its environment” to “give it a tool and it works.”
One-Line Summary
Google Workspace CLI isn’t MCP’s killer — it’s the first domino.
When major companies start building tools specifically for Agents, the Agent’s capability boundary is no longer defined by community plugins.
This shift will happen faster than most people expect.