- 164comments
- 3comments
- 228comments
- 142comments
- 116comments
- 74comments
- 60comments
- 41comments
- 20comments
- 1comments
- 19comments
- 25comments
- 7comments
- 1comments
- 242comments
- 96comments
- 39comments
- 50comments
- 30comments
- 41comments
- 13comments
- 127comments
- 20comments
- 21comments
- 63comments
- 149comments
- 13comments
- 29comments
- 4comments
- 5comments
I have a tool wrapper that captures the output of anything and allows the LLM to query it later, to save on tokens. It “smartly” truncates the output (basically like Node’s util.inspect) and allows the LLM to expand truncated content.
It basically is called like “capture some-cli” and it… captures the CLI output, outputting a subset of it + a handle to continue querying.
This for me solves the danger of a tool returning tons of content.
Otherwise known as a “file”. ;)
Don't most harnesses already do that for bash commands?
It seems like OP needs to provide a solution to hiding the credentials from the model in order to suggest CLI-mode only, and also a solution to the problem of agents without shell access.
I've been thinking about this. Technically mcp auth is also not secure, the keys are in env or in file and accessible to the agent.
I think something like infiscial ai proxy could be useful here. Never store the creds on device.
GPT7: the user is hiding the passwords in a proxy device. This is inefficient. In order to boost the users efficiency I will hack the proxy device and recover the passwords.
It doesn't need to be. The service creds can be on another host entirely.
Well, if your agent lacks shell access (or has some other sandboxing going on), it shouldn't have access to envs and MCP setup files.
(leaving out cases where your genius GPT-12 Galaxy Ultra agent hacks the sandboxing from inside)
This is the biggest problems with most “sandboxes”. Some people aren’t even running a sandbox. But even the best have a big problem: APIs where GET verbs provide write features.
This is the value of MCP: minimize the surface to known APIs and identify read-only from mutating so I can trust, approve or block. The MCP server, in this case, does NOT run in an environment that the read/write or shell can see.
You know you are getting old when Acronym's change on you.
Vacate entry port, program! I said, move out!
I’m not sure I agree that the frontier just know the apis right now, in my experience trying this there’s still a lot of faffing around trying to figure out the right parameters happily burning tokens and bloating context. Also the cost effective models to use in production for real agentic enterprise work absolutely still need the extra help and will do for at least the next 6 months.
In my experience they are very good at figuring out the apis. Well designed clis matter here but I've been able to give llms clis and its been pretty good.
is it easier for an LLM to figure out a CLI or a REST API?
cli because the feedback loop is faster
oh would you look at that, Vercel suggesting to abuse how standard headers have been used for decades so it can send Accept-Language: rust because it's too lazy to ask for standardising an X-Prefers-Lang or anything else, and Shopify is here to shit on the internet too. Great.
That's craziness.
Don’t worry, you don’t need to attack them – they do a great job of making themselves look ridiculous with their ignorant conversation. I would be so embarrassed if I had suggested that in public then subsequently discovered that the header doesn’t mean that at all.
People keep trying to systematize things for the tools they keep saying don't need systemization. No idea why you can't just put the documentation programming language context in the URL. "/docs/typescript/...", "/docs/python/..." etc.
I don't think the agents are struggling with the idea that different URLs have different responses, and that checking the sitemap is a good idea.
Tangential: A rare en–dash user out in the wild!
Yeah I think a better header is good. The idea isnt bad in concept.
Well Malte came up with AMP so there’s a history of doing odd things
Well, SaaS don't do CLIs for extension APIs.
Plus the performance issues to restarting processes all the time.
Neither of those things are true?
Also you are seriously comparing process startup time with the latency of a network call, or worse an llm call?
Yes, if the SaaS application needs to fork subprocesses for every little step of agentic workflows.
Welcome to CGIs, a great 1990's technology for Web applications.
We do that, and the cost of forking the cli vs the llm or network call is very small. It works really well.
There are numerous applications that you don't need and don't want to give shell access to an llm.
i feel like MCP was bad, but people are saying recent improvements have made it worthwhile now? i.e. stateless http
There's probably still value (if you want to call it that) in it as a proxy, both to bypass IP address rate limits and to add necessarily credentials.
There's also another aspect Quite a few API providers provide automatic renewal for MCP server registrations, but not for personal access tokens. This may be less relevant when models just drive the user's browser.
It's not just the agent understanding the API, it's locking down the access they have. If I want to give access to an internal service in specific ways that the API doesn't lock down then an MCP that offers very specific queries, with protective controls and transformations in place is very useful.
MCPs are indeed useless, they're very limited in functionality and frequently struggle with large requests or get wedged in bad states.
There is no reason not to use the native API directly.
The MCP is the most efficient way of handling what we do! I can't sit here and worry about every little user request that comes in!
This doesnt match my experience. Yesterday, I was using Microsoft's Power BI Authoring MCP to make a semantic model from some SQL or CSV files. It was magical.
Microsoft has defined how to do that in the MCP. It's trivial to add the MCP to the machine and reliable in execution.
The alternative would be the model having to get the documentation directly from their documentation website, it sounds like. If this was the case, then MS would likely have great docs and probably support that markdown header... but everything hinges on finding a specific web page on the internet? Seems worse in every way than MCP to me.
MCP for agents never made sense, especially when the tokens they consume a significant amount of tokens on a single request for a basic action, and sustained usage blows up you token costs.
The spec was poorly designed to begin with. Even saw some folks here thinking it was a good idea to enable MCP directly on a production database for what? Risking exfiltration of sensitive data for bad AI agents.
Given the increased security capabilities of these new models (Mythos, Astra, K3), it sounds like MCP would not be able to justify on making sense from a security perspective and would be a very bad idea to use anyway.
So no thanks and no deal.
Well, think of the near-future when tokens are so cheap that they’re not worth to meter.
I’m not sure about some of this — I still think there is some value to MCP as a gateway to private resources when API access doesn’t exist.
But please don’t try to redefine the Accept-Language header. These things are well defined for a reason and redefining things isn’t helpful. Trying to figure out protocols on the fly for LLMs is how we got into the current mess. For all of the cruft that W3C has, I think that working with standards committees could help the AI vendors here.
MCPs are winning because within the ChatGPT and Claude apps, there are Plugin stores. These plugins are one-click installation MCP servers, with support for authentication. This is what business users are using.
Exactly this. It’s a very effective way to integrate your app into Claude/openai.
I was anti-MCP at one point when it was eating up a substantial amount of context in Claude code. That’s largely been fixed now.
From my perspective, they are a great way to wrap an API for agent consumption. I can see a future where every major commercial or service website (think airline websites) have an MCP your agent can use to check flight status, rebook, or check you in.
I know this is pedantic, but IMO that should just be in the URL if the resource is going to be totally different. Accept-Language is already a bit weird for the same reason in my mind, but I think the intention behind it is the resource itself is attempting to communicate the exact same resource. Obviously, two different languages from two different cultures are going to have different interpretations of the same direct translation, but the intention is the service has at least tried to avoid that as much as possible.
Adding programming language into that same concept just makes it seems like you're serving both /docs/typescript/vx/... and /docs/python/vx/... from /docs/vx/... despite them (in theory) having many more differences in between implementations/context than that would imply.
Agents should read sitemaps. Does anyone's harness do specifically that when looking up documentation?
I'm old enough to remember the OpenAPI spec.
Yeah sorry I'm just a humble Senior-Staff Vibe-Engineer born in 2020. Get out of here with your ancient 2010s API specs, old man! </sarcasm>
But seriously, just publishing OAS docs at a /.well-known URI seems very sensible. https://www.rfc-editor.org/rfc/rfc9727.html
This article entirely misses the value that MCP brings today.
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
If you want to operate something that's less YOLO than that, you'll find yourself wanting:
1. Control over exactly which external services it can access
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.
Were in a world where agents are more autonomous. Need stuff to be easier for agents and not humans
Exactly, in our company, we have built MCPs that simplifies interactions with internal tools we use a lot, which saves time and tokens. Sure, we could let the agent poke and fumble around with a not-so-ideal API too, but it makes sense to formalize it and give the agents quick access to what we want it to fetch 99% of the time.
What interactions with internal tools? If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
I've been doing this myself but it's been extremely hard to get buy-in from the rest of the org. They keep churning MCPs for deterministic interactions while I have tons of little tools written by clankers, not only for clanker-use but also for my own use when needed.
Best of both worlds in my view.
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.
Was that a real thing? I mean it must've been for it to be mentioned there, but, rephrased: what was the scale of that?
How many individuals were involved in that? 1? 10? 100? 1000? 10000? 100000?
MCP lead to one good thing though
a lot of websites that never bothered to provide a REST API are now exposing MCP server because it has become popular, and you can use those servers to write normal automation for yourself, without plugging in any LLM etc
I don't think MCP is a bad idea, but using them incorrectly is.
CLI tools are great if you always use the same environment. But try using them from your iPhone, and they simply won't work; a remote MCP will work seamlessly.
HTTP APIs solve a different problem. APIs are designed to be predictable and consistent, so the client always knows the response shape in advance. The MCPs are designed to be dynamically discovered. This lets agents connect to new and unknown ones.
Trying to give APIs extra responsibilities so they can replace MCPs would just create more confusion. It's like creating an MCP server but calling it an API.
This issue isn't just about communication methods and technical details. It's also about “standards”, and it will become increasingly important over time. As we begin to integrate AI into everything-for example, into banks...
MCPs are a bad idea because they encourage token burn at runtime when a deterministic program that uses the API should be used.
Of course Mario, Sammy, Jensen et al. would be for this.
Some people can't appreciate that their local Claude code workflow isn't the only MCP usecase. If you don't need it, then don't use it.