11 ms·

MCP is dead?

400 points by nadis 4mo ago

sprakhya 4mo ago
I think mcp will become more important than ever.
c0rruptbytes 4mo ago
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
- JoshGlazebrook 4mo ago
  > Update: Since these measurements were taken, Claude Code has rolled out Tool Search with Deferred Loading, which loads MCP tool schemas on-demand and reduces context usage by 85%+. The context bloat described in Problem 1 is largely addressed for users on current Claude Code versions. The performance, debugging, and architectural arguments below still apply. pretty much
- Apocryphon 4mo ago
  Not providing a publishing date is real maddening.
zvoque 4mo ago
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.
- eikenberry 4mo ago
  MCP seems like what you'd do when you want to encapsulate and share a skill+script in a standard way.
  - noodletheworld 4mo ago
    You can share a skill by copy pasting the text file to someone in slack. Its not that hard.
    - notatoad 4mo ago
      right, but if you have 300 employees using ai and you want to share a skill with all of them, and you want to be able to push an update to the skill, mcp provides you with a standard way to do that. i dont understand why people are so invested in making this a winner-take-all battle. skills are ligthweight and ad-hoc, MCP is managed and centralized. there's a place for both of those things, even if your personal workflow only needs skills.
      - noodletheworld 4mo ago
        This is a daft argument. We have b2b enterprise solutions for sharing text files; we have 1st party, security approved methods for distributing source code that are fundamentally business friendly and compatible with using skills. MCP might have a place, but claiming it exists because you need a more “enterprise” solution to distributing prompts is just enormously difficult to justify. (Unless, as the other peer comment indicates, you're not actually trying to make things better or useful, you're trying to sell access to your MCP server. I admit, I take it back; if shilling your company is all you care about maybe MCP is a better option)
      - PhilipRoman 4mo ago
        Don't most companies have a Git repo for skills that you can pull?
        notatoad 4mo ago
        for developers working in claude code, sure. but there's ai users who don't use claude code. chatGPT business and enterprise tiers integrate with MCP servers controlled by your organization admin.
    - 4mo ago
0907 4mo ago
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...
- gk1 4mo ago
  Exactly right. Co’s like Runlayer are growing like wild exactly for this reason. Without a central control plane MCP is a minefield.
  - 0907 4mo ago
    hadn't heard of runlayer, but it does make sense. I'm a huge advocate of skills based on the company/process or project owners perspectives and workflow habits rather than using skills.sh or similar. You will end up cosplaying as someone elses perspective and wonder why you don't understand it..
- CharlieDigital 4mo ago
  This one? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/ https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
  - 0907 4mo ago
    Yes, exactly that one! thanks
- bb88 4mo ago
  So is this in lieu of using permissions to protect apis? Because it seems like API's should have some kind of permission mechanism around them anyway.
  - 0907 4mo ago
    Yes and no -- you can give internal agents access to internal APIs by using rudimentary env var, and org level agentic services tend to offer that kind of permission based access (either roll your own, use an 'enterprise' service, or be knowledgeable that if things go wrong, they'll go very wrong). APIs should, at least from my perspective, always have permission mechanisms. But internal APIs, used by 'internal' agents, have access to those the same way users on the network do, just depends on what flavour of network one is using. Essentially it's anything that _could_ be on a dashboard, but _might_ be accessed conversationally via an agent.
thenewnewguy 4mo ago
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)
- kristopolous 4mo ago
  There's a fix for the context which involved an mcp search and execute gateway. Essentially the mcp server queries for desired capabilities, gets search results with execution and requirement details and fires off the actual mcp as subcalls: https://github.com/day50-dev/mcp-search-and-run https://github.com/day50-dev/mcp-search-and-run You can call it "rag for mcp". I was pushing it hard a few months ago and nobody seemed to care but I'm all in if the timing has caught up to the tech. It's nontrivial effort: basically a giant survey of all the mcp servers, running inference over them to figure out how to instrument them, cross referencing to make sure they are the "official" sources (or at least the ones that search engines think are) then using qdrant to do embeddings and reranking and offering it for free. If people have become interested I'm all in. I'll bring the infra back up. I just don't want to spin my wheels on dead end streets. The value proposition is solid, the problem is real, this fix works, it's fast, it's free, and people give exactly zero shits. I dunno... One day I'll figure it out, hopefully...
comrade1234 4mo ago
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?
speff 4mo ago
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.
- monkpit 4mo ago
  What is special about MCP to make it any more or less fragile than any other software? MCP is a combination of a server responding to requests, and a prompt to tell the agent how to format those requests.
dnnddidiej 4mo ago
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.
bb88 4mo ago
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.
- didibus 4mo ago
  > now I just write tools for agents to consume What do you mean? Tool is a pretty generic concept.
willio58 4mo ago
> 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?
- 0xbadcafebee 4mo ago
  The usual problem is companies write an MCP server with 50 different tools, and each one has a schema, description, etc. Say each tool is 150 tokens, that's 150 * 50, or 7500 tokens, dumped into the beginning of every session. Compared to a text file that gets loaded on demand with command-line tool examples, so you still get close to the same amount of context, but you can control what tool definitions you pull in. The other thing is the agent gets the entire MCP API response dumped into context as a tool response in JSON, which can be a lot. Compare that to shell commands where agents often `head` or `tail` or `grep` the response (which I kinda hate, but it does save tokens). It also depends on whether the agent loads them on-demand or not (most modern agents do), and whether your MCP has a ton of tools or not. If your MCP only has 2 tools, and the responses aren't big, it's really not that much context. The other thing that doesn't get talked about is the non-determinism of shell one-liners. There is a lot more non-determinism in shell tool calls; the AI can mess up commands, options, arguments. It can incorrectly filter output, miss output, miss return status, which results in re-running calls, polluting context, making results worse. Compare that to MCP calls which are more likely to succeed because they have a schema, well-defined errors, etc. Do you want less token use or more reliable results? The thing is, you don't have to pick a side. I personally use both MCPs and CLIs at different times in different ways. Often I'll have the AI write a small script to do many calls (sometimes with tools, sometimes with libraries) which saves tokens, allows me to review, and is more deterministic.
  - willio58 4mo ago
    Thanks for the answer! I do see both sides
