Hacker News

I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP.

The 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.

Was this written by AI?

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

The article has no date on it, but says deferred tool loading is a recent update that occurred after the article was written. Deferred tool loading was added in Nov 2025: https://www.anthropic.com/engineering/advanced-tool-use

So these numbers are at least 7 months out of date. Why is this being posted now?

I'll kick myself for not remembering, but there was a fantastic article which suggested that MCP works at org level when unified, safe, access to internal utility APIs need to be given to non-technical staff who do use internal agent tools. Codify your workflow(s) via skills and share across instances, anything that needs context aware API access should be mcp...

Besides points already mentioned,

- 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

Here's a crazy idea: instead of dealing with MCP servers and distributing all the CLIs for all the platforms, just expose your API... through SSH.

SSH is the perfect protocol for LLMs. Coding agents can use it already, `ssh [email protected] 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.

Having implemented a skill to connect teams to our admin system, we ended up recording it as a Mcp. the Mcp exposes only doc grep and api calls so it's completely useless in itself, but the main reason to go this route was distribution. Non technical teams want a UI where to add a url then everything just works and oauth is guided. Mcp permits that in Claude or chatgpt.

Also the calling of the Mcp is nicer in the chat UI, clearer for users.

> Restaurant analogy:

> 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.

I try to use CLI-based services as much as possible and avoid MCPs.

(zero value comment following)

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.

>> MCP consumes ~65x more tokens than the CLI approach.

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.

Isn't MCP just a way to give agent tools? When you are building your own agent, you can define the tools manually, but if you're using something existing like opencode, how do you add new tools as a user? You use the API for that which is currently MCP. Saying MCP is dead is kind of like saying tools are dead, which is definitely not true because all modern LLM agents are trained for tool use and you wouldn't have agents without it.

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.

If you build connectors for yourself or your team, you probably can skip MCP because you can tell your friends to install CLI or whatever and provide extra prompts for your CLI.

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 works because it exposes primitives to agentic Loop and makes dynamic calls possible which would otherwise require very elaborate deterministic algorithms. I like to think of every mcp tool as a co-ordinate Axis. The more you have the more complex paths your agentic loops can traverse. So while that protocol is a wrapper and can surely go extinct something better with similar abstraction will show up

I love those "A coring drill is dead?" article.

"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.

Feels like we’re continuing to trend toward deterministic workflows which may actually be okay in 90% of cases. Reality is there’s a lot of unnecessary token burn happening right now. Simple market dynamics will solve that, i.e., when token cost subsidies begin to fade away and we face the true cost of agent applications.

A foolish question regarding the context window, cant it be extended using determinist compression? Like you can describe a chess game verbose or compress it down into chess similar to 1.e4 Nf6 2.e5 Nd5 3.d4 d6 4.c4 Nb6 5.f4. Basically you compress the context into deterministic knowledge sequence?

My mental model for MCPs is that it's like a Swagger/OpenAPI spec for LLMs. Point 2 doesn't make much sense in that context as it's describing MCP as a Swagger endpoint that's unstable.

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.

CLIs have to be distributed. Also have to be kept up to date. An MCP doesn't t have to concern itself with backwards compatibility and can be changed willy nilly since it's essentially always up to date.

It's also easier to manage for non-tech people. Try telling the people over at HR or finance to install a CLI.

clickbait. they knew what they were doing.

there's a long history of X is dead posts. PHP is dead, Java is dead, jquery is dead, unix is dead, REST is dead, graphql is dead, microservices is dead. and of course none of those things are dead. but... they're great for clickbait.

I used to compare MCP and Skill in my post (AI-assisted [1]) and also maintain a CLI/MCP/Skill for YouTube.

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

[3]: https://code.claude.com/docs/en/agent-sdk/tool-search

is this post old? MCP context poisoning was fixed like months ago

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

It's such a dumb discussion.

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.

Every mature MCP gateway solution should implement Code Mode (e.g. https://docs.gatana.ai/code-mode/) - it circumvents all the arguments.

In the end MCP is just a protocol for discovering tools. And agents _need_ to do stuff with tools.

Besides people with positions relevant to the field I'm weirded out by most of the replies, isn't MCP effectively just a communication standard? Like the only difference between an MCP server and my Express webserver is the supposed logic on how it needs to communicate with the AI, why are we making such a big deal out of it? Eventually we'll all converge into some form of standard to link things to our LLMs and it's probably going to be based in some form on MCP, but I genuinely don't get what the big deal is

I have been working full time in the MCP (& WebMCP) space for about a year now. Half consulting half spec work.

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

A good MCP server makes the difference between an agent using 20k tokens and 2 million. It may not matter yet with sponsored Codex and Claude subscriptions, but it will kill many use cases once providers switch to token-based billing.

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.

> Alternative 1: CLI-First Strategy

> 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.

2024. Oh woe, I have to scrape everything, why don't companies just give me an API to consume what I need.

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..

I don't understand how anyone is still primarily thinking about single-user scenarios in 2026

The points in this article don't really land for me. They are mostly critiques of particular MCP implementations rather than the modality itself. My impression right now:

- 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).

The pro-MCP arguments sound a lot like the same ones for SOAP, J2EE, "Enterprise Service Bus" and other "once-dominant, now dead in favor of dev driven simpler solutions" tech.

MCP and shell/bash tool calling serve totally different use-cases, this discussion is... odd.

I prefer the skill/CLI approach, but with Claude, I have found that building skills or plugins using CLI tools or bespoke code connected to external APIs runs into a problem with what Claude allows in its locked-down sandbox, particularly in Co-Work. The only way out of the sandbox seems to be MCP, and even then, there are timeout issues.

It was dead from the get go, agents need tools the do not cate about the details that much

I've thought that skills and small scripts > MCP for quite a while now, tried out MCP in the early days (official ones, ones i made for scripts i already had), but they always end up using more tool calls/tokens than if i had just written a script + skill for claude.

MCP is still great if you're running AI in an environment that precludes a shell while needing dynamic tool discovery, but that's a narrow set. People are learning how useful it is to give AI access to a shell. If you're giving them a shell, may as well give them a CLI.

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.

Well, I am not sure why everything is declared dead nowadays, I am actually trying to find the thing that actually die when people claim "x" is dead. Everyone is riding the wave, and so am I tbh...but the dead thing...I mean.. invite me to the funeral then

MCP’s are fine

They are easy to implement and integrate

You can use OAuth and handle ACL easily

I think mcp will become more important than ever.

I use all three (MCP/CLI/API) based on what Claude excels at:

* 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.

A bit off topic, but I think Google's A2A protocol could be a sleeper hit vs. the MCP protocol.

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.

I think those are solvable problems. E.g. wrap mcp in skill or seperate forked (non context eating) call to smaller model to ask which mcps are applicable. Iet probably does this. Honestly I have not had issues with MCPs where I felt compelled to debug them.

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 writing MCP servers, now I just write tools for agents to consume. It's often easier to simply write the tool you need and suggest to it to look at the tool to do that thing.

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.

A CLI or authenticated web endpoint requires somewhat arbitrary terminal or code access. MCP wraps the functionality in a way that doesn't require nearly the same permissions. Doesn't that enable a whole different class of users?

> Using existing CLI directly: No context wasted on tool definitions

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?

IDK, in my company we are qwen code base agent with quite a few MCP's:

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.

I just don't see how she missed in her example that the post to linear graphql endpoint needs the model to load the graphql definitions, there's no way it's 65x the tokens. Whatever overage it actually is, it's well worth not having to muck around with graphql.

People who say MCPs are dead don’t understand how MCPs work or when to use them.

I think it is on the way to death because of security .

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.

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?

There is no publishing date on the article.

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?

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.

I swear something is dead every week for yall.

Meta: there is no question mark in the title of the original post.

Editorialized title is not cool, HN.

The vernacular around prompts, text, and docs, is quite amazing. Marketing really is value creation.

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.

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 will consolidate, its all stdio fragile and stateless

Fixed with subagents.

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.

Is Betteridge's law of headlines irrelevant today?

https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines

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.

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...

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.

> 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.

[1] https://github.com/apify/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.

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.