Google Workspace CLI
github.com

・

547 points

・

gonzalovargas

・

9 hours ago

205 comments

ksri ・ 42 minutes ago

I have been working on extrasuite (https://github.com/think41/extrasuite). This is like terraform, but for google drive files.

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.

jillesvangurp ・ an hour ago

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 ・ 41 minutes ago

    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

mansilladev ・ 17 minutes 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

hrmtst93837 ・ 42 minutes ago

> Disclaimer

> This is not an officially supported Google product.

Looked like an official Google Product on the first glance.

  • ivanjermakov ・ 36 minutes ago

    Readme was written before project got grabbed into official GitHub account?

    I'm still confused, @googleworkspace is not affiliated with Google?

    Seems like it was made by Google employee: https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...

    • hrmtst93837 ・ 15 minutes ago

      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.

  • whizzter ・ 39 minutes ago

    Yeah that github name made my spider senses tingle, large scale credentials harvesting?

    • yenepho ・ 35 minutes ago

      Also the use of the google logo.

      Edit: Oh, I think this actually is an official account. Very confusing

tclancy ・ 6 hours ago

Interesting post from the main contributor about this (at least I assume it’s what he’s referencing) https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...

  • winwang ・ 6 hours ago

    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 ・ 4 hours ago

    Looks like I am hitting some Cloudflare Block when accessing this URL

mogili1 ・ 3 hours ago

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.

  • heinrichhartman ・ an hour ago

    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 ・ 43 minutes ago

      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.

  • fermisea ・ an hour ago

    https://www.supyagent.com

    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

  • justinwp ・ 2 hours ago

    Yeah, still no way around this unfortunately.

fergie ・ 2 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?

  • dahcryn ・ 2 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 ・ an hour 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)

  • jtrn ・ an hour 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.

  • allan_s ・ an hour 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).

virgildotcodes ・ 5 hours ago

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?

  • varenc ・ 5 hours ago

    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.

    • 38 ・ 3 hours ago

      [dead]

  • m8s ・ 5 hours ago

    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 ・ 5 hours ago

      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.

  • SamDc73 ・ 5 hours ago

    I find https://github.com/steipete/gogcli a bit easier (but still confusing to setup)

    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)

    • 38 ・ 3 hours ago

      [dead]

  • justinwp ・ 2 hours ago

    There are many gotchas in this process and unfortunately there is no easy way to deal with the OAuth setup.

  • jitl ・ 5 hours ago

    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.

  • sagarpatil ・ 2 hours ago

    I used Claude in chrome and Claude Code. It did everything for me.

benjaminwootton ・ an hour 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.

betaby ・ 7 hours ago

