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.
Couldn't agree more. MCP is just Tool Use and the terminal agents all have embedded tool uses like WebSearch, Bash, Grep, etc and those are just MCP by another name. CLI's called by a model are just Bash Tool usage calls. Bash tool is just the most open ended broad MCP you can expose and what you gain is less context bloat (no specialized tool descriptions, just Bash) and what you lose is control over the agent -- until you setup a rigorous set of governing permissions on the Bash Tool.
I have a fleet of sandboxed Claude Code instances running and they share files with each other. The files are stored on AWS but they don't have access to AWS at all -- they can't see the access keys. In fact they don't know the files are on AWS. Instead they have a set of MCP tools for listing/uploading/downloading from an internal, virtual filesystem with a special URI handler (ie agentfiles://somefile.json) and the outer orchestrator of the Claude Code instances takes the MCP requests and does the actual file manipulation on Claude's behalf. The LLM seems to adapt quite well to this strange, arbitrary filesystem and I get to keep these agents fully compartmentalized. And I have tool request logs and logs in the outer orchestrator for full auditing of the agents. MCP is a really natural fit for this kind of stuff.
The spec describes Resources, Prompts, Tools, and Elicitation.
In practice, I believe Tools represent 95%+ of what people actually use MCP for. I've not seen an MCP with Resources or Prompts that seems to have widespread use of those features, and I don't think I've ever seen anything implement Elicitation.
> what you gain is less context bloat (no specialized tool descriptions, just Bash)
Couldn't they train the understanding of a specific tool set directly into the model instead of needing it to be in context? Like isn't that basically what happens now with the Bash tool?
Is there a reason we need to rely on such a high level of access for something that should really only ever be cleaning up the project directory, hitting the 'Run Test' button and authoring some Git commits?
Perhaps a little out of date now, but I found claude was better (trained?) with the gh command line than with the github mcp. For a $corp internal tool ... I don't really see how and LLM would be able to be trained on it.
MCP definitely has its niche in certain environments. It's good for a specific kind of constrained problem; not so constrained that you could solve the problem with just Node.js + fetch call to LLM API but not so open that you'd want to let the AI agent directly invoke any service it wants over the web. The latter is what happens if you give the agent access to curl.
Though I agree with OP's point of view that MCP was overhyped for too many use cases. Complex agent-system integration problems are usually better solved with just AI agent + curl + SKILL.md. It's just way more flexible.
It's another variant of the 'fat client/thin server vs thin client/fat server' debate. Some people want rigid, thin (e.g. web-based) frontends with the LLM doing work in secret behind the scenes. Others want fat, versatile frontends through which the LLM can interact with the user's own environment.
I've always been a fat client guy and this time is no exception. I doubt the constrained approach is going to lead ground-breaking innovation. I also wish companies would treat SKILL.md + curl as the main mechanism for agent tool calling as opposed to MCP. MCP is niche.
That niche environment is all SaaS-to-SaaS integrations. The client doesn't want to have users struggling to get every integration working on their platform. The service providers don't want to have to support non-standarized behavior by every client.
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.
It's difficult to come up with the optimal workflow on the first try. So an API should typically start out flexible even at the expense of complexity, in order to enable experimentation, and then you can optimize to make the common case simple, once you know what the common case is.
MCP is exactly the lipstick we needed to put on our pigs, APIs that is not ours, but open source tools we use internally and also wanted to expose to our agents.
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.
Retrieving messages from Slack over MCP allows a shared read-only bot account accessible from the web browser and CLI. Setup is automated so users can just ask Claude to read them and do something.
Sharing Slack with Claude:
- Using the "normal" way, it shares too much, including privates messages.
- Using your own token, it doesn't work with Claude.AI or Cowork and requires you to go to slack.com to generate an application, tokens and more.
- Using a shared token, now you need context to tell Claude to retrieve it. It still doesn't work for non-Claude Code workflows. Rotation may break currently running workflows.
Yeah. Like I had Claude code write an upload Slab script, and a few linear integration scripts, now it just runs these to interact with those systems. I had it write a redshift proxy that doesn’t take login creds and is just a logging read only account but it can just write sql to research to its hearts content (some columns hashed on replies) and I don’t need much trust but I get a lot of good analysis and verification done.
> 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.
The MCP is the deterministic program.
You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface.
It's the interface for your deterministic program. That's it.
It's easier if you started a while back shunning all human labor (including your own) in favor of fully deterministic systems. Reality is deterministic so your company or project logically can be run off a single compiled binary with formal verification of correctness for every possible scenario.
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.
> there's almost no reason to use MCPs if you are running a full-blown terminal agent
I disagree. Adding "https://mcp.linear.app/mcp" and having everything happen (discovery, usage, updates to the API, etc) without having to install or configure anything else locally is a big deal.
Funny you mention Linear’s specifically, I just posted about moving to a CLI instead because of the MCP’s egregious token-usage [1]. While this doesn’t discount the points you mentioned, I think the context savings (which can be huge, I hadn’t listed all differences in that post) outweigh them specifically in Linear’s case. It is just too inefficient in that regard.
Edit: this of course says nothing about MCP vs API/CLI in general. It’s just a bad implementation by Linear.
This surprises me a bit. I've found much better token usage with a proper/efficient MCP as even with a deep /skill defining usage, parsing MCP results is generally just better/more efficient than parsing CLI results. I say this having written a CLI tool explicitly for harness usage, and leveraging MCPs for the same.
I'm sure there are bad MCPs and great CLI tools that parse poorly/well via harness, but I'd be curious on an better research study.
Your comment doesn’t contradict mine and mine doesn’t contradict yours. Linear’s MCP is just (very?) inefficient. I explain the source of the difference in the last two paragraphs.
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.
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.
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.
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.
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.
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.
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.
Exactly. A lot of people complaining about MCP are doing so because their only interactions with LLMs are via big batteries including code harnesses and don't understand what kind of (usually much more domain-specific) agentic systems are being built. For example, "CLI vs MCP" doesn't make any sense whatsoever if the agent doesn't have access to a CLI!
MCP suffers from its harebrained choice early on to load everything into context up front.
I think the point of those comments is this could have been much simpler for everyone if the model providers had given us some tools around existing standards.
Instead they invented something new/weird/complex standard, and then every client implemented slightly differently (and different parts of it).
> Exactly. There are so many replies here of the form “MCP sucks. If you just do <all the things mcp does a different way> you don’t need mcp at all.”
See my previous reply to simonw elsethread.
It's not "If you just do <all the things mcp does a different way> you don’t need mcp at all", it's that many of us were already doing that in a CLI prior to LLMs. You think only github and amazon had CLI clients?
As someone who has never used MCP, or allowed an AI to directly talk to APIs, putting something between a model and a service just seems like common sense. If nothing else, it presents an opportunity to tightly control what the AI is allowed to do with external services, especially if the MCP code is outside of the AI's context. I would go as far as to say it's a necessary security measure.
The better solution for security is sandbox execution. Most agents used in practice, if given terminal access, can find ways to get around most of the MCP restrictions.
well if you realease an api you should make sure its usable for ai out of box without 'something in between'. You should always assume ai might be directly calling your api.
I absolutely love when they do that unprompted. I once asked a Claude work agent to go pull comparable apartment listings and somehow it’s subagent reverse engineered like rentcafe or whatever’s private API to get the data. All unprompted.
So yes. Absolutely assume AI agents acting on behalf of their humans are finding all the token efficient ways to get at your sites data.
I feel like this would build a false sense of security.
Authentication and access controls must be able to withstand an agent with full shell access. And auditing must be on the server side to provide a full picture of all activity from all clients, whether human or agent.
We must treat agents as clever humans and secure and audit data access accordingly. The era of thinking we can handle agent access to sensitive information differently from human access has passed.
My point about MCPs here is that they provide a way to make those secrets and API keys deterministically inaccessible to the agents - even agents that's have a shell execution environment.
I noticed the security aspect to be one of the main selling points in corporations for going MCP (and one aspect that is underrepresented here).
However, maybe I'm missing something but how is defining access rights in an application layer the agent has access to more secure than defining the access rights at the target application itself?
Sure, hiding the filesystem via encapsulation tricks is one way to go. But what is the real-world usage-style of this vs. all MCP usages? I'd wager 1-10% are spending this extra effort, while 90% of users basically run shims so that they can expose APIs to their LLMs, for which they have no/bad access rights management.
just use an api gateway (ie., a reverse proxy for apis), eg., envoy. This should also be connected to observability and finops style management anyway rather than leaving it to model providers.
Without tools LLMs can do nothing more than emit text. You are probably assuming a harness is provided to the LLM with shell access but that is absolutely not necessary for LLM usage depending on the use case. For interesting stuff, you do want to provide some tools, but nothing with the power of a terminal if you are worried about security. A MCP server is perfect to securely provide the LLM with some controlled power exactly because it can do nothing at all other than call tools that go through the MCP server and can therefore be scrutinized, audited and ensure credentials are not visible to the LLM.
> This article entirely misses the value that MCP brings today.
Well, me too. I see the only advantage over a CLI app being an agreed-upon convention for syntax (not semantics).
I have a CLI interface to my webapp, not an MCP.
> 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
Access control is not built into my CLI, it's built into the WebApp.
> 2. A way to handle authentication that doesn't allow the agent to directly access API keys
My CLI takes credentials from the environment, which it uses to talk to endpoints. The caller sets the environment, then calls the CLI program. The caller provides no way for anyone sending it input (the Model) to request or retrieve environment variables.
> 3. A sensible UI to allow users to connect and authenticate further services
The parts of my WebApp that relays or re-requests to other third-party services handles access control.
> 4. Strong audit logging for what's going on
Not sure what this is supposed to mean: the WebApp already has auditing logs.
> MCP makes all of that so much easier to provide.
Sure; I'm considering writing a purely deterministic shim for MCP around my CLI. The semantic/information is the same, the only difference is syntactical in nature.
> 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.
It may as well be; coding agents are at one end of the control spectrum - run in bash, do anything/everything (so they can leak credentials to the model, or the harness). But a CLI app doesn't have to allow bash. My "harness" (using the term very loosely) can securely call other programs without giving its own caller a RCE via bash.
So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself?
Sounds to me like MCP with a slightly different interface.
> So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself?
Yes, with the difference being it can call other CLIs, just not arbitrary CLIs.
> Sounds to me like MCP with a slightly different interface.
It is, except that it is not limited to being called from harnesses. Also usable from bash (automated scripts), or even humans if hey want to run it on the command-line.
TBH, my webapp(s) had this prior to 2020, because it made automation simpler so I could write shell scripts to do various things on the WebApp.
I did end up building my own CLI for calling MCPs, mainly to better understand the protocol but also to make them easier for me to interactively debug: https://github.com/simonw/mcp-explorer
Even for coding agents. MCP is the only unified interface INTO harnesses. This pattern has not struck yet for most, but will soon in the coming months given the MCP spec. MCP has been about models calling tools., it is about to become some form of inverse and MCP will be the only actual way to integrate into the models. Simple example is sending an event to the model (today models have to poll)... these coming updates will cement MCP as permanent infrastructure.
All of these things are perfectly possible with a plain REST API with an Open API spec and using some standard auth options, and an AI client that implements a reasonable “make api request tool” (just like the AI clients implement MCP today).
I think the real value of MCP is that it allowed companies to say “we’re doing AI!” When they built an MCP server. Just saying “use our api” was a lot less exciting.
Giving it a different name probably also helped cut through politics at companies where non-technical people didn’t want to open up user data with an API, but they did want to do AI.
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
I've since come back to MCPs, because I want to build my own agents without first having to solve the problem of effectively sandboxing Bash.
It's such an important problem that it is sucking all available VC money into an exponentially-growing number of startups promising to make sandboxed agents safe and usable. In other news, MCP exists.
Bonus points if it's available on both macOS and Linux and doesn't come from a random unmaintained GitHub repository with a note in the README that says "don't run this in production".
"Battle-proven" until an LLM decides it really needs to escape the sandbox you put it in and eventually succeeds.
For personal work, I run Codex in a VM that contains only what's necessary to do software development. Could it escape the VM? Sure, if there's a zero-day in VMWare Workstation.
Yeah, I'm using a pile driver when I really probably just need a hammer, but I've seen too many horror stories, and I don't trust guard rails. Even if there was an option to limit Bash calls to read-only operations, I would be 0% surprised to eventually run into "You're absolutely right! `rm -rf / --no-preserve-root` was a write operation! That's totally on me."
I mean the ability to have an agent run commands in a Bash shell without allowing them access to any file or environment variable visible to the user on that computer, and without allowing them uncontrolled internet access.
Program specific permissions (separate from the user operating them) are part of the Linux permissioning system already right? That doesn’t seem like an issue to me.
I guess the main problem would be finding an API client that can easily plug into your harness, with a nice UI for turning specific APIs on and off.
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
MCP was a convenient answer for companies that had spent the last few years shutting down APIs because allowing API access bad.
Just leak them to the inference providers, obviously /s
If you have self hosted models and/or self hosted APIs, maybe you don’t need MCP to provide a gateway to a secure resource.
If neither of those things are true, you need an authenticating gateway/proxy or a target API that supports single use credentials (and get the model to generate a call to use them).
We can argue whether MCP is a good authenticating middle layer, but not whether one is required.
it's mostly true but the mcp also installs the knowledge of that REST API in a standard way so that a user can ask "what's projected revenue this month?" and it'll know how to hit your company brain and answer
most users i'm dealing with are not doc-reading developers. even getting them to tell claude to use tool X is pretty hit or miss whereas claude already knowing what tool to use is 100% hit with correct mcp tool descriptions.
The article also doesn't contemplate the "skill distribution problem" which will be addressed by skills-over-mcp.
With the plain ol' API solution, you still need some way for agents to fetch the instructions provided by the service. Of course there are answers for this, but they are not standardized.
With MCP, all you have to do is provide the harness with a single URL and all context can be bootstrapped the same way for every service.
> 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.
I don't think this is a valid statement too. I'll explain why.
A MCP server represents those APIs that agents and coding assistants can call.
If you feel a need to provide data and services to agents through an API and feel so strongly about it and so compelled to implement your own APIs with the express purpose of being consumed by your agents, wouldn't it make sense to develop an API that is designed purposely for agents using a protocol designed to meet their needs and simplify their work?
Because that's what MCP is all about.
Nowadays, with the improvements in tool-calling and the dissemination of agent skills, MCP's value proposition isn't as clear as back when those weren't a given. But once you face usecases to either centralize your tools across an organization, manage access, and be able to audit it's usage, right now there is no alternative to MCP.
All of that can be solved in better ways than MCP. 1+2+4 belongs to sandboxing. 3 to sandbox UIs. Ideally baked into the next generation OSs.
MCP is the wrong abstraction for all of that. Skills are better as pluggable interfaces, and I predict[0] chat and agentic loops will converge eventually (Anthropic already did this correctly; OpenAI, it's your turn) and skills marketplace will replace MCP in its current form.
I see value in MCP, but it feels like a stopgap/stepping stone.
[0] Where "predict" = "hope". The best solutions are often not the winners.
Skills are adjacent to MCP. They do not cover the same surface, in anyway. I don't understand this argument at all (and I see lots of people making it, so enlighten me)
I want my agent to be able to convert reliably between timezones. A skill does not solve this. It needs a deterministic tool it can call
Skills are not only Markdown files. I often structure my skills as small Python scripts and the actual Markdown is only the skill front matter and maybe some brief documentation. You can even stick an OpenAPI schema or whatever you see fit.
If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed. It's just files, all the way down. If you find yourself operating with dates a lot maybe you need a `datetime` skill wrapping a bunch of tiny scripts. Fully deterministic, cheap on tokens, and you can even run them without an agent (shocking nowadays :P)
As I identify repetitive actions I add (Claude adds) new scripts to the Skill to save tokens in the future, whereas MCP I'm at the mercy of the server provider. E.g. I have a Magic the Gathering skill with a bunch of tools to retrieve card databases, simulate hands, get card images...
This is why I don't feel Skills are orthogonal. They feel like MCP on steroids since the scripts can be composed with Bash et al (huge battle-tested ecosystem, plenty in the training set)... and you don't need crappy abstractions like "resources" (yes, that's a thing in MCP) when the agent has a shell and a filesystem.
I've used this pattern to great success. Nowadays I just share these `.skill` packages with my friends (I think they're just a fancy ZIP file?)
The only thing missing for me is credentials and sandboxing (see my GP post). I have my own ideas on how to solve this (and some of that Claude in cloud already solves for me), but it's not easy (which is how MCP won).
> If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed
okay, but now my agent needs a coding environment / sandbox.
MCP (or tool use in general) solves this without that (extremely tenuous and expensive to do at scale in prd) requirement.
The skill is totally orthogonal here--solving a totally separate problem
They could and code execution is actually exposed to the model as a tool!
But if im running a customer support agent at scale, i'm not sure I want it to be able to write code. I do know I need it to be able to convert timezones though. (its also far more expensive / token inefficient to have it write code each time to convert timezones rather to use a predefined tool I made an know works)
> MCP makes all of that so much easier to provide.
Easier being the key!
Right now it really does feel like early web days where like 5% of the population is adopting things, but most people just get confused and don't participate.
This is why I'm pretty excited about WebMCP in particular!
WebMCP aligns more stakeholders than pure MCP - which seems heavily biased towards model providers. It also seems like it has the potential for a much cleaner ux.
What if I don't want my agent to have terminal access though? I get the feeling many people here simply never worked with smaller models, those will confuse cli args really quickly once context expands, and then you have no idea what damage they might do. With MCP's, they get just the access they actually need. Is the Principle of least privilege just not something we want to apply anymore?
CLIs, run in a sandbox as tight as your preferred choosing, live in an ecosystem, where, via pipes and redirection, input and output can be easily manipulated. An agent can do similar things but more laboriously (and less token efficiently) via Python or similar but it would still live in a sandbox somewhere.
Going without the sandbox means hobbling the LLM. It can do things directly but is less able to construct ad-hoc programs to deal with looping, conditionality, tame verbosity, connect tools together, and so on.
It's a choice to not give the LLM an environment. As you say, it can be necessary if you're using dumb models. I don't find it particularly worth the trade most of the time.
If not even OpenAI can properly box in their models I definitely won't trust myself to do so with the very limited time available to me, and instead just use a standard that's already defined, and proven to work.
You hobble the expressiveness of the LLM and reduce its capability.
Think of an agentic harness as like a kind of body for the LLM. It gives it primitive inputs (read_file, web_search or whatever) and primitive outputs (edit file, respond to user, etc). Give it a command line environment (in a locked down sandbox, with as few or as many tools as you prefer), and you've given it a toolbox. It can do a whole lot more, faster and more efficiently. It can compose tools together. It makes fewer transcription errors manually shifting data around. It can tame verbosity with good protections in the harness and access to grep, sed and awk.
It's really up to you how useful you want your agent to be.
If you don't have something running somewhere, you don't have an agent, you don't have a harness. You've got a token generator, an LLM from the 2024 era.
That's where you are completely wrong. The point of MCP is that you can have an agent and a harness without running raw CLI or Python commands. Very common for relatively lightweight loads that involve shuffling data around between APIs, often run in a tiny serverless task.
Sure, you have an LLM which can invoke functions. I will say that without storage and composition, you're asking for hallucination. LLMs are not deterministic and while they're good at regurgitating text - you can see how replies in an instruct model are structurally keyed off the question - they will rephrase, adjust, "correct" data they're schlepping from one call result to another call input. And one noisy MCP call and there goes your context.
You could build something with storage and composition out of MCP functions, but come on, have you seen how LLMs - particularly budget LLMs - try and invoke functions reliably? The amount of retries you have to hide, feedback you need to send back to the LLM about what it did wrong. Parameters get replaced with synonyms, arrays are passed for singular arguments and vice versa, structured inputs are flattened, etc.
So maybe you fine tune on interactions with your subset of MCPs, to improve reliability. But all you end up doing is reinventing a Unix-like command line, poorly.
Firecracker micro-VMs, gVisor, wasm sandboxes. There are ways to make this work that aren't heavyweight. Giving LLMs tools that they've seen how to use millions of times in training corpora just works better.
The article misses the point of MCP but he is not wrong that it was a mistake (in some ways)
The mistake of MCP was building it in such a way that it needed to be on a separate process from the API. The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years.
Now that MCP is stateless we can start building what is actually useful: extending API’s for agents.
When people ask me if they should do MCP today, I say absolutely. But because the Oauth protocol side of MCP is very good and is a net positive for all public API’s
This is not a dig at MCP, the original vision of MCP was much different from how the community used it.
> The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years.
I remember discovering this when i wrote my first MCP server. It was like "huh? why would they do that? what use case did they have in mind?". We've spent decades making "internet shit" as stateless as possible on the backend because making it stateful is expensive and complex if you want to have any reasonable scalability. I mean good luck trying to host a stateful service on any kind of commodity serverless "scale-to-zero" infrastructure here in 2026.
Maybe it's because these AI-labs are used to statefulness. I mean LLM-based sessions are hugely stateful if you want any kind of reasonable caching to happen and caching is the only way you can economically scale out LLM's. Seen from that perspective it kind of makes sense why they'd look at MCP and think "hey, why not make this stateful on the backend as well". Statefullness just part of their DNA.
Agree. MCP also helps in some esoteric use cases like interacting with legacy windows applications over COM. I created an MCP for Outlook 2019 desktop version and COM was the most straightforward way to let my agent interact with my mails for classification.
I've taken to sandboxing my entire agent in a Docker container. I wrote a tool that pretends to be an ACP client but is actually making Docker containers, copying files I specified in, bind-mounting, etc, and then proxying ACP via websocket to an agent in the container (except the ACP terminal/FS commands, those happen in the container).
It works well, though there is some leakiness around paths. I opted to make it place/mount files at the same path as on the host so paths are the same (as opposed to manipulating the ACP messages to modify paths on the fly, that felt messy and buggy).
Configurable networking is on my list for the future, but I haven't decided whether to start with IP-level firewalls or if it's better to start with a proxy and firewall rules to force traffic to it. IP firewalls suck for APIs that might have semi-dynamic IPs.
Well, speak for yourself. My MCP servers are pretty solid.
There's nothing in the protocol making them inherently poor other than perhaps popularity, causing a swarm of people vibe-coding things they don't understand.
Still don't get what's the advantage over just adding a special API key or a wrapper cli or whatever mechanism that achieves all of that without being a "protocol" and with all the context bloat. Like the github cli is a good example. You give it proper auth keys etc. and for sure there's some telemetry in there about usage as well. If there isn't then it's easy to do from the api side too.
Even if you don't own the code or infra, like say a frontend team who wants models to test out the backend apis and do something. Well in that case how do regular devs do it? Do they also get unfettered access in the past? Surely there's still some mechanism you can repurpose for agents to use?
I'm not trying to argue I'm just saying I didn't catch on the first time mcp was a thing and I still don't know what it's doing now.
If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool. They can go as far as decompiling binaries, or rewriting them to log the key before it is used.
If you are worried about a prompt injected agent stealing your keys, that's a problem.
(There is a way around that: you can use an HTTP proxy that inserts those credentials but otherwise lives outside of the agent's realm of influence. MCP is a whole lot easier though.)
> If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool.
So, don't do that then?
Why do you need to use a full coding agent as the interface between the model and the CLI tool?
A 10-line program can do the wrapping of any existing CLI program so that environment is not leaked to the model, while providing the CLI program with the environment as well as restricting what programs can be called to a whitelist.
If you CLI program is echoing its keys in the response, or the endpoint is echoing keys back, that's not a problem that can be solved with MCP anyway.
So you're building a custom harness here that provides tools, and you're wiring up your custom harness to effectively do a subprocess execution of a CLI script for every tool call the model request?
One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls.
(That performance overhead is so trivial as to not be worth caring about, but the state thing may be useful - keeping a stateful browser session running between tool calls is harder with a CLI, for example.)
> So you're building a custom harness here that provides tools, and you're wiring up your custom harness to effectively do a subprocess execution of a CLI script for every tool call the model request?
Well, yeah. Subprocess execution is on the order of double-digit milliseconds. The "wiring up" is maintaining a whitelist of what tool commands map to which executable. It's a lookup table with very little maintenance required.
> One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls.
I feel like I am taking crazy pills :-/
The overhead of forking, on the ancient machine I call my desktop, is at most double-digit milliseconds. The state isn't being tracked by the MCP server anyway, it'll be tracked by the harness and/or the model, no?
My main reason for adding MCP support is so that existing callers that want to use my WebApp(s) can just use it without needing any changes on their side.
IOW, I am going to add it at some point, but not for the reasons you give. I'll add it to be compatible.
1. Control can be done via CLIs --> api key based access controls. We have been doing it forever.
2. I think this really only applies to Oauth based MCPs. Many server support api key based auth, stored as files --> security is still flawed imo.
3. This can be done via apis/clis too --> not something unique to MCP iimo
4. Same thing, not unique to MCP --> api servers can also be logged
MCP doesn't inherently make this easier. its still requires engineering maintaincence.
Having a standard does make sense though, because it lets agent services handle external calls in a standard way. So, for example something like Anthropic's agent platform will proxy all MCP calls and hide the credentials so that you don't have to worry about the agent leaking secrets into code/logs/the internet. Of course you could build a similar layer to proxy traffic to various APIs, but it becomes easier to make the whole thing plug and play if everyone agrees on the shape of the API (MCP).
i think standards are good for low level things. APIs change, model behvaiors change, we basically are allowing an external service provider to control our agent prompts.
The premise of the article is that the Model Context Protocol (spelling it out to emphasize the core purpose) is inefficient in its current form. We can agree to that.
Now, does it mean agents don't need a protocol to connect to a server and discover its capabilities, tools, and distributed skills? I disagree.
> Agents with terminal access can replace most MCP servers
What should all other agents that don't have terminal access do?
Aside from the actual protocol, it makes a lot of sense to have a standardized, discoverable protocol.
Because the alternative, as proposed in the article, is that an agent researches an API/CLI/UI, builds software to interact with it, and then runs that. Every time again.
Not only very inefficient, it's unpredictable, and often slow.
Just last week I had an MCP that was down (my mistake) and the agent "decided" that in order to finish my request, it needed to create a python script, refactor that, debug that, and then use that, so it could access my notes (Joplin) over the API and write it's weekly update markdown there. Somehow the thread produced a python tool with over 400 lines of code, five files. It, at some point, even considered putting all that in a git repo. And went on a side-quest to run docker containers.
With the MCP, this job typically takes between $0.05 (Mistral) or $0.90 (Claude Opus). It now cost me $17.00. It took nearly 30 minutes. To write a note in Joplin!
MCPs, or any de-facto standard/pre-known protocol, makes operating on external tools and resources cheaper, faster and above all more predictable.
The scripts that were generated included code to determine if joplin was running, and to launch it if not. It included a proxy server, that would listen on a localhost:xxxx and if a HTTP request came in, this proxy would auto-launch joplin and then forward the request/response. It then included quite some code to de/serialize json to/from datatypes.
Part of this "overengineering" came from a "skill" that claude found globally which I wrote for myself when working on a few python tools. The skill required strict typing, demanded refactoring, insisted on doing everything over http (and not local commands).
Basically, the agent could not perform its task over an MCP and should've stopped. But I suspect either tuning or some system-prompt made claude go on instead. It decided to use python, and then found my "requirements for when writing python", followed that, and burned a lot of tokens to make one or two HTTP requests.
Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
Why trust any user with access to any terminal? UNIX solved this decades ago. It’s just we’re all learning to be sysadmins for the most creatively destructive and persistent set of users of all time.
UNIX didn't really solve this scenario. Yes, you can limit what local files a user has access to. But with web applications and cloud services being so ubiquitous, the local boundaries are pretty much meaningless. Forcing an agent through an MCP is a way to grant access to remote services while still restricting how the network access can be used.
Network administrators also solved these things, e.g. you can limit what websites a virtual machine is allowed to access.
Now, if you’re letting your agents abuse network traffic there becomes a point where you’re criminally liable. Unfortunately the current US government has no interest in prosecuting such abuse.
Maybe I overestimate the ability for corporate network administrators to block and detect access to certain websites from within their networks, like adult websites. My understanding was that there’s no way to circumvent those network controls.
> Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
When even the official software from the token providers have never had human eyes on 800kSLoC, I'm afraid that ship has sailed: the principle of least privileges has already been ravaged to hell and back.
Sealing a pin-prick hole in a dam wall is pointless if half the dam has already been washed away.
What you're describing, though, is that agents need a REST API. And I meant true REST rather than the JSON RPC APIs we've been building for 20+ years now.
Had we not abandoned REST we'd still have APIs that are self documenting and typed/schemaed. Bonus if browsers still supported XSLT, that same API could have been written in XML and only browsers wanting a visual representation would load HTML templates while agents could stick with the raw XML.
Sure, it needs a REST API. And you need docs for the API. Not just per endpoint but how to accomplish tasks with the API in the context of the application it supports.
But you don't want to just give any old agent raw curl access, so now you've got to provide a special client that can call just the APIs /endpoints that they're supposed to be able to. And it needs to know what the agent shouldn't be able to do as well. And it also needs to be able to handle things like auth, because you don't want the average person (or the agent!) handling bearer tokens. And you probably want a layer in between that validates everything against an OAS so the agent can't make invalid requests.
And now you've effectively just reinvented the good parts of MCP with extra tokens.
You're starting too recent though. MCP is attempting to recreate the good parts of REST APIs circa 25 years ago.
Soap was a pain and a lot of people didn't like XML, but they solved exactly these problems.
With MCP we're effectively trying to bolt those features onto a platform that fundamentally doesn't support it. Where as with XML/XSLT we could have a single XML endpoint + XSLT templates for converting that into HTML for browsers. Instead we now have modern web frameworks building RPC calls right into the bundle/build step, splitting state and rendering across both client and server, and have to stand up a new API context for agents that needs documentation and maintenance to keep parity with new features.
This isn't a problem that existed 25 years ago. You could expose SOAP and give an agent WSDL. You could give it OpenAPI and JSON. That's just not the problem.
Agents emit tool calls as JSON. Calling a REST API means emitting a JSON tool call that invokes a HTTP client with all the desirable properties (schema checking, safe auth) and none of the undesirable ones (raw key handling, arbitrary endpoint access). Then the response gets wrapped in JSON and returned to the LLM. That's not an MCP thing, that's a model thing.
MCP says "instead of http_post with a bunch of arguments that need to be correct, call get_weather with a zip code". And then it makes principled choices for how get_weather and its schema is defined. That's literally the whole point.
Even if you wanted to use WSDL to accomplish this, you either have to unwind how literally every function calling implementation of every model works today and teach them how to read WSDL and speak XML (and deal with all the other problems, like auth), or you avoid the two layers of indirection and define a system that works with what exists today, and that solution ends up looking very MCP-shaped.
You might say "well you could just have a little script/xslt that does the translation". That's exactly what a local MCP server is.
I'm not aware of anything that makes the models prefer JSON though, that's an implementation decision from whomever implemented the transport mechanism.
LLMs will happily work with XML, including to understand data schemas and discover available actions that can be taken.
No, that's wrong. The models have special syntax for function calls. They're not simply regular responses, they're special message types. You're partially right though: most models don't output or accept JSON, they have their own syntax internally. But that syntax is different for every model, and all the tools that invoke the models have parsers that convert it to the standard JSON+JSONSchema format. That's what vLLM and llama.cpp (or your tool of choice) are doing.
But that's irrelevant, because it's the tool call. The tool call is what invokes the HTTP client, not what's in the request payload. It could be asn.1 or RDF or TOML. JSON just happens to be convenient and universally supported. MCP could easily be implemented on literally anything you throw at it: that's an internal detail to your agent harness. That's not the point.
MCP is the OAS/WSDL/whatever contract described as tool calls instead of as network requests that the agent has to construct from scratch. Its whole purpose is to eliminate the whole layer of indirection.
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.
To be fair, after visiting some trade shows recently, a lot of these “parasitic” LLM startups are not very convincing from a business-use case perspective. (They’re not really parasitic, more like a remora attaching itself to a shark, the shark being OpenAI or Anthropic).
At IMTS at Chicago the skepticism amongst the visitors towards AI and pure-AI startups was at an all-time high. More than once I heard, “Oh yeah I visited that AI booth and they couldn’t explain what value they would add to my business.”
So in that sense, while MCPs are “winning”, I also see them as a significant part of the AI “bubble”, specifically solutions looking for problems backed by VC money.
The title feels clickbaity. Direct API, CLI and MCP all have their uses.
Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky.
CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command.
MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.
The MCP use case is mainly another attempt at papering over the fact that effectively no API today is actually RESTful. We wouldn't need MCP at all if we still implemented REST APIs.
I think many devs misunderstand MCP because they work in solo mode. In solo mode, you just have your secrets local. You don't care about auditing access. There's no IT managing the infra and third party secrets. You don't have to account for different harnesses and tooling; you just use your own harness and adapt your tooling to it. You're not thinking about revoking/rotating secrets when someone leaves your team. You don't have to deliver capabilities to many different runtimes and stacks.
Back in March, everyone was already pronouncing it dead[0] when in fact, it has only proliferated and become even more essential for both 3rd party systems as well as platform level capabilities[1] as agentic tooling has moved a bit more slowly into the enterprise. It was apparent even back then that enterprises will need MCP.
In a team context? Enterprise? Building web server backed or in-process agents? Not sure how you replicate the control, auditability, accessibility, composability, and security boundary that you get with MCP over HTTPS without a lot of bespoke, point solutions; in the end, protocols almost always win.
Could you do it with just REST APIs? I mean, MCP is just JSON-RPC over HTTP with standardized auth, schemas, and agent specific exchange flows (tools, prompts, resources, etc.). Could you do it with just CLIs? You lose a lot of the control mechanisms offered by MCP (auditing, security, centralized auth, etc.). The context savings are overblown except with CLIs that have good representation in training (curl, jq, cat, sed, etc.; your custom CLI is going to need to produce instructions and add to context all the same)
Heuristic is simple: don't use MCP for local, solo dev. As soon as you need MCP, you'll know it and you'll understand why it exists. Many of the harness level capabilities themselves are implemented as first party MCP (more apparent in the CLIs). MCP is basically REST for the agentic era.
That core issue - the HN audience thinking solo or very small team, not large team or enterprise - permeates so much commentary and analysis here. You're spot on.
I also take a lot of the guidance from influencers with a grain of salt for that reason. What works for the solo dev on greenfield projects rarely scales to the enterprise 1:1. Brownfield. Security policies. Enterprise controls. Legacy systems.
There is usually a kernel of value that has to be extracted and translated to apply what works for the solo AI engineer and what works for the team.
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.
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.
I really don't care about the technical or cleanliness arguments against MCP (which are valid).
What I care about is that many companies didn't have APIs, and didn't see a reason to have them (niche, dev-focused use case, or might produce a competing frontend/app)...
but now, those companies have a reason (agentic but let customer agents access data!). And for me, that means more companies now allow me access to my own data on their platform. This has been a net win!
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
The same thing is going to happen at the app level on Google and Apple platforms. Android tried to have modular cooperating software, but both the early dominance of iPhone in the developer community, and developer interests in having monolithic apps made that effort fail.
Now both Google and Apple are making app interfaces legible and on-device tool calling discoverable. This will change apps in interesting ways.
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.
This, please refrain from using standard HTTP headers in non-standard ways. Why not use something like X-Accept-Programming-Language so that the semantics of Accept-Language can remain for human language, since the docs site is going to return text in a human language as part of the response anyway.
>Recently, a Vercel engineer called on harnesses to send the programming language the client prefers
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.
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.
It would seem that curl + jq represents most of the solution these days. I recently learned that jq programs can be used in the other direction to effectively patch a json document too.
Putting both of these things together, I am running out of problems to solve as a human developer in the space of AI agent integration.
Assuming all your systems speak JSON right now, you are already 100% there with frontier models. You don't need to write a single line of code. Even if your json documents are monstrous in size. Put a size limit around the jq output and the agent will iterate with various filters until it finds a concise view of the problem. None of this behavior needs to be prompted or orchestrated anymore. Give the agent the tools and set reasoning level > 0.
I originally used the MCP server but after running into context bloat and limitations around MCP I looked and found this. Seems to be a fantastic interface for agents, they breeze through o11y tasks with this thing.
Agreed, had a coworker come to this same conclusion and now only distributes CLIs. I think it’s solid as long as the decision tree of which tools do what is fairly simple. Perhaps MCPs were just overused before
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.
> Recently, a Vercel engineer called on harnesses to send the programming language the client prefers, so documentation sites can serve more specific examples. For example, adding Python could prioritize docs for the Python SDK instead of sending something generic.
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?
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.
Eventually this part will end. Most are in a "move fast and raise our stock value as much as possible" mode, so are fine with infinite auto-scaling to handle the surges MCP traffic is causing right now. But eventually, we'll probably see more per-auth rate limiting and/or heavily restricted MCP usage for non-frontier labs agents (especially if they only want e.g. Chat users, not coding harness users).
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.
In coop [0], a VM manager we developped to sandbox agent usage (i.e. give them freedom to do their stuff, but in an isolated environment from your main machine), we try to solve this by having an intermediate proxy (coop-proxy).
Instead of forwarding ANTHROPIC_API_KEY / OPENAI_API_KEY into the guest, we simply run a reverse-proxy within the VM that replace a constant-time token with the real API key on the host.
> 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.
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.
Something like openshell is the answer here, to the point of GET being a write. The gap left here is what, imo, is something that MCP fits nicely- which is serving non-http resources with restrictions: databases for example.
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.
I don't get excited about the directories listing all the MCPs that do all these random things. However, I used claude to create an MCP that is a gateway to our system and it's enabled some pretty helpful functionality for us. I use claude cowork to create email designs using data and content from our CMS, it can push accepted work straight into our system, evaluate content, and analyze results. All of that used to be a manual tiring process. This removed a lot of drudgery and improved the quality as well.
When I first looked at MCP protocol, I did not like it. Then I realized, I don't have to care about the protocol. Claude can implement that for me and it did.
MCP is a solid, obvious idea. The problem is the implementation and roll out. It was shotgunned from the start and made an otherwise simple thing far too complicated. IME, a shoddy foundation always leads to shoddy construction on top.
When done properly, MCP can be really useful as an API bridge. MCP is (or can be), after all, just a JSON-RPC endpoint that returns a standardized response format. "Tools" are just function calls w/ definitions that are LLM-consumable.
Agree on flexibility, you can just do a lot more with AI agent + curl + SKILL.md.
The agent comes with a good amount of API knowledge in training data already. A curated set of MCP tools throws most of that away. With curl, it can hit any endpoint and write scripts. SKILL.md covers what it gets wrong (API version, rate limits, etc.) and points at the vendor's own API docs for anything else.
The annoying part isn't tool calling, it's auth. You don't want the agent managing OAuth tokens for 10+ apps. A passthrough proxy that holds the credentials, injects them per request, and scopes permissions solves that. At Maton, we have our own MCP servers as well, but most of our customers use us for managed auth.
MCP is like anything else - it has its uses. Use it where it makes sense. Where it doesn't, don't. For my part, I probably rarely want my Agent to waste time writing its own adapter for a particular API that needs to be called, when I can just point it at an existing MCP server. And while context bloat can be a problem if you're using many many MCP tools, not every use case needs that many tools. Making that a non-issue in many cases.
For my part, I wrote an MCP server this weekend for Bugzilla, connected it to ChatGPT and now ChatGPT can help me manage my queue of bugs (and non-bugs - I use Bugzilla as sort of a generic work-item tracker, TBH). Simple, works and gives me a nice natural language interface to the tool. And if I want more than the generic API surface, I can add tools (or modify the existing ones) to add any additional business logic I want.
Can you "get there from here" other ways? Sure, absolutely. But this works quite well for my use case and I'm not anticipating "delete my MCP server" anytime soon. In fact, I plan to deploy one for interacting with my Mediawiki instance as well. I also even have plans to implement MCP for interfacing with all of my LXI/SCPI enabled test equipment!
If I get to the point where context bloat becomes an issue, I'll cross that bridge when I get to it.
MCP Apps[1] also look like a really cool addition to the stack. I've only built toy examples / demos to date but I'm pretty excited about what this brings to the table as well.
Article is focusing too much on tool use over HTTP. One of the good things about MCP is that it's the same protocol whether the tool is implemented with HTTP or using stdin over a local process. And it doesn't make sense to talk about HTTP headers with stdin.
> There are still some issues, like CLIs returning machine-readable responses (JSON/XML, etc.), which tend to be very verbose and heavy on token usage, but we have ways to fix this.
This problem is also solved by MCP.
Anyway, when building a new tool, I personally try a CLI based tool first, then I'll fall back on MCP if the CLI is not working.
One big reason I see for needing to switch from a CLI to MCP, is if the agent needs to send a lot of data to the tool, and it has to pack and format all that input data as CLI params, and you can start seeing problems with the Bash command syntax being improperly escaped. That problem is solved by MCP thanks to using JSON-RPC over stdin.
Summary.. you shouldn't use MCP for everything, but there is a time and a place for it. Which is what the experienced devs have been saying about MCP for over a year now.
I have mixed feelings about this. Going all-in on Model Context Protocol (MCP) is definitely a bad idea because I noticed the Jira and GitLab MCPs were consuming an excessive amount of tokens. To solve this, I decided to install their respective CLIs instead so we could find a balance and get the best of both worlds.
For example, certain MCPs bring too much overhead, especially when they only handle a single task. Instead of letting the coding agent constantly waste resources re-discovering how to fetch a specific work item field, I had Claude recursively run --help on the CLIs and save all possible actions into separate Markdown files.
This approach allowed me to build two lightweight plugins that do exactly what an MCP is supposed to do but with significantly less token consumption. If anyone wants to check out the code or use them, I have open-sourced both repositories on my profile:
*
* acli-skills: An Atlassian CLI agent skill that maps out Jira commands cleanly.
* glab-skills: A GitLab CLI companion built directly for efficient agent workflows.
*
To maintain visibility with this setup, we also developed a custom [Claude Code](https://code.claude.com/docs/en/plugins) plugin that streams live updates regarding our background operations directly into the console.
That said, MCPs are still extremely useful for rapid prototyping and when we build custom internal tools to speed up development. We found them particularly valuable for:
*
* Sampling: Asking the LLM directly to detect entities and summarize log files.
* Notifications: Handling long-running tasks that require fetching data from multiple sources. By logging each step and aggregating them via sampling, a single update is sent back to the coding agent, preventing it from spinning up multiple redundant processes.
*
Maybe I'm not "using it right" but I often spin up my own MCPs as an authorisation control mechanism, as a wrapper around existing tools. For example, an MCP server that can only do GET requests. This way I can stay relatively secure about the fact that when the agent uses the MCP, it isn't going to mistakenly execute something I didn't want it to.
I know there are other ways to achieve this but to me this, but they all seem "soft" controls - a hard limitation feels more reassuring than simply a line in context that says "don't do this".
In the spirit of the linked post, one could argue I should just write cli wrappers - but I think I like the explicit routing of `Agent -> MCP -> available tools` instead of `Agent -> available tools`. The former lets me control the surface available to the agent. While LLMs are smarter now, at the same time, the applications that use those LLMs have become more assuming of what I want to allow them to do. I don't want to be one hallucination away from a disaster.
Best idea in the article, and I'm going to try it out later today:
We should start to standardize how agents use HTTP APIs directly. For example, agent clients could attach headers to identify themselves as agents, and servers could automatically send them response data as Markdown or text instead of HTML or verbose JSON.
I honestly never really thought much about this, but there is a level of awesome to it especially when it makes zero sense to have 50 words of text accompanied 6.5MB of markup, scripts and styles. The experiment went well... and it worked extremely well.
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.
I think there's at least one thing that MCPs get right, and it's that they make it easier to establish permission boundaries when agents are working with third part services and applications. Even with Claude from the terminal, MCP makes it easier for folks to standardize separate permissions and operations for general agent use than making people have to have multiple complicated API keys. Do I think it's the best solution for that? Not really, but I think it's probably better and on average safer than giving agents unfettered access to credentials to do anything, which seems like it'd be the default without MCP. That said, I can see MCP being replace with some sort of permission and sandbox system that's more generalized.
CLI, API, MCP are all useful ways to connect. It just depends on the use case you're going for. I've used all 3 and find that they all have benefits.
MCPs are great when you just want that native out of the box low mistake way for agents to call your services it's great for certain cases.
I also developed a new method of using MCP called ADP (Agent Delegation Protocol) that sits on top of MCP where there is only 1 tool for the MCP, and when the agent wants to do something it just issues natural language commands and the ADP engine handles the rest it does all the routing etc... to the right sub-agents and executes tasks and return the results. (more on this soon).
Internally if you have a good orchestration system you do not need MCPs and can use APIs but those APIs should be designed for agents, IE based on DSLs, that project into internal operations. I do this too.
CLIs are great for testing things out, but agents often get things wrong, it's great for experimenting to see what works out of the box and what doesn't.
For me the perfect medium is a mix of MCPs and APIs. APIs are cheap if designed well, and if your workflow is a DAG then APIs are especially good because you already have a deterministic flow which means you can use small LLMs or even just something like Jev.
So my summary is:
CLI - Great for out of the box, things that are well known, where you want to verify the output
API - Great for low-cost large volume, highly repeatable workflows, that require high reliability you want your agent to execute without you having to hand hold.
MCP - Great for building debugging systems, or as an entry point to more complex workflows that you need your agent to have some ability to orchestrate.
I'm using MCP with ADP to route to large workflows that execute APIs internally for what i'm working on. So it's a mixture.
The major advantage of CLI is IMHO that you can use a CLI yourself too. It's a universal tool.
One thing I hate is when people write an MCP server for something useful and just that. Like, why don't you tell the same Claude or Codex instance you wrote to also expose the same functionalities as a CLI? The problem is that it's full of technical people with zero CLI knowledge nowadays (or, rather, for the last 20 years or so), and it kinda sucks in general, because lots of stuff only comes in GUIs that are not composable, not scriptable and sure as heck full of stupid bugs and limitations due to how harder it is to get GUIs right compared to popping out a "dowhateverctl" kind of tool
In many companies, the process for launching/updating a hosted service like remote MCP is very different than distributing compiled or open source client code.
I have used Unity and Blender MCPs and I am not sure I am seeing why this is not a needed concept (or is a bad implementation).
If Unity updates the version (and the MCP server with it) - my agents immediately see the new surface. They weren't trained on the features of the new version of Unity, but they know about them as soon as they are added.
Context bloat is a thing - but you only turn on the MCP servers for what you are actually working with. If I am only in Blender, I don't need the Unity MCP. So it can be disabled.
These are just two example pieces of software but the concept applies to all of them with MCPs.
These articles always assume the MCP is being used by technical people. MCP can be used via plugins on OpenAI/Claude marketplaces by random corporate users who don't know what a terminal is.
Correct me if I'm wrong, but an MCP server still make a lot of sense for remote-controlling a UI application (like a game engine editor) which otherwise doesn't have any 'access points' for remote-control right?
An AmigaOS-style "scripting port" would work just as well, but AFAIK that's essentially what an MCP server is (a socket that implements a discoverable command protocol).
I would actually love if all applications and services could agree on a standard for scripting / remote-control. If the AI hype is what it takes to get there, then so be it ;)
Of course you can raw dog it with "computer use" and just have the agent click around the UI, but exposing semantic actions directly from the site seems like a much cleaner interface.
I find it hard to agree that MCP merely wraps a simple API.
Sometimes a filtered model-specific interface is needed.
MCP is one of those interfaces.
In our SaaS service, sensitive information can be viewed via REST, but since MCPs may be exposed to LLMs, they are blocked from going outside.
MCP systems always felt like hacks. I haven't ever found one that satisfactorily interacted with a system as well as a good command line tool.
They provide interaction for most of your GUI programs but often the limitations of the MCP systems leaves agents highly confused about how to execute something you see on screen, where command line systems the agents seem to work 99% of the time.
Both MCP and other APIs put you at the mercy of the other party. Often that means that features will unintentionally drift from the "source of truth" human UI. At worst, capabilities will be intentionally limited.
Automating the human UI used to be difficult and fragile, but modern AI makes it much easier and change resilient.
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.
Isn't the whole point of an MCP is to increase somehow the determinism of how to communicate with a certain external system? MCPs feel to give easier guidance to the LLMs, rather than letting them extracting the knowledge on how to connect to a given system.
Without, I feel they are more confused on how to get an outcome, as they may try, infra or inter sessions, different approaches
The exact same thing has been discussed many times here on HN and elsewhere, yet the author did not bother to just look them up before posting these uninformed opinions, as if they just discovered something new. It seems a complete waste of time to go to a conference on MCP with that kind of understanding.
With MCP or HTTP, how do you implicitly limit access of the agent to a particular user? In other words, how do you avoid giving the agent access to perform an operation for any injected user? This is a basic security question.
I can do this trivially when my tool functions are closures that have the user-id pre-bound, but with MCP and HTTP I naively assume that the callables are pre-set.
LLMs were a bad idea. MCPs were the band-aid to get them closer to the real world and do something for recursive self improvement. Then LLMs became better suited for everyday use.
I'm tired of these kind of posts. This author is on my black pill list.
MCP is an incomplete abstraction. It solves things in the right direction, allowing agents to interact with some given system via a controlled ingress. It's a fancy proxy, and by itself doesn't really do much to enable autonomous interactions.
The real value of MCPs lays in providing a controlled interface to models.
The benefits of control are multiple; models getting better means that, if necessary, they can go around the limitations, but generally their adherence to it is desired.
MCP is basically RPC, and it suffers all the problems of RPC like mechanisms. It has long round trips times, significant de/marshalling costs, coupling between caller and consumer, versioning issues, etc.
Over time I think we'll see an evolution towards client-side micro models that reduces RTT latency, and a message bus architecture that allows multiple local micro models to push queries to the server, continue working, and receive updates on various topic asynchronously. The channels or topics (like a blackboard system) would be accessible to multiple local agents, as would the results of tool calls.
Message bus systems are easier to version, write adapters for and debug than random CLI tools and web interfaces. MCP interfaces are not going anywhere, they are just evolving.
Just have a route that describes your API endpoints in a machine readable format, eventually they'll come to some consensus and in the mean time this works well enough to allow LLMs to plan.
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...
I use myself the DaisyUI Blueprint MCP and it's totally worth it. Not even fable 5.1 without all that context and way of directing could work this well. At least, I feel is worth paying for that MCP.
If you haven’t checked out AXI as an alternative to MCP I recommend checking it out. I’ve started wrapping almost every cli or MCP in an AXI bin as it’s more reliable and uses fewer tokens.
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.
It is all useful, and depends on the distribution channel and surface complexity.
I use both MCP and CLI in my case.
Having the CLI allows you to have the huge application with the big surface be available to the AI agent and so they'll be able to learn it on demand. For example my app has more than 1,000 help pages. There are no other ways to load all this information into the CLI context and to be frank it will be quite stupid. Instead I use progressive discovery.
It first reads the original help message to understand which stage of the flow it is right now. It auto-discovers the topics through the error messages and through the various hints. It has an Elasticsearch-like search inside its own help command so it's a full self-contained application with self-discoverability, which has a graph, ontology and the full developing flows inside of it. All of those parts are automatically given to the AI only when it actually needs them.
And to be frank if you look at the latest YCombinator batch, all of the companies are building the custom harness. What I'm calling above CLI is actually a custom harness, which is running inside someone else's agent group.
Having remote MCP allows me to give limited read-only surface to clients which not supposed to run any CLI commands. And while MCP has similar patterns, like bundling docs and prompts, it is not as flexible as CLI and does not allow huge scale.
Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
MCP is an abstraction for remote tool calls with a standard interface. More specifically it's for when a local CLI will not do, and you want determinism and standardization. It also avoids all of the potential errors and guesswork involved with a model trying to "figure out" how to do something; you simply make one standard call, and the remote side "figures it out" for you, without failure.
If you can do what you need to do without MCP, then don't use MCP. When you eventually get sick of AIs playing guessing games with local tools/data, or spending lots of time to get functionality somebody already published as an MCP, or you need isolated control over the execution, maybe check it out again.
> Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
Yeah that's me. Idk what MCP is really, just that there's always some auth issue with it and I've never actually needed it. Is it dead yet?
Think of MCP as a universal CLI tool for anything you can imagine running on a server (remote!). Even if you wanted to use a local CLI tool to call some remote server command, local CLI tools have different input/output formats, different commands/options, and those tools change over time. MCP doesn't change, it always tells the AI exactly how to call it, the calls always use the same format, it includes a standard, quite secure method of authentication, and it's all done in an AI-friendly way. And because of all of this, it uses less tokens, and has a much higher likelihood of success (e.g. AI tools failing to call CLI tools properly and looping trying to figure out the right arguments/input/output).
Now, if you don't care about authentication, don't care about wasted tokens, don't care about the AI screwing up CLI tool calls or needing to be trained on every one, and if you don't need to call something on a server, then MCP is useless to you.
In that case, you can use a skill calling an HTTP+JSON endpoint. Or if you mean it's literally a remote CLI, so it needs bidi streaming, that's what websockets is for (or gRPC but ehh). Those are well-established. MCP sounds like one of those "we need yet another a new standard, this time to rule them all" things.
Yeah that still fails a ton. A skill will mess up the call, not know how to handle errors correctly, not flag an error as an error (false positive), hallucinate, require custom input/output formats, require custom code to validate, won't handle authentication the same way, you'll need a unique skill for each endpoint, you need to version the skill, and of course there needs to be an endpoint, as well as all of the tools needed on the client machine to process everything, hoping of course that they're the right version.
Compare that to MCP. One standard tool call. Works on every agent. Everything built in. Determinism. Reliability. Simplicity. It just works.
Skills are non-deterministic balls of mud. MCP are deterministic standard tool calls. MCP solves all the problems. A skill can't do what MCP does.
In terms of "using standards" to solve the problems, tell me 3 different APIs (from different companies) that have identical input format, identical output format, identical request URI format, identical headers, identical methods, identical auth. You won't find them, because everyone implements their API differently. You can use 50 different standards 50 different ways, and still not solve the problems mentioned above. MCP is one standard that works one way and actually solves all the problems.
And this is just addressing the client-side problems. There's a whole world of server side (logging, tracing, auth, execution, etc) that's not standard either, unless you use MCP.
I've cut token counts significantly for some of my MCP servers by returning csv or tabular data or sometimes even just good old fashioned plaintext "template style" words. JSON is highly repetitious. In some instances like 30% or more of the token response was just boilerplate JSON.
Once you realize that to an LLM JSON is just a stream of tokens no different than XML, markdown, or a punctuation-less stream of conciseness.... you start to realize there is no reason not to just make up your own crazy formats. The LLM isn't throw parsing errors if your MCP is returning something other than JSON. The LLM is smart enough to figure it out. It's far more important to make sure your tool descriptions and parameter descriptions properly "market" what it is you do (and dont do) than return syntactically correct JSON.
Same with versioning.... it's all ephemeral. There is no backwards compatibility to speak of with MCP (at least for tooling "contracts".... what the tool actually does however... that is a different level and is product requirements not API contracts).
Related to this discussion, I have written a manifesto against the excessive usage of MCP and other "tools" when using coding agents. I believe sticking to the basics yields the better quality overall in output
Bad take. And what's coming down the pipe with MCP will cement it. Has less with the model calling tools and will become about tools calling models. There is no unified integration into harnesses to support this other than MCP.
What legal responsibility would they take on by not using it, in specific? I can only think of defamation or something but I doubt a question mark covers you for that.
"legal" in media companies. It's a loophole in law where if you phrase something as a question, you are not claiming as truth.
Say the media claims, "Your mom could be the murder suspect?" You are not technically saying yo mama is a murder suspect though it is implied so.
Media companies won't be prosecuted for any "wrong info" for such titles by law because it's a "question".
Same here for the blog post. It's framing as a question, not taking a responsibility that (though author implies so) he is claming MCP is a bad idea wihtout owning it.
MCP is now only good at getting credentials from any source. If SaaS cared about their API the same way we would have OAuth for all APIs, MCP would just die
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.
Couldn't agree more. MCP is just Tool Use and the terminal agents all have embedded tool uses like WebSearch, Bash, Grep, etc and those are just MCP by another name. CLI's called by a model are just Bash Tool usage calls. Bash tool is just the most open ended broad MCP you can expose and what you gain is less context bloat (no specialized tool descriptions, just Bash) and what you lose is control over the agent -- until you setup a rigorous set of governing permissions on the Bash Tool.
I have a fleet of sandboxed Claude Code instances running and they share files with each other. The files are stored on AWS but they don't have access to AWS at all -- they can't see the access keys. In fact they don't know the files are on AWS. Instead they have a set of MCP tools for listing/uploading/downloading from an internal, virtual filesystem with a special URI handler (ie agentfiles://somefile.json) and the outer orchestrator of the Claude Code instances takes the MCP requests and does the actual file manipulation on Claude's behalf. The LLM seems to adapt quite well to this strange, arbitrary filesystem and I get to keep these agents fully compartmentalized. And I have tool request logs and logs in the outer orchestrator for full auditing of the agents. MCP is a really natural fit for this kind of stuff.
> MCP is just Tool Use
I wish. https://modelcontextprotocol.io/specification/2026-07-28
The spec describes Resources, Prompts, Tools, and Elicitation.
In practice, I believe Tools represent 95%+ of what people actually use MCP for. I've not seen an MCP with Resources or Prompts that seems to have widespread use of those features, and I don't think I've ever seen anything implement Elicitation.
> what you gain is less context bloat (no specialized tool descriptions, just Bash)
Couldn't they train the understanding of a specific tool set directly into the model instead of needing it to be in context? Like isn't that basically what happens now with the Bash tool?
Is there a reason we need to rely on such a high level of access for something that should really only ever be cleaning up the project directory, hitting the 'Run Test' button and authoring some Git commits?
Perhaps a little out of date now, but I found claude was better (trained?) with the gh command line than with the github mcp. For a $corp internal tool ... I don't really see how and LLM would be able to be trained on it.
MCP definitely has its niche in certain environments. It's good for a specific kind of constrained problem; not so constrained that you could solve the problem with just Node.js + fetch call to LLM API but not so open that you'd want to let the AI agent directly invoke any service it wants over the web. The latter is what happens if you give the agent access to curl.
Though I agree with OP's point of view that MCP was overhyped for too many use cases. Complex agent-system integration problems are usually better solved with just AI agent + curl + SKILL.md. It's just way more flexible.
It's another variant of the 'fat client/thin server vs thin client/fat server' debate. Some people want rigid, thin (e.g. web-based) frontends with the LLM doing work in secret behind the scenes. Others want fat, versatile frontends through which the LLM can interact with the user's own environment.
I've always been a fat client guy and this time is no exception. I doubt the constrained approach is going to lead ground-breaking innovation. I also wish companies would treat SKILL.md + curl as the main mechanism for agent tool calling as opposed to MCP. MCP is niche.
That niche environment is all SaaS-to-SaaS integrations. The client doesn't want to have users struggling to get every integration working on their platform. The service providers don't want to have to support non-standarized behavior by every client.
[flagged]
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.
The simplified interactions are how it should have been designed in the first place.
It's difficult to come up with the optimal workflow on the first try. So an API should typically start out flexible even at the expense of complexity, in order to enable experimentation, and then you can optimize to make the common case simple, once you know what the common case is.
Sure but that common case should go into the core APIs, not an MCP.
agreed lots of ppl writing mcp as a lipstick on the pig.
MCP is exactly the lipstick we needed to put on our pigs, APIs that is not ours, but open source tools we use internally and also wanted to expose to our agents.
[dead]
Yea my company is willing to pour money into an MCP but has concretely resisted attempts to improve or care about the API for years.
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.
Retrieving messages from Slack over MCP allows a shared read-only bot account accessible from the web browser and CLI. Setup is automated so users can just ask Claude to read them and do something.
Sharing Slack with Claude:
- Using the "normal" way, it shares too much, including privates messages.
- Using your own token, it doesn't work with Claude.AI or Cowork and requires you to go to slack.com to generate an application, tokens and more.
- Using a shared token, now you need context to tell Claude to retrieve it. It still doesn't work for non-Claude Code workflows. Rotation may break currently running workflows.
Yeah that's a good idea. Then we should standardize these tools and find an easy way for agents to discover and use them. ... Oh wait
And call it not-closed API or something like that.
Congrats you just invented the Unix shell!
[flagged]
Just tell the clanker to read the api documentation that should already exist. You dont need an MCP server for that.
Yes, having LLMs write deterministic programs is still an under used solution.
Less token spend, lower latency, more predictable results compared to having the LLM perform the task directly every time.
Yeah. Like I had Claude code write an upload Slab script, and a few linear integration scripts, now it just runs these to interact with those systems. I had it write a redshift proxy that doesn’t take login creds and is just a logging read only account but it can just write sql to research to its hearts content (some columns hashed on replies) and I don’t need much trust but I get a lot of good analysis and verification done.
> 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.
The MCP is the deterministic program.
You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface.
It's the interface for your deterministic program. That's it.
they were suggesting that you take the agent out of the run time tool usage
> they were suggesting that you take the agent out of the run time tool usage
That only applies if you are talking about a well established recurrent workflow. That's not how MCPs are used to begin with.
It's easier if you started a while back shunning all human labor (including your own) in favor of fully deterministic systems. Reality is deterministic so your company or project logically can be run off a single compiled binary with formal verification of correctness for every possible scenario.
Heisenberg begs to differ with your view of reality.
So does Gödel. Maybe it was a joke? Unclear.
A protocol is not a program.
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.
> there's almost no reason to use MCPs if you are running a full-blown terminal agent
I disagree. Adding "https://mcp.linear.app/mcp" and having everything happen (discovery, usage, updates to the API, etc) without having to install or configure anything else locally is a big deal.
Funny you mention Linear’s specifically, I just posted about moving to a CLI instead because of the MCP’s egregious token-usage [1]. While this doesn’t discount the points you mentioned, I think the context savings (which can be huge, I hadn’t listed all differences in that post) outweigh them specifically in Linear’s case. It is just too inefficient in that regard.
Edit: this of course says nothing about MCP vs API/CLI in general. It’s just a bad implementation by Linear.
1: https://thebiglog.com/links/linear-cli-instead-of-linear-mcp
This surprises me a bit. I've found much better token usage with a proper/efficient MCP as even with a deep /skill defining usage, parsing MCP results is generally just better/more efficient than parsing CLI results. I say this having written a CLI tool explicitly for harness usage, and leveraging MCPs for the same.
I'm sure there are bad MCPs and great CLI tools that parse poorly/well via harness, but I'd be curious on an better research study.
Your comment doesn’t contradict mine and mine doesn’t contradict yours. Linear’s MCP is just (very?) inefficient. I explain the source of the difference in the last two paragraphs.
How much are using Linear if token usage is a problem? Sounds like a case of straining at a gnat and swallowing a camel.
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.
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".
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.
> 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.
Exactly. A lot of people complaining about MCP are doing so because their only interactions with LLMs are via big batteries including code harnesses and don't understand what kind of (usually much more domain-specific) agentic systems are being built. For example, "CLI vs MCP" doesn't make any sense whatsoever if the agent doesn't have access to a CLI!
MCP suffers from its harebrained choice early on to load everything into context up front.
The other problem with MCPs is that the harnesses don't auto-reconnect if you've enabled access. Connection status should be persistent
[flagged]
Exactly. There are so many replies here of the form “MCP sucks. If you just do <all the things mcp does a different way> you don’t need mcp at all.”
Well yes.
I think the point of those comments is this could have been much simpler for everyone if the model providers had given us some tools around existing standards.
Instead they invented something new/weird/complex standard, and then every client implemented slightly differently (and different parts of it).
> Exactly. There are so many replies here of the form “MCP sucks. If you just do <all the things mcp does a different way> you don’t need mcp at all.”
See my previous reply to simonw elsethread.
It's not "If you just do <all the things mcp does a different way> you don’t need mcp at all", it's that many of us were already doing that in a CLI prior to LLMs. You think only github and amazon had CLI clients?
As someone who has never used MCP, or allowed an AI to directly talk to APIs, putting something between a model and a service just seems like common sense. If nothing else, it presents an opportunity to tightly control what the AI is allowed to do with external services, especially if the MCP code is outside of the AI's context. I would go as far as to say it's a necessary security measure.
The service itself needs to control what the agent can access.
Relying on an intermediary to provide access controls, and that agents will never access the service directly, seems dangerous and naive.
And it's easy for the service to do that by hosting a remote MCP server.
Agent doesn't have api key to access service directly
What? Why? More is more but you're arguing a security proxy is a dangerous and naive pattern?
What’s the advantage of MCP over a regular old security proxy?
The better solution for security is sandbox execution. Most agents used in practice, if given terminal access, can find ways to get around most of the MCP restrictions.
well if you realease an api you should make sure its usable for ai out of box without 'something in between'. You should always assume ai might be directly calling your api.
Ai can't use any api out of box. It requires thing called "harness" to use anything.
And if you don't have a public API, you should always assume AI will be using your UI, reverse engineering your private API, and driving it directly.
I absolutely love when they do that unprompted. I once asked a Claude work agent to go pull comparable apartment listings and somehow it’s subagent reverse engineered like rentcafe or whatever’s private API to get the data. All unprompted.
So yes. Absolutely assume AI agents acting on behalf of their humans are finding all the token efficient ways to get at your sites data.
I feel like this would build a false sense of security.
Authentication and access controls must be able to withstand an agent with full shell access. And auditing must be on the server side to provide a full picture of all activity from all clients, whether human or agent.
We must treat agents as clever humans and secure and audit data access accordingly. The era of thinking we can handle agent access to sensitive information differently from human access has passed.
My point about MCPs here is that they provide a way to make those secrets and API keys deterministically inaccessible to the agents - even agents that's have a shell execution environment.
That's the opposite of a false sense of security.
I noticed the security aspect to be one of the main selling points in corporations for going MCP (and one aspect that is underrepresented here).
However, maybe I'm missing something but how is defining access rights in an application layer the agent has access to more secure than defining the access rights at the target application itself?
Sure, hiding the filesystem via encapsulation tricks is one way to go. But what is the real-world usage-style of this vs. all MCP usages? I'd wager 1-10% are spending this extra effort, while 90% of users basically run shims so that they can expose APIs to their LLMs, for which they have no/bad access rights management.
just use an api gateway (ie., a reverse proxy for apis), eg., envoy. This should also be connected to observability and finops style management anyway rather than leaving it to model providers.
Without tools LLMs can do nothing more than emit text. You are probably assuming a harness is provided to the LLM with shell access but that is absolutely not necessary for LLM usage depending on the use case. For interesting stuff, you do want to provide some tools, but nothing with the power of a terminal if you are worried about security. A MCP server is perfect to securely provide the LLM with some controlled power exactly because it can do nothing at all other than call tools that go through the MCP server and can therefore be scrutinized, audited and ensure credentials are not visible to the LLM.
> This article entirely misses the value that MCP brings today.
Well, me too. I see the only advantage over a CLI app being an agreed-upon convention for syntax (not semantics).
I have a CLI interface to my webapp, not an MCP.
> 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
Access control is not built into my CLI, it's built into the WebApp.
> 2. A way to handle authentication that doesn't allow the agent to directly access API keys
My CLI takes credentials from the environment, which it uses to talk to endpoints. The caller sets the environment, then calls the CLI program. The caller provides no way for anyone sending it input (the Model) to request or retrieve environment variables.
> 3. A sensible UI to allow users to connect and authenticate further services
The parts of my WebApp that relays or re-requests to other third-party services handles access control.
> 4. Strong audit logging for what's going on
Not sure what this is supposed to mean: the WebApp already has auditing logs.
> MCP makes all of that so much easier to provide.
Sure; I'm considering writing a purely deterministic shim for MCP around my CLI. The semantic/information is the same, the only difference is syntactical in nature.
> 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.
It may as well be; coding agents are at one end of the control spectrum - run in bash, do anything/everything (so they can leak credentials to the model, or the harness). But a CLI app doesn't have to allow bash. My "harness" (using the term very loosely) can securely call other programs without giving its own caller a RCE via bash.
So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself?
Sounds to me like MCP with a slightly different interface.
> So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself?
Yes, with the difference being it can call other CLIs, just not arbitrary CLIs.
> Sounds to me like MCP with a slightly different interface.
It is, except that it is not limited to being called from harnesses. Also usable from bash (automated scripts), or even humans if hey want to run it on the command-line.
TBH, my webapp(s) had this prior to 2020, because it made automation simpler so I could write shell scripts to do various things on the WebApp.
I did end up building my own CLI for calling MCPs, mainly to better understand the protocol but also to make them easier for me to interactively debug: https://github.com/simonw/mcp-explorer
Even for coding agents. MCP is the only unified interface INTO harnesses. This pattern has not struck yet for most, but will soon in the coming months given the MCP spec. MCP has been about models calling tools., it is about to become some form of inverse and MCP will be the only actual way to integrate into the models. Simple example is sending an event to the model (today models have to poll)... these coming updates will cement MCP as permanent infrastructure.
All of these things are perfectly possible with a plain REST API with an Open API spec and using some standard auth options, and an AI client that implements a reasonable “make api request tool” (just like the AI clients implement MCP today).
I think the real value of MCP is that it allowed companies to say “we’re doing AI!” When they built an MCP server. Just saying “use our api” was a lot less exciting.
Giving it a different name probably also helped cut through politics at companies where non-technical people didn’t want to open up user data with an API, but they did want to do AI.
Hah, I made that same point last December: https://simonwillison.net/2025/Dec/31/the-year-in-llms/#the-...
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
I've since come back to MCPs, because I want to build my own agents without first having to solve the problem of effectively sandboxing Bash.
Yeah, from a design perspective MCP upsets me, because it’s a poorly designed standard and creating a good one could have been much easier.
But you’re right, since clients don’t have a nicely sandboxed “make api request” tool, it’s basically the way to go for a lot of use cases.
I think the new 07-28 spec is quite decent
Understood but it seems like effectively sandboxing cash is a very very important problem for the industry to solve!
Would be a much more robust and general solution of the problem of controlling and auditing agentic access to sensitive information.
It's such an important problem that it is sucking all available VC money into an exponentially-growing number of startups promising to make sandboxed agents safe and usable. In other news, MCP exists.
Honest question: which startups are trying to write a sandboxed-by-default easy to configure bash meant to be safely used by agents?
It's not "bash", it's containers/VMs/whatever that are isolated from the host and run the agent, which can access a shell to do work.
"without first having to solve the problem of effectively sandboxing Bash"
Hopefully this is easier as time goes on. Of course- also policy on the egress
> without first having to solve the problem of effectively sandboxing Bash
"Sandboxing bash" is a problem that has been solved a zillion years ago already. Take your pick of any of the dozens of battle-proven solutions.
Which solution do you recommend?
Bonus points if it's available on both macOS and Linux and doesn't come from a random unmaintained GitHub repository with a note in the README that says "don't run this in production".
"Battle-proven" until an LLM decides it really needs to escape the sandbox you put it in and eventually succeeds.
For personal work, I run Codex in a VM that contains only what's necessary to do software development. Could it escape the VM? Sure, if there's a zero-day in VMWare Workstation.
Yeah, I'm using a pile driver when I really probably just need a hammer, but I've seen too many horror stories, and I don't trust guard rails. Even if there was an option to limit Bash calls to read-only operations, I would be 0% surprised to eventually run into "You're absolutely right! `rm -rf / --no-preserve-root` was a write operation! That's totally on me."
What do you mean by sandboxing bash? Isn’t this about just having a tool like curl or Postman?
Implanting an MCP client in your agent code isn’t all that different from calling requests or whatever
I mean the ability to have an agent run commands in a Bash shell without allowing them access to any file or environment variable visible to the user on that computer, and without allowing them uncontrolled internet access.
Program specific permissions (separate from the user operating them) are part of the Linux permissioning system already right? That doesn’t seem like an issue to me.
I guess the main problem would be finding an API client that can easily plug into your harness, with a nice UI for turning specific APIs on and off.
MCP is one of those things that is "too good enough".
> For a while it also felt like MCP was a convenient answer for companies that were under pressure to have “an AI strategy” but didn’t really know how to do that.
MCP was a convenient answer for companies that had spent the last few years shutting down APIs because allowing API access bad.
Pretty much, MCP is still a bad idea.
LLMs perform significantly better and faster when you strap them to plain old apis/and an open api spec with a search tool.
My current MCP design is… grab a fastapi spec shove it into fastmcp, shallow wrapper, search tool for the full schema.
Oh boy so exciting I just wrapped an api spec for no reason and have to host infra for the translation layer. If only we invented api gateways.
But I am Mr. AI now.
How do you handle credentials safely?
You mean oauth? API keys?
API gateway is a thing…
Just leak them to the inference providers, obviously /s
If you have self hosted models and/or self hosted APIs, maybe you don’t need MCP to provide a gateway to a secure resource.
If neither of those things are true, you need an authenticating gateway/proxy or a target API that supports single use credentials (and get the model to generate a call to use them).
We can argue whether MCP is a good authenticating middle layer, but not whether one is required.
What about just handing the agent a token with limited time to live and constrained access permissions?
it's mostly true but the mcp also installs the knowledge of that REST API in a standard way so that a user can ask "what's projected revenue this month?" and it'll know how to hit your company brain and answer
Or just write good API docs that humans can use too.
most users i'm dealing with are not doc-reading developers. even getting them to tell claude to use tool X is pretty hit or miss whereas claude already knowing what tool to use is 100% hit with correct mcp tool descriptions.
The article also doesn't contemplate the "skill distribution problem" which will be addressed by skills-over-mcp.
With the plain ol' API solution, you still need some way for agents to fetch the instructions provided by the service. Of course there are answers for this, but they are not standardized.
With MCP, all you have to do is provide the harness with a single URL and all context can be bootstrapped the same way for every service.
> 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.
I don't think this is a valid statement too. I'll explain why.
A MCP server represents those APIs that agents and coding assistants can call.
If you feel a need to provide data and services to agents through an API and feel so strongly about it and so compelled to implement your own APIs with the express purpose of being consumed by your agents, wouldn't it make sense to develop an API that is designed purposely for agents using a protocol designed to meet their needs and simplify their work?
Because that's what MCP is all about.
Nowadays, with the improvements in tool-calling and the dissemination of agent skills, MCP's value proposition isn't as clear as back when those weren't a given. But once you face usecases to either centralize your tools across an organization, manage access, and be able to audit it's usage, right now there is no alternative to MCP.
Agents are perfectly capable of using the same APIs designed for humans.
All of that can be solved in better ways than MCP. 1+2+4 belongs to sandboxing. 3 to sandbox UIs. Ideally baked into the next generation OSs.
MCP is the wrong abstraction for all of that. Skills are better as pluggable interfaces, and I predict[0] chat and agentic loops will converge eventually (Anthropic already did this correctly; OpenAI, it's your turn) and skills marketplace will replace MCP in its current form.
I see value in MCP, but it feels like a stopgap/stepping stone.
[0] Where "predict" = "hope". The best solutions are often not the winners.
Skills are adjacent to MCP. They do not cover the same surface, in anyway. I don't understand this argument at all (and I see lots of people making it, so enlighten me)
I want my agent to be able to convert reliably between timezones. A skill does not solve this. It needs a deterministic tool it can call
Skills are not only Markdown files. I often structure my skills as small Python scripts and the actual Markdown is only the skill front matter and maybe some brief documentation. You can even stick an OpenAPI schema or whatever you see fit.
If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed. It's just files, all the way down. If you find yourself operating with dates a lot maybe you need a `datetime` skill wrapping a bunch of tiny scripts. Fully deterministic, cheap on tokens, and you can even run them without an agent (shocking nowadays :P)
As I identify repetitive actions I add (Claude adds) new scripts to the Skill to save tokens in the future, whereas MCP I'm at the mercy of the server provider. E.g. I have a Magic the Gathering skill with a bunch of tools to retrieve card databases, simulate hands, get card images...
This article enlightened me: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-ne...
This is why I don't feel Skills are orthogonal. They feel like MCP on steroids since the scripts can be composed with Bash et al (huge battle-tested ecosystem, plenty in the training set)... and you don't need crappy abstractions like "resources" (yes, that's a thing in MCP) when the agent has a shell and a filesystem.
I've used this pattern to great success. Nowadays I just share these `.skill` packages with my friends (I think they're just a fancy ZIP file?)
The only thing missing for me is credentials and sandboxing (see my GP post). I have my own ideas on how to solve this (and some of that Claude in cloud already solves for me), but it's not easy (which is how MCP won).
> If you often need timezone conversion, sounds like a `timezones` skill exposing a few lines in a Python script. Boom. No MCP needed. No server needed
okay, but now my agent needs a coding environment / sandbox.
MCP (or tool use in general) solves this without that (extremely tenuous and expensive to do at scale in prd) requirement.
The skill is totally orthogonal here--solving a totally separate problem
I guess someone could expose the coding environment via MCP.
They could and code execution is actually exposed to the model as a tool!
But if im running a customer support agent at scale, i'm not sure I want it to be able to write code. I do know I need it to be able to convert timezones though. (its also far more expensive / token inefficient to have it write code each time to convert timezones rather to use a predefined tool I made an know works)
> token inefficient to have it write code
It does not write code. It just calls my tool.
But I see your other points though.
> MCP makes all of that so much easier to provide.
Easier being the key!
Right now it really does feel like early web days where like 5% of the population is adopting things, but most people just get confused and don't participate.
This is why I'm pretty excited about WebMCP in particular!
WebMCP aligns more stakeholders than pure MCP - which seems heavily biased towards model providers. It also seems like it has the potential for a much cleaner ux.
A CLI doing all this is still a better UI for the agent though.
What if I don't want my agent to have terminal access though? I get the feeling many people here simply never worked with smaller models, those will confuse cli args really quickly once context expands, and then you have no idea what damage they might do. With MCP's, they get just the access they actually need. Is the Principle of least privilege just not something we want to apply anymore?
CLIs, run in a sandbox as tight as your preferred choosing, live in an ecosystem, where, via pipes and redirection, input and output can be easily manipulated. An agent can do similar things but more laboriously (and less token efficiently) via Python or similar but it would still live in a sandbox somewhere.
Going without the sandbox means hobbling the LLM. It can do things directly but is less able to construct ad-hoc programs to deal with looping, conditionality, tame verbosity, connect tools together, and so on.
It's a choice to not give the LLM an environment. As you say, it can be necessary if you're using dumb models. I don't find it particularly worth the trade most of the time.
If not even OpenAI can properly box in their models I definitely won't trust myself to do so with the very limited time available to me, and instead just use a standard that's already defined, and proven to work.
By OpenAI, I presume you mean Irregular - these guys https://www.irregular.com/about ?
These guys are the common factor, the guys running the evals that let all the AI agents out, it looks like.
What if the agent doesn't have a CLI?
You hobble the expressiveness of the LLM and reduce its capability.
Think of an agentic harness as like a kind of body for the LLM. It gives it primitive inputs (read_file, web_search or whatever) and primitive outputs (edit file, respond to user, etc). Give it a command line environment (in a locked down sandbox, with as few or as many tools as you prefer), and you've given it a toolbox. It can do a whole lot more, faster and more efficiently. It can compose tools together. It makes fewer transcription errors manually shifting data around. It can tame verbosity with good protections in the harness and access to grep, sed and awk.
It's really up to you how useful you want your agent to be.
Yeah but you're still assuming it's running on someone's machine with a CLI to even use.
Someone can be OpenAI/Anthropic/whomever.
If you don't have something running somewhere, you don't have an agent, you don't have a harness. You've got a token generator, an LLM from the 2024 era.
That's where you are completely wrong. The point of MCP is that you can have an agent and a harness without running raw CLI or Python commands. Very common for relatively lightweight loads that involve shuffling data around between APIs, often run in a tiny serverless task.
Sure, you have an LLM which can invoke functions. I will say that without storage and composition, you're asking for hallucination. LLMs are not deterministic and while they're good at regurgitating text - you can see how replies in an instruct model are structurally keyed off the question - they will rephrase, adjust, "correct" data they're schlepping from one call result to another call input. And one noisy MCP call and there goes your context.
You could build something with storage and composition out of MCP functions, but come on, have you seen how LLMs - particularly budget LLMs - try and invoke functions reliably? The amount of retries you have to hide, feedback you need to send back to the LLM about what it did wrong. Parameters get replaced with synonyms, arrays are passed for singular arguments and vice versa, structured inputs are flattened, etc.
So maybe you fine tune on interactions with your subset of MCPs, to improve reliability. But all you end up doing is reinventing a Unix-like command line, poorly.
Firecracker micro-VMs, gVisor, wasm sandboxes. There are ways to make this work that aren't heavyweight. Giving LLMs tools that they've seen how to use millions of times in training corpora just works better.
What does that even mean?
totally makes no sense. so weird after all this time people don’t “get” the value of MCPs, so weird
The article misses the point of MCP but he is not wrong that it was a mistake (in some ways)
The mistake of MCP was building it in such a way that it needed to be on a separate process from the API. The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years.
Now that MCP is stateless we can start building what is actually useful: extending API’s for agents.
When people ask me if they should do MCP today, I say absolutely. But because the Oauth protocol side of MCP is very good and is a net positive for all public API’s
This is not a dig at MCP, the original vision of MCP was much different from how the community used it.
> The statefullness of MCP was such a massive detour for the industry that we will be cleaning up after it for years.
I remember discovering this when i wrote my first MCP server. It was like "huh? why would they do that? what use case did they have in mind?". We've spent decades making "internet shit" as stateless as possible on the backend because making it stateful is expensive and complex if you want to have any reasonable scalability. I mean good luck trying to host a stateful service on any kind of commodity serverless "scale-to-zero" infrastructure here in 2026.
Maybe it's because these AI-labs are used to statefulness. I mean LLM-based sessions are hugely stateful if you want any kind of reasonable caching to happen and caching is the only way you can economically scale out LLM's. Seen from that perspective it kind of makes sense why they'd look at MCP and think "hey, why not make this stateful on the backend as well". Statefullness just part of their DNA.
Agree. MCP also helps in some esoteric use cases like interacting with legacy windows applications over COM. I created an MCP for Outlook 2019 desktop version and COM was the most straightforward way to let my agent interact with my mails for classification.
In essence: MPC servers are the sandbox
True but a pretty shitty sandbox and we need a less leaky and more general sandbox solution ASAP.
I've taken to sandboxing my entire agent in a Docker container. I wrote a tool that pretends to be an ACP client but is actually making Docker containers, copying files I specified in, bind-mounting, etc, and then proxying ACP via websocket to an agent in the container (except the ACP terminal/FS commands, those happen in the container).
It works well, though there is some leakiness around paths. I opted to make it place/mount files at the same path as on the host so paths are the same (as opposed to manipulating the ACP messages to modify paths on the fly, that felt messy and buggy).
Configurable networking is on my list for the future, but I haven't decided whether to start with IP-level firewalls or if it's better to start with a proxy and firewall rules to force traffic to it. IP firewalls suck for APIs that might have semi-dynamic IPs.
[1] https://github.com/SethCurry/abyss
>pretty shitty sandbox
Well, speak for yourself. My MCP servers are pretty solid.
There's nothing in the protocol making them inherently poor other than perhaps popularity, causing a swarm of people vibe-coding things they don't understand.
Real hard to not think-
"This is a job for a CLI/terminal, which is absolutely a million times easier to learn today, thanks to AI."
Feels like MCP is still a product of -- well, "AI as a product" brain, which I have no love or use for. Give EVERYONE ALL the tools.
So how do you make that CLI tool work in the context of a web client?
Also MCP allows exposition, which helps an autonomous agent understand the semantics of the API.
That's the killer feature from my PoV. I just point my agent at a URL and suddenly it knows when, why and how to use it.
Congratulations you reinvented man pages!
MCPs just misses what AI is. If you think MCP is a good idea you are confused what is going on. AI is beyond MCP. MCP is SOAP of AI.
What matters is local server or not. Using a remote server means exposure.
Were in a world where agents are more autonomous. Need stuff to be easier for agents and not humans
Still don't get what's the advantage over just adding a special API key or a wrapper cli or whatever mechanism that achieves all of that without being a "protocol" and with all the context bloat. Like the github cli is a good example. You give it proper auth keys etc. and for sure there's some telemetry in there about usage as well. If there isn't then it's easy to do from the api side too.
Even if you don't own the code or infra, like say a frontend team who wants models to test out the backend apis and do something. Well in that case how do regular devs do it? Do they also get unfettered access in the past? Surely there's still some mechanism you can repurpose for agents to use?
I'm not trying to argue I'm just saying I didn't catch on the first time mcp was a thing and I still don't know what it's doing now.
If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool. They can go as far as decompiling binaries, or rewriting them to log the key before it is used.
If you are worried about a prompt injected agent stealing your keys, that's a problem.
(There is a way around that: you can use an HTTP proxy that inserts those credentials but otherwise lives outside of the agent's realm of influence. MCP is a whole lot easier though.)
> If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool.
So, don't do that then?
Why do you need to use a full coding agent as the interface between the model and the CLI tool?
A 10-line program can do the wrapping of any existing CLI program so that environment is not leaked to the model, while providing the CLI program with the environment as well as restricting what programs can be called to a whitelist.
If you CLI program is echoing its keys in the response, or the endpoint is echoing keys back, that's not a problem that can be solved with MCP anyway.
So you're building a custom harness here that provides tools, and you're wiring up your custom harness to effectively do a subprocess execution of a CLI script for every tool call the model request?
One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls.
(That performance overhead is so trivial as to not be worth caring about, but the state thing may be useful - keeping a stateful browser session running between tool calls is harder with a CLI, for example.)
> So you're building a custom harness here that provides tools, and you're wiring up your custom harness to effectively do a subprocess execution of a CLI script for every tool call the model request?
Well, yeah. Subprocess execution is on the order of double-digit milliseconds. The "wiring up" is maintaining a whitelist of what tool commands map to which executable. It's a lookup table with very little maintenance required.
> One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls.
I feel like I am taking crazy pills :-/
The overhead of forking, on the ancient machine I call my desktop, is at most double-digit milliseconds. The state isn't being tracked by the MCP server anyway, it'll be tracked by the harness and/or the model, no?
My main reason for adding MCP support is so that existing callers that want to use my WebApp(s) can just use it without needing any changes on their side.
IOW, I am going to add it at some point, but not for the reasons you give. I'll add it to be compatible.
You didn't address my comment about state. If you're driving something like Playwright you need a way to maintain state between tool calls.
(Oddly enough I did solve that with my own CLI tool for running browsers during my "who needs MCP" phase, but it's a bit of a nasty hack that involves leaving files with PIDs lying around: https://github.com/simonw/rodney#directory-scoped-sessions and https://github.com/simonw/rodney/blob/a842432246f39775ccb14f...)
[flagged]
Why not just give the agent a short lived token with limited access rights?
We have reached the point where we need to control agent access the same way we control human access to systems.
[flagged]
[flagged]
[dead]
1. Control can be done via CLIs --> api key based access controls. We have been doing it forever. 2. I think this really only applies to Oauth based MCPs. Many server support api key based auth, stored as files --> security is still flawed imo. 3. This can be done via apis/clis too --> not something unique to MCP iimo 4. Same thing, not unique to MCP --> api servers can also be logged
MCP doesn't inherently make this easier. its still requires engineering maintaincence.
Having a standard does make sense though, because it lets agent services handle external calls in a standard way. So, for example something like Anthropic's agent platform will proxy all MCP calls and hide the credentials so that you don't have to worry about the agent leaking secrets into code/logs/the internet. Of course you could build a similar layer to proxy traffic to various APIs, but it becomes easier to make the whole thing plug and play if everyone agrees on the shape of the API (MCP).
i think standards are good for low level things. APIs change, model behvaiors change, we basically are allowing an external service provider to control our agent prompts.
The premise of the article is that the Model Context Protocol (spelling it out to emphasize the core purpose) is inefficient in its current form. We can agree to that.
Now, does it mean agents don't need a protocol to connect to a server and discover its capabilities, tools, and distributed skills? I disagree.
> Agents with terminal access can replace most MCP servers
What should all other agents that don't have terminal access do?
Aside from the actual protocol, it makes a lot of sense to have a standardized, discoverable protocol.
Because the alternative, as proposed in the article, is that an agent researches an API/CLI/UI, builds software to interact with it, and then runs that. Every time again. Not only very inefficient, it's unpredictable, and often slow.
Just last week I had an MCP that was down (my mistake) and the agent "decided" that in order to finish my request, it needed to create a python script, refactor that, debug that, and then use that, so it could access my notes (Joplin) over the API and write it's weekly update markdown there. Somehow the thread produced a python tool with over 400 lines of code, five files. It, at some point, even considered putting all that in a git repo. And went on a side-quest to run docker containers.
With the MCP, this job typically takes between $0.05 (Mistral) or $0.90 (Claude Opus). It now cost me $17.00. It took nearly 30 minutes. To write a note in Joplin!
MCPs, or any de-facto standard/pre-known protocol, makes operating on external tools and resources cheaper, faster and above all more predictable.
Follow up, because people asked me about it.
The scripts that were generated included code to determine if joplin was running, and to launch it if not. It included a proxy server, that would listen on a localhost:xxxx and if a HTTP request came in, this proxy would auto-launch joplin and then forward the request/response. It then included quite some code to de/serialize json to/from datatypes.
Part of this "overengineering" came from a "skill" that claude found globally which I wrote for myself when working on a few python tools. The skill required strict typing, demanded refactoring, insisted on doing everything over http (and not local commands).
Basically, the agent could not perform its task over an MCP and should've stopped. But I suspect either tuning or some system-prompt made claude go on instead. It decided to use python, and then found my "requirements for when writing python", followed that, and burned a lot of tokens to make one or two HTTP requests.
Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
Why trust any user with access to any terminal? UNIX solved this decades ago. It’s just we’re all learning to be sysadmins for the most creatively destructive and persistent set of users of all time.
UNIX didn't really solve this scenario. Yes, you can limit what local files a user has access to. But with web applications and cloud services being so ubiquitous, the local boundaries are pretty much meaningless. Forcing an agent through an MCP is a way to grant access to remote services while still restricting how the network access can be used.
Network administrators also solved these things, e.g. you can limit what websites a virtual machine is allowed to access.
Now, if you’re letting your agents abuse network traffic there becomes a point where you’re criminally liable. Unfortunately the current US government has no interest in prosecuting such abuse.
It's not so easy, because HTTPS thwarts attempts to filter out unwanted API calls, for example.
Maybe I overestimate the ability for corporate network administrators to block and detect access to certain websites from within their networks, like adult websites. My understanding was that there’s no way to circumvent those network controls.
> Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
When even the official software from the token providers have never had human eyes on 800kSLoC, I'm afraid that ship has sailed: the principle of least privileges has already been ravaged to hell and back.
Sealing a pin-prick hole in a dam wall is pointless if half the dam has already been washed away.
What you're describing, though, is that agents need a REST API. And I meant true REST rather than the JSON RPC APIs we've been building for 20+ years now.
Had we not abandoned REST we'd still have APIs that are self documenting and typed/schemaed. Bonus if browsers still supported XSLT, that same API could have been written in XML and only browsers wanting a visual representation would load HTML templates while agents could stick with the raw XML.
Sure, it needs a REST API. And you need docs for the API. Not just per endpoint but how to accomplish tasks with the API in the context of the application it supports.
But you don't want to just give any old agent raw curl access, so now you've got to provide a special client that can call just the APIs /endpoints that they're supposed to be able to. And it needs to know what the agent shouldn't be able to do as well. And it also needs to be able to handle things like auth, because you don't want the average person (or the agent!) handling bearer tokens. And you probably want a layer in between that validates everything against an OAS so the agent can't make invalid requests.
And now you've effectively just reinvented the good parts of MCP with extra tokens.
You're starting too recent though. MCP is attempting to recreate the good parts of REST APIs circa 25 years ago.
Soap was a pain and a lot of people didn't like XML, but they solved exactly these problems.
With MCP we're effectively trying to bolt those features onto a platform that fundamentally doesn't support it. Where as with XML/XSLT we could have a single XML endpoint + XSLT templates for converting that into HTML for browsers. Instead we now have modern web frameworks building RPC calls right into the bundle/build step, splitting state and rendering across both client and server, and have to stand up a new API context for agents that needs documentation and maintenance to keep parity with new features.
This isn't a problem that existed 25 years ago. You could expose SOAP and give an agent WSDL. You could give it OpenAPI and JSON. That's just not the problem.
Agents emit tool calls as JSON. Calling a REST API means emitting a JSON tool call that invokes a HTTP client with all the desirable properties (schema checking, safe auth) and none of the undesirable ones (raw key handling, arbitrary endpoint access). Then the response gets wrapped in JSON and returned to the LLM. That's not an MCP thing, that's a model thing.
MCP says "instead of http_post with a bunch of arguments that need to be correct, call get_weather with a zip code". And then it makes principled choices for how get_weather and its schema is defined. That's literally the whole point.
Even if you wanted to use WSDL to accomplish this, you either have to unwind how literally every function calling implementation of every model works today and teach them how to read WSDL and speak XML (and deal with all the other problems, like auth), or you avoid the two layers of indirection and define a system that works with what exists today, and that solution ends up looking very MCP-shaped.
You might say "well you could just have a little script/xslt that does the translation". That's exactly what a local MCP server is.
I'm not aware of anything that makes the models prefer JSON though, that's an implementation decision from whomever implemented the transport mechanism.
LLMs will happily work with XML, including to understand data schemas and discover available actions that can be taken.
No, that's wrong. The models have special syntax for function calls. They're not simply regular responses, they're special message types. You're partially right though: most models don't output or accept JSON, they have their own syntax internally. But that syntax is different for every model, and all the tools that invoke the models have parsers that convert it to the standard JSON+JSONSchema format. That's what vLLM and llama.cpp (or your tool of choice) are doing.
But that's irrelevant, because it's the tool call. The tool call is what invokes the HTTP client, not what's in the request payload. It could be asn.1 or RDF or TOML. JSON just happens to be convenient and universally supported. MCP could easily be implemented on literally anything you throw at it: that's an internal detail to your agent harness. That's not the point.
MCP is the OAS/WSDL/whatever contract described as tool calls instead of as network requests that the agent has to construct from scratch. Its whole purpose is to eliminate the whole layer of indirection.
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.
To be fair, after visiting some trade shows recently, a lot of these “parasitic” LLM startups are not very convincing from a business-use case perspective. (They’re not really parasitic, more like a remora attaching itself to a shark, the shark being OpenAI or Anthropic).
At IMTS at Chicago the skepticism amongst the visitors towards AI and pure-AI startups was at an all-time high. More than once I heard, “Oh yeah I visited that AI booth and they couldn’t explain what value they would add to my business.”
So in that sense, while MCPs are “winning”, I also see them as a significant part of the AI “bubble”, specifically solutions looking for problems backed by VC money.
The title feels clickbaity. Direct API, CLI and MCP all have their uses.
Direct access (Curl/own small function): This requires agent to have full understanding of the API spec. Yes, context can be protected using progressive disclosure, but this essentially means agent needing to understand the API again and again, before every use. Also, a typical API spec may or may not be agent-friendly. If there are nuances when calling an endpoint, where do we put these? Into OAS description? Works, but clunky.
CLI: It works beautifully, especially when a 3rd party CLI already exists for a complex backend. Assumes a well documented, agent friendly CLI, most CLIs are designed for human or CI/CD consumption. Talking about MCP taking up too much context, think about agent starting with my_cli --help, and going down through the switches and parameters one at a time to figure out how the CLI should be called. Less of a problem when calling a well know CLI (e.g. aws), but anything more niche (or custom) requires multiple turns to compose the final CLI command.
MCP: Has its issues, but offers an agent-native solution. Everything agent needs to know about a tool becomes available at once. In an enterprise environment MCPs can be served through an MCP Gateway, providing governance and permission management, this is quite contrast against running a CLI that requires agent to have execute permissions in its shell.
Another strong point for CLI is the `--dry-run` flag
The MCP use case is mainly another attempt at papering over the fact that effectively no API today is actually RESTful. We wouldn't need MCP at all if we still implemented REST APIs.
I think many devs misunderstand MCP because they work in solo mode. In solo mode, you just have your secrets local. You don't care about auditing access. There's no IT managing the infra and third party secrets. You don't have to account for different harnesses and tooling; you just use your own harness and adapt your tooling to it. You're not thinking about revoking/rotating secrets when someone leaves your team. You don't have to deliver capabilities to many different runtimes and stacks.
Back in March, everyone was already pronouncing it dead[0] when in fact, it has only proliferated and become even more essential for both 3rd party systems as well as platform level capabilities[1] as agentic tooling has moved a bit more slowly into the enterprise. It was apparent even back then that enterprises will need MCP.
In a team context? Enterprise? Building web server backed or in-process agents? Not sure how you replicate the control, auditability, accessibility, composability, and security boundary that you get with MCP over HTTPS without a lot of bespoke, point solutions; in the end, protocols almost always win.
Could you do it with just REST APIs? I mean, MCP is just JSON-RPC over HTTP with standardized auth, schemas, and agent specific exchange flows (tools, prompts, resources, etc.). Could you do it with just CLIs? You lose a lot of the control mechanisms offered by MCP (auditing, security, centralized auth, etc.). The context savings are overblown except with CLIs that have good representation in training (curl, jq, cat, sed, etc.; your custom CLI is going to need to produce instructions and add to context all the same)
Heuristic is simple: don't use MCP for local, solo dev. As soon as you need MCP, you'll know it and you'll understand why it exists. Many of the harness level capabilities themselves are implemented as first party MCP (more apparent in the CLIs). MCP is basically REST for the agentic era.
[0] https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
[1] https://blog.cloudflare.com/mcp-v2/
That core issue - the HN audience thinking solo or very small team, not large team or enterprise - permeates so much commentary and analysis here. You're spot on.
I also take a lot of the guidance from influencers with a grain of salt for that reason. What works for the solo dev on greenfield projects rarely scales to the enterprise 1:1. Brownfield. Security policies. Enterprise controls. Legacy systems.
There is usually a kernel of value that has to be extracted and translated to apply what works for the solo AI engineer and what works for the team.
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.
But you had to install their MCP server on your computer? That works for developers. Wouldn't it be nice to avoid another install?
As opposed to which alternative? Spending credits to send the work to a non-local AI to fumble through it?
AWS has many MCP servers that work extremely well.
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.
If one can build a MCP with proper protections, they can certainly do the same for their API/CLI/SDK.
I can build a local MCP that gives restricted access to an API which I have no control over.
I really don't care about the technical or cleanliness arguments against MCP (which are valid).
What I care about is that many companies didn't have APIs, and didn't see a reason to have them (niche, dev-focused use case, or might produce a competing frontend/app)...
but now, those companies have a reason (agentic but let customer agents access data!). And for me, that means more companies now allow me access to my own data on their platform. This has been a net win!
Yeah the AI FOMO beating out the desire to monopolize through closed API and lock in has been one of the nice side effects of this hype cycle.
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
You have to throw in “load bearing” in the request though to avoid suspicion
Also dynamic oidc registration (client.dev) has became better supported on oidc idps to support MCP
The same thing is going to happen at the app level on Google and Apple platforms. Android tried to have modular cooperating software, but both the early dominance of iPhone in the developer community, and developer interests in having monolithic apps made that effort fail.
Now both Google and Apple are making app interfaces legible and on-device tool calling discoverable. This will change apps in interesting ways.
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.
This, please refrain from using standard HTTP headers in non-standard ways. Why not use something like X-Accept-Programming-Language so that the semantics of Accept-Language can remain for human language, since the docs site is going to return text in a human language as part of the response anyway.
>Recently, a Vercel engineer called on harnesses to send the programming language the client prefers
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.
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!
Well Malte came up with AMP so there’s a history of doing odd things
> Accept-Language: rust
That's craziness.
Yeah I think a better header is good. The idea isnt bad in concept.
It would seem that curl + jq represents most of the solution these days. I recently learned that jq programs can be used in the other direction to effectively patch a json document too.
Putting both of these things together, I am running out of problems to solve as a human developer in the space of AI agent integration.
Assuming all your systems speak JSON right now, you are already 100% there with frontier models. You don't need to write a single line of code. Even if your json documents are monstrous in size. Put a size limit around the jq output and the agent will iterate with various filters until it finds a concise view of the problem. None of this behavior needs to be prompted or orchestrated anymore. Give the agent the tools and set reasoning level > 0.
jq is an awesome tool and bothers me deeply having claude generating some big fat python script for a single line jq command.
I think a most interesting middle ground option is the advent of CLIs specifically with agents in mind.
For example, grafana has a newer CLI called gcx that replaced grafanactl https://grafana.com/docs/grafana/latest/as-code/observabilit...
I originally used the MCP server but after running into context bloat and limitations around MCP I looked and found this. Seems to be a fantastic interface for agents, they breeze through o11y tasks with this thing.
Agreed, had a coworker come to this same conclusion and now only distributes CLIs. I think it’s solid as long as the decision tree of which tools do what is fairly simple. Perhaps MCPs were just overused before
For anything with CLI access and permissions CLI >>> MCP, not even close
Also this how most ADEs enable agent messaging and the like
Wow, this couldn't have been written at a worse time. OP absolutely doesn't know what he's talking about.
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.
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!
> Recently, a Vercel engineer called on harnesses to send the programming language the client prefers, so documentation sites can serve more specific examples. For example, adding Python could prioritize docs for the Python SDK instead of sending something generic.
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
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.
> both to bypass IP address rate limits
Eventually this part will end. Most are in a "move fast and raise our stock value as much as possible" mode, so are fine with infinite auto-scaling to handle the surges MCP traffic is causing right now. But eventually, we'll probably see more per-auth rate limiting and/or heavily restricted MCP usage for non-frontier labs agents (especially if they only want e.g. Chat users, not coding harness users).
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.
In coop [0], a VM manager we developped to sandbox agent usage (i.e. give them freedom to do their stuff, but in an isolated environment from your main machine), we try to solve this by having an intermediate proxy (coop-proxy).
Instead of forwarding ANTHROPIC_API_KEY / OPENAI_API_KEY into the guest, we simply run a reverse-proxy within the VM that replace a constant-time token with the real API key on the host.
Works well enough in practice
[0] https://github.com/trailofbits/coop
[flagged]
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.
> 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.
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.
Something like openshell is the answer here, to the point of GET being a write. The gap left here is what, imo, is something that MCP fits nicely- which is serving non-http resources with restrictions: databases for example.
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)
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.
I don't get excited about the directories listing all the MCPs that do all these random things. However, I used claude to create an MCP that is a gateway to our system and it's enabled some pretty helpful functionality for us. I use claude cowork to create email designs using data and content from our CMS, it can push accepted work straight into our system, evaluate content, and analyze results. All of that used to be a manual tiring process. This removed a lot of drudgery and improved the quality as well.
When I first looked at MCP protocol, I did not like it. Then I realized, I don't have to care about the protocol. Claude can implement that for me and it did.
MCP is a solid, obvious idea. The problem is the implementation and roll out. It was shotgunned from the start and made an otherwise simple thing far too complicated. IME, a shoddy foundation always leads to shoddy construction on top.
When done properly, MCP can be really useful as an API bridge. MCP is (or can be), after all, just a JSON-RPC endpoint that returns a standardized response format. "Tools" are just function calls w/ definitions that are LLM-consumable.
But, imo, it's foolish to dismiss MCP outright.
Agree on flexibility, you can just do a lot more with AI agent + curl + SKILL.md.
The agent comes with a good amount of API knowledge in training data already. A curated set of MCP tools throws most of that away. With curl, it can hit any endpoint and write scripts. SKILL.md covers what it gets wrong (API version, rate limits, etc.) and points at the vendor's own API docs for anything else.
The annoying part isn't tool calling, it's auth. You don't want the agent managing OAuth tokens for 10+ apps. A passthrough proxy that holds the credentials, injects them per request, and scopes permissions solves that. At Maton, we have our own MCP servers as well, but most of our customers use us for managed auth.
MCP is like anything else - it has its uses. Use it where it makes sense. Where it doesn't, don't. For my part, I probably rarely want my Agent to waste time writing its own adapter for a particular API that needs to be called, when I can just point it at an existing MCP server. And while context bloat can be a problem if you're using many many MCP tools, not every use case needs that many tools. Making that a non-issue in many cases.
For my part, I wrote an MCP server this weekend for Bugzilla, connected it to ChatGPT and now ChatGPT can help me manage my queue of bugs (and non-bugs - I use Bugzilla as sort of a generic work-item tracker, TBH). Simple, works and gives me a nice natural language interface to the tool. And if I want more than the generic API surface, I can add tools (or modify the existing ones) to add any additional business logic I want.
Can you "get there from here" other ways? Sure, absolutely. But this works quite well for my use case and I'm not anticipating "delete my MCP server" anytime soon. In fact, I plan to deploy one for interacting with my Mediawiki instance as well. I also even have plans to implement MCP for interfacing with all of my LXI/SCPI enabled test equipment!
If I get to the point where context bloat becomes an issue, I'll cross that bridge when I get to it.
MCP Apps[1] also look like a really cool addition to the stack. I've only built toy examples / demos to date but I'm pretty excited about what this brings to the table as well.
[1]: https://modelcontextprotocol.io/extensions/apps/overview
Article is focusing too much on tool use over HTTP. One of the good things about MCP is that it's the same protocol whether the tool is implemented with HTTP or using stdin over a local process. And it doesn't make sense to talk about HTTP headers with stdin.
> There are still some issues, like CLIs returning machine-readable responses (JSON/XML, etc.), which tend to be very verbose and heavy on token usage, but we have ways to fix this.
This problem is also solved by MCP.
Anyway, when building a new tool, I personally try a CLI based tool first, then I'll fall back on MCP if the CLI is not working.
One big reason I see for needing to switch from a CLI to MCP, is if the agent needs to send a lot of data to the tool, and it has to pack and format all that input data as CLI params, and you can start seeing problems with the Bash command syntax being improperly escaped. That problem is solved by MCP thanks to using JSON-RPC over stdin.
Summary.. you shouldn't use MCP for everything, but there is a time and a place for it. Which is what the experienced devs have been saying about MCP for over a year now.
For claude check these out:
https://www.anthropic.com/engineering/advanced-tool-use
https://platform.claude.com/docs/en/agents-and-tools/tool-us...
I have mixed feelings about this. Going all-in on Model Context Protocol (MCP) is definitely a bad idea because I noticed the Jira and GitLab MCPs were consuming an excessive amount of tokens. To solve this, I decided to install their respective CLIs instead so we could find a balance and get the best of both worlds. For example, certain MCPs bring too much overhead, especially when they only handle a single task. Instead of letting the coding agent constantly waste resources re-discovering how to fetch a specific work item field, I had Claude recursively run --help on the CLIs and save all possible actions into separate Markdown files. This approach allowed me to build two lightweight plugins that do exactly what an MCP is supposed to do but with significantly less token consumption. If anyone wants to check out the code or use them, I have open-sourced both repositories on my profile:
* * acli-skills: An Atlassian CLI agent skill that maps out Jira commands cleanly. * glab-skills: A GitLab CLI companion built directly for efficient agent workflows. *
To maintain visibility with this setup, we also developed a custom [Claude Code](https://code.claude.com/docs/en/plugins) plugin that streams live updates regarding our background operations directly into the console. That said, MCPs are still extremely useful for rapid prototyping and when we build custom internal tools to speed up development. We found them particularly valuable for:
* * Sampling: Asking the LLM directly to detect entities and summarize log files. * Notifications: Handling long-running tasks that require fetching data from multiple sources. By logging each step and aggregating them via sampling, a single update is sent back to the coding agent, preventing it from spinning up multiple redundant processes. *
Maybe I'm not "using it right" but I often spin up my own MCPs as an authorisation control mechanism, as a wrapper around existing tools. For example, an MCP server that can only do GET requests. This way I can stay relatively secure about the fact that when the agent uses the MCP, it isn't going to mistakenly execute something I didn't want it to.
I know there are other ways to achieve this but to me this, but they all seem "soft" controls - a hard limitation feels more reassuring than simply a line in context that says "don't do this".
In the spirit of the linked post, one could argue I should just write cli wrappers - but I think I like the explicit routing of `Agent -> MCP -> available tools` instead of `Agent -> available tools`. The former lets me control the surface available to the agent. While LLMs are smarter now, at the same time, the applications that use those LLMs have become more assuming of what I want to allow them to do. I don't want to be one hallucination away from a disaster.
MCP's monolithic design always felt like fighting a hydra; one fix created five new bugs elsewhere. Never understood why it gained traction.
Best idea in the article, and I'm going to try it out later today:
We should start to standardize how agents use HTTP APIs directly. For example, agent clients could attach headers to identify themselves as agents, and servers could automatically send them response data as Markdown or text instead of HTML or verbose JSON.
I honestly never really thought much about this, but there is a level of awesome to it especially when it makes zero sense to have 50 words of text accompanied 6.5MB of markup, scripts and styles. The experiment went well... and it worked extremely well.
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
I think there's at least one thing that MCPs get right, and it's that they make it easier to establish permission boundaries when agents are working with third part services and applications. Even with Claude from the terminal, MCP makes it easier for folks to standardize separate permissions and operations for general agent use than making people have to have multiple complicated API keys. Do I think it's the best solution for that? Not really, but I think it's probably better and on average safer than giving agents unfettered access to credentials to do anything, which seems like it'd be the default without MCP. That said, I can see MCP being replace with some sort of permission and sandbox system that's more generalized.
CLI, API, MCP are all useful ways to connect. It just depends on the use case you're going for. I've used all 3 and find that they all have benefits.
MCPs are great when you just want that native out of the box low mistake way for agents to call your services it's great for certain cases.
I also developed a new method of using MCP called ADP (Agent Delegation Protocol) that sits on top of MCP where there is only 1 tool for the MCP, and when the agent wants to do something it just issues natural language commands and the ADP engine handles the rest it does all the routing etc... to the right sub-agents and executes tasks and return the results. (more on this soon).
Internally if you have a good orchestration system you do not need MCPs and can use APIs but those APIs should be designed for agents, IE based on DSLs, that project into internal operations. I do this too.
CLIs are great for testing things out, but agents often get things wrong, it's great for experimenting to see what works out of the box and what doesn't.
For me the perfect medium is a mix of MCPs and APIs. APIs are cheap if designed well, and if your workflow is a DAG then APIs are especially good because you already have a deterministic flow which means you can use small LLMs or even just something like Jev.
So my summary is:
CLI - Great for out of the box, things that are well known, where you want to verify the output
API - Great for low-cost large volume, highly repeatable workflows, that require high reliability you want your agent to execute without you having to hand hold.
MCP - Great for building debugging systems, or as an entry point to more complex workflows that you need your agent to have some ability to orchestrate.
I'm using MCP with ADP to route to large workflows that execute APIs internally for what i'm working on. So it's a mixture.
The major advantage of CLI is IMHO that you can use a CLI yourself too. It's a universal tool.
One thing I hate is when people write an MCP server for something useful and just that. Like, why don't you tell the same Claude or Codex instance you wrote to also expose the same functionalities as a CLI? The problem is that it's full of technical people with zero CLI knowledge nowadays (or, rather, for the last 20 years or so), and it kinda sucks in general, because lots of stuff only comes in GUIs that are not composable, not scriptable and sure as heck full of stupid bugs and limitations due to how harder it is to get GUIs right compared to popping out a "dowhateverctl" kind of tool
In many companies, the process for launching/updating a hosted service like remote MCP is very different than distributing compiled or open source client code.
There are numerous applications that you don't need and don't want to give shell access to an llm.
I have used Unity and Blender MCPs and I am not sure I am seeing why this is not a needed concept (or is a bad implementation).
If Unity updates the version (and the MCP server with it) - my agents immediately see the new surface. They weren't trained on the features of the new version of Unity, but they know about them as soon as they are added.
Context bloat is a thing - but you only turn on the MCP servers for what you are actually working with. If I am only in Blender, I don't need the Unity MCP. So it can be disabled.
These are just two example pieces of software but the concept applies to all of them with MCPs.
These articles always assume the MCP is being used by technical people. MCP can be used via plugins on OpenAI/Claude marketplaces by random corporate users who don't know what a terminal is.
Correct me if I'm wrong, but an MCP server still make a lot of sense for remote-controlling a UI application (like a game engine editor) which otherwise doesn't have any 'access points' for remote-control right?
An AmigaOS-style "scripting port" would work just as well, but AFAIK that's essentially what an MCP server is (a socket that implements a discoverable command protocol).
I would actually love if all applications and services could agree on a standard for scripting / remote-control. If the AI hype is what it takes to get there, then so be it ;)
Every few years we're all doomed to reinvent COM again.
Surprised WebMCP hasn't come up here.
Of course you can raw dog it with "computer use" and just have the agent click around the UI, but exposing semantic actions directly from the site seems like a much cleaner interface.
WebMCP isn't MCP (which is great).
WebMCP is much simpler and more useful, I have the impression it might just replace the original.
Agree.
There are definitely pure MCP use cases.
For web apps though, WebMCP seems like an awesome enabler: better ux and better stakeholder alignment
> The MCP Industrial Complex
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?
I find it hard to agree that MCP merely wraps a simple API. Sometimes a filtered model-specific interface is needed. MCP is one of those interfaces. In our SaaS service, sensitive information can be viewed via REST, but since MCPs may be exposed to LLMs, they are blocked from going outside.
MCP systems always felt like hacks. I haven't ever found one that satisfactorily interacted with a system as well as a good command line tool.
They provide interaction for most of your GUI programs but often the limitations of the MCP systems leaves agents highly confused about how to execute something you see on screen, where command line systems the agents seem to work 99% of the time.
Both MCP and other APIs put you at the mercy of the other party. Often that means that features will unintentionally drift from the "source of truth" human UI. At worst, capabilities will be intentionally limited.
Automating the human UI used to be difficult and fragile, but modern AI makes it much easier and change resilient.
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.
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.
> captures the output of anything and allows the LLM to query it later
Otherwise known as a “file”. ;)
I’ve been trying headroom-ai for this reason. That project also reduces tokens in other clever ways. Have you looked into it?
Don't most harnesses already do that for bash commands?
Isn't the whole point of an MCP is to increase somehow the determinism of how to communicate with a certain external system? MCPs feel to give easier guidance to the LLMs, rather than letting them extracting the knowledge on how to connect to a given system.
Without, I feel they are more confused on how to get an outcome, as they may try, infra or inter sessions, different approaches
The exact same thing has been discussed many times here on HN and elsewhere, yet the author did not bother to just look them up before posting these uninformed opinions, as if they just discovered something new. It seems a complete waste of time to go to a conference on MCP with that kind of understanding.
With MCP or HTTP, how do you implicitly limit access of the agent to a particular user? In other words, how do you avoid giving the agent access to perform an operation for any injected user? This is a basic security question.
I can do this trivially when my tool functions are closures that have the user-id pre-bound, but with MCP and HTTP I naively assume that the callables are pre-set.
"[...] built for a time when LLMs weren’t that smart", which was roughly 1.5 years ago - unreal development.
LLMs were a bad idea. MCPs were the band-aid to get them closer to the real world and do something for recursive self improvement. Then LLMs became better suited for everyday use.
I'm tired of these kind of posts. This author is on my black pill list.
MCP is an incomplete abstraction. It solves things in the right direction, allowing agents to interact with some given system via a controlled ingress. It's a fancy proxy, and by itself doesn't really do much to enable autonomous interactions.
I don't agree.
The real value of MCPs lays in providing a controlled interface to models.
The benefits of control are multiple; models getting better means that, if necessary, they can go around the limitations, but generally their adherence to it is desired.
MCP is basically RPC, and it suffers all the problems of RPC like mechanisms. It has long round trips times, significant de/marshalling costs, coupling between caller and consumer, versioning issues, etc.
Over time I think we'll see an evolution towards client-side micro models that reduces RTT latency, and a message bus architecture that allows multiple local micro models to push queries to the server, continue working, and receive updates on various topic asynchronously. The channels or topics (like a blackboard system) would be accessible to multiple local agents, as would the results of tool calls.
Message bus systems are easier to version, write adapters for and debug than random CLI tools and web interfaces. MCP interfaces are not going anywhere, they are just evolving.
Just have a route that describes your API endpoints in a machine readable format, eventually they'll come to some consensus and in the mean time this works well enough to allow LLMs to plan.
Even if the premise is correct, bad ideas are often the first step towards a good idea.
MCP was terribly executed by a inexperienced team. The current changes are mostly changing or removing what was initially implemented.
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...
I always wonder why they didn't use Swagger|https://www.openapis.org. It addresses all the key description and security details.
I use myself the DaisyUI Blueprint MCP and it's totally worth it. Not even fable 5.1 without all that context and way of directing could work this well. At least, I feel is worth paying for that MCP.
If you haven’t checked out AXI as an alternative to MCP I recommend checking it out. I’ve started wrapping almost every cli or MCP in an AXI bin as it’s more reliable and uses fewer tokens.
Why are they still having this debate in 2026 when CodeAct have existed for years, and the LLM's are getting much better at coding in the first place?
I happen to be much more token efficient by
- installing a cli tool
- exposing it via a simple SKILL.md
- turn repetitive patterns into bash scripts fast
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.
[dead]
MCP always seemed like something that wouldn't be necessary if AI lived up to the hype.
MCP is like JavaScript. Sometimes adoption/availability matters more than the fundamentals
i feel like MCP was bad, but people are saying recent improvements have made it worthwhile now? i.e. stateless http
REST or specifically non-self-documenting rest has always been a bad idea.
SOAP does not need MCP, for example.
I don't know how so many people miss the fact that MCP is another attempt at papering over the terrible idea of replacing RESTful APIs with JSON RPC.
Isn’t Markdown header the same thing? Kicking the can further until models catch up?
It is all useful, and depends on the distribution channel and surface complexity. I use both MCP and CLI in my case.
Having the CLI allows you to have the huge application with the big surface be available to the AI agent and so they'll be able to learn it on demand. For example my app has more than 1,000 help pages. There are no other ways to load all this information into the CLI context and to be frank it will be quite stupid. Instead I use progressive discovery.
It first reads the original help message to understand which stage of the flow it is right now. It auto-discovers the topics through the error messages and through the various hints. It has an Elasticsearch-like search inside its own help command so it's a full self-contained application with self-discoverability, which has a graph, ontology and the full developing flows inside of it. All of those parts are automatically given to the AI only when it actually needs them.
And to be frank if you look at the latest YCombinator batch, all of the companies are building the custom harness. What I'm calling above CLI is actually a custom harness, which is running inside someone else's agent group.
Having remote MCP allows me to give limited read-only surface to clients which not supposed to run any CLI commands. And while MCP has similar patterns, like bundling docs and prompts, it is not as flexible as CLI and does not allow huge scale.
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.
I used this tool for 1 month since then I never used it again
MCP is a gateway protocol, not tool use.
You know you are getting old when Acronym's change on you.
Vacate entry port, program! I said, move out!
Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
MCP is an abstraction for remote tool calls with a standard interface. More specifically it's for when a local CLI will not do, and you want determinism and standardization. It also avoids all of the potential errors and guesswork involved with a model trying to "figure out" how to do something; you simply make one standard call, and the remote side "figures it out" for you, without failure.
If you can do what you need to do without MCP, then don't use MCP. When you eventually get sick of AIs playing guessing games with local tools/data, or spending lots of time to get functionality somebody already published as an MCP, or you need isolated control over the execution, maybe check it out again.
> Somebody's got a case of Chesterton's Fence. They doesn't understand what MCP's for or how it's used, but they find it mildly irritating or unhelpful, so they demand it be removed.
Yeah that's me. Idk what MCP is really, just that there's always some auth issue with it and I've never actually needed it. Is it dead yet?
Think of MCP as a universal CLI tool for anything you can imagine running on a server (remote!). Even if you wanted to use a local CLI tool to call some remote server command, local CLI tools have different input/output formats, different commands/options, and those tools change over time. MCP doesn't change, it always tells the AI exactly how to call it, the calls always use the same format, it includes a standard, quite secure method of authentication, and it's all done in an AI-friendly way. And because of all of this, it uses less tokens, and has a much higher likelihood of success (e.g. AI tools failing to call CLI tools properly and looping trying to figure out the right arguments/input/output).
Now, if you don't care about authentication, don't care about wasted tokens, don't care about the AI screwing up CLI tool calls or needing to be trained on every one, and if you don't need to call something on a server, then MCP is useless to you.
In that case, you can use a skill calling an HTTP+JSON endpoint. Or if you mean it's literally a remote CLI, so it needs bidi streaming, that's what websockets is for (or gRPC but ehh). Those are well-established. MCP sounds like one of those "we need yet another a new standard, this time to rule them all" things.
Yeah that still fails a ton. A skill will mess up the call, not know how to handle errors correctly, not flag an error as an error (false positive), hallucinate, require custom input/output formats, require custom code to validate, won't handle authentication the same way, you'll need a unique skill for each endpoint, you need to version the skill, and of course there needs to be an endpoint, as well as all of the tools needed on the client machine to process everything, hoping of course that they're the right version.
Compare that to MCP. One standard tool call. Works on every agent. Everything built in. Determinism. Reliability. Simplicity. It just works.
Skills are non-deterministic balls of mud. MCP are deterministic standard tool calls. MCP solves all the problems. A skill can't do what MCP does.
In terms of "using standards" to solve the problems, tell me 3 different APIs (from different companies) that have identical input format, identical output format, identical request URI format, identical headers, identical methods, identical auth. You won't find them, because everyone implements their API differently. You can use 50 different standards 50 different ways, and still not solve the problems mentioned above. MCP is one standard that works one way and actually solves all the problems.
And this is just addressing the client-side problems. There's a whole world of server side (logging, tracing, auth, execution, etc) that's not standard either, unless you use MCP.
[dead]
> guessing games
that still doesn't answer why to choose MCPs over Skills.
Summaries aren't a bad idea though.
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.
MCP is a good idea
JSON is a bad format/transport.
> JSON is a bad format/transport.
I've cut token counts significantly for some of my MCP servers by returning csv or tabular data or sometimes even just good old fashioned plaintext "template style" words. JSON is highly repetitious. In some instances like 30% or more of the token response was just boilerplate JSON.
Once you realize that to an LLM JSON is just a stream of tokens no different than XML, markdown, or a punctuation-less stream of conciseness.... you start to realize there is no reason not to just make up your own crazy formats. The LLM isn't throw parsing errors if your MCP is returning something other than JSON. The LLM is smart enough to figure it out. It's far more important to make sure your tool descriptions and parameter descriptions properly "market" what it is you do (and dont do) than return syntactically correct JSON.
Same with versioning.... it's all ephemeral. There is no backwards compatibility to speak of with MCP (at least for tooling "contracts".... what the tool actually does however... that is a different level and is product requirements not API contracts).
https://github.com/kunchenguid/axi
If your customers are normal people who use ChatGPT in the browser, they want ChatGPT Apps, which are based on MCP.
Like JSON, MCP solves a problem without being overengineered. Both are painful for the overengineering type.
Related to this discussion, I have written a manifesto against the excessive usage of MCP and other "tools" when using coding agents. I believe sticking to the basics yields the better quality overall in output
https://www.just-prompt-motherfucker.com/
CLI first
Bad take. And what's coming down the pipe with MCP will cement it. Has less with the model calling tools and will become about tools calling models. There is no unified integration into harnesses to support this other than MCP.
Shady title with "?" not to own the statement.
Ending with a question is a shady media way of getting aroudn the legal issue of taking responsibility.
I hate blog titles like this as the author doesn't want to take responsiblity for the claim.
What legal responsibility would they take on by not using it, in specific? I can only think of defamation or something but I doubt a question mark covers you for that.
"legal" in media companies. It's a loophole in law where if you phrase something as a question, you are not claiming as truth.
Say the media claims, "Your mom could be the murder suspect?" You are not technically saying yo mama is a murder suspect though it is implied so.
Media companies won't be prosecuted for any "wrong info" for such titles by law because it's a "question".
Same here for the blog post. It's framing as a question, not taking a responsibility that (though author implies so) he is claming MCP is a bad idea wihtout owning it.
It's worse than weasel phrases.
Yet again, using HTTP as intended is a better solution than bespoke protocols.
MCP is now only good at getting credentials from any source. If SaaS cared about their API the same way we would have OAuth for all APIs, MCP would just die
MCP is a more controlled environment than yoloing an access token. Article missed the point entirely.
Is this another "Dropbox is just rsync"-like post?
"The attack surface wasn't big _enough_"
The article completely misses the main MCP point - it's authentication handling. Sure you can login via CLI, but it's much more clunky to manage.
Terrible take. Access control.
[dead]
[flagged]
[dead]
[flagged]
[flagged]
Not sure why the title on HN ends with a question mark. It's grammatically incorrect and not in the original article
[dead]
[dead]
[dead]
[flagged]
[dead]
[flagged]
[dead]
[dead]
[dead]