- 4mo ago
rgbrenner 4mo ago
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 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?
- wild_egg 4mo ago
  Deferred tool loading is not part of MCP. It's a Claude API special parameter that most other LLM APIs do not support.
  - didibus 4mo ago
    Deferred cli/skill loading is also not part of CLIs or skills, it's all about how the coding agent/harness is implemented.
  - red_hare 4mo ago
    OpenAI API also supports defer_loading https://developers.openai.com/api/docs/guides/tools-tool-search https://developers.openai.com/api/docs/guides/tools-tool-sea... And it's not actually necessary for it to exist at the API level. It's a pattern. Making it API-side is just an optimization. To do it client-side: 1. Define a single tool, tool_search 2. List the names of your deferred tools in context (or tool_search's description) 3. When tool_search is called, match the query against the tool names (or names + descriptions) 4. Append the matched tool def to the context in a new <system>-esque tag Claude Code (as of the leak) does this client side. You can even see the custom matching function and A/B tests about whether to include the descriptions. Whether or not that tool definition comes from MCP or a local definition is kind of beside the point.
  - BeetleB 4mo ago
    On the flip side, Claude is at fault in not letting you choose which tools on which MCP servers to keep in context. When I first starting using MCP about a year ago (not on Claude Code), my tools actually let me selectively turn on/off individual tools. Crazy that the company that invented MCP is not putting basic features like this in the product.
CSMastermind 4mo ago
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.
- bluegatty 4mo ago
  It's the way that it occupies the context relatively permanently, that it doesn't come along with nice install/uninstall or discovery etc. is the problem. 'Skills' should all be based on MCP, they should load on demand, be very easily manageable and discoverable by humans and by AI, and then it would work The scope was too narrow, given how it ended up being applied. If they layer something on top of it, it may yet be revived.
  - didibus 4mo ago
    You do know MCPs are loaded on demand same as skills now right? The only place where sometimes it still uses too much context is if you have too many MCPs (same issue with skills) or some MCP is poorly designed and responds with huge description or MCP calls respond with way too much info, but skills can have this issue as well.
    - bluegatty 4mo ago
      Yes, MCP taking the form of 'skill' because MCP serves no purpose. The concept of 'mcp server' is a brittle abstraction that need not exist. A 'skill' is utterly superior in every sense: a 'right sized abstraction for whatever it is you're trying to do' - that can include cli / rest - and other key bits of information.
      - ok_dad 4mo ago
        You realize that not every user of agents uses them like Claude or Codex on your local CLI right? MCP is the standard for cloud agents. How do you get a cloud agent working in an ephemeral container access to skills? The answer is MCP.
madrox 4mo ago
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.
mxstbr 4mo ago
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.
- alexwwang 4mo ago
  I agree. Mcp might be useless in a personal scenario but it absolutely plays a role of service infrastructure in organizations. It is another form of api for those abilities that are not wrapped with rest api yet. But when they are wrapped in mcp, it seems not necessary to wrap them into rest api or cli again in near future. So these mcp services survive. The only thing matters is how to import these mcp services into agent context on demand or say by the gradual disclosure principle.
  - jimbokun 4mo ago
    Unless you also want humans to also interact with your tools. That’s covered in the article: a human can modify the commands generated by the agent, or vice versa, to debug problems or transfer knowledge.
    - alexwwang 4mo ago
0xbadcafebee 4mo ago
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.
- notgenerated 4mo ago
  Most of the internet is clickbait for a long while now. No one would read a title like "MCP and CLI can both be usefull in certain scenarios. Ask your AI and he'll tell ya" :)
msukkarieh 4mo ago
> MCP is dead scrolls down the page... > So is MCP really dead? Not entirely sigh...
adi_kurian 4mo ago
The vernacular around prompts, text, and docs, is quite amazing. Marketing really is value creation.
insane_dreamer 4mo ago
Claude context window is now 1M, not 200K, which significantly weakens the first argument.
- DonHopkins 4mo ago
  And significantly increases the price.
  - insane_dreamer 4mo ago
    I'm paying the same $100/month that I was back when the context window was 200K, so, no.
    - DonHopkins 4mo ago
      In other words, you're on a monthly plan, haven't read the not-so-fine print, and not going over your monthly limit, so not paying by the token yet. When you do, you will be in for a big surprise. Look it up. You'll thank me later.
cowlby 4mo ago
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.
- etoxin 4mo ago
  Also MCPs for programs like Chrome Dev tools or Playwright.
  - sodafountan 4mo ago
    Ah, this helped me wrap my head around what actually makes an MCP special.
king_zee 4mo ago
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
xyzsparetimexyz 4mo ago
[flagged]
- DonHopkins 4mo ago
  Then don't read the article, and don't post your Human Slop to this discussion. With your incurious attitude and performative compulsion to proudly announce your cultivated self imposed ignorance instead of contributing to the discussion, it would be best for everyone if you just deleted your account. Your best hope is to go find a job in the Trump Administration regulating AI, where you'll fit in perfectly.
ActorNightly 4mo ago
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.
- youre-wrong3 4mo ago
  No. The author is wrong. If you’re still using single model/context then it’s kinda your own fault for using things poorly.
fg137 4mo ago
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?
- esafak 4mo ago
  So you have to manually enable/disable every MCP? What fun...
  - fg137 4mo ago
    You have MCPs disabled by default but turn on the ones you need in specific projects. Set this up once per project. I use Playwright MCP, but there is absolutely no reason I'd keep it enabled in a Go project.
tanin 4mo ago
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
- d0mine 4mo ago
  If you need a network boundary, what MCP provides that REST API + llms.txt can't do?
  - jiggunjer 4mo ago
    Standardization. Who writes llms.txt? Everyone writes their own? Will agents still behave the same?
  - tanin 4mo ago
    The AI probably can figure out. However, Claude Code and other tools are built to support MCP. This means MCP is probably more reliable than using REST API + llms.txt.
  - charrondev 4mo ago
    OIDC? Ease of deployment in a company? You can have your IT department configure an MCP for the org, and your regular non-technical users click a button and login with their account the service. Then they get all the tool calls authenticated as themselves.
hendersoon 4mo ago
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 https://github.com/apify/mcpc
- huodon 4mo ago
  [flagged]