I'm curious why `npm` is used to install a `rust` binary?

  • varenc ・ 7 hours ago

    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.

    • bigstrat2003 ・ 5 hours ago

      Most people aren't going to have npm installed though. Nobody outside of web devs uses it.

      • patates ・ 2 hours ago

        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.

        In the case that they don't, releases can be downloaded directly too: https://github.com/googleworkspace/cli/releases

      • sankalpmukim ・ 4 hours ago

        "Most people" are webdevs

        Bracing for getting cancelled

      • gempir ・ 2 hours ago

        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.

    • freakynit ・ 6 hours ago

      Why not just downloadable binary then?

      • varenc ・ 6 hours ago
        ・ 2 more

        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 ・ 5 hours ago

          Hmm, that's right... thanks..

  • cobbal ・ 6 hours ago

    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 ・ 6 hours ago

      Doesn’t this seem excessive over just using rust’s cross platform builds?

      • csomar ・ 5 hours ago
        ・ 2 more

        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 ・ 4 hours ago

          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)

  • r2champloo ・ 5 hours ago

    Interesting fact, because cargo builds every tool it downloads from source, you can’t actually run cargo install on Google laptops internally.

    • efreak ・ 30 minutes ago

      I use cargo-binstall, which supports quick install and a couple other methodsfor downloading binaries for rust packages

  • jamesmishra ・ 6 hours ago

    Why should the package's original language matter?

    When I use apt-get, I have no idea what languages the packages were written in.

    • hahn-kev ・ 4 hours ago

      Because npm is not an os package manager, it's a nodejs package manager

    • nazgul17 ・ 3 hours ago

      Not everyone has or wants yet another package manager in their system.

  • brunoborges ・ 7 hours ago

    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 ・ 6 hours ago

      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 ・ 6 hours ago
        ・ 10 more

        No package manager is. But of the ones that are installed by users, npm is probably the most popular.

        • spinagon ・ 6 hours ago
          ・ 7 more

          What about pip? It's either installed or immediately available on many OSes

          • Fabricio20 ・ 4 hours ago

            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.

          • jitl ・ 6 hours ago

            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.

          • piperswe ・ 6 hours ago

            `pip install` either doesn’t work out of the box or has the chance to clobber system files though

          • nikanj ・ 6 hours ago
            ・ 3 more

            This is about eight years old. The python situation has mostly gotten worse since https://xkcd.com/1987/

            • jitl ・ 4 hours ago

              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.

            • a_t48 ・ 4 hours ago

              What? It’s much much better now, you can just use uv. Yeah, it’s yet another package manager, but it does it well.

    • oefrha ・ 6 hours ago

      > 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.

    • mcmcmc ・ 3 hours ago

      More of a de facto standard for supply chain attacks tbh

    • mountainriver ・ 6 hours ago

      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

    • koakuma-chan ・ 4 hours ago

      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 ・ 2 hours ago

        Not because it's fast, but because of its compiler. It acts as a very good guardrail and feedback mechanism for LLMs.

    • bigstrat2003 ・ 5 hours ago

      > 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 ・ 4 hours ago

        they offer npm for the large market of cli users who have it, and curl|bash to those who don’t. ¯\_(ツ)_/¯

    • xarope ・ 4 hours ago

      "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.

arjie ・ an hour ago

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.

internet2000 ・ 6 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 ・ 4 hours ago

    Can you tell it to write to /tmp/s.py instead of trying to execute it inline?

  • flakiness ・ 4 hours ago

    You should use Gemini obviously </s>

    • gck1 ・ 2 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.

avaer ・ 7 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 ・ 6 hours ago

    I think it is unrelated.

pimlottc ・ 4 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.

benkaiser ・ 4 hours ago

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.

[1] https://github.com/benkaiser/joey-mcp-client

iosjunkie ・ 7 hours ago

Basically Google’s take on GAM https://github.com/GAM-team/GAM

  • pimlottc ・ 4 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 ・ 6 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 ・ 6 hours ago

      This - gog - yes. But I think it is different than GAM which is an admin tool. reply

  • hrimfaxi ・ 7 hours ago

    It's about time. Reminds me of how even Apple uses Jamf.

  • conception ・ 5 hours ago

    Except GAM is already heavily in training data and less likely to be called incorrectly.

tgma ・ 5 hours ago

"This is not an officially supported Google product."

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

swaminarayan ・ 2 hours ago

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?

sbinnee ・ 7 hours ago

I can already see all the CTOs are getting excited to plug this in their OpenClaw instances.

  • sanex ・ 7 hours ago

    Depends how it compares to gog.

    • electriclove ・ 4 hours ago

      Work fine as a gog replacement for my limited use cases of reading and writing Sheets.

epicprogrammer ・ 6 hours ago

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?

lewisjoe ・ 6 hours ago

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)

_wizard ・ 3 hours ago

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.

sega_sai ・ 7 hours ago

Interesting, but scary, given that this is not a google product. Who knows whether that breaks any TOS somehow.

  • spankalee ・ 7 hours ago

    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 ・ an hour ago

      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.

  • jryio ・ 7 hours ago

    This appears to be published by Google itself

lloydatkinson ・ 25 minutes ago

Google will wait for businesses to become very coupled to this and then kill off the CLI just because.

outlore ・ 5 hours ago

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

cyrusradfar ・ 6 hours ago

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.

mace01 ・ 6 hours ago

Seems weird to require another tool (gcloud) to set it up, but it does look to be tightly integrated with google cloud.

  • justinwp ・ 2 hours ago

    You can skip that setup if you already have the OAuth credentials.

wonderfuly ・ 6 hours ago

