Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP is dead; long live MCP

chrlschn.dev

Post reply on HN
Print view View original

211–220 of 231 posts

Re: MCP is dead; long live MCP

#211

Post by senordevnyc »

arnitdo wrote: post #156

Every single AI integration feels under-engineered (or not even engineered in case of tokenslop), as the creators put exactly the same amount of thought that $LLMOFTHEWEEK did into vomiting "You're absolutely right, $TOOL is a great solution for solving your issue!" We're yet to genuinely standardise bloody help texts for basic commands (Does -h set the hostname, or does it print the help text? Or is it -H? Does --he…

We're yet to genuinely standardise bloody help texts for basic commands (Does -h set the hostname, or does it print the help text? Or is it -H? Does --help exist?). Writing man-pages seems like a lost art at this point, everyone points to $WEBSITE/docs (which contains, as you guessed, LLM slopdocs).

Are you describing under-engineered AI integrations, or just the general state of CLIs for decades now?

Re: MCP is dead; long live MCP

#213

Post by senordevnyc »

tcbrah wrote: post #163

the maintenance burden is the real MCP killer nobody talks about. your agent needs github? now you depend on some npm package wrapping an API that already had good docs. i just shell out to gh cli and curl - when the API changes, the agent reads updated docs and adapts. with MCP you wait on a middleman to update a wrapper. tptacek nailed it - once agents run bash, MCP is overhead. the security argument is weird too,…

the maintenance burden is the real MCP killer nobody talks about.

...

for dev tooling? just write better CLIs.

You realize those custom CLIs you're writing will now need to be maintained too, right?

Re: MCP is dead; long live MCP

#214

Post by 0xbadcafebee »

troupo wrote: post #208
0xbadcafebee wrote: post #201

Earlier quoted context omitted.

No, this misunderstands what MCP is for and how it works. Let's say you use Claude's chat interface. How can you make Claude connect to, say, the lights in your house? Without MCP, you would need Anthropic the company to add support to Claude the web interface to connect over a network to your home, use some custom routing software (that you don't have) to communicate over whatever lightbulb-specific IoT protocol you…

> But with MCP, Claude only has to support MCP. They don't have to know anything about your lightbulbs Except the fact that it has to "know" about that specific manufacturer's bespoke API aka "tool calls" for that specific lightbulb. If the manufacturer provides an API for the lightbulb. MCP is a vibe-coded communications protocol. There's nothing more standard or re-usable in MCP than HTTP, or any protocols built ov…

1) MCP does more than just make an API call, 2) only the MCP server has to know about the lightbulb.

Example: right now, I want to add web search to my local AI agent. Normally you'd have to add some custom logic to the agent to do this. But instead, I merely support MCP in the agent. Now I can connect to a SearXNG MCP server, and tell my agent to "use /web_search". Boom, I have web search, and the agent didn't need anything added to it. Similarly, SearXNG didn't need to know anything about my AI agent.

If you "just used HTTP", you could not do that. You'd need to add extra code to SearXNG, or extra code to the AI agent, just to support this one use case.

GraphQL does not have any of the AI-specific features in it, and is way more complex than MCP.

Re: MCP is dead; long live MCP

#215

Post by 0xbadcafebee »

losvedir wrote: post #204
0xbadcafebee wrote: post #201

Earlier quoted context omitted.

No, this misunderstands what MCP is for and how it works. Let's say you use Claude's chat interface. How can you make Claude connect to, say, the lights in your house? Without MCP, you would need Anthropic the company to add support to Claude the web interface to connect over a network to your home, use some custom routing software (that you don't have) to communicate over whatever lightbulb-specific IoT protocol you…

No, that's not MCP. That's a pleasant idea that MCP has been shoehorned into trying to solve. But MCP the spec is far more complicated than it needs to be to support that story. Streamable HTTP transport makes it much more workable, and I imagine was designed by real people rather than the version prior to that, but it's still much more than it needs. Ultimately, 90% of use cases would be solved by a dramatically sim…

More than it needs? Buddy, HTTP is more than any web app needs. It has a lot of stuff in it because it's intended to solve a lot of problems. The fact that there is a bidirectional stateful mode for HTTP is horrifying, but it's there now, and it solves problems. MCP is here, it solves problems we have now, it's supported by industry. If there are pain points, we can fix them in the standard without throwing the baby out with the bathwater.

Re: MCP is dead; long live MCP

#216

Post by troupo »

0xbadcafebee wrote: post #214
troupo wrote: post #208

Earlier quoted context omitted.

> But with MCP, Claude only has to support MCP. They don't have to know anything about your lightbulbs Except the fact that it has to "know" about that specific manufacturer's bespoke API aka "tool calls" for that specific lightbulb. If the manufacturer provides an API for the lightbulb. MCP is a vibe-coded communications protocol. There's nothing more standard or re-usable in MCP than HTTP, or any protocols built ov…

1) MCP does more than just make an API call, 2) only the MCP server has to know about the lightbulb. Example: right now, I want to add web search to my local AI agent. Normally you'd have to add some custom logic to the agent to do this. But instead, I merely support MCP in the agent. Now I can connect to a SearXNG MCP server, and tell my agent to "use /web_search". Boom, I have web search, and the agent didn't need…

