Not Everything Needs MCP: What Google Workspace CLI Taught Us About AI Agent Architecture

Menu on the Table vs Order from the Kitchen — Why CLI Beats MCP for Large APIs

When Google Workspace CLI launched, several articles mentioned its MCP server.

But when I tried to run gws mcp, something strange happened.

The command didn't exist.

What followed was a deep forensic investigation — from README to source code to git history — that ended with a discovery: Google implemented a full MCP server, improved it, then deliberately deleted all 1,151 lines of it as a breaking change. Two days after launch.

This is the story of that investigation, and what it reveals about AI agent tool design.

---

What is Google Workspace CLI?

Google Workspace CLI (gws) is a Rust-based CLI tool that covers nearly every Google Workspace API. It's open source under Apache 2.0 and installs via npm:

npm install -g @googleworkspace/cli

Its killer feature: commands are dynamically generated from Google's Discovery Service at runtime. Unlike traditional CLI tools that hardcode commands for each API, gws reads the Discovery Document and builds its command surface on the fly. When Google adds a new Workspace API endpoint, gws picks it up automatically — zero maintenance required.

gws drive files list --params '{"pageSize": 10}'
gws gmail users messages list --params '{"userId": "me"}'
gws calendar events list --params '{"calendarId": "primary"}'

Every response is structured JSON. It ships with 100+ Agent Skills — not just prompt templates, but complete workflow definitions covering auth, safety, and API usage patterns. In short, gws is built as a runtime for AI agents to operate Google Workspace, not just a tool for humans.

Keep this architecture in mind. It's the key to understanding why MCP was removed.

---

"MCP Server Included" — Or So the Articles Said

Within hours of launch, tech publications ran with it:

"It also includes an MCP server mode through gws mcp"
— VentureBeat

"MCPサーバーを起動することができ、Claude Desktop、Gemini CLI、VS CodeなどのMCP対応クライアントからGoogle Workspace APIを直接呼び出すことができる"
A Japanese tech publication made a similar claim, saying that the CLI could start an MCP server and be used from Claude Desktop, Gemini CLI, and VS Code.
— Japanese tech publication

MCP (Model Context Protocol) is arguably the hottest protocol in the AI agent ecosystem right now. Originally proposed by Anthropic for Claude, then donated to the Linux Foundation, it's being adopted by Claude Desktop, Gemini CLI, VS Code, Cursor, and many others.

"Google Workspace supports MCP" was exactly the kind of news the community was waiting for.

So I tried it immediately.

---

The Wall: gws mcp Doesn't Work

$ gws mcp
{
  "error": {
    "code": 400,
    "message": "Unknown service 'mcp'. Known services: drive, sheets, gmail, 
    calendar, admin-reports, reports, docs, slides, tasks, people, chat, 
    classroom, forms, keep, meet, events, modelarmor, workflow, wf.",
    "reason": "validationError"
  }
}

gws interprets its first argument as a Google API service name. mcp isn't a service, so it fails. Fair enough — maybe the syntax is different?

$ npx -y @googleworkspace/cli mcp   # Same error
$ gws --help                         # No mention of mcp anywhere
$ gws mcp --help                     # Same error

The --help output lists exactly three top-level commands: schema, generate-skills, and auth. MCP is nowhere to be found.

Something was off.

---

Dissecting the npm Package

I looked at what was actually installed:

$ readlink -f "$(which gws)"
.../node_modules/@googleworkspace/cli/run-gws.js

The entry point is a Node.js wrapper that downloads and runs a prebuilt Rust binary. Checking package.json:

{
  "bin": {
    "gws": "run-gws.js"
  },
  "version": "0.8.1"
}

The only binary exposed is gws. No gws-mcp, no gws-server. The supportedPlatforms section confirms: every platform ships a single binary named gws.

The MCP entry point simply doesn't exist in the distributed package.

---

Reading the Rust Source

Maybe MCP exists in the repo but isn't included in the npm release? I cloned the repository and read src/main.rs:

