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

91–100 of 231 posts

Re: MCP is dead; long live MCP

#91

Post by monsieurbanana »

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

> I have no idea what I'm missing. The questions I'd ask: - Do you work in a team context of 10+ engineers? - Do you all use different agent harnesses? - Do you need to support the same behavior in ephemeral runtimes (GH Agents in Actions)? - Do you need to share common "canonical" docs across multiple repos? - Is it your objective to ensure a higher baseline of quality and output across the eng org? - Would your wor…

What I want to know is what's the difference between a remote mcp and an api with an openapi.json endpoint for self-discovery? It's just as centralized

Re: MCP is dead; long live MCP

#92

Post by mkoubaa »

harrall wrote: post #88
tptacek wrote: post #75

Earlier quoted context omitted.

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…

CLI doesn’t work for your coworkers that aren’t technical. Have you tried to use a random API before? It’s a process of trial and error. With the MCP tools I use, it works the first time and every time. There is no “figuring out.”

If you can't write a good CLI I doubt you could write a good MCP

Re: MCP is dead; long live MCP

#93

Post by gtirloni »

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 are you investing time in instead?

Re: MCP is dead; long live MCP

#94

Post by re-thc »

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

That "AI" got renamed to "AGI"

Re: MCP is dead; long live MCP

#95

Post by tptacek »

isbvhodnvemrwvn wrote: post #81
tptacek wrote: post #75

Earlier quoted context omitted.

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…

It's significantly more difficult to secure random clis than those apis. All llm tools today bypass their ignore files by running commands their harness can't control.

I'm fuzzy when we're talking about what makes an LLM work best because I'm not really an expert. But, on this question of securing/constraining CLIs and APIs? No. It is not easier to secure an MCP than it is a CLI. Constraining a CLI is a very old problem, one security teams have been solving for at least 2 decades. Securing MCPs is an open problem. I'll take the CLI every time.

Re: MCP is dead; long live MCP

#96

Post by kybernetikos »

behehebd wrote: post #89
kybernetikos wrote: post #69

Earlier quoted context omitted.

I've just been discovering this pattern too. It's made a huge difference. Trying to get Claude to remote control an app for testing via the various other means was miserable and unreliable. I got it to build an MCP server into the app that supported sending commands to allow Claude to interact with it as if it was a user, including keypresses and grabbing screenshots, and the difference was immediate and really benef…

How does it compare to my goto: a test suite that uses Playwright? > Claude imolement plan.md until all unit and browser tests pass

I assume that this is dependent on app, and it's quite possible that your approach is best in some cases.

In my case I started with something somewhat like Playwright, and claude had a habit of interacting with the app more directly than a user would be able to and so not spotting problems because of it. Forcing it to interact by pressing keys rather than delving into the dom or executing random javascript helped. In particular I wanted to be able to chat with it as it tried things interactively. This is more to help with manual tests or exploratory testing rather than classic automated testing.

My current app is a desktop app, so playwright isn't as applicable.

Re: MCP is dead; long live MCP

#97

Post by thunkle »

So if I release a new cli. How do I get the LLM to know about it? Do i tell it every time to run the command? Do I build a skill. Should I release a skill with the cli? Do I just create docs on GitHub and hope the next crawl gets into the training set?

Re: MCP is dead; long live MCP

#98

Post by jollyllama »

grensley wrote: post #15
jollyllama wrote: post #3

> Centralization is Key > (I preface that this is primarily relevant for orgs and enterprises; it really has no relevance for individual vibe-coders) The thing about tools that "democratize" software development, whether it is Visual Studio/Delphi/QT or LLMs, is that you wind up with people in organizations building internal tools on which business processes will depend who do not understand that centralization is ke…

On the other hand, I've seen over-centralization completely crush the hopes and dreams of people with good ideas.

Why not both? There are orgs where good ideas are crushed under the banner of centralization and duplicate efforts proliferate, side by side.

Re: MCP is dead; long live MCP

#99

Post by kybernetikos »

kburman wrote: post #49

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

I don't even fully understand what people are suggesting instead. That we use CLI tools for everything? There are lots of things I do and tools I use that cli would be very inefficient for interacting with.

Re: MCP is dead; long live MCP

#100

Post by oneseventwonine »

tptacek wrote: post #75
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…

For the Agent to use CLI, don't we have to install CLI in the run-time environment first? Instead for the MCP over streamable HTTP we don't have to install anything and just specify the tool call in the context in't it?
Post reply on HN