Live data from Hacker News

Google Workspace CLI

github.com

181–190 of 316 posts

Re: Google Workspace CLI

#181
post #45

Earlier quoted context omitted.

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.

Can you link to a sample of how I can do this?

https://axodotdev.github.io/cargo-dist/

Re: Google Workspace CLI

#182

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?

It's built for agents first, unfortunately.

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

Re: Google Workspace CLI

#183
post #2

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

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.

[flagged]

Re: Google Workspace CLI

#184
post #175

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

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

Re: Google Workspace CLI

#186

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.

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

Re: Google Workspace CLI

#188
post #175

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

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.

Re: Google Workspace CLI

#189
post #175

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

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)

Re: Google Workspace CLI

#190
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.
Post reply on HN