FRESH
Hacker News
Hacker News Hacker NewsThe thing that all these "MCP is dead" posts are missing is that whether or not MCP is used as a transport protocol is actually completely irrelevant.
The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Most of these companies don't have a CLI. Many of these companies don't even have an external API! And yet, they're all building MCP servers.
And that's why MCP is not only not dead, but more important than ever.
Maybe we will turn every MCP server into a CLI under the hood. Maybe we'll use code mode. Maybe we'll implement tool search.
All of those are just implementation details to the much more important point: our AI agents are getting access to services they otherwise would never have had access to.[0] That's what matters.
So, is MCP dead as a direct communication layer for models to speak to? Maybe, maybe not. Is MCP dead as a protocol? Hell no, couldn't be further from the truth.
[0]: Although I will say the Codex app's computer & browser use features have made this statement a lot weaker than it used to be. If you haven't tried them yet—they're mindblowing.
MCP is essentially just JSON RPC with a few special fields that must be included. I have reservations about JSON RPC, but there needs to be some 'service discovery' layer for LLMs to interface with.
It needs to be available in places like websites, desktop applications, backend services, etc. The CLI is only one place that these systems interface with.
Whatever you replace MCP with will be in a similar shape even if you specify a different communication protocol or different fields for tool discovery.
> Problem 1: It Devours the Context Window
> Problem 2: Low Operational Reliability
> Problem 3: Overlaps with Existing CLI/API
> Provide CLI -> API -> docs, in that order
So these numbers are at least 7 months out of date. Why is this being posted now?
Also the calling of the Mcp is nicer in the chat UI, clearer for users.
SSH is the perfect protocol for LLMs. Coding agents can use it already, `ssh api@example.com list-users` is all it takes. There's a 90% chance that your users already have ssh installed. It's text-in, text-out (which is exactly what LLMs need). It handles authentication (through public keys), streaming output, interactive I/O, even file transfers (through scp / rsync) if that's something you want.
If your users link their accounts to Github or GitLab, you can even scrape their ssh keys and pre-configure authentication for them, so they just connect and they're in.
- remote mcps are server driven, meaning the producer can introduce new functionality without requiring all clients to update their skills and clis
- remote mcps are safe as they don't require literal code execution privileges on your system. Many times skills even bundle scripts with `npx`/`uvx` which is basically just `curl npm.com | bash` level of unsafe
Every time I read MCP, I think it means "master control program".
http://mcp.a1k.org/indexe.html
And I know I will forget again. "Model Context Protocol" is so bland I already forgot half of it by the time I'm at the third word, so that even some old Amiga stuff instantly overrides it.
> You sit down and 10 menus (MCP tool definitions) are spread across the table
> There's no room left for actual food (your work)
> Every time you order, the menus have to be pulled out again
This is a bad analogy. Ordering repeatedly is uncommon except for tapas restaurants. You could easily put food on top of menus, but more commonly, menus are removed after ordering, thereby freeing the table (context??) for the food. If you're going to try to explain things by analogy, it's worth putting effort into making it more relevant.
For this example, there seems to be no explanation for the LLM to know when to use this curl command, etc. Is the idea that the linear API is known in the LLM weights already and therefore there is no need to include "the manual" in the context window? If so, it's a pretty narrow win.
The problems listed on the article are problems with specific tools that have large tool descriptions. This has nothing to do with MCP. There is nothing in MCP that would cause the tool descriptions to use more context than they would otherwise.
"We've done extensive renovations in our apartment and while the coring drill was essential to install electrical conduits it's pretty useless in making furniture installations".
In the world of AI development we are jumping from tech to tech every 20 minutes. I'm in shivers every time when I see "A new claude version was released, do you want to update now?"
The moment you kinda automate something with the AI, the process breaks and you have to build the new thing.
So don't blame a coring drill.
If you have external users, then you have to use MCP, which comes with how to use each endpoint and etc. MCP is what their current apps e.g. Cowork, Cursor support out-of-the-box.
In that sense, MCP is very much not dead
MCP is an API with some description. It adds tools to your agent, along with some context.
The (common) complaint is that the principle of progressive disclosure isn't working because all tools, with all their descriptions, are loaded into context right at the start. This is a somewhat reasonable complaint, as the structure makes it hard for the harness to progressively disclose the tools.
This is a fundamental issue with anything that just adds a bunch of tools, whether it be via MCP or HTTP (still sad that MCP won over OpenAI's HTTP based approach).
How might it be solved? Well, we could work with sets of tools. That's pretty much what the CLI approach does: Wait until you need it, then invoke the help command to discover what to do exactly. The caveat of the CLI being that it's a nightmare to secure.
At the end of the day, every capability eats some amount of context because the LLM needs to know when to invoke it.
They are easy to implement and integrate
You can use OAuth and handle ACL easily
It's also easier to manage for non-tech people. Try telling the people over at HR or finance to install a CLI.
In my opinion, MCP is not dead. "MCP Belongs to Software Engineering", it ships existing concepts from software engineering into AI. CLI, MCP-tools, and OpenAPI are interchangeable to some degree, but MCP is more than tools; there are mcp-apps[2], lazy load in context[3].
[1]: https://log.ifor.dev/posts/mcp_vs_skill/
[2]: https://modelcontextprotocol.io/extensions/apps/overview
Chrome/Ghidra MCP does have a tendency of crashing, but I'm not sure why this is. Is my way of thinking of MCP incorrect? If it really is a descriptor of how to talk to another tool, then why do they seem fragile at times? I feel like there's a gap in my knowledge somewhere.
i personally was anti-MCP but they just work better in terms of tool search than a CLI, especially with the idea of tool nudging
In the end MCP is just a protocol for discovering tools. And agents _need_ to do stuff with tools.
However, I don't think that's what is really hurting MCP, because it could evolve. What really killed it was the standards process and enterprise groups getting ahold of it. It went into spec writing and got adjudicated into uselessness all while enterprise authentication groups were figuring out the best angle to make money on it. I listened to a pitch from Okta on MCP and they wanted to charge out the nose for it for no good reason.
The article is semi right. Local MCPs that are made by enthusiasts wrapping an api they don’t own? Yes that is dead and should never have been a thing in the first place.
But MCP in its current direction and form is really an OAuth Protocol over http. And it has something other that other agent identity protocols don’t: client adoption
That may sound like an exaggeration, but it’s exactly what I see in our product.
Humans developing something already have context that agents don’t have yet. Most agents start a task with virtually no prior knowledge. And they start from zero every single time. That may improve in the future, but we’re not there yet.
Can agents get the job done? Yes. But without a thoughtfully implemented MCP server, they are awkwardly inefficient.
> Provide CLI -> API -> docs, in that order. LLMs already learned from man pages and StackOverflow.
So how is the agent going to know about your niche CLI? It's still going to use up context to learn your command line interface, same as for an MCP interface.
Agents only excel at CLIs if a particular CLI was part of their training data. The same would be true of well-known MCP interfaces.
> Alternative 2: Skills Pattern
> If MCP is "spreading all menus on the table upfront", Skills is "asking the librarian for only the book you need".
Or: Layer your MCP help commands, like a directory at a mall. The agent only looks up what it needs at the time.
2026. Oh woe, the MCP that all the companies are giving me isn't ideal.
2028? oh woe, the CLI that calls the REST API, that calls the MCP that all the companies are giving me..
- MCPs are great for stateless, mostly read-only interactions with document store type things. Notion/Slack/Linear are perfect use cases. I have those MCPs connected to claude code and they work great. These tools never had CLIs or super well used public APIs to begin with. MCP handles the auth for me. Cool.
- MCPs are great but not fully necessary for "function shaped" things where you're trying to run some Function and that Function has a lot of parameters with some subtlety to them and perhaps needs some examples to really help the LLM understand. Though you can get away with a skill + curl, or a hand rolled script even.
- MCPs are not so great for interacting with more complex stateful systems with large surface area. You don't want/need an AWS MCP, for example. And of course Cloudflare is the canonical example here where they do have an MCP but it has a special "Code Mode" because they have a huge product surface and a lot of state.
Most companies are somewhere in the vast space between being a document store type thing and AWS, so aren't really sure what their MCP should look like, or how customers will use it, but feel like they're missing the boat if they don't ship something. So they ship an MCP and perhaps the people who need the document type stuff load it up and get some use out of it, but others are not so satisfied. Or maybe from the other direction, people are trying to use your product but aren't super technical or don't know how to best use it with AI, but "loading up an MCP" seems like a reasonable way to start, so they ask everyone "Where's your MCP"?
I run into this at work all the time. We get a lot of requests for an MCP. But our product is not so simple to just stuff into a bunch of stateless API calls. And we question whether the people requesting the MCP really know what they want it for, exactly, other than to hook up to claude code so they can say "claude go do everything" (which is a valid sentiment, but implies a lot of work on our end to figure out how to make that work well).
Not because it's better, but with one switch a significant portion of web traffic can be directed to A2A servers through Google's new search box.
* CLI: GitHub & AWS it already knows how to operate the CLIs well. Even learned about a few new CLIs like 1Password's op which it volunteered one day.
* MCP: Supabase, Shopify etc. where the CLI would be non-obvious and the affordances from the tools/descriptions helps Claude maneuver.
* API: Sometimes it just knows an API exists and is able to call it directly with python/curl. I discovered from Claude the Pokemon ecosystem has a free API out there for example.
Jira
Confluence
Gitlab
Logs & Metrics platform (inhouse solution)
QA (not sure what this one does)
Context7
mattermost
I have no idea about modern trands etc, but I wouldn't say that MCP is dead. Not the hottest new thing, sure.
MCPs are very useful when you don't have a CLI or you do but the MCP can handle auth like a proxy to something (e.g. Splunk). Or just for the USB-C analogy she gave.
I was also surprised to find out Claude knew how to use the gitlab api with pointing it at the token var in the environment. But for corporations it might make more sense to use a cli to keep the secrets separate from the agent.
Can someone explain this to me? I've seen claude code try to run a not-well-known package and it basically shot in the dark a command, noticed that failed, then ran the help command for the cli tool to get a list of commands and what they do.
How is that different than passing the tools with an MCP? Like how are we saving context?
In the early days of computing, desktop apps and later webapps provided richer human experiences.
What will provide richer experiences for agents, after CLIs?
Oh. You mean that new thing also named MCP?
Turns LLMs are shit with JSON. Especially those JSON str embeded inside another JSON key-value pairs.
Why do smart ppl design a schema like escape JSON into str embeded into another?
It's based on another lie: AIs favor static typed languages.
Clearly MCP is not dead, as the article itself says. But the article lies in order to play on human sentiment/heuristics and steal your attention. It's like shouting fire in order to get people to run over to see your business.
The good think about MCP is the authentication story. It is almost perfect. Compare this with CLIs which mostly piggy back on quirky browser authentication, env files and other bad practices. It is a security nightmare. It is certifiably insane.
So to compare MCPs to CLIs purely on token cost is missing the entire point that at the end of the day these agents need to operate safely and OAuth is the defacto standard where this can be done in somewhat consistent way across different vendors.
For example I have a no-auth clock for AI deployed from https://github.com/firasd/mcpclock to https://mcpclock.firasd.workers.dev/mcp (anyone is welcome to go ahead and add it to your AI apps as an MCP endpoint)
You can still call it via CLI if you're a MCP hater
curl -s -X POST "https://mcpclock.firasd.workers.dev/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id": 1,"method":"tools/call","params":{"name":"clock_get","arguments":{}}}' event: message data: {"result":{"content":[{"type":"text","text":"[\n {\n \"timezone\": \"UTC\",\n \"iso\": \"2026-05-30T04:05:07.175Z\",\n \"unixtime\": 1780113907\n },\n {\n \"timezone\": \"Alphadec\",\n \"alphadec\": \"2026_K6G7_066464\"\n }\n]"}]},"jsonrpc":"2.0","id":1}
curl -s -X POST "https://mcpclock.firasd.workers.dev/mcp" -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d '{"jsonrpc":"2.0","id": 1,"method":"tools/list","params":{"name":"","arguments": {}}}' 2>&1 | grep '^data:' | sed 's/^data: //'| jq -r '.result. tools[].name' clock_get clock_day_info clock_convert clock_convert_alphadec clock_convert_unixtime clock_shift_utc clock_delta_utc clock_delta_alphadec
The "just use a CLI" crowd is implicitly assuming:
1) You're a developer 2) On a laptop 3) With a shell open Inside an agentic coding harness (Claude Code, Codex CLI, Cursor) 4) Working on a software project 5) That's like... maybe 2% of AI usage.
The other 98% is: Someone on the ChatGPT iOS app asking a question on the subway; Someone in Claude.ai web chatting about their calendar; Someone using ChatGPT Desktop to summarize their Notion; A non-developer using AI in a browser at work; Voice mode on a phone; An embedded chat widget on some company's website...
scrolls down the page...
> So is MCP really dead? Not entirely
sigh...
Until that happy day arrives I run every required MCP with mcpc.
> Problem 1: It Devours the Context Window
Don't harnesses support progressive discovery these days?
Claude (200K).... GPT-4o..........?
> every MCP server adds a process layer between the LLM and the underlying API
But a CLI doesn't?
------------------
> Measurement: Tool Definition Sizes
> MCP Server: Linear, Notion, Slack, Postgres
Oh, so these are the MCP servers that are examples of context bloat we're going to replace! Later in the article:
> At Quandri we use all three approaches side by side...
> MCP for services without a strong CLI (Slack, Linear, Notion)
The only thing worse than the people saying it are the people that repeat it.
While the title is quite obnoxious, the author is right.
I don't think that anyone would argue against standardizing training for any model on ways of invoking tools through specific output templates (with MCP being an extension of that). However, the question is what is the best way of having the model use those tools? There are 2 options
1 - Encode actual functionality during training, let the model figure out how to use available tools to do what it needs to. Latest Claude models are a good example of this, when editing files if it encounters issues with the under the hood tool, it will write a bash python command to edit the file
2 - Describe functionality in instruction context. This allows you to define complex sequences of things to do, but at the risk of the model losing context as the conversation continues.
3 - Use tool calling, where every request gets an available tools section appended to it, and define the complex functionality in the static code (whether its local tools or MCP servers)
Ideally, if we are pushing towards smarter models, the answer is between 1 and 2, where you have a model that only has access to be able to run shell commands, and some memory that it can reference on sequences of shell commands to run. An MCP invocation is then a simple echo jsonrpc pipe to local executable or a curl command. Eventually, its probably worthwhile to have your LLM run in a CPU like sandbox where it can execute arbitrary assembly commands from sequences stored in memory to do what it needs to do.
Until then, 2 and 3 are really what we have for adapting with current frameworks.