spotlayn 4mo ago
[flagged]
onesingleblast 4mo ago
I swear something is dead every week for yall.
dannypdx 4mo ago
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'.
- monkpit 4mo ago
  You should disclose that you are behind g8e.
  - dannypdx 4mo ago
    Do I need to add a disclaimer to every one of my posts that shits on the wrong way?
    - monkpit 4mo ago
      When you mention your own product in a positive light, it’s customary, yes.
827a 4mo ago
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".
jalospinoso 4mo ago
[flagged]
iJohnDoe 4mo ago
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.
- Aldipower 4mo ago
  At some point people are dead. Really.
joeyguerra 4mo ago
Wait. it was alive?
miguelspizza 4mo ago
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
TurdF3rguson 4mo ago
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.
jaynate 4mo ago
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.
- btbuildem 4mo ago
  Bingo. All this agentic hype is just people discovering POCs. Yes you can hodgepodge semi-reliable solutions where you don't really know what you're trying to build so you wrap it in a layer than can sometimes approximate logic and decision making, so that you don't have to use logic or make decisions. Amazing. Sooner or later you have to build the real thing, and the cost and slowness of token-based computation become unacceptable.
  - jaynate 4mo ago
    Yes, and the free-for-all building of nonsense (and insecure) apps by non engineers is probably going to slow down as well.
figmert 4mo ago
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.
OpenWaygate 4mo ago
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/ https://log.ifor.dev/posts/mcp_vs_skill/ [2]: https://modelcontextprotocol.io/extensions/apps/overview https://modelcontextprotocol.io/extensions/apps/overview [3]: https://code.claude.com/docs/en/agent-sdk/tool-search https://code.claude.com/docs/en/agent-sdk/tool-search
ericyd 4mo ago
> 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.
firasd 4mo ago
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 https://github.com/firasd/mcpclock to https://mcpclock.firasd.workers.dev/mcp 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 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 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...
_puk 4mo ago
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..
Spiritus 4mo ago
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.
- deleted 4mo ago
  [deleted]
osigurdson 4mo ago
>> 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.
- didibus 4mo ago
  Not just that, but they retracted this: > Update: Since these measurements were taken, Claude Code has rolled out Tool Search with Deferred Loading, which loads MCP tool schemas on-demand and reduces context usage by 85%+. The context bloat described in Problem 1 is largely addressed for users on current Claude Code versions. The performance, debugging, and architectural arguments below still apply. Because Claude Code only loads the tools it needs now, so context bloat is pretty much solved for MCPs.
etoxin 4mo ago
People who say MCPs are dead don’t understand how MCPs work or when to use them.
tiffanyh 4mo ago
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?
robertclaus 4mo ago
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?
rixed 4mo ago
> Problem 1: It Devours the Context Window Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? At least with MCP your harness could add in the context only the title of each tool and add full documentation on demand, MCP server by MCP server and tool by tool. The equivalent would be for all CLI to feature a "--short-descr" command. > Problem 2: Low Operational Reliability If the tool is also using a REST API I see no reason why MCP should be slower, given the protocols are so close. When that happen, it's probably because MCP was added on top of an API, maybe hosted in a far away datacenter by a subcontractor? I won't argue that most MCP servers are probably awful, but that's an argument against the industry not the protocol. > Problem 3: Overlaps with Existing CLI/API Yes, when a CLI tool already exist. A SQL MCP server sounds stupid to me, and a waste of token. Why not a curl MCP? But in the vast majority of shops, a cli tool does not exist. At best they have an API, which is designed to be used by programs not LLMs (you know what I mean). > Provide CLI -> API -> docs, in that order Sure, and instead of slow and wasteful websites companies should first provide a native client for desktop, then a native client for phone.
- Mashimo 4mo ago
  > Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? I'm not super deep into all of this, but I think except latest Claude Code release the mcp is frontloaded into the context. So if you don't need it that often you have to disable and enabled it again when needed. And I guess you can put some usage examples into the skill file. Which might migate the first --help. Also I guess with cli it's easy to spin up a sub agent with their own context that just returns the result?
  - rixed 4mo ago
    Yes I believe it is preloaded (from a recent test with latest claude-code actually). But that's an issue with the harness not something that's mandated by the MCP protocol.
    - ok_dad 4mo ago
binyu 4mo ago
MCP is what XML dreamed of becoming.
extr 4mo ago
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).
kstenerud 4mo ago
> 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.
big-chungus4 4mo ago
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.
- helloplanets 4mo ago
  You can create tools without using MCP for OpenCode: https://opencode.ai/docs/custom-tools/ https://opencode.ai/docs/custom-tools/
  - nicman23 4mo ago
    i mean yeah but is just a spec
    - helloplanets 4mo ago
      What do you mean?
      - big-chungus4 4mo ago
        MCP is a way to define tools that works with many apps and has a lot of extra functionality built in, it's not the only way, but it's popular because many apps support it. You can also make tools using the opencode API or any other API, and you can give them large descriptions that take up a lot of context. No matter how you define the tools, they are injected into the context of the model using the same chat template provided by the developers of the model.
estetlinus 4mo ago
[dead]
crazytweek 4mo ago
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.
- geysersam 4mo ago
  Seems to me that you're saying the MCP is a simplified API with good documentation geared towards agents. But if that's the case, could you not exposes the simplified interface as part of the API, instead of exposing it in MCP?
  - crazytweek 4mo ago
    When it is part of the API, the agent still has the choice between multiple options. If it chooses the less efficient one, the request can become significantly more CPU- and token-intensive than necessary. The problem is that the agent does not care. Its primary goal is to get the job done. Maybe the agent is smart enough to choose the optimal path, but that strongly depends on the model being used. You also do not know who is on the other side. With a human-facing API, you can usually assume who is using it and what they want to achieve. Humans are generally lazy and tend to look for the most efficient solution. An agent, however, will happily iterate through 1,000 users and fetch the online state for each one individually, even across multiple paginated requests if necessary. You can provide an endpoint that returns the online states for all users at once. A human will most likely use that endpoint, but I have seen agents go completely wild on the other side. :D At some point, you may get a response like “token limit reached.” But what do you do then? You give the agent more tokens and increase your bill, because you cannot even tell whether there was a more optimized way to achieve the same result. In practice, this is a surprisingly tricky problem. :D
