alt Hacker NewsMCP was always a bad idea?
Comments
MCP is like JavaScript. Sometimes adoption/availability matters more than the fundamentals
I used this tool for 1 month since then I never used it again
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.
REST or specifically non-self-documenting rest has always been a bad idea.
SOAP does not need MCP, for example.
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...
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.
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.
>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.
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.
i feel like MCP was bad, but people are saying recent improvements have made it worthwhile now? i.e. stateless http
MCP always seemed like something that wouldn't be necessary if AI lived up to the hype.
Summaries aren't a bad idea though.
Well, SaaS don't do CLIs for extension APIs.
Plus the performance issues to restarting processes all the time.
If your customers are normal people who use ChatGPT in the browser, they want ChatGPT Apps, which are based on 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.
Yet again, using HTTP as intended is a better solution than bespoke protocols.
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. *
MCP is a good idea
JSON is a bad format/transport.
Like JSON, MCP solves a problem without being overengineered. Both are painful for the overengineering type.
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.
CLI first
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
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.
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?
Is this another "Dropbox is just rsync"-like post?
MCP is a more controlled environment than yoloing an access token. Article missed the point entirely.
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.
You know you are getting old when Acronym's change on you.
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.
"The attack surface wasn't big _enough_"
Terrible take. Access control.
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.
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.
[dead]
[flagged]
[flagged]
[dead]
[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]
[flagged]
[dead]
[dead]
Isn’t Markdown header the same thing? Kicking the can further until models catch up?