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

181–190 of 444 posts

Re: MCP is dead?

#181

Post by didibus »

usrusr wrote: post #174
didibus wrote: post #140

Earlier quoted context omitted.

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

I still didn't follow, you mean to pipe things between tool calls? Like if you want to query something and then update another without the intermediate getting brought in context?

Re: MCP is dead?

#182

Post by hnlmorg »

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…

That’s only true for the frontier. The moment you start looking at enterprise consumers of AI you’ll see slow monoliths that make decisions by committee and those committees often don’t even understand the tech they’re passing ruling on.

And you’ll also often see CISO-offices that are managed by checklists and yet more committees.

Asking for MCP access is generally easier than asking for an API for several reasons:

1. MCP supports OAuth, so your access conform with numerous CIS (et al) compliance checklists (short lived secrets, MFA, user-specific credentials, user access managed by centralised directory services and thus can have business rules applied, etc)

2. MCP is something a business can make a cooperate decision on. And then you can refer to that decision each time you need an access to new service. Whereas API access isn’t. In some cases APIs are governed by LLDs, and then you have an extra layer of “fun” having to update documentation to describe, in detail, the technical specifications too.

3. MCP defines the interaction better. If you need to request access to an API then the inevitable question from the committee is “where is this code running from?” and so on and so forth. Whereas saying “MCP access for AI to assist the project team with development” is a lot easier conversation to have.

In short: Enterprises are a very different beast to your average business.

Re: MCP is dead?

#184

Post by helloplanets »

big-chungus4 wrote: post #165

Isn't MCP just a way to give agent tools? When you are building your own agent, you can define the tools manually, but if you're using something existing like opencode, how do you add new tools as a user? You use the API for that which is currently MCP. Saying MCP is dead is kind of like saying tools are dead, which is definitely not true because all modern LLM agents are trained for tool use and you wouldn't have ag…

You can create tools without using MCP for OpenCode: https://opencode.ai/docs/custom-tools/

Re: MCP is dead?

#185

Post by personjerry »

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…

> temporary workaround

I've heard this one before

(Maybe it'll be the first time that a temporary workaround stays around longer than expected then)

Re: MCP is dead?

#186

Post by wren6991 »

eddythompson80 wrote: post #93
jimbokun wrote: post #33

Earlier quoted context omitted.

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?

Not a fan of MCPs for my personal use, but I still think the value for companies is obvious. The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution. You only need to "trust" the MCP client implementation, not a thousand different CLIs. Also being a standard HTTP endpoint, a lot of logic can be offloaded to proxies and such. The second value is more about how business wo…

> The first value for their downstream (OpenAI, Anthropic, etc) is REST call vs arbitrary code execution.

Is this an advantage? Phrased differently, every MCP that could have been a CLI call is a new opportunity for sandbox escape.

Re: MCP is dead?

#188

Post by nicman23 »

helloplanets wrote: post #184
big-chungus4 wrote: post #165

Isn't MCP just a way to give agent tools? When you are building your own agent, you can define the tools manually, but if you're using something existing like opencode, how do you add new tools as a user? You use the API for that which is currently MCP. Saying MCP is dead is kind of like saying tools are dead, which is definitely not true because all modern LLM agents are trained for tool use and you wouldn't have ag…

You can create tools without using MCP for OpenCode: https://opencode.ai/docs/custom-tools/

i mean yeah but is just a spec

Re: MCP is dead?

#189

Post by PhilipRoman »

notatoad wrote: post #86
noodletheworld wrote: post #10

Earlier quoted context omitted.

You can share a skill by copy pasting the text file to someone in slack. Its not that hard.

right, but if you have 300 employees using ai and you want to share a skill with all of them, and you want to be able to push an update to the skill, mcp provides you with a standard way to do that. i dont understand why people are so invested in making this a winner-take-all battle. skills are ligthweight and ad-hoc, MCP is managed and centralized. there's a place for both of those things, even if your personal work…

Don't most companies have a Git repo for skills that you can pull?

Re: MCP is dead?

#190

Post by dorgo »

_flux wrote: post #170
827a wrote: post #68

Earlier quoted context omitted.

Yes, in the same way a programming language would be worse off if they focused all of their effort on building an implementation instead of a language specification. You could literally, deterministically, zero AI, code-gen a CLI from an MCP specification, just like you can with an OpenAPI specification. I'm sure tools exist that do this. So if you want a CLI, there it is. But the problem with a CLI is that it requir…

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?

Post reply on HN