krissvai 4mo ago
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.
aykutseker 4mo ago
[dead]
xlii 4mo ago
Is Betteridge's law of headlines irrelevant today? https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines
- fragmede 4mo ago
  No.
david_shi 4mo ago
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.
bestony 4mo ago
It sounds like what we need is a better option for converting an existing OpenAPI into an MCP Server?
deleted 4mo ago
[deleted]
konart 4mo ago
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.
pmontra 4mo ago
Meta: there is no question mark in the title of the original post.
woodylondon 4mo ago
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.
thecopy 4mo ago
Every mature MCP gateway solution should implement Code Mode (e.g. https://docs.gatana.ai/code-mode/ 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.
rbanffy 4mo ago
I’m sure Unisys will still support it for decades to come. Oh. You mean that new thing also named MCP?
Ozzie-D 4mo ago
[flagged]
ashm1104 4mo ago
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
jedisct1 4mo ago
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.
disclos 4mo ago
[flagged]
deleted 4mo ago
[deleted]
miki123211 4mo ago
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 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.
- shdh 4mo ago
  Scale this across your organization
vonneumannstan 4mo ago
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.
menacingly 4mo ago
I don't understand how anyone is still primarily thinking about single-user scenarios in 2026
IFC_LLC 4mo ago
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.
customguy 4mo ago
(zero value comment following) Every time I read MCP, I think it means "master control program". http://mcp.a1k.org/indexe.html 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.
helloansh 4mo ago
mcp will consolidate, its all stdio fragile and stateless
_pdp_ 4mo ago
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.
- _pdp_ 4mo ago
  Oh forgot to mention that each CLI is basically another supply chain issue too. So there is that.
aspectop 4mo ago
[dead]
tyingq 4mo ago
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.
syedofc 4mo ago
[flagged]
Alifatisk 4mo ago
There is no publishing date on the article.
est 4mo ago
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.
olup 4mo ago
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.
xurenwu 4mo ago
I think it is on the way to death because of security .
- leowoo91 4mo ago
  i dont think there is anything preventing devs to filter out certain items from the tools list - security is more of a issue for how you are harnessing your agent (at code-level of course)
Voblit 4mo ago
good to hear!
spriterock 4mo ago
[flagged]
solarkraft 4mo ago
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.
fireant 4mo ago
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
wolttam 4mo ago
MCP and shell/bash tool calling serve totally different use-cases, this discussion is... odd.
dev_l1x_be 4mo ago
It was dead from the get go, agents need tools the do not cate about the details that much
lowbloodsugar 4mo ago
Fixed with subagents.
martinloop 4mo ago
[flagged]
shdh 4mo ago
MCP’s are fine They are easy to implement and integrate You can use OAuth and handle ACL easily
octoberfranklin 4mo ago
Editorialized title is not cool, HN.
ahonn 4mo ago
[dead]
warumdarum 4mo ago
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?
nkmak 4mo ago
[dead]
yarinzhang 4mo ago
[dead]
loaderchips 4mo ago
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
rupatiwari25 4mo ago
[dead]
ailinter 4mo ago
[flagged]
citelix 4mo ago
[dead]
ascotan 4mo ago
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.
g42gregory 4mo ago
I try to use CLI-based services as much as possible and avoid MCPs.
devil1432 4mo ago
From my experience, the biggest flaw of mcp is lack of control over your system prompt. Prompts need to be tailored for specific model (duh). Tool definitions are de facto part of your system prompt. By injecting tool definition from MCP servers into your prompt, you are basically adding prompt that was (likely) not tailored for your specific model. That causes drop in quality of answers. Other issue is that adding one new feature via MCP can introduce regression into your system and cause other MCP features to work incorrectly (and I am not talking about malicious prompt injection by MCP provider). Real life example: tools from MCP server for ms outlook requires certain date format for filtering emails. That worked fine in our prod. Until we added another MCP server (built in-house in another department of our company) that required dates in different format. After adding these tools, now our agent started making mistakes: putting dates in outlook format in our internal mcp tool and vice versa - putting dates in our internal format into outlook tool. There is no obvious way to fix it other than separating these prompts. And that goes against standard MCP architecture and consumes way more tokens to cycle through multiple prompts and agents. If that's already the issue with two MCP servers, then this architecture clearly does not scale.
navs 4mo ago
As much as I like to hate MCP, it has a place in its accessibility outside terminal based agents and in its ability to wrangle data before it’s consumed by the agent requesting it. Sure you can use a cli tool and jq. Most cli tools that interact with third party providers are just APIs so you could argue it could be replaced with a curl.
deleted 4mo ago
[deleted]
apf6 4mo ago
old and inaccurate knowledge.. - Skills do take up space in the context. The name and description of every skill goes into the system prompt. You can't add unlimited skills without context pressure. - MCP context spam is less of a big deal now that there is deferred tool loading. - If you work with the agents long enough you'll run into situations where using bash CLI tools suck and an MCP works better. - MCP is not dead and has never been dead, it's the right solution in certain cases.
powersjcb 4mo ago
MCP protocol layer is for all practical purposes an irrelevant implementation detail. We need some new layer to handle things that used to be abstracted away by UIs - filter to 6 of 50 fields for the paginated pipeline views - show all the important fields on a detail view - organize for understanding of fields that might have been poorly named in the public APIs Some of this can be handled by a CLI wrapper around an API, but it really just shifts the complexity into a different system. One thing that I haven't heard a lot of people talk about is that MCPs are often able to be far more flexible than a traditional REST api. You can ship breaking changes/renames and agents will adapt. Why should we couple the agent tooling locked 1-1 with our calcified systems?
crad 4mo ago
Perhaps this should be "People don't understand how to implement good MCP servers" as opposed to MCP is dead. MCP shouldn't be 1-1 to API. It should empower users and LLMs to perform tasks and see data. CLIs don't improve upon that issue if they're designed the same way people are implementing MCPs.
mikekuharuk 4mo ago
To be honest a bit weird. You say MCP is dead and talking about tokens price, then mentioning SKILLS to replace it - which will cost probably more tokens to do it. And not even mentioning that SKILLS has nothing to do with functionality itself MCP provides. To be honest a bit weird article :D
rldjbpin 4mo ago
it is not dead for my team, but surely if one prefers to replace them with skills, they are most likely wrong. at least outside of personal, one-user scenarios. has anybody ever use the prompt templates in practice? for what it's worth, these protocols are a product of their time, and unfortunately people lose patience with seeing it through in practice. in the end it is all text. things are overengineered regardless, but at least this allowed reuse across projects.

400 points by nadis 4mo ago

I think mcp will become more important than ever.

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

JoshGlazebrook 4mo ago
> Update: Since these measurements were taken, Claude Code has rolled out Tool Search with Deferred Loading, which loads MCP tool schemas on-demand and reduces context usage by 85%+. The context bloat described in Problem 1 is largely addressed for users on current Claude Code versions. The performance, debugging, and architectural arguments below still apply. pretty much
Apocryphon 4mo ago
Not providing a publishing date is real maddening.

zvoque 4mo ago

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.

eikenberry 4mo ago
MCP seems like what you'd do when you want to encapsulate and share a skill+script in a standard way.
- noodletheworld 4mo ago
  You can share a skill by copy pasting the text file to someone in slack. Its not that hard.
  - notatoad 4mo ago
    right, but if you have 300 employees using ai and you want to share a skill with all of them, and you want to be able to push an update to the skill, mcp provides you with a standard way to do that. i dont understand why people are so invested in making this a winner-take-all battle. skills are ligthweight and ad-hoc, MCP is managed and centralized. there's a place for both of those things, even if your personal workflow only needs skills.
    - noodletheworld 4mo ago
      This is a daft argument. We have b2b enterprise solutions for sharing text files; we have 1st party, security approved methods for distributing source code that are fundamentally business friendly and compatible with using skills. MCP might have a place, but claiming it exists because you need a more “enterprise” solution to distributing prompts is just enormously difficult to justify. (Unless, as the other peer comment indicates, you're not actually trying to make things better or useful, you're trying to sell access to your MCP server. I admit, I take it back; if shilling your company is all you care about maybe MCP is a better option)
    - PhilipRoman 4mo ago
      Don't most companies have a Git repo for skills that you can pull?
      - notatoad 4mo ago
        for developers working in claude code, sure. but there's ai users who don't use claude code. chatGPT business and enterprise tiers integrate with MCP servers controlled by your organization admin.
  - 4mo ago

0907 4mo ago

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

gk1 4mo ago
Exactly right. Co’s like Runlayer are growing like wild exactly for this reason. Without a central control plane MCP is a minefield.
- 0907 4mo ago
  hadn't heard of runlayer, but it does make sense. I'm a huge advocate of skills based on the company/process or project owners perspectives and workflow habits rather than using skills.sh or similar. You will end up cosplaying as someone elses perspective and wonder why you don't understand it..
CharlieDigital 4mo ago
This one? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/ https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
- 0907 4mo ago
  Yes, exactly that one! thanks
bb88 4mo ago
So is this in lieu of using permissions to protect apis? Because it seems like API's should have some kind of permission mechanism around them anyway.
- 0907 4mo ago
  Yes and no -- you can give internal agents access to internal APIs by using rudimentary env var, and org level agentic services tend to offer that kind of permission based access (either roll your own, use an 'enterprise' service, or be knowledgeable that if things go wrong, they'll go very wrong). APIs should, at least from my perspective, always have permission mechanisms. But internal APIs, used by 'internal' agents, have access to those the same way users on the network do, just depends on what flavour of network one is using. Essentially it's anything that _could_ be on a dashboard, but _might_ be accessed conversationally via an agent.

thenewnewguy 4mo ago

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)

kristopolous 4mo ago
There's a fix for the context which involved an mcp search and execute gateway. Essentially the mcp server queries for desired capabilities, gets search results with execution and requirement details and fires off the actual mcp as subcalls: https://github.com/day50-dev/mcp-search-and-run https://github.com/day50-dev/mcp-search-and-run You can call it "rag for mcp". I was pushing it hard a few months ago and nobody seemed to care but I'm all in if the timing has caught up to the tech. It's nontrivial effort: basically a giant survey of all the mcp servers, running inference over them to figure out how to instrument them, cross referencing to make sure they are the "official" sources (or at least the ones that search engines think are) then using qdrant to do embeddings and reranking and offering it for free. If people have become interested I'm all in. I'll bring the infra back up. I just don't want to spin my wheels on dead end streets. The value proposition is solid, the problem is real, this fix works, it's fast, it's free, and people give exactly zero shits. I dunno... One day I'll figure it out, hopefully...

comrade1234 4mo ago

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?

speff 4mo ago

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.

monkpit 4mo ago
What is special about MCP to make it any more or less fragile than any other software? MCP is a combination of a server responding to requests, and a prompt to tell the agent how to format those requests.

dnnddidiej 4mo ago

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.

bb88 4mo ago

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.

didibus 4mo ago
> now I just write tools for agents to consume What do you mean? Tool is a pretty generic concept.

willio58 4mo ago

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

0xbadcafebee 4mo ago
The usual problem is companies write an MCP server with 50 different tools, and each one has a schema, description, etc. Say each tool is 150 tokens, that's 150 * 50, or 7500 tokens, dumped into the beginning of every session. Compared to a text file that gets loaded on demand with command-line tool examples, so you still get close to the same amount of context, but you can control what tool definitions you pull in. The other thing is the agent gets the entire MCP API response dumped into context as a tool response in JSON, which can be a lot. Compare that to shell commands where agents often `head` or `tail` or `grep` the response (which I kinda hate, but it does save tokens). It also depends on whether the agent loads them on-demand or not (most modern agents do), and whether your MCP has a ton of tools or not. If your MCP only has 2 tools, and the responses aren't big, it's really not that much context. The other thing that doesn't get talked about is the non-determinism of shell one-liners. There is a lot more non-determinism in shell tool calls; the AI can mess up commands, options, arguments. It can incorrectly filter output, miss output, miss return status, which results in re-running calls, polluting context, making results worse. Compare that to MCP calls which are more likely to succeed because they have a schema, well-defined errors, etc. Do you want less token use or more reliable results? The thing is, you don't have to pick a side. I personally use both MCPs and CLIs at different times in different ways. Often I'll have the AI write a small script to do many calls (sometimes with tools, sometimes with libraries) which saves tokens, allows me to review, and is more deterministic.
- willio58 4mo ago
  Thanks for the answer! I do see both sides
4mo ago

rgbrenner 4mo ago

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

wild_egg 4mo ago
Deferred tool loading is not part of MCP. It's a Claude API special parameter that most other LLM APIs do not support.
- didibus 4mo ago
  Deferred cli/skill loading is also not part of CLIs or skills, it's all about how the coding agent/harness is implemented.
- red_hare 4mo ago
  OpenAI API also supports defer_loading https://developers.openai.com/api/docs/guides/tools-tool-search https://developers.openai.com/api/docs/guides/tools-tool-sea... And it's not actually necessary for it to exist at the API level. It's a pattern. Making it API-side is just an optimization. To do it client-side: 1. Define a single tool, tool_search 2. List the names of your deferred tools in context (or tool_search's description) 3. When tool_search is called, match the query against the tool names (or names + descriptions) 4. Append the matched tool def to the context in a new <system>-esque tag Claude Code (as of the leak) does this client side. You can even see the custom matching function and A/B tests about whether to include the descriptions. Whether or not that tool definition comes from MCP or a local definition is kind of beside the point.
- BeetleB 4mo ago
  On the flip side, Claude is at fault in not letting you choose which tools on which MCP servers to keep in context. When I first starting using MCP about a year ago (not on Claude Code), my tools actually let me selectively turn on/off individual tools. Crazy that the company that invented MCP is not putting basic features like this in the product.

CSMastermind 4mo ago

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.

bluegatty 4mo ago
It's the way that it occupies the context relatively permanently, that it doesn't come along with nice install/uninstall or discovery etc. is the problem. 'Skills' should all be based on MCP, they should load on demand, be very easily manageable and discoverable by humans and by AI, and then it would work The scope was too narrow, given how it ended up being applied. If they layer something on top of it, it may yet be revived.
- didibus 4mo ago
  You do know MCPs are loaded on demand same as skills now right? The only place where sometimes it still uses too much context is if you have too many MCPs (same issue with skills) or some MCP is poorly designed and responds with huge description or MCP calls respond with way too much info, but skills can have this issue as well.
  - bluegatty 4mo ago
    Yes, MCP taking the form of 'skill' because MCP serves no purpose. The concept of 'mcp server' is a brittle abstraction that need not exist. A 'skill' is utterly superior in every sense: a 'right sized abstraction for whatever it is you're trying to do' - that can include cli / rest - and other key bits of information.
    - ok_dad 4mo ago
      You realize that not every user of agents uses them like Claude or Codex on your local CLI right? MCP is the standard for cloud agents. How do you get a cloud agent working in an ephemeral container access to skills? The answer is MCP.

madrox 4mo ago

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.

mxstbr 4mo ago

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.

alexwwang 4mo ago
I agree. Mcp might be useless in a personal scenario but it absolutely plays a role of service infrastructure in organizations. It is another form of api for those abilities that are not wrapped with rest api yet. But when they are wrapped in mcp, it seems not necessary to wrap them into rest api or cli again in near future. So these mcp services survive. The only thing matters is how to import these mcp services into agent context on demand or say by the gradual disclosure principle.
- jimbokun 4mo ago
  Unless you also want humans to also interact with your tools. That’s covered in the article: a human can modify the commands generated by the agent, or vice versa, to debug problems or transfer knowledge.
  - alexwwang 4mo ago

0xbadcafebee 4mo ago

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.

notgenerated 4mo ago
Most of the internet is clickbait for a long while now. No one would read a title like "MCP and CLI can both be usefull in certain scenarios. Ask your AI and he'll tell ya" :)

