I am a Developer Relations Engineer at Google. Currently I am on the Google Workspace DevRel team and was on the Google Maps Platform before that. Previously I worked at Descartes Labs and the US Geological Survey.
This is made by Google Devrel. It's not going to break the TOS, but it could be abandoned. That happens frequently with devrel projects, since they're not actually tasked with or graded on engineering projects.
hrmtst93837•Mar 5, 2026
I think calling DevRel projects 'frequently abandoned' is blunt, but in my experience they are more like samples than production-owned libraries, so you should assume limited maintenance. Before relying on the Google Workspace CLI for automation inspect commit cadence, open issues, last release tag, number of contributors, and whether a product team or SDK maintainer is listed. If you need it in production pin to a release tag and vendor the code with go modules replace or npm shrinkwrap, add a thin adapter so swapping implementations is trivial, and run a couple of integration tests in GitHub Actions to catch regressions. I once had to fork a DevRel CLI that our on-call scripts depended on and maintaining that fork cost a weekend plus a steady trickle of small fixes, so now I put third party CLIs behind a tiny internal wrapper and keep the command surface minimal.
tedk-42•Mar 5, 2026
Haha in the world of AI/MCPs, all of a sudden we have a push for companies to properly build out APIs/CLI tools.
sh3rl0ck•Mar 5, 2026
One of the very few good things from the AI race has been everyone finally publishing more data APIs out in the open, and making their tools usable via CLIs (or extensible APIs).
citizenpaul•Mar 5, 2026
I feel like the CLI craze started around 2020. That predates this chat GPT.
CharmCLI golang
Nushell rust
Warp. Shell
Were all around 2020 also that is when alt shells started getting popular probably for same reasons they still are.
BarryMilo•Mar 5, 2026
Took them this long to realize MCPs are just worse APIs.
dack•Mar 5, 2026
yeah there's way more demand, and at the same time, it's way easier for the company to build and maintain (with the help of AI). Great to see!
benatkin•Mar 5, 2026
They aren't doing that though. At least not yet. It's generated from the discovery tool, which amounts to the spec of the existing API. If they want a high powered CLI they need to dig into the servers behind Google Workspace like they have when they've improved the web apps.
spullara•Mar 5, 2026
I have always said that if we had done for developers what we are doing for agents the whole world would have been a much better place.
ryandrake•Mar 5, 2026
Perhaps we will finally emerge from this decades-long dark age of bloated, do-everything GUI development tools being the fashionable happy path.
techpression•Mar 5, 2026
The AWS cli tool wants to have a talk… hard to find a more bloated mess of strung together scripts held together by tape.
theshrike79•Mar 5, 2026
Even if the AI bubble bursts hard, we'll still have all of the better tooling for us actual humans.
But saying "it's for AI" is a corporate life hack for you to get permission to build said better tooling... =)
forrestthewoods•Mar 5, 2026
About 90% of “make codebase better for LLMs” is just good old fashioned better engineering that is also good for humans.
22c•Mar 5, 2026
I noted something similar a few weeks ago. Companies are finally putting APIs in front of things that should have had APIs for years!
vishnugupta•Mar 5, 2026
But on the other hand a (possibly dark) pattern is emerging where companies are asking you to upgrade to a higher plan to access MCP.
sbinnee•Mar 5, 2026
I can already see all the CTOs are getting excited to plug this in their OpenClaw instances.
sanex•Mar 5, 2026
Depends how it compares to gog.
electriclove•Mar 5, 2026
Work fine as a gog replacement for my limited use cases of reading and writing Sheets.
skybrian•Mar 5, 2026
Having the available commands change on you dynamically seems like an anti-pattern, but I suppose an AI can deal with it.
blondin•Mar 5, 2026
This is a very interesting way of building agent skills. Seems like the imperative way of orchestration/automation is making a comeback.
evanjrowley•Mar 5, 2026
Hoping Apple will do the same with iCloud.
wepple•Mar 5, 2026
Don’t hold your breath
paxys•Mar 5, 2026
Lol
avaer•Mar 5, 2026
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.
GCP Next is Apr 22-24. Hope this continues to live afer that.
loveparade•Mar 5, 2026
Great, i hope this becomes a trend now that agent skills want clis
betaby•Mar 5, 2026
I'm curious why `npm` is used to install a `rust` binary?
varenc•Mar 5, 2026
I found that strange as well. My guess is that `npm` is just the package manager people are most likely to already have installed and doing it this way makes it easy. They might think asking people to install Cargo is too much effort. Wonder if the pattern of using npm to install non-node tools will keep gaining traction.
freakynit•Mar 5, 2026
Why not just downloadable binary then?
varenc•Mar 5, 2026
For many, installing something with npm is still easier. It chooses the right binary for your OS/architecture, puts it on your PATH, and streamlines upgrades.
Their Github releases provides the binaries, as well as a `curl ... | sh` install method and a guide to use github releases attestation which I liked.
freakynit•Mar 5, 2026
Hmm, that's right... thanks..
krzyk•Mar 5, 2026
I feel better with `curl ... | sh` than with npm.
npm suggests projects written in js, which is not something I'm comfortable.
It is nice to see that this is not JS, but Rust.
varenc•Mar 5, 2026
Agreed! The `curl ... | sh` is sketchy, but it's more obviously a security risk and easier to inspect. With install hooks, `npm install ...` also allows arbitrary code execution when you run it, but this is less obvious.
Most people aren't going to have npm installed though. Nobody outside of web devs uses it.
sankalpmukim•Mar 5, 2026
"Most people" are webdevs
Bracing for getting cancelled
patates•Mar 5, 2026
A lot of people who are not web devs use it, that's what I see. I even saw some mainframe developers use npx to call some tool on some data dump.
Also, this is a web project anyway. Google Workspace is web based, so while there is a good chance that the users aren't web developers, it's a better chance that they have npm than anything else.
If you had to pick one package manager that was most likely installed across all the different user machines in the world, I'd say npm is a pretty good bet.
wiseowise•Mar 5, 2026
Pip.
m000•Mar 5, 2026
It's still weird. Why not just use an effing install.sh script like everybody else? And don't tell me "security". Because after installation you will be running an unknown binary anyway.
brunoborges•Mar 5, 2026
NPM as a cross platform package distribution system works really well.
The install script checks the OS and Arch, and pulls the right Rust binary.
Then, they get upgrade mechanism out of the box too, and an uninstall mechanism.
NPM has become the de facto standard for installing any software these days, because it is present on every OS.
danpalmer•Mar 5, 2026
To my knowledge NPM isn't shipped in _any_ major OSes. It's available to install on all, just like most package managers, but I'm not sure it's in the default distributions of macOS, Windows, or the major Linux distros?
anilgulecha•Mar 5, 2026
No package manager is. But of the ones that are installed by users, npm is probably the most popular.
spinagon•Mar 5, 2026
What about pip? It's either installed or immediately available on many OSes
piperswe•Mar 5, 2026
`pip install` either doesn’t work out of the box or has the chance to clobber system files though
nikanj•Mar 5, 2026
This is about eight years old. The python situation has mostly gotten worse since https://xkcd.com/1987/
a_t48•Mar 5, 2026
What? It’s much much better now, you can just use uv. Yeah, it’s yet another package manager, but it does it well.
chrisweekly•Mar 5, 2026
Or go up a rung or two on the abstraction ladder, and use mise to manage all the things (node, npm, python, etc).
jitl•Mar 5, 2026
python packaging / envs is solved now by uv. its not promising or used by people in the know like the last 2 trendy python package managers. i was a big time python hater since it was a pita to support as a devtools guy but now its trivial. uv just works, it won.
abustamam•Mar 5, 2026
I'm not a python dev, but I see a bit of its ecosystem. How does uv compare with conda or venv? I thought JS had the monopoly on competing package managers.
jitl•Mar 5, 2026
system pip w/ sudo usually unleashes Zalgo, i’d rather curl | bash but npm is fine too. it’s just about meeting people where they’re at, and in the ai age many devs have npm
if you build for the web, no matter what your backend is (python, go, rust, java, c#), your frontend will almost certainly have some js, so likely you need npm.
Fabricio20•Mar 5, 2026
pip might be but it was historically super inconsistent (at least in my experience). Is it `pip install`? `python3 -m pip install`? maybe `pip3 install`? Yeah ubuntu did a lot of damage to pip here. npm always worked because you had to install it and it didnt have a transition phase from python2 being in the OS by default.
oefrha•Mar 5, 2026
> The install script checks the OS and Arch, and pulls the right Rust binary.
That's the arbitrary code execution at install time aspect of npm that developers should be extra wary of in this day and age. Saner node package managers like pnpm ignore the build script and you have to explicitly approve it on a case-by-case basis.
That said, you can execute code with build.rs with cargo too. Cargo is just not a build artifact distribution mechanism.
mountainriver•Mar 5, 2026
Yeah except you need to install NPM, whereas with a rust binary, which can easily compile cross platform, you don’t.
Honestly I’m shocked to see so many people supporting this
bigstrat2003•Mar 5, 2026
> NPM has become the de facto standard for installing any software these days, because it is present on every OS.
That's not remotely true. If there is a standard (which I wouldn't say there is), it's either docker or curl|bash. Nobody is out there using npm to install packages except web devs, this is absolutely ridiculous on Google's part.
jitl•Mar 5, 2026
they offer npm for the large market of cli users who have it, and curl|bash to those who don’t. ¯\_(ツ)_/¯
abustamam•Mar 5, 2026
I agree but this isn't a Google project, it's one Google employee.
koakuma-chan•Mar 5, 2026
I think there has been an influx of people vibe coding in Rust because its "fast" but otherwise they have no idea about Rust.
gck1•Mar 5, 2026
Not because it's fast, but because of its compiler. It acts as a very good guardrail and feedback mechanism for LLMs.
abustamam•Mar 5, 2026
Typescript has surpassed Python and JS as most used on Github for a similar reason
It's crazy that people think strict typing is a chore. Says a lot about our society.
abustamam•Mar 5, 2026
I learned TS after a few years with JS. I thought having strict types was cool. Many of my colleagues with much more (JS) experience than me thought it was a hassle. Not sure if they meant the setup or TS or what but I always thought it was weird.
xarope•Mar 5, 2026
"NPM has become the de facto standard for installing any software these days, because it is present on every OS."
What?!? Must not be in any OS I've ever installed.
Now tar, on the other hand, exists even in windows.
mcmcmc•Mar 5, 2026
More of a de facto standard for supply chain attacks tbh
cobbal•Mar 5, 2026
They're not doing so here, but shipping a wasm-compiled binary with npm that uses node's WASI API is a really easy way to ship a cross-platform CLI utility. Just needs ~20 lines of JS wrapping it to set up the args and file system.
mountainriver•Mar 5, 2026
Doesn’t this seem excessive over just using rust’s cross platform builds?
csomar•Mar 5, 2026
There's no such thing as a truly "cross-platform" build. Depending on what you use, you might have to target specific combinations of OS and processor architecture. That's actually why WASM (though they went with WASI) is a better choice; especially for libraries, since anyone can drop it into their environment without worrying about compatibility.
jitl•Mar 5, 2026
there’s 3 os and 2 architectures minus darwin-amd64 so you just need to do 5 builds to avoid the WASM performance tax.
(freebsd runs linux binaries and the openbsd people probably want to build from source anyways)
This - gog - yes. But I think it is different than GAM which is an admin tool.
reply
tomComb•Mar 5, 2026
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.
conception•Mar 5, 2026
Except GAM is already heavily in training data and less likely to be called incorrectly.
pimlottc•Mar 5, 2026
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…
Really interesting. I was thinking about something similar regarding the shape of code. I have no qualms recommending my agents take static analysis to the extreme, though it would cumbersome for most people.
albert_e•Mar 5, 2026
Looks like I am hitting some Cloudflare Block when accessing this URL
abustamam•Mar 5, 2026
Probably because he built his site for agents not humans
hamasho•Mar 5, 2026
lol but it’s definitely happening. Some services are solely for llm consumption and human is not a welcomed customer.
dang•Mar 5, 2026
Thanks! Looks like he submitted it here, judging by the username:
This is really interesting: "Humans hate writing nested JSON in the terminal. Agents prefer it." Are others seeing the same thing? I've just moved away from json-default because agents were always using jq to convert it to what I could have been producing anyway.
lostmsu•Mar 5, 2026
In my experience agents struggle with escape sequence nesting as much as humans do. IMHO that is one well-paved road to RCE via code injection.
blks•Mar 5, 2026
No, we won’t be in fact doing that. Machine parsable, readable for other tools - yes.
internet2000•Mar 5, 2026
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.
flakiness•Mar 5, 2026
You should use Gemini obviously </s>
gck1•Mar 5, 2026
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.
nurettin•Mar 5, 2026
Can you tell it to write to /tmp/s.py instead of trying to execute it inline?
mace01•Mar 5, 2026
Seems weird to require another tool (gcloud) to set it up, but it does look to be tightly integrated with google cloud.
justinwp•Mar 5, 2026
You can skip that setup if you already have the OAuth credentials.
pdyc•Mar 5, 2026
wow this will gel very well with my current project. Main hurdle i was facing was connecting with individual services via google oauth to get the data.
mmaunder•Mar 5, 2026
Forget the Gemini extension - Gemini CLI sucks. Forget the MCP - MCP is beyond dead. But for codex or claude cli this is a game changer. Next question is how programmatic have they made the sheets interface... because Gemini sucks at sheets.
Where you have to download a tarball, extract it and run a shell script.
I mean how hard is it to just imitate everyone else out there and make it a straight up npm install?
ceroxylon•Mar 5, 2026
The readme is AI generated, so I am assuming the lack of effort and hand-off to the bots extends to the rest of this repository.
The contributors are a Google DRE, 5 bots / automating services, and a dev in Canada.
jitl•Mar 5, 2026
gcloud cli will probably also require you to make a Google Cloud project and stuff by clicking around their godforsaken webui. hopefully they streamlined that, it took me a long time to figure out when i wanted to write some JS in my spreadsheet
justinwp•Mar 5, 2026
You don't need to use gcloud if you already have:
1. A GCP project (needed for OAuth)
2. Enabled APIs in said project
epicprogrammer•Mar 5, 2026
I've built a few internal tools using the Workspace APIs, and while they are powerful, the rate limits on the Drive API can be brutal if you are doing bulk operations. Does this repository handle automatic backoff and retries, or do we need to wrap it ourselves?
yakkomajuri•Mar 5, 2026
For all people have to say about Pete the openclaw guy he's been perhaps one of the most vocal voices about CLIs > MCPs (or maybe his is just the loudest?) and he also built a GSuite CLI that probably inspired this project.
I mean it's great that we get this, hopefully it can continue to be maintained and I'd love to see a push for similar stuff for other products and at other companies.
wonderfuly•Mar 5, 2026
Why cli instead of just HTTP API doc? The agent can use curl or write code to send requests.
hedora•Mar 5, 2026
CLI is probably more reliable. Also, the ergonomics for the person setting up the machine for the AI are better. They can check to see if the command is working without screwing with curl. It's also possible a human might want to use the software / service they're paying for.
wonderfuly•Mar 5, 2026
Why is it more reliable?
The human usage point is fair, but I doubt how long it is still necesary.
theshrike79•Mar 5, 2026
Imagine the amount of boilerplate you need around a single HTTP API call, every time.
The CLI has abstracted that into one single reusable, scriptable command
boberoni•Mar 5, 2026
A CLI runs on the client, so they can embed client-side functionality like telemetry or caching.
jitl•Mar 5, 2026
if nothing else the cli gives very easy access to the HTTP api docs via `gws schema`
i’d rather not waste the context tokens re implementing their cli from scratch, if indeed it does a good job.
mindwok•Mar 5, 2026
They already have a HTTP API, but the real reason is that CLIs are emerging as the most ergonomic way for the current wave of AI agents to do stuff. There's a few benefits over APIs:
- No need to worry about transport layer stuff at all, including auth or headers. This is baked in, so saves context.
- They are self describing with --help and then nested --help commands, way better than trying to decipher an OpenAPI spec. You usually don't even need an agent skill, just call the --help and the LLM figures it out.
lewisjoe•Mar 5, 2026
How to expose my product suite's API to AI has been a roller coster ride. First it was tool calling hooks, then MCP, then later folks found out AI is better at coding so MCPs suddenly became code-mode, then people realized skills are better at context and eventually now Google has launched cli approach.
Remember this repo is not an agent. It's just a cli tool to operate over gsuite documents that happens to have an MCP command and a bunch of skills prebundled.
That's a new one. I guess the hope is agents are good at navigating cli and it also democratizes the ecosystem to be used by any agent as opposed to Microsoft (which only allows Copilot to work in its ecosystem)
cyrusradfar•Mar 5, 2026
Correct me if I'm wrong but the UX difficulty with the Google API ecosystem isn't resolved. It's the goddamn permissioning and service accounts. Great to have a CLI that every other minute says, "you can't do this" -- the CLI really needed to solve this to check my boxes.
tgma•Mar 5, 2026
"This is not an officially supported Google product."
Probably someone's hobby project or 20% time at best.
htrp•Mar 5, 2026
at least it's actually a google product
jitl•Mar 5, 2026
> quick setup
> requires setting up gcloud cli first, necessitates making a Google Cloud project
cmon google how come even your attempts at good ux start out with bad ux? let me just oauth with my regular google account like every other cli tool out there. gh cli, claude, codex - all are a simple “click ok” in the browser to log in. wtf.
and the slow setup - i need to make my own oauth app & keys??
EDIT: oh yeah and get my oath app verified all so i can use it with my own account
outlore•Mar 5, 2026
Are integration vendors like Pipedream in trouble now that every company is pushing out MCP servers and CLIs to ride the AI craze? After the Twitter and Reddit API troubles of prior years, I can't imagine any company would willingly bring down the walls of their gardens and give easy access to precious user data. I'm waiting for the rug pull
virgildotcodes•Mar 5, 2026
God, getting this set up is frustrating. I've spent 45 minutes trying to get this to work, just following their defaults the whole way through.
Multiple errors and issues along the way, now I'm on `gws auth login`, and trying to pick the oAuth scopes. I go ahead and trust their defaults and select `recommended`, only to get a warning that this is too many scopes and may error out (then why is this the recommended setting??), and then yeah, it errors out when trying to authenticate in the browser.
The error tells me I need to verify my app, so I go to the app settings in my cloud console and try to verify and there's no streamlined way to do this. It seems the intended approach is for me to manually add, one by one, each of the 85 scopes that are on the "recommended" list, and then go through the actual verification.
Have the people that built and released this actually tried to install and run this, just a single time, purely following their own happy path?
jitl•Mar 5, 2026
i had to do all that the last time i wanted to do a little js in my google sheets. when i saw their quick start required gcloud already set up, i decided not to bother trying this out. idk why google makes something that should take 15s (clicking “ok” in an oauth popup) take tens of minutes to hours of head scratching.
m8s•Mar 5, 2026
I’ve been really unhappy with pretty much every Google product I’ve used except their consumer productivity tools — Gmail, Calendar, and Meet. Diving into Google Cloud has been extremely unsatisfactory
brightball•Mar 5, 2026
I ran a project for a company on Google Cloud a few years ago and enjoyed it once I got used to everything. I’d use it more now if they had better low end pricing to start projects there.
It’s a very different experience than AWS though and takes some getting used to.
julianozen•Mar 5, 2026
Same. I was using Gemini and firebase for a work project and I was stunned how hard it was for me to use
varenc•Mar 5, 2026
Similar frustrations. I was only able auth using some Google app I created for an old project years ago that happened to have the right bits.
It wild that this process is still so challenging. There's got to be some safe streamlined way that sets up an app identity you own that can only use to access your own account.
My guess is that organizationally within Google, the developer app authorization process must have many teams involved in its implementation and many other outside stakeholders. A single unified team wouldn't responsible for this confusion and complexity. I get why... it's a huge source of bad actors. But there's got to be a better way.
Google Workspace API(s) keys and Roles was always confusing to me at so many levels .. and they just seem to keeping topping that confusion, no one is addressing the core (honestly not sure if that is even possible at this point)
getting the authentication to work is a real pain and it's basically preventing people access to an otherwise really good and useful MCP
Imagine a marketing person trying to set it up...
sagarpatil•Mar 5, 2026
I used Claude in chrome and Claude Code. It did everything for me.
justinwp•Mar 5, 2026
There are many gotchas in this process and unfortunately there is no easy way to deal with the OAuth setup.
semenko•Mar 5, 2026
I have "Advanced Protection" turned on, so I just can't use this at all, because my newly created Google Cloud GCP app isn't trusted (even though I own it and I'm requesting read-only scopes). What a mess.
Access blocked: [app name] is not approved by Advanced Protection. Error 400: policy_enforced
mosajjal•Mar 5, 2026
AI Agents are becoming first-class citizens for SaaS
Yet somehow Microsoft Copilot doesn't know how to use that tooling.
pimlottc•Mar 5, 2026
> 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.
benkaiser•Mar 5, 2026
Would be nice if the MCP implemented the Streamable HTTP MCP spec instead of the CLI one. I know this is already a HTTP API, but making it available as an MCP server that clients like Joey[1] can consume easily over network would be nice.
It’s npm and a 750mb install. Meaning it won’t even install on micro instances. I wish it were rust or go binary
_wizard•Mar 5, 2026
Neat. I've been running something very similar to this locally for a few months now. They introduced all their documentation into markdown recently. I still rely on discover API and lenient cloud project permissions, so maybe some gains there. Will compare note later.
arthurcolle•Mar 5, 2026
My agents will follow this repo with great interest
shivam310•Mar 5, 2026
I'm surprised that this didn't officially exist before.
mogili1•Mar 5, 2026
I was excited to see this but all of that went away when I realized you need to create an app in GCP to use it. Can't really expect non technical users to set this up across the company.
justinwp•Mar 5, 2026
Yeah, still no way around this unfortunately.
heinrichhartman•Mar 5, 2026
Can someone explain to me, why Google can't (or does not want to) implement the same auth flow that any other SaaS company uses:
# API Keys in Settings
1. Go to Settings -> API Keys Page
2. Create Token (set scope and expiration date)
# OAuth flow
1. `gws login` shows url to visit
2. Login with Google profile & select data you want to share
3. Redirect to localhost page confirms authentication
I get that I need to configure Project and OAuth screens if I want to develop an Applications for other users, that uses GCP services. This is fine. But I am trying to access my own data over a (/another) HTTP API. This should not be hard.
AJRF•Mar 5, 2026
Can you name a service you think works like that?
Google have over a billion very non-technical users.
The friction of not having this in the account page that everyone has access too probably saves both parties lots of heartbreak.
krzyk•Mar 5, 2026
github? I just do some click here, click there, copy paste and gh cli is ready.
For google I need PhD to setup any kind of API access to my own data. And it frequently blocks you, because you can setup as a test product, add test accounts (but it can't be owner account (WTF?)) etc.
I gave up on using a google calendar cli project because of all that lack of normal UX.
UX for google APIs looks like it was designed by accountant.
gws auth setup looks promising, but it won't work yet for personal accounts.
We’re trying to create a single unified cli to every service on the planet, and make sure that everything can be set up with 3 clicks
tomashubelbauer•Mar 5, 2026
Same story here, I installed it and ran `gwc auth setup` only to find I needed to install a `gloud` CLI by hand. That led me to this link with install instructions: https://cloud.google.com/sdk/docs/install. Unmistakeable Google DX strikes again.
aantix•Mar 5, 2026
It's an un-invite. A hollow gesture.
Google's Gemini can read Google Docs directly.
They really don't want you to use another LLM product.
So they make the setup as difficult as possible.
larodi•Mar 5, 2026
Would it help to backup all my mailboxes and be ready to ditch gmail?
Very uninteresting post. Why is this the number one post on Hacker News ? Honestly, absolutely disgusting and you can be ashamed, or ashamed for them.
swaminarayan•Mar 5, 2026
This reminds me a bit of how the GitHub CLI evolved into a foundation for automation and tooling. Do you see the Google Workspace CLI primarily as something for humans using the terminal, or more as a stable interface that automation and AI agents can build on?
dakolli•Mar 5, 2026
I'm just not going to give agents access to my workspace account!
swaminarayan•Mar 5, 2026
I agree
mhogers•Mar 5, 2026
but may they have their own workspace account while working with you? :)
> 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?
dahcryn•Mar 5, 2026
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•Mar 5, 2026
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•Mar 5, 2026
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•Mar 5, 2026
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).
jtrn•Mar 5, 2026
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.
anthonypasq•Mar 5, 2026
theres a lot more to the MCP spec than tool calling
anthonypasq•Mar 5, 2026
theres a lot more to the MCP spec than tool calling, and also people ignoring the fact that remote mcps exist
plastic041•Mar 5, 2026
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].
I've been using `gog` but I'd rather have an agent-first thing. I don't want a big bad MCP that occupies all context all the time. I need my claw to be aware on how to edit things. As it so happens, right now `gog` works. But I'm eager to see how this develops.
benjaminwootton•Mar 5, 2026
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.
jillesvangurp•Mar 5, 2026
Generating a good cli isn't all that hard for agentic coding tools. When you do it manually it's highly repetitive work. But all you are doing is low level plumbing. Given some parsed arguments, call a function, return the result (with some formatting, prettying, etc.). In the end it's just a facade for an API, library, or whatever else you want to have a cli for. Easy to write. Easy to test. But manually going through your API resource by resource, parameter by parameter, etc. takes a long time. An LLM just blazes through that in a few minutes. Generate some tests, tweak as needed, and you are good to go.
I did a few CLIs with codex in the last few weeks. I do simple ops with this stuff. I've had a few use cases for new features where previously I would have had to build some kind of quick and dirty admin UI just to use and test a new API feature before being able to integrate it into our product. With a generated cli, I can just play with it from the command line. Or make codex do that for me.
A good cli with a modern command line argument parser, well documented options, bash/zsh auto complete, pretty colors, etc. is generally nice to have. I mapped resources to commands and sub commands, made it add parameters with sensible defaults or optional ones. Then I got lazy and just asked it what else it thought it was missing, it made some suggestions and I gave it the thumbs up and it all got added. I even generated a simple interactive TUI at some point. Because why not? I also made it generate a md skill file explaining how to use the cli that you can just drop in your skills directory.
codeulike•Mar 5, 2026
But manually going through your API resource by resource, parameter by parameter, etc. takes a long time.
This CLI dynamically generates itself at run time though
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
qalmakka•Mar 5, 2026
> 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
You're not exactly describing rocket science. This is basically how websites work, there's never been anything stopping anyone from doing dynamic UI in TUIs except the fact that TUI frameworks were dog poop until a few years ago (and there was no Windows Terminal, so no Windows support). Try doing that in ncurses instead of Rataui or whatever, it's horrendous
gbrindisi•Mar 5, 2026
the most annoying thing with Google Workspace is that you need super admin privilege to properly audit the environment programmatically, I believe because of the cloud-identity api.
It provides a git like pull/push workflow to edit sheets/docs/slides. `pull` converts the google file into a local folder with agent friendly files. For example, a google sheet becomes a folder with a .tsv, a formula.json and so on. The agent simply edits these files and `push`es the changes. Similarly, a google doc becomes an XML file that is pure content. The agent edits it and calls push - the tool figures out the right batchUpdate API calls to bring the document in sync.
None of the existing tools allow you to edit documents. Invoking batchUpdate directly is error prone and token inefficient. Extrasuite solves these issues.
In addition, Extrasuite also uses a unique service token that is 1:1 mapped to the user. This means that edits show up as "Alice's agent" in google drive version history. This is secure - agents can only access the specific files or folders you explicitly share with the agent.
This is still very much alpha - but we have been using this internally for our 100 member team. Google sheets, docs, forms and app scripts work great - all using the same pull/push metaphor. Google slides needs some work.
sothatsit•Mar 5, 2026
We have been using something similar for editing Confluence pages. Download XML, edit, upload. It is very effective, much better than direct edit commands. It’s a great pattern.
holmb•Mar 5, 2026
I would be very interested in this if you could share? Maintaining a Knowledge Base without a Git workflow is a pain currently.
sothatsit•Mar 5, 2026
I'm afraid I can't easily share this, as we have embedded a lot of company-specific information in our setup, particularly for cross-linking between confluence/jira/zendesk and other systems. I can try explain it though, and then Claude Code is great at implementing these simple CLI tools and writing the skills.
We wrote CLIs for Confluence, Jira, and Zendesk, with skills to match. We use a simple OAuth flow for users to login (e.g., they would run jira login). Then confluence/jira/zendesk each have REST APIs to query pages/issues/tickets and submit changes, which is what our CLIs would use. Claude Code was exceptional at finding the documentation for these and implementing them. Only took a couple days to set these up and Claude Code is now remarkably good at loading the skills and using the CLIs. We use the skills to embed a lot of domain-specific information about projects, organisation of pages, conventions, standard workflows, etc.
Being able to embed company-specific links between services has been remarkably useful. For example, we look for specific patterns in pages like AIT-553 or zd124132 and then can provide richer cross-links to Jira or Zendesk that help agents navigate between services. This has made agents really efficient at finding information, and it makes them much more likely to actually read from multiple systems. Before we made changes like this, they would often rabbit-hole only looking at confluence pages, or only looking at jira issues, even when there was a lot of very relevant information in other systems.
My favourite is the confluence integration though, as I like to record a lot of worklog-style information in there that I would previously write down as markdown files. It's nicer to have these in Confluence as then they are accessible no matter what repo I am working in, what region I am working in, or what branch or feature I'm working on. I've been meaning to try to set something similar up for my personal projects using the new Obsidian CLI.
graeme•Mar 5, 2026
Thank you! Sounds like a fantastic setup. Are the claude code agents acting autonomously from any trigger conditions or is this all manual work with them? And how do you manage write permissions for documents amongst team members/agents, presumably multiple people have access to this system?
(Not OP, but have been looking into setting up a system for a similar use case)
sothatsit•Mar 5, 2026
This is all manual, so people ask their agent to load Jira issues, edit Confluence pages, etc. Users sign-in using their own accounts using the CLIs, so the agents inherit their own permissions. Then we have the permissions in Claude Code setup so any write commands are in Ask, so it always prompts the user if it wants to run them.
holmb•Mar 5, 2026
Thanks for the insights!
We have been doing something similar but it sounds like you have come further along this way of working. We (with help from Claude) have built a similar tool that you describe to interface with our task- and project management system, and use it together with the Gitlab and Github CLI tools to allow agents to read tickets, formulate a plan and create solutions and create MR/PR to the relevant repos. For most of our knowledge base we use Markdown but some of it is tied up in Confluence, that's why I have an interest in that part. And, some is even in workflows are in Google Docs which makes the OP tool interesting as well -- currently our tool output Markdown and we just "paste from markdown" into Gdocs. We might be able to revise and improve that too.
Jagerbizzle•Mar 5, 2026
You can use the Copilot CLI with the atlassian mcp to super easily edit/create confluence pages. After having the agent complete a meaningful amount of work, I have it go create a confluence page documenting what has been done. Super useful.
reachableceo•Mar 5, 2026
Edit the markdown using GitHub workflow. Then insert markup (pick markdown) into the confluence page.
Yeah, we wrote our own CLIs for Jira/Confluence/Zendesk using their REST APIs instead. Works well, although a bit more work.
lewisjoe•Mar 5, 2026
Excellent project! I see that the agent modifies the google docs using an interesting technique: convert doc to html, AI operates over the HTML and then diff the original html with ai-modified html, send the diff as batchUpdate to gdocs.
IMO, this is a better approach than the one used by Anthropic docx editing skill.
1. Did you compare this one with other document editing agents? Did you have any other ideas on how to make AI see and make edits to documents?
2. What happens if the document is a big book? How do you manage context when loading big documents?
PS:I'm working on an AI agent for Zoho Writer(gdocs alternative) and I've landed on a similar html based approach. The difference is I ask the AI to use my minimal commands (addnode, replacenode, removenode) to operate over the HTML and convert them into ops.
This works pretty well for me.
hrmtst93837•Mar 5, 2026
> Disclaimer
> This is not an officially supported Google product.
Looked like an official Google Product on the first glance.
whizzter•Mar 5, 2026
Yeah that github name made my spider senses tingle, large scale credentials harvesting?
yenepho•Mar 5, 2026
Also the use of the google logo.
Edit: Oh, I think this actually is an official account. Very confusing
ivanjermakov•Mar 5, 2026
I'm still confused, @googleworkspace is not affiliated with Google?
I think an official project from Google would be hosted under https://github.com/google, a GitHub Org which contains 2,800 repositories and has more than 500 Google employees as member.
googleworkspace/cli appears to be more of a hobby project developed by a single Google employee.
jsnell•Mar 5, 2026
Most projects under the "google" org will have exactly the same disclaimer about not being official Google products.
hrmtst93837•Mar 5, 2026
But at least they are under the Google organization. Thing is anyone could create an organization, name it something like "googlesomething", use Google logos, and design it in a way that some users might believe it has an official connection.
abustamam•Mar 5, 2026
Couldn't Google do a cease and desist for that kind of impersonation?
hrmtst93837•Mar 5, 2026
I think so, but it could be enough for someone to create such an organization, share it on HN for malicious purposes, such as infecting devices, and have it taken down only afterward. I'm not saying that's what happened here, but it does illustrate a potential attack vector.
krzyk•Mar 5, 2026
Crazy.
And this project uses "google" in its org, so I would assume it is offical or at least lawyers are running toward the owner with lawsuits.
tuckerman•Mar 5, 2026
Google operates across so many verticals that it's difficult to argue a side project is outside the scope of Google’s business and therefore Google could argue it has copyright over the work. To make it easier for engineers to keep contributing to open source, there’s a fairly straightforward path to release code through a Google-owned repository (if you look at github.com/google it is full of personal projects alongside official ones).
There is an official process where an engineer can apply to a committee to have Google waive any copyright claim. That requires additional work so if your goal is simply to publish the code as open source and you do not mind it living under the Google org, using the Google repo path is usually much faster.
Disclaimer: ex-googler, not a lawyer, not arguing whether or not the situation with copyright assignment is legally enforceable or not/good or bad/etc.
qmarchi•Mar 5, 2026
Generally, this disclaimer is required for products that are released under the "Google" name but without any kind of support guarantees for enterprise customers.
That or it's a personal project that IARC decided could live in the workspace project.
Disc: Former Googler
bandrami•Mar 5, 2026
> but without any kind of support guarantees for enterprise customers
Also known as every single Google product
decimalenough•Mar 5, 2026
It's by Google, but it's open source and comes with no SLAs.
lloydatkinson•Mar 5, 2026
Google will wait for businesses to become very coupled to this and then kill off the CLI just because.
mansilladev•Mar 5, 2026
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
fs111•Mar 5, 2026
For the love of god, please google, give us personal access tokens and not this Oauth madness inside GCP. It is impossible to get that in any big enterprise.
javadhu•Mar 5, 2026
Nice, now I can use this alongside claude to auto document my research work.
Also, what I find fascinating is that the repo was initialized 3 days ago so it seems it's still a work in progress.
shanehoban•Mar 5, 2026
Feel like this should be at the top of the README - not the bottom
> Disclaimer
> Caution
> This is not an officially supported Google product.
lightningspirit•Mar 5, 2026
Yeah, I was surprised by that as well.
dnw•Mar 5, 2026
Schema Discovery Service is interesting but I have been wondering whether it is finally time to start implementing HATEOAS[0] in REST services.
This is effectively why people want agents, right? To be able to bypass all the stuff companies "optimize", ie. the ad-filled websites. The inserted extra conversations that now literally get triggered BECAUSE you're chatting to someone else. The ...
In other words: this is the FANGs worst enemy. This is adblock * 1000, as far as consumers are concerned.
moralestapia•Mar 5, 2026
`npm install ...`
I wonder why they didn't do this on Python or Ruby, them being the superior languages where `==` works, blah, blah ...
climike•Mar 5, 2026
Building www.cliwatch.com, so you can keep an eye on how agent-friendly your CLI is ;) feel free to request a benchmark against your CLI docs. Cheers
corby•Mar 5, 2026
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.
philipallstar•Mar 5, 2026
> This is not an officially supported Google product.
julianozen•Mar 5, 2026
Damn, so it won’t have the legendary Google promise of reliability and maintenance.
petercooper•Mar 5, 2026
Common for them. Even for projects on the main google GH org more often than not there'll be stuff like "not an official Google product" and "it is just code that happens to be owned by Google" in the README.
wg0•Mar 5, 2026
Seems to be built by using Claud code?
delduca•Mar 5, 2026
Good for AI agents.
d4rkp4ttern•Mar 5, 2026
Related, I often work with markdown docs (usually created via CLI agents like Claude Code) and need to collaborate with others in google docs, which is extremely markdown-unfriendly[1], so I built small quality-of-life CLI tools to convert Gdocs -> md and vice versa, called gdoc2md and md2gdoc:
They handle embedded images in both directions. There are similar gsheet2csv and csv2gsheet tools in the same repo.
Similar to the posted tool, there is a first time set up involving creating an app, that is documented above.
[1] in the sense there are multiple annoying clicks/steps to get a markdown doc to look good in Gdocs. You'd know the pain if you've tried it.
greymalik•Mar 5, 2026
Paste from markdown (Chrome only) works _really_ well for me. What are the extra steps you’re running into?
d4rkp4ttern•Mar 5, 2026
Interesting, in my Arc browser, I just tried File -> open -> upload -> blah.md and it does seem to render fine. This exact thing did not work a few weeks ago, meaning the various header markers etc showed up as raw "##" etc, and I had to further select something like "open as new doc" to finally make it look good.
z3ugma•Mar 5, 2026
Right click > "Paste from Markdown" instead of just straight up pasting in
d4rkp4ttern•Mar 5, 2026
Images wouldn't work though, right? I'd be amazed if that worked.
My CLI tools handle those.
chrisweekly•Mar 5, 2026
Obsidian has become almost an operating system for working with markdown. Its Live View / Edit mode is excellent (WYSIWYG) and its ability to accept pasted content and handle it appropriately is good and getting better. Its plugin/extension ecosystem is robust (and has a low barrier to entry), and now that it has a CLI I expect to see an acceleration of clever workflows and integrations.
No affiliation, just a very happy ~early adopter and daily user.
d4rkp4ttern•Mar 5, 2026
I’m intrigued by their recent CLI release as well. I’ll have to check out the markdown edit support too, thanks
Lord_Zero•Mar 5, 2026
BUT the main supported sync module is cloud only they wont let you self host for free which is really shitty and lame.
chrisweekly•Mar 5, 2026
Wow, that's a strong opinion and harsh words that come across as really entitled, and probably unfair. From my PoV, they're a tiny, scrappy, transparent and likeable company who built and maintain a fantastic software application that radically improved ~everything about my daily workflow and PKM. I get more value out of Obsidian in a day than most other apps in their entire lifespan. The core app is free! They have to eat. I'd probably throw $ at them even if they didn't charge a few bucks / month for Sync. (Which works flawlessly.) Sure it'd be cool if you could self-host their Sync module -- but many Obsidian users use other DIY approaches for sync; in the end it's markdown files on a local disk, do with it what you will.
ritzaco•Mar 5, 2026
interesting we have a very similar internal flow - we like working in markdown but our customers want to leave feedback in Google docs, so we also have an md -> gdoc tool. We don't do the reverse as we ask them to only leave comments/suggested changes and we apply those directly to the markdown and re-export.
I ran into similar issues as you for the image handling, and the work around I use is to use pandoc to convert to docx as a first step and then import that as a Google Doc using the API, as Google Docs seems to handle docx much better than markdown from what I've seen.
imglorp•Mar 5, 2026
It's funny because all these cloud services are suddenly motivated to have truly useful CLIs.
948382828528•Mar 5, 2026
What's the over/under on this being killed by Google within the next year?
udioron•Mar 5, 2026
What a shame Google Photos have no decent API or CLI. Photos could have been the best SAAS but changes in the API make it terribely unusable.
I wish I could use an API/CLI to query/geoquery my photos.
krzyk•Mar 5, 2026
Is Google Workspace some separate thing from well, normal Google?
I mean I have personal gmail,drive, keep, etc. Will it work there?
abustamam•Mar 5, 2026
It should, as long as you have access to Google cloud for Auth.
Looks like it is not available for @gmail.com accounts, because of that bug.
rot13maxi•Mar 5, 2026
The move to CLIs has been really interesting lately. They're easy for agents to use. They're composable with other shell tools. It's going to be interesting to see if mcp sticks around or if everything just moves to service specific CLIs.
The decision to pass all params as a JSON string to --params makes it unfriendly for humans to experiment with, although Claude Code managed to one-shot the right command for me, so I guess this is fine. This is an intentional design per https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...
76 Comments
> This is not an officially supported Google product.
jpoehnelt/README.md
About
I am a Developer Relations Engineer at Google. Currently I am on the Google Workspace DevRel team and was on the Google Maps Platform before that. Previously I worked at Descartes Labs and the US Geological Survey.
Check out my website at https://justin.poehnelt.com.
CharmCLI golang
Nushell rust
Warp. Shell
Were all around 2020 also that is when alt shells started getting popular probably for same reasons they still are.
But saying "it's for AI" is a corporate life hack for you to get permission to build said better tooling... =)
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...
Their Github releases provides the binaries, as well as a `curl ... | sh` install method and a guide to use github releases attestation which I liked.
npm suggests projects written in js, which is not something I'm comfortable.
It is nice to see that this is not JS, but Rust.
Bracing for getting cancelled
Also, this is a web project anyway. Google Workspace is web based, so while there is a good chance that the users aren't web developers, it's a better chance that they have npm than anything else.
In the case that they don't, releases can be downloaded directly too: https://github.com/googleworkspace/cli/releases
The install script checks the OS and Arch, and pulls the right Rust binary.
Then, they get upgrade mechanism out of the box too, and an uninstall mechanism.
NPM has become the de facto standard for installing any software these days, because it is present on every OS.
if you build for the web, no matter what your backend is (python, go, rust, java, c#), your frontend will almost certainly have some js, so likely you need npm.
That's the arbitrary code execution at install time aspect of npm that developers should be extra wary of in this day and age. Saner node package managers like pnpm ignore the build script and you have to explicitly approve it on a case-by-case basis.
That said, you can execute code with build.rs with cargo too. Cargo is just not a build artifact distribution mechanism.
Honestly I’m shocked to see so many people supporting this
That's not remotely true. If there is a standard (which I wouldn't say there is), it's either docker or curl|bash. Nobody is out there using npm to install packages except web devs, this is absolutely ridiculous on Google's part.
https://xcancel.com/github/status/2029277638934839605?s=20
It's crazy that people think strict typing is a chore. Says a lot about our society.
What?!? Must not be in any OS I've ever installed.
Now tar, on the other hand, exists even in windows.
(freebsd runs linux binaries and the openbsd people probably want to build from source anyways)
When I use apt-get, I have no idea what languages the packages were written in.
https://github.com/steipete/gogcli
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.
You need to rewrite your CLI for AI agents - https://news.ycombinator.com/item?id=47252459.
I think that's pretty cool so I put the post in the SCP (https://news.ycombinator.com/item?id=26998308).
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.
npm install -g @googleworkspace/cli
gws auth setup
{ "error": { "code": 400, "message": "gcloud CLI not found. Install it from https://cloud.google.com/sdk/docs/install", "reason": "validationError" } }
Which takes you to...
https://docs.cloud.google.com/sdk/docs/install-sdk
Where you have to download a tarball, extract it and run a shell script.
I mean how hard is it to just imitate everyone else out there and make it a straight up npm install?
The contributors are a Google DRE, 5 bots / automating services, and a dev in Canada.
1. A GCP project (needed for OAuth) 2. Enabled APIs in said project
I mean it's great that we get this, hopefully it can continue to be maintained and I'd love to see a push for similar stuff for other products and at other companies.
The CLI has abstracted that into one single reusable, scriptable command
i’d rather not waste the context tokens re implementing their cli from scratch, if indeed it does a good job.
- No need to worry about transport layer stuff at all, including auth or headers. This is baked in, so saves context.
- They are self describing with --help and then nested --help commands, way better than trying to decipher an OpenAPI spec. You usually don't even need an agent skill, just call the --help and the LLM figures it out.
Remember this repo is not an agent. It's just a cli tool to operate over gsuite documents that happens to have an MCP command and a bunch of skills prebundled.
That's a new one. I guess the hope is agents are good at navigating cli and it also democratizes the ecosystem to be used by any agent as opposed to Microsoft (which only allows Copilot to work in its ecosystem)
Probably someone's hobby project or 20% time at best.
> requires setting up gcloud cli first, necessitates making a Google Cloud project
cmon google how come even your attempts at good ux start out with bad ux? let me just oauth with my regular google account like every other cli tool out there. gh cli, claude, codex - all are a simple “click ok” in the browser to log in. wtf.
and the slow setup - i need to make my own oauth app & keys??
EDIT: oh yeah and get my oath app verified all so i can use it with my own account
Multiple errors and issues along the way, now I'm on `gws auth login`, and trying to pick the oAuth scopes. I go ahead and trust their defaults and select `recommended`, only to get a warning that this is too many scopes and may error out (then why is this the recommended setting??), and then yeah, it errors out when trying to authenticate in the browser.
The error tells me I need to verify my app, so I go to the app settings in my cloud console and try to verify and there's no streamlined way to do this. It seems the intended approach is for me to manually add, one by one, each of the 85 scopes that are on the "recommended" list, and then go through the actual verification.
Have the people that built and released this actually tried to install and run this, just a single time, purely following their own happy path?
It’s a very different experience than AWS though and takes some getting used to.
It wild that this process is still so challenging. There's got to be some safe streamlined way that sets up an app identity you own that can only use to access your own account.
My guess is that organizationally within Google, the developer app authorization process must have many teams involved in its implementation and many other outside stakeholders. A single unified team wouldn't responsible for this confusion and complexity. I get why... it's a huge source of bad actors. But there's got to be a better way.
Google Workspace API(s) keys and Roles was always confusing to me at so many levels .. and they just seem to keeping topping that confusion, no one is addressing the core (honestly not sure if that is even possible at this point)
getting the authentication to work is a real pain and it's basically preventing people access to an otherwise really good and useful MCP
Imagine a marketing person trying to set it up...
Clever, but frustrating that they don’t bother to provide any docs on the actual commands this supports.
[1] https://github.com/benkaiser/joey-mcp-client
# API Keys in Settings
1. Go to Settings -> API Keys Page
2. Create Token (set scope and expiration date)
# OAuth flow
1. `gws login` shows url to visit
2. Login with Google profile & select data you want to share
3. Redirect to localhost page confirms authentication
I get that I need to configure Project and OAuth screens if I want to develop an Applications for other users, that uses GCP services. This is fine. But I am trying to access my own data over a (/another) HTTP API. This should not be hard.
Google have over a billion very non-technical users.
The friction of not having this in the account page that everyone has access too probably saves both parties lots of heartbreak.
For google I need PhD to setup any kind of API access to my own data. And it frequently blocks you, because you can setup as a test product, add test accounts (but it can't be owner account (WTF?)) etc.
I gave up on using a google calendar cli project because of all that lack of normal UX.
UX for google APIs looks like it was designed by accountant.
gws auth setup looks promising, but it won't work yet for personal accounts.
We’re trying to create a single unified cli to every service on the planet, and make sure that everything can be set up with 3 clicks
Google's Gemini can read Google Docs directly.
They really don't want you to use another LLM product.
So they make the setup as difficult as possible.
(all pass through)
https://news.ycombinator.com/item?id=47157398
IMHO, CLI tools are better more often than not against MCP.
EDIT: and here is similar opinion from author himself: https://news.ycombinator.com/item?id=47252459
https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...
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?
I consider it a good first attempt, but indeed hope for a sort of mcp2.0
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.
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).
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.
[1] https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...
I did a few CLIs with codex in the last few weeks. I do simple ops with this stuff. I've had a few use cases for new features where previously I would have had to build some kind of quick and dirty admin UI just to use and test a new API feature before being able to integrate it into our product. With a generated cli, I can just play with it from the command line. Or make codex do that for me.
A good cli with a modern command line argument parser, well documented options, bash/zsh auto complete, pretty colors, etc. is generally nice to have. I mapped resources to commands and sub commands, made it add parameters with sensible defaults or optional ones. Then I got lazy and just asked it what else it thought it was missing, it made some suggestions and I gave it the thumbs up and it all got added. I even generated a simple interactive TUI at some point. Because why not? I also made it generate a md skill file explaining how to use the cli that you can just drop in your skills directory.
This CLI dynamically generates itself at run time though
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
You're not exactly describing rocket science. This is basically how websites work, there's never been anything stopping anyone from doing dynamic UI in TUIs except the fact that TUI frameworks were dog poop until a few years ago (and there was no Windows Terminal, so no Windows support). Try doing that in ncurses instead of Rataui or whatever, it's horrendous
It provides a git like pull/push workflow to edit sheets/docs/slides. `pull` converts the google file into a local folder with agent friendly files. For example, a google sheet becomes a folder with a .tsv, a formula.json and so on. The agent simply edits these files and `push`es the changes. Similarly, a google doc becomes an XML file that is pure content. The agent edits it and calls push - the tool figures out the right batchUpdate API calls to bring the document in sync.
None of the existing tools allow you to edit documents. Invoking batchUpdate directly is error prone and token inefficient. Extrasuite solves these issues.
In addition, Extrasuite also uses a unique service token that is 1:1 mapped to the user. This means that edits show up as "Alice's agent" in google drive version history. This is secure - agents can only access the specific files or folders you explicitly share with the agent.
This is still very much alpha - but we have been using this internally for our 100 member team. Google sheets, docs, forms and app scripts work great - all using the same pull/push metaphor. Google slides needs some work.
We wrote CLIs for Confluence, Jira, and Zendesk, with skills to match. We use a simple OAuth flow for users to login (e.g., they would run jira login). Then confluence/jira/zendesk each have REST APIs to query pages/issues/tickets and submit changes, which is what our CLIs would use. Claude Code was exceptional at finding the documentation for these and implementing them. Only took a couple days to set these up and Claude Code is now remarkably good at loading the skills and using the CLIs. We use the skills to embed a lot of domain-specific information about projects, organisation of pages, conventions, standard workflows, etc.
Being able to embed company-specific links between services has been remarkably useful. For example, we look for specific patterns in pages like AIT-553 or zd124132 and then can provide richer cross-links to Jira or Zendesk that help agents navigate between services. This has made agents really efficient at finding information, and it makes them much more likely to actually read from multiple systems. Before we made changes like this, they would often rabbit-hole only looking at confluence pages, or only looking at jira issues, even when there was a lot of very relevant information in other systems.
My favourite is the confluence integration though, as I like to record a lot of worklog-style information in there that I would previously write down as markdown files. It's nicer to have these in Confluence as then they are accessible no matter what repo I am working in, what region I am working in, or what branch or feature I'm working on. I've been meaning to try to set something similar up for my personal projects using the new Obsidian CLI.
(Not OP, but have been looking into setting up a system for a similar use case)
We have been doing something similar but it sounds like you have come further along this way of working. We (with help from Claude) have built a similar tool that you describe to interface with our task- and project management system, and use it together with the Gitlab and Github CLI tools to allow agents to read tickets, formulate a plan and create solutions and create MR/PR to the relevant repos. For most of our knowledge base we use Markdown but some of it is tied up in Confluence, that's why I have an interest in that part. And, some is even in workflows are in Google Docs which makes the OP tool interesting as well -- currently our tool output Markdown and we just "paste from markdown" into Gdocs. We might be able to revise and improve that too.
Works wonderfully!
IMO, this is a better approach than the one used by Anthropic docx editing skill.
1. Did you compare this one with other document editing agents? Did you have any other ideas on how to make AI see and make edits to documents?
2. What happens if the document is a big book? How do you manage context when loading big documents?
PS:I'm working on an AI agent for Zoho Writer(gdocs alternative) and I've landed on a similar html based approach. The difference is I ask the AI to use my minimal commands (addnode, replacenode, removenode) to operate over the HTML and convert them into ops.
This works pretty well for me.
> This is not an officially supported Google product.
Looked like an official Google Product on the first glance.
Edit: Oh, I think this actually is an official account. Very confusing
Seems like it was made by Google employee: https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...
googleworkspace/cli appears to be more of a hobby project developed by a single Google employee.
And this project uses "google" in its org, so I would assume it is offical or at least lawyers are running toward the owner with lawsuits.
There is an official process where an engineer can apply to a committee to have Google waive any copyright claim. That requires additional work so if your goal is simply to publish the code as open source and you do not mind it living under the Google org, using the Google repo path is usually much faster.
Disclaimer: ex-googler, not a lawyer, not arguing whether or not the situation with copyright assignment is legally enforceable or not/good or bad/etc.
That or it's a personal project that IARC decided could live in the workspace project.
Disc: Former Googler
Also known as every single Google product
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
Also, what I find fascinating is that the repo was initialized 3 days ago so it seems it's still a work in progress.
> Disclaimer
> Caution
> This is not an officially supported Google product.
[0] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
In other words: this is the FANGs worst enemy. This is adblock * 1000, as far as consumers are concerned.
I wonder why they didn't do this on Python or Ruby, them being the superior languages where `==` works, blah, blah ...
https://pchalasani.github.io/claude-code-tools/integrations/...
They handle embedded images in both directions. There are similar gsheet2csv and csv2gsheet tools in the same repo.
Similar to the posted tool, there is a first time set up involving creating an app, that is documented above.
[1] in the sense there are multiple annoying clicks/steps to get a markdown doc to look good in Gdocs. You'd know the pain if you've tried it.
No affiliation, just a very happy ~early adopter and daily user.
I ran into similar issues as you for the image handling, and the work around I use is to use pandoc to convert to docx as a first step and then import that as a Google Doc using the API, as Google Docs seems to handle docx much better than markdown from what I've seen.
I wish I could use an API/CLI to query/geoquery my photos.
I mean I have personal gmail,drive, keep, etc. Will it work there?
https://workspace.google.com/
Google Workspace is their corporate offering (think Microsoft suite competitor)
Looks like it is not available for @gmail.com accounts, because of that bug.
Sounds handy. But use at your own risk.
checks https://github.com/googleworkspace/cli/tags
v0.1.1 2 days ago
v0.2.2 yesterday
v0.3.3 18 hours ago
v0.4.2 9 hours ago
v0.5.0 8 minutes ago
Interesting times we live in..
The decision to pass all params as a JSON string to --params makes it unfriendly for humans to experiment with, although Claude Code managed to one-shot the right command for me, so I guess this is fine. This is an intentional design per https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...