Top
Best
New

Posted by gonzalovargas 23 hours ago

Google Workspace CLI(github.com)
879 points | 273 commentspage 2
corby 11 hours ago|
I think we all have been working on our own bespoke CLI tools. MCPs are bloated, insecure token hogs. CLIs are easy to write and you can cut it down to only what you need, saving thousands of tokens per prompt. This is another one I'll add to my repertoire of claude CLIs to replace the MCP.
internet2000 20 hours ago||
Claude Opus 4.6 couldn't figure out how to use it to write to a Google Sheet (something to do with escaping the !?) and fell back to calling the sheets API directly with gcloud auth.
nurettin 18 hours ago||
Can you tell it to write to /tmp/s.py instead of trying to execute it inline?
flakiness 18 hours ago||
You should use Gemini obviously </s>
gck1 16 hours ago||
Yeah, that one can't even figure out how to write a formula, or sometimes read data when it's sitting WITHIN context of sheets.

I get better experience if I just copy-paste the sheet data into Gemini web. And IIRC copy-paste is just space "delimited" by default.

fergie 16 hours ago||
> gws doesn't ship a static list of commands. It reads Google's own Discovery Service at runtime and builds its entire command surface dynamically.

What is the practical difference between a "discovery service"+API and an MCP server? Surely humans and LLMs are better off using discovery service"+API in all cases? What would be the benefit of MCP?

jtrn 15 hours ago||
Nothing. MCP and HTTP APIs and CLI tools without the good parts. They lack the robustness of the OpenAPI spec, including security standardization, and are more complex to run than simple CLI utilities without any authentication.

I have done it many times, using the swagger.json as a "discovery service" and then having the agent utilize that API. A good OpenAPI spec was working perfectly fine for me all the way back when OpenAI introduced GPTs.

If we standardized on a discovery/ endpoint, or something like that, as a more compact description of the API to reduce token usage compared to consuming the somewhat bloated full OpenAPI spec, you would have everything you need right there.

The MCP side quest for AI has been one of the most annoying things in AI in recent years. Complete waste of time.

dahcryn 15 hours ago|||
Benefit of mcp is that it exists and kinda works, and a lot of tools are available on it. I guess it's all about adoption. But inherently yeah it's a discovery service thingy. Google will never embrace mcp since it's invented by anthropic

I consider it a good first attempt, but indeed hope for a sort of mcp2.0

fergie 15 hours ago||
Right, but surely swagger/openapi has been providing robust API discovery for years? I just don't get what LLMs don't like about it (apart from it possibly using slightly more tokens than MCP)
theshrike79 14 hours ago||
MCP is like "this is what the API is about, figure it out". You can also change the server side pretty liberally and the agent will figure it out.

Swagger/OpenAPI is "this is EXACTLY what the API does, if you don't do it like this, you will fail". If you change something, things will start falling apart.

allan_s 15 hours ago|||
in a lot of sphere, MCP is still the hype. And it was the hype in even more sphere some month ago.

Because of FOMO a lot of higher up decided that "we must do a MCP to show that we're also part of the cool kids" and to give an answer to their even-higher-up about "What are you doing regarding IA ?"

The project has been approved, a lot of time has been sunk into the project, so nobody wants to admit that "hmmm actually now it's irrelevant our existing API + a skill.md is enough"

I've seen that in at least 4 companies my friends work in, so I would be surprised if it's not something like that here too.

On the contrary claude code, in my experience, has been perfectly able to use `stripe` `gh` and to construct on the fly a figma cli (once instructed to do it).

anthonypasq 7 hours ago|||
theres a lot more to the MCP spec than tool calling, and also people ignoring the fact that remote mcps exist
anthonypasq 7 hours ago||
theres a lot more to the MCP spec than tool calling
avaer 21 hours ago||
Is this basically a CLI version of [1]? If so, I'm glad Google is being forward thinking about how developers actually want to use their apps.

Better this than a Google dashboard, or slopped together third party libs. I know Google says they don't support it, but they'll probably support it better than someone outside of Google can support it.

[1] https://workspaceupdates.googleblog.com/2025/12/workspace-st...

tomComb 20 hours ago|
I think it is unrelated.
pimlottc 18 hours ago||
> gws doesn't ship a static list of commands.

Clever, but frustrating that they don’t bother to provide any docs on the actual commands this supports.

iosjunkie 20 hours ago||
Basically Google’s take on GAM https://github.com/GAM-team/GAM
pimlottc 18 hours ago||
That’s the first thing I thought as well, although GAM is for admin tools only. I think this is for user APIs? But it’s not really clear…
webXL 20 hours ago|||
gog too, which my openclaw agent always stubbornly wants to use instead of delegating to a subagent + custom calendar/imap proxy server I built.

https://github.com/steipete/gogcli

tomComb 20 hours ago||
This - gog - yes. But I think it is different than GAM which is an admin tool. reply
tomComb 8 hours ago||
Yikes, I wrote that? I hate it when people write cryptic replies like that.

What I meant was 'yes', Google Workspace CLI appears to quite similar to 'gogcli', the CLI written for OpenClaw. Both provide CLI access to a broad range of Google services for both workspace and regular gmail accounts.

GAM, on the other hand, is an admin tool, and strictly for Google Workspace accounts.

hrimfaxi 20 hours ago|||
It's about time. Reminds me of how even Apple uses Jamf.
conception 19 hours ago||
Except GAM is already heavily in training data and less likely to be called incorrectly.
plastic041 15 hours ago||
The fact that humans can use this feels like a side effect. The developer says it's "built for agents first" and "AI agents would be the primary consumers of every command, every flag, and every byte of output"[1].

[1] https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...

mansilladev 14 hours ago||
I remember reading gog setup instructions, and thinking, "Create oauth app/client? That's bonkers." And as cool+useful as this project looks, it's quite a bit harder to get going, especially if you're not familiar with Google Console and OAuth (or not a dev).

Reading lots of comments about "MCP vs CLI" -- reminds me a bit of the "agent vs. script/app/rpa" debates. It's usually not one or the other, but rather, both.. or the right tool for the job (and that can shift over time).

Biggest complaint we have about MCP is bigger context windows and token spend. Tools do exist that address this. I have just one MCP endpoint with a half dozen tools behind it, including Gmail, Google Calendar, Docs, Github, Notion, and more. Uses tool search tool (ToolIQ) with tiny context footprint. Give it a whirl. https://venn.ai

tgma 19 hours ago||
"This is not an officially supported Google product."

Probably someone's hobby project or 20% time at best.

htrp 6 hours ago|
at least it's actually a google product
benjaminwootton 15 hours ago|
They need something like this as it's hard and flaky to automate Google apps with AI. However, step 2 drops me to a fairly technical looking page where I have to configure Google Cloud. If they had a one click installer to automate Google Apps it would be an absolute killer use case for AI for me.
More comments...