Why cli instead of just HTTP API doc? The agent can use curl or write code to send requests.

  • mindwok ・ 5 hours ago

    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.

  • hedora ・ 6 hours ago

    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 ・ 6 hours ago

      Why is it more reliable? The human usage point is fair, but I doubt how long it is still necesary.

  • boberoni ・ 6 hours ago

    A CLI runs on the client, so they can embed client-side functionality like telemetry or caching.

  • jitl ・ 5 hours ago

    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.

skybrian ・ 7 hours ago

Having the available commands change on you dynamically seems like an anti-pattern, but I suppose an AI can deal with it.

mmaunder ・ 6 hours ago

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.

larodi ・ 3 hours ago

Would it help to backup all my mailboxes and be ready to ditch gmail?

shivam310 ・ 3 hours ago

I'm surprised that this didn't officially exist before.

loveparade ・ 7 hours ago

Great, i hope this becomes a trend now that agent skills want clis

arthurcolle ・ 3 hours ago

My agents will follow this repo with great interest

hsaliak ・ 7 hours ago

GCP Next is Apr 22-24. Hope this continues to live afer that.

mmaunder ・ 6 hours ago

Google really know how to screw up a product experience.

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?

  • ceroxylon ・ 6 hours ago

    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.

  • justinwp ・ 2 hours ago

    You don't need to use gcloud if you already have:

    1. A GCP project (needed for OAuth) 2. Enabled APIs in said project

  • jitl ・ 5 hours ago

    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

gbrindisi ・ an hour ago

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.

jitl ・ 5 hours ago

> 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

sciencesama ・ 6 hours ago

Would be useful if it can atleast show google drive storage in folder structure

yakkomajuri ・ 6 hours ago

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.

tedk-42 ・ 7 hours ago

Haha in the world of AI/MCPs, all of a sudden we have a push for companies to properly build out APIs/CLI tools.

  • spullara ・ 6 hours ago

    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 ・ 6 hours ago

      Perhaps we will finally emerge from this decades-long dark age of bloated, do-everything GUI development tools being the fashionable happy path.

      • techpression ・ 5 hours ago

        The AWS cli tool wants to have a talk… hard to find a more bloated mess of strung together scripts held together by tape.

  • sh3rl0ck ・ 7 hours ago

    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 ・ 5 hours ago

      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.

  • vishnugupta ・ 5 hours ago

    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.

  • 22c ・ 5 hours ago

    I noted something similar a few weeks ago. Companies are finally putting APIs in front of things that should have had APIs for years!

  • dack ・ 7 hours ago

    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!

  • BarryMilo ・ 7 hours ago

    Took them this long to realize MCPs are just worse APIs.

  • forrestthewoods ・ 6 hours ago

    About 90% of “make codebase better for LLMs” is just good old fashioned better engineering that is also good for humans.

  • benatkin ・ 6 hours ago

    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.

pdyc ・ 6 hours ago

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.

evanjrowley ・ 7 hours ago

Hoping Apple will do the same with iCloud.

  • wepple ・ 7 hours ago

    Don’t hold your breath

  • paxys ・ 7 hours ago

    Lol

ernsheong ・ 2 hours ago

Archived in 3… 2… 1…

blondin ・ 7 hours ago

This is a very interesting way of building agent skills. Seems like the imperative way of orchestration/automation is making a comeback.

mosajjal ・ 5 hours ago

AI Agents are becoming first-class citizens for SaaS

sjeiuhvdiidi ・ 2 hours ago

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.

bpiroman ・ 4 hours ago

written in Rust lol

  • zenlot ・ 2 hours ago

    [dead]

shubhamintech ・ 6 hours ago

