[flagged]
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...
Google Workspace CLI
201–210 of 316 posts
Re: Google Workspace CLI
#202Re: Google Workspace CLI
#203I'm curious why `npm` is used to install a `rust` binary?
Interesting fact, because cargo builds every tool it downloads from source, you can’t actually run cargo install on Google laptops internally.
I use cargo-binstall, which supports quick install and a couple other methodsfor downloading binaries for rust packages
Re: Google Workspace CLI
#204Google will wait for businesses to become very coupled to this and then kill off the CLI just because.
Re: Google Workspace CLI
#205I 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
Re: Google Workspace CLI
#206Re: Google Workspace CLI
#207[flagged]
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
Re: Google Workspace CLI
#208Generating 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 throu…
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
> 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
Re: Google Workspace CLI
#209Earlier quoted context omitted.
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
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)
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.
Re: Google Workspace CLI
#210Earlier quoted context omitted.
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.
Why is it more reliable? The human usage point is fair, but I doubt how long it is still necesary.
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