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.

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

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

Thanks! Looks like he submitted it here, judging by the username:

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

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.

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

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

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.

Yeah, still no way around this unfortunately.

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.

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

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)

had the same frustration trying to set up Google analytics MCP server: https://github.com/googleanalytics/google-analytics-mcp

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

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

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

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.

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.

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.

Why should the package's original language matter?

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

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.

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

It's built for agents first, unfortunately.

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

I'm just not going to give agents access to my workspace account!

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

You should use Gemini obviously </s>

I think it is unrelated.

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…

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

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

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

Depends how it compares to gog.

https://news.ycombinator.com/item?id=47208398

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

Yet somehow Microsoft Copilot doesn't know how to use that tooling.

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.

This appears to be published by Google itself

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

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.

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.

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

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.

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.

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

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

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

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.

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

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.

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

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!

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

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

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.

Don’t hold your breath

Lol