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

71–80 of 231 posts

Re: MCP is dead; long live MCP

#71

Post by theptip »

8note wrote: post #56
ambicapter wrote: post #20

Earlier quoted context omitted.

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.

Why the desire to reinvent the wheel every time? Agents can do it accurately, but you have to wait for them to figure it out every time, and waste tokens on non-differentiated work The agents are writing the mcps, so they can figure out those http and ftp calls. MCP makes it so they dont have to every time they want to do something. I wouldnt hire a new person to read a manual and then make a bespoke json to call an…

It’s simply about making standard, centralized plugins available. Right now Claude benefits from a “link GitHub Connector” button with a clear manifest of actions.

Obviously if the self-modifying, Clawd-native development thing catches on, any old API will work. (Preferably documented but that’s not a hard requirement.)

For now though, Anthropic doesn’t host a clawd for you, so there isn’t yet a good way for it to persist customs integrations.

Re: MCP is dead; long live MCP

#72

Post by skybrian »

CharlieDigital wrote: post #13
skybrian wrote: post #9

If it's a remote API, I suppose the argument is that you might as well fetch the documentation from the remote server, rather than using a skill that might go out of date. You're trusting the API provider anyway. But it's putting a lot of trust in the remote server not to prompt-inject you, perhaps accidentally. Also, what if the remote docs don't suit local conditions? You could make local edits to a skill if needed…

Or just build your own remote MCP server for docs? It's easy enough now that the protocol and supporting SDKs have stabilized. Most folks are familiar with MCP tools but not so much MCP resources[0] and MCP prompts[1]. I'd make the case that these latter two are way more powerful and significant because (most) tools support them (to varying degrees at the moment, to be fair). For teams/orgs, these are really powerful…

I think that might make sense for teams or people working in multiple repos. Maybe less so for individuals working on a side project.

Re: MCP is dead; long live MCP

#73

Post by antirez »

CharlieDigital wrote: post #41
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.

So you love interacting with web sites sending requests with curl? And if you need the price of an AWS service, you love to guess the service name (querying some other endpoint), then ask some tool the price for it, get JSON back, and so forth? Or you are better served by a small .md file you pre-compiled with the services you use the most, and read from it a couple of lines?

> I'd recommend that you take a peek at MCP prompts and resources spec

Don't assume that if somebody does not like something they don't know what it is. MCP makes happy developers that need the illusion of "hooking" things into the agent, but it does not make LLMs happy.

Re: MCP is dead; long live MCP

#75

Post by tptacek »

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…

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use.

The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly.

There is a clear problem that you'd like an "automatic" solution for, but it's not "we don't have a standard protocol that captures every possible API shape", it's "we need a good way to simulate what a CLI does for agents that can't run bash".

Re: MCP is dead; long live MCP

#76

Post by CPLX »

8note wrote: post #67
moralestapia wrote: post #18

Earlier quoted context omitted.

Our workflows must be massively different. I code in 8 languages, regularly, for several open source and industry projects. I use AI a lot nowadays, but have never ever interacted with an MCP server. I have no idea what I'm missing. I am very interested in learning more about what do you use it for.

Its very similar to the switch from a text editor + command line, to having an IDE with a debugger. the AI gets to do two things: - expose hidden state - do interactions with the app, and see before/after/errors it gives more time where the LLM can verify its own work without you needing to step in. Its also a bit more integration test-y than unit. if you were to add one mcp, make it Playwright or some similar browse…

I’ve been using Chrome DevTools MCP a lot for this purpose and have been very happy with it.

Re: MCP is dead; long live MCP

#77

Post by tptacek »

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.

I still don't really understand what LangChain even is.

Re: MCP is dead; long live MCP

#78

Post by tptacek »

MaxLeiter wrote: post #47

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…

I can add Supabase or Stripe to my project with zero clicks just by setting up a .envrc.

Re: MCP is dead; long live MCP

#79

Post by MaxLeiter »

tptacek wrote: post #78
MaxLeiter wrote: post #47

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…

I can add Supabase or Stripe to my project with zero clicks just by setting up a .envrc.

But then the LLM needs to write its own tools/code for interacting with said service. Which is fine, but slower and it can make mistakes vs officially provided tools

Re: MCP is dead; long live MCP

#80

Post by jamesrom »

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.

What part of MCP do you think is over-engineered?

This is quite literally the opposite opinion I and many others had when first exploring MCP. It's so _obviously_ simple, which is why it gained traction in the first place.

Post reply on HN