[flagged]

  • nozzlegear ・ 5 hours ago

    Is this comment AI generated? I don't like to accuse people of generating comments, but looking at your comment history, almost all of them fit this pattern of a single paragraph with "LLM-isms", this one included (i.e. "the X angle here is real -").

    • steve_adams_86 ・ 4 hours ago

      I've been noticing this a lot more often here. And everywhere. I'd like it if I could flag accounts as definitely or likely AI so I don't bother parsing them out over and over.

      I guess I could build a browser extension to allow for that easily enough.

    • doctoboggan ・ 4 hours ago

      Yes, it most likely is. Click on the "x hours ago" and then flag the comment. That's the best way I've found to deal with these.

    • GCUMstlyHarmls ・ 4 hours ago

      Whats the point of all that? I guess at some point you hope to amass enough "quality" accounts to sway opinion on products? It makes more direct sense on Facebook et al or Reddit, but I guess on HN you're doing the same thing.

      Botting HN is probably actually more effective as the audience is smaller, probably by several magnitudes? So 20 pro-product comments in a thread is more likely to hit an investors eyeball?

    • throwaway_08932 ・ 5 hours ago

      I find this form you're commenting on less annoying than people starting posts with "this." What a stupid way to say "I agree."

      • AdieuToLogic ・ 4 hours ago

        > I find this form you're commenting on less annoying than people starting posts with "this." What a stupid way to say "I agree."

        This.

        :-p

    • cubefox ・ 4 hours ago

      Yeah, those other comments also have an AI vibe. The LLM bots are getting better.

    • gjs278 ・ 5 hours ago

      [dead]

  • nerdix ・ 5 hours ago

    What gave you the impression that this was related to AI?

    Was it the 100+ Agent Skills?

    The Gemini CLI extension?

    Or the bundled MCP server?

  • anabis ・ 5 hours ago

    I'm hoping Facebook will bring back API to access Groups. My family Photo is in it. I feeling trepidation because they failed to acquhire OpenClaw's author.

  • voidhorse ・ 6 hours ago

    Totally. I was just remarking today how funny it is that it was apparently ok for humans to suffer from a dearth if documentation for years, but suddenly, once the machines need it, everyone is frantic to make their tools as usable and well-documented as possible

    • overfeed ・ 5 hours ago

      > everyone is frantic to make their tools as usable and well-documented as possible

      Eh, enjoy it while it lasts. Companies are still trying to figure out how to get value by letting a thousand flowers blossom. The walled-garden gates will swing shut soon enough, just like they did after the last open access revolutions (semantic web, Web 2.0, etcetera)

      • citizenpaul ・ 5 hours ago
        ・ 2 more

        I two am wondering exactly what form slamming the gates shut in our face will take. Closing the first hit is free train And opening the doors to pay me, $#%&

        • CamperBob2 ・ 4 hours ago

          I two am wondering exactly what form slamming the gates shut in our face will take.

          "You will rent only the best PCs, eat only the tastiest bugs, and live in the 15-minute City of Tomorrow (also known as New Kowloon). And you will like it. Or else."

  • nikanj ・ 6 hours ago

    Well, mostly because you can now task an LLM with writing the docs.

    • notpushkin ・ 5 hours ago

      You also have to expose the API in the first place.

      • jaxn ・ 4 hours ago

        the LLM writes that too

  • hoppp ・ 5 hours ago

    Google will slowly win at the AI game. They got everything going, lots of free usage and they are keeping it real, unlike openAI that rides a hype train

    • jitl ・ 5 hours ago

      yeah just like they’ve slowly won at cloud over AWS and Azure. oh wait

      • eitally ・ 4 hours ago

        They are. I don't know why you think you're making that statement sarcastically. GCP started late and from a much smaller base, but has been growing consistently faster than both of their competitors. Moreover, AWS has recently almost completely leveled off and is losing customers, most of whom are moving to GCP because of the AI leadership/differentiation.

        AWS is the IBM of clouds. You won't get fired for choosing it, but you also know you're just getting a plain vanilla set of services, too, that usually cost more than colo or on-prem. Without any meaningful first party AI investments (this goes for MSFT, too), Google is the only one stop shop.

      • candiddevmike ・ 5 hours ago
        ・ 2 more

        I mean, they are? GCP usage/revenue is growing faster than AWS and Azure. Mostly driven by Gemini pushing folks onto the platform and them deciding "why not move everything else too".

        • manbash ・ 4 hours ago

          Wait, I am curious how Gemini "pushes" devs to GCP.

      • SV_BubbleTime ・ 5 hours ago

        Remember that time they used their network effects to auto-enroll all Gmail users into their Facebook competitor and instantly won?

    • jen20 ・ 5 hours ago

      They're going to have to significantly up their game - IIUC, you can't use a Gemini subscription with OpenCode anymore, and the Gemini CLI is such utter trash that it's unusable (it doesn't even have a plan mode in the preview releases, and can barely maintain a connection to a server).

  • notpushkin ・ 5 hours ago

    This. I’ve been genuinely excited about MCP from the start mostly because you can use it by hand, too.