Live data from Hacker News

MCP is dead; long live MCP

chrlschn.dev

131–140 of 231 posts

Re: MCP is dead; long live MCP

#131
post #19

This came up in recent discussions about the Google apps CLI that was recently released. Google initially included an MCP server but then removed it silently - and some people believe this is because of how many different things the Google Workspace CLI exposes, which would flood the context. And it seemed like in social media, suddenly a lot of people were talking about how MCP is dead. But fundamentally that doesn’…

MCP loads all tools immediately. CLI does not because it’s not auto exposed to the agent, got have more control of how the context of which tools exist, and how to deliver that context.

”to know what tools you have access to read the dockerfile”?

Re: MCP is dead; long live MCP

#132
This seems misguided when you have to work in enterprise settings. MCP is a very natural fit for all the API auditing and domain borders that exist in enterprise environments, because it provides deterministic tooling and auditable interfaces for agents. Nobody wants an AI agent doing random API calls or shell commands.

Re: MCP is dead; long live MCP

#133
One part that makes me wary of these tools is security.

If I use a remote MCP or CLI that relies on network calls, and I give it in the hands of my coding assistant, wouldn't be too easy to inject prompts and exfiltrate data from my machine?

At least MCP don't have direct access to my machine, but CLIs do.

Re: MCP is dead; long live MCP

#134
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…

I am creator of HasMCP (my response could have a little bias). Not everyone has home/work computer by preference mostly. I know a lot of people just use iPad or Android tablet in addition to their phone. They still use applications to work on the things. This number is not a small amount of people. They need to access openworld data or service specific data. This is where MCP is still the one of the best ways. It tri…

> It tries to standardize the auth, messaging, feedback loop where API can't do alone.

If it tried to do that, you wouldn't have the pain point list.

It's a vibe coded protocol that keeps using one-directional protocols for bi-directional communication, invents its own terms for existing stuff (elicitation lol), didn't even have any auth at the beginnig etc.

It's a slow sad way of calling APIs with JSON-RPC

Re: MCP is dead; long live MCP

#135
post #132

This seems misguided when you have to work in enterprise settings. MCP is a very natural fit for all the API auditing and domain borders that exist in enterprise environments, because it provides deterministic tooling and auditable interfaces for agents. Nobody wants an AI agent doing random API calls or shell commands.

MCP is an API endpoint. If your MCP endpoints are auditable, and the rest of your APIs are not, you're doing something wrong

Re: MCP is dead; long live MCP

#136

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…

MCP is literally "define a bespoke API using this vibe-coded protocol over JSON-RPC".

There's nothing more standard or reusable or application-agnostic about it than using an API over any of the existing protocols.

Re: MCP is dead; long live MCP

#137
post #119

A lot of the best tooling around AI we're seeing is adding deterministic gates that the probabilistic AI agents work with. This is why I'm using MCP over http. I'm happy for the the agent to use it's intelligence and creativity to help me solve problems, but for a range of operations, I want a gate past which actions run with the certainty of normal software functions. NanoClaw sells itself on using deterministic fil…

[dead]

Re: MCP is dead; long live MCP

#139
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.

[flagged]

Re: MCP is dead; long live MCP

#140
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.

Just use a custom PATH and run in a chroot jail.

CLI sandboxing is a solved problem compared to whatever MCP is.

Post reply on HN