async fn run() -> Result<(), GwsError> {
    let args: Vec<String> = std::env::args().collect();
    // ...
    if first_arg == "schema" { /* ... */ }
    if first_arg == "generate-skills" { /* ... */ }
    if first_arg == "auth" { /* ... */ }
    // Everything else → treat as service name
    let (api_name, version) = parse_service_and_version(&args, &first_arg)?;
}

Three top-level commands. Everything else falls through to service name resolution. No mcp branch exists. The print_usage() function doesn't mention MCP. The mod declarations don't include mcp_server.

I built from source to confirm:

$ cargo build
$ ./target/debug/gws mcp
→ Same error

At this point I had confirmed across five layers:

1. gws --help — no MCP
2. gws mcp — unknown service
3. package.json — bin is gws only
4. main.rs — no MCP branch
5. Fresh build from source — still no MCP

MCP doesn't exist. Not in the release. Not in the source.

---

But the Traces Were There

I wasn't ready to give up. I grepped the repo:

$ grep -R "mcp" .
./.github/labeler.yml:"area: mcp":
./.github/labeler.yml:          - src/mcp_server.rs
./CHANGELOG.md:- dd3fc90: Remove mcp command
./CHANGELOG.md:- 9cf6e0e: Add --tool-mode compact|full flag to gws mcp.
./CHANGELOG.md:- 670267f: feat: add gws mcp Model Context Protocol server

There it was.

The CHANGELOG told a clear story: MCP was implemented, improved, and then removed.

GitHub Issues search returned 19 results for "MCP" (7 open, 12 closed):

