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

41–50 of 231 posts

Re: MCP is dead; long live MCP

#41

Post by CharlieDigital »

antirez wrote: post #25

As yourself: what kind of tool I would love to have, to accomplish the work I'm asking the LLM agent to do? Often times, what is practical for humans to use, it is for LLMs. And the reply is almost never the kind of things MCP exports.

You interact with REST APIs (analogue of MCP tools) and web pages (analogue of MCP resources) every day.

I'd recommend that you take a peek at MCP prompts and resources spec and understand the purpose that these two serve and how they plug into agent harnesses.

Re: MCP is dead; long live MCP

#42

Post by CharlieDigital »

simianwords wrote: post #37
CharlieDigital wrote: post #28

Earlier quoted context omitted.

You can solve the same problem by giving subsets of MCP tools to subagents so each subagent is responsible for only a subset of tools. Or...just don't slam 100 tools into your agent in the first place.

>Or...just don't slam 100 tools into your agent in the first place. But I can do them with CLI so that's a negative for MCP?

You've missed the point and hyperfocused on the story around context and not why an org would want to have centralized servers exposing MCP endpoints instead of CLIs

Re: MCP is dead; long live MCP

#43

Post by nonethewiser »

ambicapter wrote: post #20
0xbadcafebee wrote: post #12

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy some…

If AI is AI, why does it need a protocol to figure out how to interact with HTTP, FTP, etc.? MCP is a way to quickly get those integrations up and running, but purely because the underlying technology has not lived up to its hyped abilities so far. That's why people think of MCP as a band-aid fix.

If AI is AI why does it need me to prompt it?

Re: MCP is dead; long live MCP

#44

Post by kubanczyk »

codemog wrote: post #2

As soon as MCP came out I thought it was over engineered crud and didn’t invest any time in it. I have yet to regret this decision. Same thing with LangChain. This is one key difference between experienced and inexperienced devs; if something looks like crud, it probably is crud. Don’t follow or do something because it’s popular at the time.

> if something looks like crud, it probably is crud

Yes, technically, but you've probably meant cruft here.

Re: MCP is dead; long live MCP

#45

Post by simianwords »

CharlieDigital wrote: post #42
simianwords wrote: post #37

Earlier quoted context omitted.

>Or...just don't slam 100 tools into your agent in the first place. But I can do them with CLI so that's a negative for MCP?

You've missed the point and hyperfocused on the story around context and not why an org would want to have centralized servers exposing MCP endpoints instead of CLIs

I would want to know what point I missed. I can have 100 CLI's but not 100 MCP tools.

100 MCP tools will bloat the context whereas 100 CLI's won't. Which part do you disagree with?

Re: MCP is dead; long live MCP

#46

Post by fartfeatures »

ambicapter wrote: post #40
CharlieDigital wrote: post #27

Earlier quoted context omitted.

Because protocols provide structure that increases correctness. It is not a guarantee (as we see with structured output schemas), but it significantly increases compliance.

You're interacting with an LLM, so correctness is already out the window. So model-makers train LLMs to work better with MCP to increase correctness. So the only reason correctness is increased with MCP is because LLMs are specifically trained against it. So why MCP? Are there other protocols that will provide more correctness when trained? Have we tried? Maybe a protocol that offers more compression of commands will…

> You're interacting with an LLM, so correctness is already out the window.

With all due respect if you are prompting correctly and following approaches such as TDD / extensive testing then correctness is not out the window. That is a misunderstanding likely caused by older versions of these models.

Correctness can be as complete as any other new code, I've used the AI to port algorithms from Python to Rust which I've then tested against math oracles and published examples. Not only can I check my code mathematically but in several instances I've found and fixed subtle bugs upstream. Even in well reviewed code that has been around for many years and is well used. It is simply a tool.

Re: MCP is dead; long live MCP

#47

Post by MaxLeiter »

MCPs are great for some use cases

In v0, people can add e.g. Supabase, Neon, or Stripe to their projects with one click. We then auto-connect and auth to the integration’s remote MCP server on behalf of the user.

v0 can then use the tools the integration provider wants users to have, on behalf of the user, with no additional configuration. Query tables, run migrations, whatever. Zero maintenance burden on the team to manage the tools. And if users want to bring their own remote MCPs, that works via the same code path.

We also use various optimizations like a search_tools tool to avoid overfilling context

Re: MCP is dead; long live MCP

#48

Post by CharlieDigital »

ambicapter wrote: post #40
CharlieDigital wrote: post #27

Earlier quoted context omitted.

Because protocols provide structure that increases correctness. It is not a guarantee (as we see with structured output schemas), but it significantly increases compliance.

You're interacting with an LLM, so correctness is already out the window. So model-makers train LLMs to work better with MCP to increase correctness. So the only reason correctness is increased with MCP is because LLMs are specifically trained against it. So why MCP? Are there other protocols that will provide more correctness when trained? Have we tried? Maybe a protocol that offers more compression of commands will…

    > So why MCP? ...  MCP seems arbitrary as a protocol
You're right, it is an arbitrary protocol, but it's one that is supported by the industry.

See the screencaps at the end of the post that show why this protocol. Maybe one day, we will get a better protocol. But that day is not today; today we have MCP.

Re: MCP is dead; long live MCP

#49

Post by kburman »

I’m struggling to understand the recent wave of backlash against MCP. As a standard, it elegantly solves a very real set of integration problems without forcing you to buy into a massive framework.

It provides a unified way to connect tools (whether local via stdio or remote via HTTP), handles bidirectional JSON-RPC communication natively, and forces tools to be explicit about their capabilities, which is exactly what you want for managing LLM context and agentic workflows.

This current anti-MCP hype train feels highly reminiscent of the recent phase where people started badmouthing JSON in favor of the latest niche markup language. It’s just hype driven contrarianism trying to reinvent the wheel.

Re: MCP is dead; long live MCP

#50

Post by hannasanarion »

simianwords wrote: post #21
0xbadcafebee wrote: post #12

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy some…

> This is absolutely necessary since you can (and will) use AI for a million different things the point is, is it necessary to create a new protocol?

Exactly this. I've made some MCP servers and attached tons of other people's MCP servers to my llms and I still don't understand why we can't just use OpenAPI.

Why did we have to invent an entire new transport protocol for this, when the only stated purpose is documentation?

Post reply on HN