[dead]
MCP is dead?
171–180 of 444 posts
Re: MCP is dead?
#172A 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 with virtually no prior knowledge. And they start from zero every single time. That may improve in the future, but we’re not there yet.
Can agents get the job done? Yes. But without a thoughtfully implemented MCP server, they are awkwardly inefficient.
Re: MCP is dead?
#173We can't generalize, it depends on the case, and it's not a XOR. I personally go CLI first, and if not possible MCP.
Re: MCP is dead?
#174Earlier quoted context omitted.
Build a more specific skill the for the exact workflow you want?
Skill still needs to be loaded in context, what would it change?
I think that what they mean is that instead of ten perfectly orthogonal "unix philosophy" tools (skills) for the agent to compose when solving a problem, each with an API surface (description text) the size of Texas, you'd want to can each composition in a shell script (or a bespoke rust binary, if you enjoy watching your bot perform some heavy lifting) that only solves one problem but solves it so focused that the accompanying skill description barely consumes more context than the tool's self descriptive name.
Re: MCP is dead?
#175Is Betteridge's law of headlines irrelevant today?
Re: MCP is dead?
#176[dead]
Re: MCP is dead?
#177A bit off topic, but I think Google's A2A protocol could be a sleeper hit vs. the MCP protocol.
Not because it's better, but with one switch a significant portion of web traffic can be directed to A2A servers through Google's new search box.
Re: MCP is dead?
#178I 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…
Hank Hill: "Excuse me, are y'all with the cult?"
Jane #2: "We're not a cult. We're an organization that promotes love and—"
Hank Hill: "Yeah, this is it."
Re: MCP is dead?
#179Earlier 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…
> 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.
Re: MCP is dead?
#180I 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…
> 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? Presumably your API and API docs have a release process. Hopefully an automated one. Why isn't the "hey Claude, update the MCP server" step a part of it?