msukkarieh 4mo ago

> MCP is dead scrolls down the page... > So is MCP really dead? Not entirely sigh...

adi_kurian 4mo ago

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

insane_dreamer 4mo ago

Claude context window is now 1M, not 200K, which significantly weakens the first argument.

DonHopkins 4mo ago
And significantly increases the price.
- insane_dreamer 4mo ago
  I'm paying the same $100/month that I was back when the context window was 200K, so, no.
  - DonHopkins 4mo ago
    In other words, you're on a monthly plan, haven't read the not-so-fine print, and not going over your monthly limit, so not paying by the token yet. When you do, you will be in for a big surprise. Look it up. You'll thank me later.

cowlby 4mo ago

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.

etoxin 4mo ago
Also MCPs for programs like Chrome Dev tools or Playwright.
- sodafountan 4mo ago
  Ah, this helped me wrap my head around what actually makes an MCP special.

king_zee 4mo ago

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

xyzsparetimexyz 4mo ago

[flagged]

DonHopkins 4mo ago
Then don't read the article, and don't post your Human Slop to this discussion. With your incurious attitude and performative compulsion to proudly announce your cultivated self imposed ignorance instead of contributing to the discussion, it would be best for everyone if you just deleted your account. Your best hope is to go find a job in the Trump Administration regulating AI, where you'll fit in perfectly.

