Live data from Hacker News

MCP is dead?

quandri.io

41–50 of 444 posts

Re: MCP is dead?

#41

Earlier quoted context omitted.

It's not 'who is building' but 'who is using' that's the concern. AI is a bandwagon tech, a lot of people will 'build because others are' adhering to an ostensible standard. Most of the people that I know are moving away from MCP in favour of skills where the advantage of MCP goes away if the REST API is clear enough. Also - I'm sorry to say but MCP management on Codex (and Claude) is just really bad. Everything from…

OpenAI should hire you.

This is not even 'basic product design' - it's just 'product common sense'.

That the 'smartest people in the world' have $100 Billion and are are totally scattered on so many issues completely blows my mind but it speaks to how systems are organized.

They don't need to hire anyone for this stuff, they need to have some basic product discipline and prioritize it, that's all.

If they don't do that, all the money in the world and all the best product people wouldn't be able to help.

I totally respect that 'Codex is young' - but it's been kind of a year now. That's a long time - and AI is supposed to 'accelerate time scales' and make people 'super productive' remember?

I hope they improve.

Re: MCP is dead?

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

Re: MCP is dead?

#43
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

Re: MCP is dead?

#45
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…

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 security model and runtime requirements are completely different between making an HTTP request and executing arbitrary code.

They have different tradeoffs.

Re: MCP is dead?

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

Re: MCP is dead?

#47
post #40
post #24

Earlier quoted context omitted.

personally if i have the need to move a skill/script, etc. to another one of my machines, i'll make a git repo for them (if they aren't already on git)

This was one of the first ideas me and my team had for sharing skills and scripts. The problem is this is a very "why Dropbox and not FTP" answer. The second you utter the word git, you may have lost 90% of your audience - depending on their background, of course. MCPs are a lot more non-tech friendly

yeah it 100% depends on who you'll be sharing them with, for me its just myself and a couple agents i have on a dedicated machine so git is ideal to keep versions matching when i update something on my daily driver

Re: MCP is dead?

#48

Earlier quoted context omitted.

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

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.

This, IMO, is another scenario. MCP is designed and played as a part of the automatic tool chains. These are two different types of needs. But in the case you mentioned, when some parts of the work should be automated, it’s also possible to utilize mcp there.

Re: MCP is dead?

#49
post #45

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 security model and runtime requirements are completely different between making an HTTP request and executing arbitrary code. They have different tradeoffs.

You nailed it! There are established tools that handle the security model. MCP is the 5th leg.

Re: MCP is dead?

#50
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…

Basically MCP is little more than a brand name for "APIs LLM's can use". This means more services are creating APIs, because xyz company who's never been super tech forward doesn't want their tools to be obsolete when everyone uses agents.

Overall, I am in favor of this goal. I'm not sure this is the protocol I'd choose to accomplish it, but it's the one people hear about, and the one they're using.

Post reply on HN