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

221–230 of 444 posts

Re: MCP is dead?

#221

Post by debarshri »

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…

Totally agree with you.

Re: MCP is dead?

#222

Post by crazytweek »

geysersam wrote: post #197
crazytweek wrote: post #172

A good MCP server makes the difference between an agent using 20k tokens and 2 million. It may not matter yet with sponsored Codex and Claude subscriptions, but it will kill many use cases once providers switch to token-based billing. That may sound like an exaggeration, but it’s exactly what I see in our product. Humans developing something already have context that agents don’t have yet. Most agents start a task wi…

Seems to me that you're saying the MCP is a simplified API with good documentation geared towards agents. But if that's the case, could you not exposes the simplified interface as part of the API, instead of exposing it in MCP?

When it is part of the API, the agent still has the choice between multiple options. If it chooses the less efficient one, the request can become significantly more CPU- and token-intensive than necessary.

The problem is that the agent does not care. Its primary goal is to get the job done.

Maybe the agent is smart enough to choose the optimal path, but that strongly depends on the model being used. You also do not know who is on the other side. With a human-facing API, you can usually assume who is using it and what they want to achieve. Humans are generally lazy and tend to look for the most efficient solution.

An agent, however, will happily iterate through 1,000 users and fetch the online state for each one individually, even across multiple paginated requests if necessary.

You can provide an endpoint that returns the online states for all users at once. A human will most likely use that endpoint, but I have seen agents go completely wild on the other side. :D

At some point, you may get a response like “token limit reached.” But what do you do then? You give the agent more tokens and increase your bill, because you cannot even tell whether there was a more optimized way to achieve the same result.

In practice, this is a surprisingly tricky problem. :D

Re: MCP is dead?

#223

Post by oldsecondhand »

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

> So the current situation is basically that I used Claude to write an MCP server on top of our API. And then I need to occasionally tell it update it match the public doc. > And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net. My reaction to this is.. really? P…

That wouldn't solve the core issue: if Claude makes a mistake during the MCP generaration, it would poison further agentic use.

It's adding another failure point to the process for no gain.

Re: MCP is dead?

#224

Post by _flux »

dorgo wrote: post #190
_flux wrote: post #170

Earlier quoted context omitted.

Not having access to the shell is a big hindrance. I have my agent access Gitlab and Jira via CLI tools and in so many cases jq or python is used to manipulate or combine the data into a more useful format, making use of pipes and temporary files. You can of course limit what an agent can do, most easily by not giving it access to things it shouldn't do. I suppose there are no existing easy gateway methods to grant f…

>to manipulate or combine the data into a more useful format why not build this directly into MCPs?

Hmm, indeed, so maybe I could have all this as an MCP, so I can just easily pass any imaginable data manipulation inside it, and then also have it support calling other MCPs, all inside that one MCP, to avoid filling context with intermediate data..

Sounds a lot like a shell to me.

Re: MCP is dead?

#225

Post by coderbants »

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 get the debate in this thread but this is IMHO the detail that matters:

"Many of these companies don't even have an external API! And yet, they're all building MCP servers."

Whether or not MCP is a temporary means to an end or a more permanent standard is kind of missing the point that the overall callable API surface is expanding rapidly. How it's called by the agent is an implementation detail.

Re: MCP is dead?

#226

Post by mrgaro »

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…

MCP has a great advantage over agent using cli: MCP is much easier to secure so that it's hardwired that the agent can only call the pre-configured MCP server. We run our agents so that they don't have access to public internet, so they could not run any cli commands. It's all either built-in agent tools, or 3rd party mcp servers. The agents never have access to any credentials, which makes them much more safe to use than a claude code running in yolo mode with fetching random cli binaries from the web.

Re: MCP is dead?

#227

Post by dannypdx »

monkpit wrote: post #104
dannypdx wrote: post #64

MCP is just one of many -insecure- protocols that will be swallowed by a runtime governance protocol (like g8e) that is purpose-built for security, not to 'move fast and break stuff'.

You should disclose that you are behind g8e.

Do I need to add a disclaimer to every one of my posts that shits on the wrong way?

Re: MCP is dead?

#228

Post by Mashimo »

rixed wrote: post #135

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

> Like would running `linearcli --help` then `notioncli --help` then `slackcli --help` etc, or am I missing something?

I'm not super deep into all of this, but I think except latest Claude Code release the mcp is frontloaded into the context. So if you don't need it that often you have to disable and enabled it again when needed.

And I guess you can put some usage examples into the skill file. Which might migate the first --help.

Also I guess with cli it's easy to spin up a sub agent with their own context that just returns the result?

Re: MCP is dead?

#229

Post by jurgenburgen »

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.

> Wow if that's not an echo-chamber comment I don't know what is.

Wouldn’t expect anything less from someone working as a manager at OpenAI. I don’t think their org culture is survivable if you’re not 200% all-in on LLMs eating the universe.

Re: MCP is dead?

#230

Post by _flux »

ithkuil wrote: post #198
_flux wrote: post #170

Earlier quoted context omitted.

Not having access to the shell is a big hindrance. I have my agent access Gitlab and Jira via CLI tools and in so many cases jq or python is used to manipulate or combine the data into a more useful format, making use of pipes and temporary files. You can of course limit what an agent can do, most easily by not giving it access to things it shouldn't do. I suppose there are no existing easy gateway methods to grant f…

Can an MCP provide prompts for your model to download and use CLIs (and ensure they have the right versions of those tools) in such a way that the data flows through the client side tools? The more I read this thread the more I'm convinced that the main value of MCP is to provide a server managed release process. This is the same advantage that SaaS has over client side apps. However MCPs couples with a client willin…

As far as I know, the only way an MCP can provide you data that doesn't go into the context is by providing URLs to the data, and then the model uses e.g. curl to access that data for data manipulation purposes. You could also return result set ids and provide accessors to such data, but ultimately you'd need to provide powerful accessors to that result set to avoid polluting context. Things like shell with all its power already provides.

It seems like there's little point in MCP in that case. Maybe more point if it was a standard mechanism for MCP to provide additional data, in a completely compatible fashion with all other tools? You could perhaps even pass such URLs to other MCPs. You could have an MCP for jq for doing stream processing. Starts to look a lot like a shell, though.

Seems like MCPs could also be extended to store auxiliary data to your memory (or filesystem..), and then an additional extension to provide that kind of data as auxiliary data in the calls to MCP.

Well, even as is, MCP still provides a standard method of using OAuth for accessing such services. And you must use MCP if you wish to add something to the ChatGPT.com web service, so it's easy to see why OpenAI folks are seeing companies going that way.

Post reply on HN