Live data from Hacker News

MCP is dead?

quandri.io

201–210 of 444 posts

Re: MCP is dead?

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

MCP vs CLI is the same discussion as between a GUI app and a web app: it's all about the distribution. There is approximately no difference in functionality except whether you're hitting a dedicated service or running a local tool which connects to a dedicated service.

With saas is turned out that distribution to a browser solves a pretty major pain point and I expect MCPs to be treated the same. Can you trivially replace an MCP server with a CLI tool which accepts a token? Yes - but why do that to yourself when you can hit the endpoint directly?

Re: MCP is dead?

#202

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…

Every time I read articles about MCP I feel like the internet (or HN) is having a collective stroke.

People are saying API are better than MCP. But MCP is just API with some instructions for the AI to discover how to use it. Nothing more nothing less. And some people are saying we should use 'CLI'... what does it even mean? LLMs are good with common CLI tools like ffmpeg because the knowledge is solidified inside the weights. If I make a new CLI tool I still need to somehow teach the AI to use it. If one wants the 'teaching' part comes from a server then MCP. If one wants it local and static then skills. How could there be so many debates around these simple concepts?

Re: MCP is dead?

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

Isn’t this just a lagging indicator of popularity at the early liftoff of cli ai?

A sign of weariness in the rapid evolution of tooling, where people got off the train a stop too early?

A confusing overloaded acronym (cli) and term (skill) lacking the marketability / easy mind share of a unique acronym?

These all fail to establish a hearty reason to be.

The walking dead are still dead.

Re: MCP is dead?

#204
post #112

Earlier quoted context omitted.

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…

Totally agree, MCP is the WAP equivalent of mobile internet access.

I'm old enough to get this reference! Spent years writing WAP... it was really great at the time.

Re: MCP is dead?

#206

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…

Every time I read articles about MCP I feel like the internet (or HN) is having a collective stroke. People are saying API are better than MCP. But MCP is just API with some instructions for the AI to discover how to use it. Nothing more nothing less. And some people are saying we should use 'CLI'... what does it even mean? LLMs are good with common CLI tools like ffmpeg because the knowledge is solidified inside the…

i feel exactly the same its literally the only api standard that we truly made plug and play and even automatically oauth antenticathable with dcr and people are falling over it. also in an absolute record speed thousands of mcps.

cli’s also need to be documented and input/output typed.

its also extremly dsitributable by just pointing to an url.

cli’s are great because they are composable but i really got huge mileage out of mcps

Re: MCP is dead?

#208

Earlier quoted context omitted.

> AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use). Should it? I think it can be very useful to constrain what your AI can do (e.g. read files but don’t delete them). MCP is a way to do that.

Authorisation is a way to do that, too.

Yes, but you often do not have much control over that.

For example try giving a local LLM read access to specific folders in your email account

Re: MCP is dead?

#209
post #157
post #112

Earlier quoted context omitted.

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

I definitely see it going that way from a marketing perspective if you want what you send/produce to be machine readable and actually used in intermediated surfaces like email and web search.
Post reply on HN