alt Hacker NewsMCP is dead?
Comments
There is no publishing date on the article.
We can't generalize, it depends on the case, and it's not a XOR. I personally go CLI first, and if not possible MCP.
Fixed with subagents.
What comes after CLI?
In the early days of computing, desktop apps and later webapps provided richer human experiences.
What will provide richer experiences for agents, after CLIs?
It sounds like what we need is a better option for converting an existing OpenAPI into an MCP Server?
I’m sure Unisys will still support it for decades to come.
Oh. You mean that new thing also named MCP?
So what's this saying? Rather than trust the llm to query external tools via mcp you should handle the external queries yourself? Otherwise the llm wastes a bunch of queries?
I never understand the "eats context" argument. Why do you have so many MCP enabled in the first place? Do you actually use them in every project?
Meta: there is no question mark in the title of the original post.
Man I wish I could downvote stories. There needs to be some way to push back against dark patterns in writing, like clickbait.
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.
MCP is based on a lie: Machines are good at read/generate machine-parsable procotols.
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.
I swear something is dead every week for yall.
mcp will consolidate, its all stdio fragile and stateless
The vernacular around prompts, text, and docs, is quite amazing. Marketing really is value creation.
The idea that MCP tool definitions take up a certain number of tokens is laughable. That's an implementation detail of the agent harness. MCP is just an API specification. Hell, there's nothing in it that makes it much of any different than OpenAPI, except that its a bit more local-dev focused. There's a thousand things harnesses can and do do to optimize MCP beyond just "spit out the raw MCP output into the context window and pray".
MCP is just one of many -insecure- protocols that will be swallowed by a runtime governance protocol (like g8e) that is purpose-built for security, not to 'move fast and break stuff'.
MCP is what XML dreamed of becoming.
MCP will die for the same reason RAG died and why prompt engineering is dying. The models get better at understanding what you want and where to find the right tool or context to solve the problem on their own.
good to hear!
When agents don’t encrypt secrets, MCP servers help prevent users from handing their API tokens to AI providers or intermediaries such as Cloudflare and Akamai.
At cbk.ai we dynamically load MCPs into the context when the LLM needs them and unload them when finished. The cost for doing this is negligible and it scales well.
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.
Do CLI enjoyers realize that MCP can be called via curl?
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...
> MCP is dead
scrolls down the page...
> So is MCP really dead? Not entirely
sigh...
Claude code basically fixes MCP context usage with tool search, so MCPs are only loaded into context when actually used. Unfortunately codex doesn't support that functionality.
Until that happy day arrives I run every required MCP with mcpc.
Claude context window is now 1M, not 200K, which significantly weakens the first argument.
These AI slop articles about AI are getting especially boring to read.
> 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)
Wait. it was alive?
MCP is dead. AI bubble. Windows is dead. Linux is dead.
The only thing worse than the people saying it are the people that repeat it.
Everyone is sort of missing the point here.
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.
[dead]
[dead]
[dead]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[dead]
[flagged]
[dead]
I still don't know what MCP is and I don't want to learn
I don't know about it being dead, but i certainly stopped using it because it kills the context. A huge amount of tokens are wasted to mcp when in use. Skills use far fewer tokens. From my experience anyway. I'm also not advanced enough so maybe I'm not using it right.
People who say MCPs are dead don’t understand how MCPs work or when to use them.