• gws mcp -s does not exist (#69)
• MCP server ignores GOOGLE_WORKSPACE_CLI_ACCOUNT env var (#221)
• MCP tools/list returns uncallable tool names (#162)
• Switch MCP tool names from underscore to hyphen separator (#235)
• feat: add tool annotations, deferred loading, and pagination to MCP server (#260)

These aren't wishlist items. These are real bug reports from real users who were running the MCP server. You don't debate underscore vs hyphen in tool names unless you're actually calling those tools.

MCP wasn't missing. It was there, and it was deleted.

---

The Moment of Deletion: 1,151 Lines Gone

I found the commit:

$ git show --stat dd3fc90
commit dd3fc9074d74a3c74792aa08c6bff7a9984d0d46
Author: Steve Bazyl <[e-mail]>
Date:   Fri Mar 6 13:33:23 2026 -0500

    fix!: Remove MCP server mode (#275)

    * BREAKING CHANGE: Remove MCP server mode
    * Add changeset file

 .changeset/no-mcp.md |    5 +
 README.md            |   34 ----
 src/main.rs          |    6 -
 src/mcp_server.rs    | 1151 --------------------------------------------------
 5 files changed, 5 insertions(+), 1192 deletions(-)

March 6, 2026. Two days after launch.

The ! in fix!: is Conventional Commits syntax for a breaking change. This wasn't a quiet deprecation — it was a deliberate, loud removal.

src/mcp_server.rs — 1,151 lines deleted. This was no prototype. It was a complete MCP server implementation: JSON-RPC protocol handling, tools/list for tool discovery, tools/call for tool execution, Discovery API integration.

The area: mcp label was also removed from AGENTS.md. The next day, Issue #260 (proposing tool annotations and deferred loading for the MCP server) was closed as not_planned.

This wasn't a temporary retreat. It was a policy decision.

---

Why Google Removed MCP

The answer lies in the collision between MCP's protocol design and Google Workspace API's scale.

The tools/list Problem

In MCP, when a server starts up, it exposes all available tools via tools/list. The client's LLM loads these tool definitions into its context window to decide which tools to use and when.

Google Workspace API is massive. Drive, Gmail, Calendar, Sheets, Docs, Chat, Tasks, People, Forms, Admin — over 10 major services, each with dozens of methods. Drive alone has files.list, files.get, files.create, files.update, files.delete, permissions.create... easily 10+ methods.

Run all of that through Discovery API and you get 200–400 MCP tools.

The CHANGELOG confirms this:

Add --tool-mode compact|full flag to gws mcp. Compact mode exposes one tool per service plus a gws_discover meta-tool, reducing context window usage from 200-400 tools to ~26.

That's 2–8x the practical limit for most MCP clients (typically 50–100 tools).

Context Explosion

200–400 tool definitions, each with name, description, parameter schemas, and required/optional markers, all serialized as JSON and loaded into the context window. Estimated token cost: 40,000–100,000 tokens — just for tool definitions.

That leaves dramatically less room for user instructions, conversation history, and actual reasoning. Latency increases. Inference quality degrades.

Compact Mode Didn't Save It

The team tried. Compact mode reduced the tool count to ~26 by exposing one meta-tool per service. But MCP was deleted the day after compact mode was implemented. That tells you the mitigation wasn't sufficient.

Bug Avalanche

During MCP's brief existence, at least 7 bug fixes were needed:

• Tool naming ambiguity (fixed twice)
• Schema inconsistencies in tool calls
• Alias vs Discovery Document name mismatch
• unwrap() panics in mcp_server.rs
• Auth environment variable being ignored
• Empty body: {} on GET methods causing 400 errors

For a small OSS project, that's an unsustainable maintenance burden over just two days.

The Root Cause: Architectural Mismatch

The bug count alone didn't kill MCP. The real issue is structural.

Google Workspace API is optimized for dynamic generation of hundreds of methods via Discovery Service. That's its superpower as a CLI — new APIs appear automatically, no code changes needed.

But that same superpower becomes a liability under MCP. MCP's tool model requires all tool definitions to be sent upfront to the client. "Dynamically generate hundreds of methods" directly translates to "flood the context window with hundreds of tool schemas."

This isn't a fixable bug. It's a fundamental mismatch between Google's API design and MCP's protocol design.

MCP was technically implementable. But it couldn't be shaped into a feature that justified its implementation complexity.

---

The Architecture After MCP: CLI-First

Here's what gws looks like now:

Google Workspace APIs
        ↓
    Discovery Service
        ↓
      gws CLI
        ↓
    JSON output
        ↓
  AI Agent (via shell)

This is fundamentally different from MCP.

MCP model: LLM discovers all tools upfront via protocol → calls tools via structured protocol. All tool definitions live in the context window.

CLI model: Agent calls gws as a shell command. Skills and CONTEXT.md guide which commands to run. gws schema provides on-demand schema queries. Context overhead: near zero.

The MCP approach is "spread the entire menu on the table and choose." The CLI approach is "order from the kitchen when you're hungry." For an API surface as vast as Google Workspace, the kitchen model wins.

The 100+ Agent Skills remain. The 50+ curated recipes for Gmail, Drive, Calendar, Docs, and Sheets remain. The structured JSON output remains. The on-demand schema discovery remains.

MCP's removal didn't reduce functionality. The project converged on a more efficient agent integration model that didn't need MCP as a layer.

---

Were the Articles Verified?

Multiple publications reported "MCP server included" — in English and Japanese. But by the time I checked the repository:

• gws --help showed no MCP
• gws mcp returned "unknown service"
• The npm package exposed only gws in bin
• main.rs had no MCP branch
• Building from source didn't produce MCP
• MCP had been removed as a BREAKING CHANGE two days after launch

The MCP implementation did exist in the repo's history. Issues, PRs, and CHANGELOG entries confirm it was real. So "pure fabrication" would be unfair.

But a responsible technical article needs at least one of: a startup command, a config example, an execution log, or a version number where the feature works. None of the articles I found had any of these.

I use AI as a research partner too — I had ChatGPT help analyze the README and used Claude Code to dig through commit history. AI-assisted research is fine. The problem is publishing AI-generated summaries without running the actual software.

If you write about an OSS tool, run it first. Especially in the first week after launch, when READMEs and released artifacts can be out of sync. That gap is where misleading articles are born.

---

Will MCP Come Back?

Short term (< 6 months): Unlikely.

Issue #260 was closed as not_planned. PR #275 declared a BREAKING CHANGE. The area: mcp label was removed from AGENTS.md. This isn't a pause — it's a clear signal that MCP is not in the development roadmap.

Medium term (6–12 months): Conditionally possible.

If the MCP specification evolves to address:

• Tool count limits — clients efficiently handling hundreds of tools
• Lazy loading standardization — on-demand tool discovery as a first-class MCP feature
• Community contribution — someone submits and maintains a complete implementation

Long term: Architecture-dependent.

Google currently positions gws as a Gemini CLI Extension. If Gemini's ecosystem adopts a tool integration protocol similar to MCP, something functionally equivalent could emerge.

But the current trajectory is clearly CLI + Skills + on-demand schema discovery. MCP's near-term revival is unlikely.

---

What This Investigation Revealed

Tool Design in the Age of AI Agents

gws poses an important question about AI agent tool integration.

MCP standardizes tool discovery and invocation at the protocol level. LLMs see all available tools and call them through structured interfaces. This works beautifully for small-to-medium tool sets.

But for services with massive API surfaces like Google Workspace, MCP's model breaks down. Tool definitions consume the context window and degrade reasoning capability.

CLI-based integration lets agents call external tools as shell commands. No tool definitions in the context window. Skills and documentation teach the agent what's available; schemas are queried on demand. Even with hundreds of available operations, context overhead stays near zero.

This isn't MCP vs CLI as a universal choice. The optimal integration method depends on the scale and characteristics of the tool set. Google didn't remove MCP because MCP is a bad protocol. They removed it because Google Workspace API's scale created a structural mismatch with MCP's tool model. For smaller tool sets (10–50 tools), MCP remains one of the best integration approaches available.

The Speed of OSS

gws MCP followed this timeline:

• v0.3.x: MCP server added
• v0.5.x: compact/full mode improvement
• v0.6.x: bug fixes (naming, schemas, auth)
• v0.8.x: MCP removed (BREAKING CHANGE)

All of this happened within days. Features can be added and removed faster than articles can be written about them. That's why running the software yourself matters more than reading about it.

CLI = Agent Runtime

Tracing gws's design reveals something about Google's vision for AI agents:

API schema (Discovery Service)
    ↓
CLI runtime (gws)
    ↓
Structured JSON output
    ↓
AI Agent (guided by Skills)

This is "CLI as Agent Runtime." Traditionally, CLI was a human interface. gws is explicitly designed as an interface for AI agents to call. Structured JSON everywhere. 100+ pre-defined Skills. On-demand API schema queries via gws schema. Agent guidelines in CONTEXT.md.

This design philosophy is precisely what made MCP redundant. MCP exposes tools via protocol; gws treats the CLI itself as the tool. No need to send tool definitions over JSON-RPC when you can just execute a shell command.

If this is Google's answer, then the future of AI agents won't be MCP-only. At least for services with large API surfaces, CLI-first will remain a viable — perhaps superior — alternative.

---

Conclusion

This investigation started with a trivial error: gws mcp returning "unknown service."

I read the README. Checked --help. Opened package.json. Read the Rust source. Built from source. Traced the git log. Examined commit diffs. Searched GitHub Issues. At the end of that trail was 1,151 lines of MCP server code, deliberately removed as a BREAKING CHANGE.

The removal wasn't a technical failure. It was the recognition of an architectural mismatch. Google's Discovery API dynamically generates hundreds of methods — a strength that directly became MCP's context window problem. Compact mode was attempted as a mitigation but couldn't resolve the fundamental collision between Google's API scale and MCP's tool model.

What remains is everything an AI agent needs to operate Google Workspace: 100+ Agent Skills, structured JSON output, on-demand schema discovery — all without MCP.

There's no universal answer to the MCP vs CLI debate. But what gws demonstrated through its own history is that AI agent tool design is still an open problem. The right architecture depends on the shape and scale of the API surface.

If you write about an OSS tool, run it first. Not the README — the actual software. In the age of AI, repository analysis takes hours, not days. Use that speed for verification, not just content production.