Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP is dead?

quandri.io

Post reply on HN
Print view View original

131–140 of 444 posts

Re: MCP is dead?

#131

Post by tvink »

julianlam wrote: post #82
mxstbr wrote: post #22

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…

> 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. Wow if that's not an echo-chamber comment I don't know what is.

Yeah this is copium. Everyone is sprinting to adopt everything that is useful, and it just haven't happened with MCP.

Also, what's the hold up? If they all are building one, presumably using AI, shouldn't they all be done already?

Re: MCP is dead?

#132

Post by robertclaus »

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?

Re: MCP is dead?

#133

Post by didibus »

varenc wrote: post #95
jimbokun wrote: post #33

Earlier quoted context omitted.

You failed to describe what value the MCP protocol provides. If all of these companies spent equivalent time writing a CLI for agents to consume as they spend on MCP servers, would they be any worse off in terms of agents being able to interact with their products?

The value is that many companies like building MCP servers much more than CLIs. For whatever reason. Here's some companies that offer MCP servers but don't seem to offer an equally featured CLI: - Asana - Square - Linear - Dropbox - Canva - Slack (sorta) - Figma (sorta) and many more that offer both, but support their MCP more. Should they all be offering CLI tools? IMHO, yes absolutely. But an MCP server gets much m…

A CLI needs to work on windows, mac, linux, android, iOS, etc. And it still needs some backend APIs to call. So creating one is a lot more work than just making an MCP.

Re: MCP is dead?

#134

Post by noodletheworld »

notatoad wrote: post #86
noodletheworld wrote: post #10

Earlier quoted context omitted.

You can share a skill by copy pasting the text file to someone in slack. Its not that hard.

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 work…

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)

Re: MCP is dead?

#135

Post by rixed » 

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

Re: MCP is dead?

#137

Post by didibus »

bluegatty wrote: post #23
CSMastermind wrote: post #18

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…

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 b…

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.

Re: MCP is dead?

#138

Post by didibus »

osigurdson wrote: post #122

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

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.

Re: MCP is dead?

#139

Post by [deleted] »

Spiritus wrote: post #121

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]

Re: MCP is dead?

#140

Post by didibus »

fooster wrote: post #117
red_hare wrote: post #101

Earlier quoted context omitted.

+1 Its crazy that people are still discussing this. It's ancient history. Deferred tool loading, large contexts, and prompt caching have made 2026 completely different from 2025. Also, the "CLI saves token" debate really falls apart when step one of using the CLI is running "--help". The problem remains: if knowing how to call the thing isn't in parametric memory, it has to be in context.

Build a more specific skill the for the exact workflow you want?

Skill still needs to be loaded in context, what would it change?
Post reply on HN