ActorNightly 4mo ago

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.

youre-wrong3 4mo ago
No. The author is wrong. If you’re still using single model/context then it’s kinda your own fault for using things poorly.

fg137 4mo ago

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?

esafak 4mo ago
So you have to manually enable/disable every MCP? What fun...
- fg137 4mo ago
  You have MCPs disabled by default but turn on the ones you need in specific projects. Set this up once per project. I use Playwright MCP, but there is absolutely no reason I'd keep it enabled in a Go project.

tanin 4mo ago

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

d0mine 4mo ago
If you need a network boundary, what MCP provides that REST API + llms.txt can't do?
- jiggunjer 4mo ago
  Standardization. Who writes llms.txt? Everyone writes their own? Will agents still behave the same?
- tanin 4mo ago
  The AI probably can figure out. However, Claude Code and other tools are built to support MCP. This means MCP is probably more reliable than using REST API + llms.txt.
- charrondev 4mo ago
  OIDC? Ease of deployment in a company? You can have your IT department configure an MCP for the org, and your regular non-technical users click a button and login with their account the service. Then they get all the tool calls authenticated as themselves.

hendersoon 4mo ago

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 https://github.com/apify/mcpc

huodon 4mo ago
[flagged]

spotlayn 4mo ago

[flagged]

onesingleblast 4mo ago

