Hacker News Reader

Comment by 0x696C6961 | Hacker News Reader

Even if your agent has internet access, why waste tokens having it re-discover and re-implement its own API client each time? It doesn't make any sense.

View on HN

For me, I have a service that has multiple vectors of what would be called an API - PowerShell Modules, WMI, RESTFUL Web Services, some are available, some can do some things, some are more direct, some are not allowed with enterprise security etc.

Either way, I don't do what you suggest. I have self-learning rules and have the models build a well-rounded API engine once, then re-use it with query scripts through skills. Its portable and flexible in many environments.

No one is saying to wrap your local power shell modules in an MCP. That would be pointless and stupid.

This is my favorite position, the advantage of an MCP tends to lie more in token optimization.

In what way?

Not sure whats the norm nowadays, but it used to be MCP descriptions were loaded in from the start.

In any case, to be cheaper the `cli --help` command needs to more noisy than the json description.

Finally, and the really big one: cli can be composed with `grep`, `jq` , etc.

On the contrary, you burn more tokens with MCP.

This is not true.

I guess it depends on the implementations.

When I use the Atlassian CLI vs their MCP server, I tend to see something like half the token burn with the CLI with more accurate results.

That could be an Atlassian issue but that's the results I'm seeing.

yeah MCP contains a provision for some blocktext for instructions. If your MCP has walls of text in those instructions, it will burn more tokens that a terse MCP.

How do you think the LLM becomes aware of which mcps are available? Vibes?

It depends on the harness. But most use a tool_search tool.

yes and using that tool does what with tokens?

You seem confused.

I'm not. You can build an MCP and throw a ton of junk in there and bloat the shit out of its token cost. So, really, "it depends".

> re-implement its own API client each time

Is using curl considered re-implementing your own api client each time?

Making the model use curl is even stupider. It still needs to do the same amount of work to lookup and understand the API contracts (assuming those are even public). But now it also needs to juggle the auth flows and marshalling at the tool call level.

You said ""re-implements an API client" which means you either don't know what curl is or don't know what an api client is. So I'd chill on calling things "stupider" when you don't have a strong grasp on the words you're using.

What is "implementing".... I'd define it as "figuring out the workflow, and storing it in a way that allows reuse". This could be a program written in assembly, or rust, or even python. Or it could be a shell script that calls curl. Or it could just be a set of tokens in the current session. Outside of the computer it could even be a set of processes people do, or a mechanical device.

If it's just a set of tokens in the current session, well then next session it has to figure out the workflow, and then store it in a way to use in the next session.

Seems like maybe you should take your own advice.

How does the definition of "implementing" change the fact that curl quite literally is an api client? It's an implemented api client.

> Seems like maybe you should take your own advice.

Seems like maybe if you have to use your own custom definition of a word in order to support a point you might not have one. lol.

Nonsense, curl is a tool for executing a single http request.

Many apis require several requests to get things done. (one to auth, one or more to fecth resource ids, one or more to modify resources, etc).

That would be a series of curl calls with logic applied to the output of each call to curl. An api client just does those things in a single function call. The steps are the same, but in one case the AI has to figure out each curl call and implement the logic, rather than just call the function.

lol Id say the nonsense is tying multiple calls to the definition of an api client.

Irony died in this comment thread.

By your logic 'ls' is a file manager, 'grep' is a search engine, and 'echo $X >> /proc/sys/$Y' is a settings manager.

It makes sense though. It's the same logic that allows you to say promting an AI with "do a simple thing for me" makes you a programmer, and prompting an AI with "what is an api" allows makes you knowledgable about computers.

In your mind, is netcat also an API client? When normal people talk about api clients, they're referring to an sdk or a cli which provides a simpler interface for a specific API.

You're not implying netcat and curl are synonymous are you?

And When "normal" people talk about api clients? lol This site is wild.

Alright dude ... Either you have major comprehension issues or you're arguing in bad faith. But I'm done responding to you.

Did you know that computer programs, once written, can be stored to disk once and run many times?

Sure, but if you have a staff of 10000, you're doing this 10000 times. Unless you share that in a common place, and now you're re-inventing the thing we're claiming not to need.

I love the level of sassiness this debate brings forward in people

People like you can't seem to comprehend that there are use-cases other than your little local claude code workflow.

Reply on news.ycombinator.com