> 1) MCP does more than just make an API call

It literally does that. What MCP calls a "tool call" is literally an API call (well, technically an RPC call since it's just JSON-RPC underneath).

But that's beside the point. Your original claim was this:

--- start quote ---

The only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app).

--- end quote ---

1. The MCP doesn't solve that. Every MCP server you connect to will expose their own bespoke API (aka tools) incompatible with anything else, in data formats incompatible with anything else.

2. No idea what SearXNG is, but if you used Swagger/OpenAPI or GraphQL you could easily have provided a standard way to discover what your API offers, and ways of calling that API

> You'd need to add extra code to SearXNG

You literally added extra code to SearXNG to expose an MCP server.

> GraphQL does not have any of the AI-specific features in it

Neither does MCP. Just because they invented new cute terms for JSON-RPC doesn't make it any more suitable for AI than literally any other protocol. And don't forget the idiocy of using a one-way communication protocol for two-way communication.

MCP re-invented SOAP, badly, with none of the advantages, and most of the disadvantages

Re: MCP is dead; long live MCP

#217

Post by troupo »

0xbadcafebee wrote: post #215
losvedir wrote: post #204

Earlier quoted context omitted.

No, that's not MCP. That's a pleasant idea that MCP has been shoehorned into trying to solve. But MCP the spec is far more complicated than it needs to be to support that story. Streamable HTTP transport makes it much more workable, and I imagine was designed by real people rather than the version prior to that, but it's still much more than it needs. Ultimately, 90% of use cases would be solved by a dramatically sim…

More than it needs? Buddy, HTTP is more than any web app needs. It has a lot of stuff in it because it's intended to solve a lot of problems. The fact that there is a bidirectional stateful mode for HTTP is horrifying , but it's there now, and it solves problems. MCP is here, it solves problems we have now, it's supported by industry. If there are pain points, we can fix them in the standard without throwing the baby…

> The fact that there is a bidirectional stateful mode for HTTP is horrifying,

Oh no, really? So why didn't the new vibe-coded hotness use WebSockets for bidirectional communication?

> MCP is here, it solves problems we have now,

Many other protocols save the exact same problem of client-server communication with well-defined ways of discovering available API calls.

> it's supported by industry.

It's supported by hype and people who have very little knowledge of what existis in the world.

Also, industry is notorious for supporting a lot of crazy and bad shit. Doesn't make it good.

> If there are pain points, we can fix them in the standard without throwing the baby out with the bathwater.

You have already thrown out a lot of babies by deciding that the vibe-coded MCP protocol is the only true way to set up two-way communication between a server and a client, and refuse to even entertain the thought that it might not be a good protocol to begin with.

Re: MCP is dead; long live MCP

#219

Post by tom_m »

If I'm being completely honest, I don't think most AI influencers even know the difference between something that is deterministic vs. non-deterministic. The author here probably gives too much credit.

I agree it is a silly debate, but it's simply surprising to me that not enough people ask why. No one wants to think anymore, they just want to be told the answer. That's why there's a "debate" in the first place.

Re: MCP is dead; long live MCP

#220

Post by JLangley »

senordevnyc wrote: post #211
arnitdo wrote: post #156

Every single AI integration feels under-engineered (or not even engineered in case of tokenslop), as the creators put exactly the same amount of thought that $LLMOFTHEWEEK did into vomiting "You're absolutely right, $TOOL is a great solution for solving your issue!" We're yet to genuinely standardise bloody help texts for basic commands (Does -h set the hostname, or does it print the help text? Or is it -H? Does --he…

We're yet to genuinely standardise bloody help texts for basic commands (Does -h set the hostname, or does it print the help text? Or is it -H? Does --help exist?). Writing man-pages seems like a lost art at this point, everyone points to $WEBSITE/docs (which contains, as you guessed, LLM slopdocs). Are you describing under-engineered AI integrations, or just the general state of CLIs for decades now?

Yeah, with 44 years of experience working with CLIs, this is just the general state of CLIs for decades now.
Post reply on HN