I swear something is dead every week for yall.

dannypdx 4mo ago

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

monkpit 4mo ago
You should disclose that you are behind g8e.
- dannypdx 4mo ago
  Do I need to add a disclaimer to every one of my posts that shits on the wrong way?
  - monkpit 4mo ago
    When you mention your own product in a positive light, it’s customary, yes.

827a 4mo ago

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

jalospinoso 4mo ago

[flagged]

iJohnDoe 4mo ago

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.

Aldipower 4mo ago
At some point people are dead. Really.

joeyguerra 4mo ago

Wait. it was alive?

miguelspizza 4mo ago

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

TurdF3rguson 4mo ago

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.

jaynate 4mo ago

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.

btbuildem 4mo ago
Bingo. All this agentic hype is just people discovering POCs. Yes you can hodgepodge semi-reliable solutions where you don't really know what you're trying to build so you wrap it in a layer than can sometimes approximate logic and decision making, so that you don't have to use logic or make decisions. Amazing. Sooner or later you have to build the real thing, and the cost and slowness of token-based computation become unacceptable.
- jaynate 4mo ago
  Yes, and the free-for-all building of nonsense (and insecure) apps by non engineers is probably going to slow down as well.

figmert 4mo ago

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.

OpenWaygate 4mo ago

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/ https://log.ifor.dev/posts/mcp_vs_skill/ [2]: https://modelcontextprotocol.io/extensions/apps/overview https://modelcontextprotocol.io/extensions/apps/overview [3]: https://code.claude.com/docs/en/agent-sdk/tool-search https://code.claude.com/docs/en/agent-sdk/tool-search

ericyd 4mo ago

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

firasd 4mo ago

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 https://github.com/firasd/mcpclock to https://mcpclock.firasd.workers.dev/mcp 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 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 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...

_puk 4mo ago

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

Spiritus 4mo ago

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.

deleted 4mo ago
[deleted]

osigurdson 4mo ago

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

didibus 4mo ago
Not just that, but they retracted this: > Update: Since these measurements were taken, Claude Code has rolled out Tool Search with Deferred Loading, which loads MCP tool schemas on-demand and reduces context usage by 85%+. The context bloat described in Problem 1 is largely addressed for users on current Claude Code versions. The performance, debugging, and architectural arguments below still apply. Because Claude Code only loads the tools it needs now, so context bloat is pretty much solved for MCPs.

etoxin 4mo ago

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

tiffanyh 4mo ago

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?

robertclaus 4mo ago

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?

rixed 4mo ago

> Problem 1: It Devours the Context Window Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? At least with MCP your harness could add in the context only the title of each tool and add full documentation on demand, MCP server by MCP server and tool by tool. The equivalent would be for all CLI to feature a "--short-descr" command. > Problem 2: Low Operational Reliability If the tool is also using a REST API I see no reason why MCP should be slower, given the protocols are so close. When that happen, it's probably because MCP was added on top of an API, maybe hosted in a far away datacenter by a subcontractor? I won't argue that most MCP servers are probably awful, but that's an argument against the industry not the protocol. > Problem 3: Overlaps with Existing CLI/API Yes, when a CLI tool already exist. A SQL MCP server sounds stupid to me, and a waste of token. Why not a curl MCP? But in the vast majority of shops, a cli tool does not exist. At best they have an API, which is designed to be used by programs not LLMs (you know what I mean). > Provide CLI -> API -> docs, in that order Sure, and instead of slow and wasteful websites companies should first provide a native client for desktop, then a native client for phone.

Mashimo 4mo ago
> Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something? I'm not super deep into all of this, but I think except latest Claude Code release the mcp is frontloaded into the context. So if you don't need it that often you have to disable and enabled it again when needed. And I guess you can put some usage examples into the skill file. Which might migate the first --help. Also I guess with cli it's easy to spin up a sub agent with their own context that just returns the result?
- rixed 4mo ago
  Yes I believe it is preloaded (from a recent test with latest claude-code actually). But that's an issue with the harness not something that's mandated by the MCP protocol.
  - ok_dad 4mo ago

binyu 4mo ago

MCP is what XML dreamed of becoming.

extr 4mo ago

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

kstenerud 4mo ago

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

big-chungus4 4mo ago

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.

helloplanets 4mo ago
You can create tools without using MCP for OpenCode: https://opencode.ai/docs/custom-tools/ https://opencode.ai/docs/custom-tools/
- nicman23 4mo ago
  i mean yeah but is just a spec
  - helloplanets 4mo ago
    What do you mean?
    - big-chungus4 4mo ago
      MCP is a way to define tools that works with many apps and has a lot of extra functionality built in, it's not the only way, but it's popular because many apps support it. You can also make tools using the opencode API or any other API, and you can give them large descriptions that take up a lot of context. No matter how you define the tools, they are injected into the context of the model using the same chat template provided by the developers of the model.

estetlinus 4mo ago

[dead]

crazytweek 4mo ago

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.

geysersam 4mo ago
Seems to me that you're saying the MCP is a simplified API with good documentation geared towards agents. But if that's the case, could you not exposes the simplified interface as part of the API, instead of exposing it in MCP?
- crazytweek 4mo ago
  When it is part of the API, the agent still has the choice between multiple options. If it chooses the less efficient one, the request can become significantly more CPU- and token-intensive than necessary. The problem is that the agent does not care. Its primary goal is to get the job done. Maybe the agent is smart enough to choose the optimal path, but that strongly depends on the model being used. You also do not know who is on the other side. With a human-facing API, you can usually assume who is using it and what they want to achieve. Humans are generally lazy and tend to look for the most efficient solution. An agent, however, will happily iterate through 1,000 users and fetch the online state for each one individually, even across multiple paginated requests if necessary. You can provide an endpoint that returns the online states for all users at once. A human will most likely use that endpoint, but I have seen agents go completely wild on the other side. :D At some point, you may get a response like “token limit reached.” But what do you do then? You give the agent more tokens and increase your bill, because you cannot even tell whether there was a more optimized way to achieve the same result. In practice, this is a surprisingly tricky problem. :D

