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

231–240 of 444 posts

Re: MCP is dead?

#231

Post by Aldipower »

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…

Off-topic question: Where is this an "App Store", as this is basically just a curated list off apps? I wouldn't exactly call it a "store". I have an approved ChatGPT App myself, but those do not surface anyway on the chatgpt.com domain. So, this isn't a "store", but a "curated directory". Calling this a store is misleading to a lot of us developers as you can see in the openai forums on this topic, where you find a lot of confusion around this. People put a lot of energy into developing a ChatGPT App, just to find out, they are completely on their own afterwards.

Re: MCP is dead?

#232

Post by gobdovan »

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…

Remember when practically ~every company on the planet was building an NFT collection?

Re: MCP is dead?

#233

Post by jedisct1 »

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.

Re: MCP is dead?

#234

Post by otabdeveloper4 »

Someone wrote: post #208
codebje wrote: post #179

Earlier quoted context omitted.

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

Theoretically you should be creating a "read email" CLI tool and letting agents interact with it in a chroot sandbox.

LLMs are much more proficient with bash and --help than they are with bespoke API protocols.

Treat LLMs like you would a junior programmer - keep things as generic and obvious as you can.

Re: MCP is dead?

#235

Post by brabel »

geysersam wrote: post #194
zuzululu wrote: post #129

Earlier quoted context omitted.

great post I find a lot of HN content seems to be doomer farming i was a big skeptic of MCPs now i build em

What advantage did you find in MCP vs a traditional API?

No OP, but MCP really is just a logical next step once you've got an API. The API is the "low level" protocol, the MCP is the high level one, suited perfectly to an LLM that can call tools (since MCP essentially turns an API into a LLM tool).

With just an API, the agent needs to "read your API docs" to know how to call it (that can be an OpenAPI spec or even just text).

With MCP, the agent sees a bunch of tools it can call, and they've been trained to call tools so they nail it.

One more very important factor is authorization, which no one seems to mention in these discussions. CLIs were made for humans and use primitive mechanisms for authorization: either an API key you hardcode in your environment, or they literally run a background HTTP Server to get a callback OAuth call to receive a token from a browser authentication flow. Incredible that people are happy with that, appparently. With the MCP Authorization spec, you solve authorization across multiple MCP servers in the same standardized way, the LLM client you use just need to know the protocol, not how to login for every single MCP server.

Very importantly, if the MCP client does the authorization, the MCP provider has auditability: is this a call from a human or from a LLM? That's important in Enterprise! People think it's ok to let an LLM act on behalf of the human but that will eventually bite a lot of people. Did the LLM just try to hack the API while you were mindlessly clicking "yes" when it asked if you wanted to let it do something? Tough luck, there's no way to distinguish an LLM making a mistake from a human maliciously running some attack.

And as the post mentions, there's also more benefits like being able to "elicit" user input (not just request/response cycles) and the ability to have documentation and assets (skills also have this though).

Re: MCP is dead?

#236

Post by CharlieDigital »

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…

That's because you're not thinking about how teams and enterprises work. You're thinking about how individuals work.

An enterprise has 20 services that each have a secret key (Datadog, Snowflake, etc). I want my team to have access to those services via coding agents. How do I guard those keys from both developer and agent? Put it behind MCP; neither dev nor agent ever sees the key. If developer leaves, revoke one OAuth cred.

I want to add access to internal and external services from one entry point without developers across hundred of teams having to sync or update their workspace. Put it behind one MCP interface.

I have enterprise skills and resources that I want to standardize and deliver to every team. But it has to vary in 10-15% of the skill body. Think same heuristics, but different specifics. MCP delivered prompts and resources can do that by dynamically templating them.

I want telemetry and data on how skills and tools are being used and I want to capture them using standard tooling like OTEL regardless of agent harness because I don't want to have to rebuild a solution on hooks if I charge vendors. MCP does that because I can capture all of the telemetry there.

    > jsonschema, openapi, all of it is a better integration point than MCP.
MCP is schema + interaction model. If MCP were built on OpenAPI, it would still need another layer to describe interaction. It is effectively JSON schema + interaction flow + standard surface area.

Your argument feels like asking why do we need OAuth and OIDC when we already have usernames and passwords. They solve different problems. A simple service can just use a secret key or username + password. But more complex enterprise scenarios need the structure and flow of OAuth, SAML, and SCIM.

Re: MCP is dead?

#237

Post by neya »

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…

Just because everyone builds it doesn't mean it will take off. Case in point: All the cloud serverless BS. Everyone in the industry are now switching back from server less because the math didn't work out.

I think it's just a fad and eventually you'll need to address the math no matter how much you sugar coat it - the 3x slower metric, eating of context window is all beneficial for LLM companies but not for the end user.

Ok, how many AI tools do you even use from 3 years ago? Funnily enough, I stopped paying for my chatGPT subscription a year ago.

Re: MCP is dead?

#238

Post by jeroenhd »

raincole wrote: post #202
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…

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…

My take is that most of the AI related posts are written by AI under instruction of people who hype it up but have no idea about how any of it works.

It all has some form of "the thing I'm doing is the future and everyone who doesn't join me will fall behind" energy that AI/NFT/blockchain/web3/etc. enthusiasts talk about when they're trying to sell you something or when they're trying to convince the world they really are the big money makers they claim to be.

The LLM isn't going to care about where the tokens it's inserting into the context window are coming from. For all it cares the data it's processing came in over fax and was read in with OCR.

Re: MCP is dead?

#239

Post by MatthewPhillips »

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…

Please keep in mind that CLIs do not run on mobile and never will. This is the elephant in the room that nearly everypne seems to be ignoring. This "debate" is built around the assumption that AI is only for at-your-desk work. It's obviously not. Having the ability to mix/match the services you use for everything in your life, whether that's email or social networks or managing your book collection, is going to be a normal thing everyone does in the future. It's just not today, because AI companies are almost exclusively focused on the programming use-case (and related desk job stuff).

Re: MCP is dead?

#240

Post by docheinestages »

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…

Agreed. I think MCP should stay abstract in the sense tool-calling is. JSON-RPC could be one way to do it.
Post reply on HN