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

151–160 of 444 posts

Re: MCP is dead?

#151

Post by jiggunjer »

d0mine wrote: post #98
tanin wrote: post #55

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

If you need a network boundary, what MCP provides that REST API + llms.txt can't do?

Standardization. Who writes llms.txt? Everyone writes their own? Will agents still behave the same?

Re: MCP is dead?

#152

Post by mkl »

rgbrenner wrote: post #16

The article has no date on it, but says deferred tool loading is a recent update that occurred after the article was written. Deferred tool loading was added in Nov 2025: https://www.anthropic.com/engineering/advanced-tool-use So these numbers are at least 7 months out of date. Why is this being posted now?

Older than that, as it implies GPT-4o is current.

Re: MCP is dead?

#153

Post by kstenerud »

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

Re: MCP is dead?

#154

Post by usrusr »

nostrebored wrote: post #115
CharlieDigital wrote: post #70

Earlier quoted context omitted.

MCP is more than is more than tools. Tools is one of three major features: prompts[0] and resources[1] being the other two. Prompts are effectively "server delivered skills" which are are quite powerful because it solves a distribution and synchronization problem. It also allows server materialization and dynamic construction of skills. MCP also has a few other under utilized mechanisms: elicitation[2] on the client…

this is bad. Anyone doing any cursory work with agents will realize how brittle > can be. Adding an extra layer of indirection isn’t helpful, it’s a gigantic hindrance that gives you a moving eval target. Being an MCP developer means you have a moving target of model optimization. It is a win for nobody. The tools we need to solve this problem exist and they are boring. Types, jsonschema, openapi, all of it is a bett…

It keeps people employed, yes?

And with people I guess I might actually mean not people but tokens everybody has to spend on keeping their environment self-adapting...

Re: MCP is dead?

#155

Post by tanin »

d0mine wrote: post #98
tanin wrote: post #55

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

If you need a network boundary, what MCP provides that REST API + llms.txt can't do?

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.

Re: MCP is dead?

#156

Post by hobofan »

jimbokun wrote: post #33
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…

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?

Yes they would be.

MCP servers on the side of the consuming organizations fit into the existing IT landscape, with centralized safeguard on who can access what a lot better and are easier to administer than letting their employees run arbitrary agents against arbitrary sources and destinations and cause chaos.

Re: MCP is dead?

#157

Post by Groxx »

tlogan wrote: post #112
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…

I would bet that MCP is going to die. The main reason is that it adds another layer (and human) that can, and probably will, get out of sync with the real-world implementation, whether that implementation is an API, web, or a CLI. AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use). Sure, companies want to expose MCP servers because it is the cool…

I have some hope that this'll all lead to a revival of semantic web / microformats / etc. Why write an API when you can just add some markup to your existing API, which already looks like stuff that it was trained on, and won't fall out of sync (because you use it too)?

Re: MCP is dead?

#158

Post by charrondev »

d0mine wrote: post #98
tanin wrote: post #55

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

If you need a network boundary, what MCP provides that REST API + llms.txt can't do?

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.

Re: MCP is dead?

#159

Post by sagrd »

didibus wrote: post #133
varenc wrote: post #95

Earlier quoted context omitted.

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.

[dead]

Re: MCP is dead?

#160

Post by huodon »

hendersoon wrote: post #56

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

[flagged]
Post reply on HN