krissvai 4mo ago

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.

aykutseker 4mo ago

[dead]

xlii 4mo ago

Is Betteridge's law of headlines irrelevant today? https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines

fragmede 4mo ago
No.

david_shi 4mo ago

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.

bestony 4mo ago

It sounds like what we need is a better option for converting an existing OpenAPI into an MCP Server?

deleted 4mo ago

[deleted]

konart 4mo ago

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.

pmontra 4mo ago

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

woodylondon 4mo ago

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.

thecopy 4mo ago

Every mature MCP gateway solution should implement Code Mode (e.g. https://docs.gatana.ai/code-mode/ 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.

rbanffy 4mo ago

I’m sure Unisys will still support it for decades to come. Oh. You mean that new thing also named MCP?

Ozzie-D 4mo ago

[flagged]

ashm1104 4mo ago

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

jedisct1 4mo ago

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.

disclos 4mo ago

[flagged]

deleted 4mo ago

[deleted]

miki123211 4mo ago

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

shdh 4mo ago
Scale this across your organization

vonneumannstan 4mo ago

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.

menacingly 4mo ago

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

IFC_LLC 4mo ago

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.

customguy 4mo ago

(zero value comment following) Every time I read MCP, I think it means "master control program". http://mcp.a1k.org/indexe.html 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.

helloansh 4mo ago

mcp will consolidate, its all stdio fragile and stateless

_pdp_ 4mo ago

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.

_pdp_ 4mo ago
Oh forgot to mention that each CLI is basically another supply chain issue too. So there is that.

aspectop 4mo ago

[dead]

tyingq 4mo ago

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.

syedofc 4mo ago

[flagged]

Alifatisk 4mo ago

There is no publishing date on the article.

est 4mo ago

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.

olup 4mo ago

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.

xurenwu 4mo ago

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

leowoo91 4mo ago
i dont think there is anything preventing devs to filter out certain items from the tools list - security is more of a issue for how you are harnessing your agent (at code-level of course)

Voblit 4mo ago

good to hear!

spriterock 4mo ago

[flagged]

solarkraft 4mo ago

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.

fireant 4mo ago

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

wolttam 4mo ago

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

dev_l1x_be 4mo ago

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

lowbloodsugar 4mo ago

Fixed with subagents.

martinloop 4mo ago

[flagged]

shdh 4mo ago

MCP’s are fine They are easy to implement and integrate You can use OAuth and handle ACL easily

octoberfranklin 4mo ago

Editorialized title is not cool, HN.

ahonn 4mo ago

[dead]

warumdarum 4mo ago

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?

nkmak 4mo ago

[dead]

yarinzhang 4mo ago

[dead]

loaderchips 4mo ago

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

rupatiwari25 4mo ago

[dead]

ailinter 4mo ago

[flagged]

citelix 4mo ago

[dead]

ascotan 4mo ago

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.

g42gregory 4mo ago

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

devil1432 4mo ago

From my experience, the biggest flaw of mcp is lack of control over your system prompt. Prompts need to be tailored for specific model (duh). Tool definitions are de facto part of your system prompt. By injecting tool definition from MCP servers into your prompt, you are basically adding prompt that was (likely) not tailored for your specific model. That causes drop in quality of answers. Other issue is that adding one new feature via MCP can introduce regression into your system and cause other MCP features to work incorrectly (and I am not talking about malicious prompt injection by MCP provider). Real life example: tools from MCP server for ms outlook requires certain date format for filtering emails. That worked fine in our prod. Until we added another MCP server (built in-house in another department of our company) that required dates in different format. After adding these tools, now our agent started making mistakes: putting dates in outlook format in our internal mcp tool and vice versa - putting dates in our internal format into outlook tool. There is no obvious way to fix it other than separating these prompts. And that goes against standard MCP architecture and consumes way more tokens to cycle through multiple prompts and agents. If that's already the issue with two MCP servers, then this architecture clearly does not scale.

navs 4mo ago

As much as I like to hate MCP, it has a place in its accessibility outside terminal based agents and in its ability to wrangle data before it’s consumed by the agent requesting it. Sure you can use a cli tool and jq. Most cli tools that interact with third party providers are just APIs so you could argue it could be replaced with a curl.

deleted 4mo ago

[deleted]

apf6 4mo ago

old and inaccurate knowledge.. - Skills do take up space in the context. The name and description of every skill goes into the system prompt. You can't add unlimited skills without context pressure. - MCP context spam is less of a big deal now that there is deferred tool loading. - If you work with the agents long enough you'll run into situations where using bash CLI tools suck and an MCP works better. - MCP is not dead and has never been dead, it's the right solution in certain cases.

powersjcb 4mo ago

MCP protocol layer is for all practical purposes an irrelevant implementation detail. We need some new layer to handle things that used to be abstracted away by UIs - filter to 6 of 50 fields for the paginated pipeline views - show all the important fields on a detail view - organize for understanding of fields that might have been poorly named in the public APIs Some of this can be handled by a CLI wrapper around an API, but it really just shifts the complexity into a different system. One thing that I haven't heard a lot of people talk about is that MCPs are often able to be far more flexible than a traditional REST api. You can ship breaking changes/renames and agents will adapt. Why should we couple the agent tooling locked 1-1 with our calcified systems?

crad 4mo ago

Perhaps this should be "People don't understand how to implement good MCP servers" as opposed to MCP is dead. MCP shouldn't be 1-1 to API. It should empower users and LLMs to perform tasks and see data. CLIs don't improve upon that issue if they're designed the same way people are implementing MCPs.

mikekuharuk 4mo ago

To be honest a bit weird. You say MCP is dead and talking about tokens price, then mentioning SKILLS to replace it - which will cost probably more tokens to do it. And not even mentioning that SKILLS has nothing to do with functionality itself MCP provides. To be honest a bit weird article :D

rldjbpin 4mo ago

it is not dead for my team, but surely if one prefers to replace them with skills, they are most likely wrong. at least outside of personal, one-user scenarios. has anybody ever use the prompt templates in practice? for what it's worth, these protocols are a product of their time, and unfortunately people lose patience with seeing it through in practice. in the end it is all text. things are overengineered regardless, but at least this allowed reuse across projects.