Live data from Hacker News

MCP is dead; long live MCP

chrlschn.dev

161–170 of 231 posts

Re: MCP is dead; long live MCP

#161

Earlier quoted context omitted.

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.

I agree and you can see that my blog post really focuses on orgs and teams and explaining why MCP is the future for enterprise.

Garry Tan and the influencer take is focused on vibe coding whereas orgs need things like auth and telemetry.

Re: MCP is dead; long live MCP

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

I follow a similar pattern. My autonomous agent Smith has a service mesh that I plug MCPs into, which gives me a single place to define policy (OPA for life) and monitoring. The service gateway own credentials. This pattern is secure, easy to manage and lets you can programmatically generate a CLI from the tool catalog. https://github.com/sibyllinesoft/smith-gateway if you want to understand the model and how to implement it yourself.

Re: MCP is dead; long live MCP

#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, it shipped without auth and now claims security as chief benefit. chroot jails and scoped tokens solved this decades ago.

only place MCP wins is oauth flows for non-technical users who will never open a terminal. for dev tooling? just write better CLIs.

Re: MCP is dead; long live MCP

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

LangChain is not over-engineered; it's not engineered at all. Pure Chaos.

I wish job openings for anything LLM related would stop asking for experience with langchain

Re: MCP is dead; long live MCP

#165
This article is sort of right, though MCP itself is still a very meh standard, for secure enterprise use cases, SOME agent specific standard is really valuable. It gives you a single point of management. What matters is that it's _for agents_ and it has traction.

I wrote a little bit about this a while ago: https://sibylline.dev/articles/2026-03-01-mcp-changed-my-min...

I created an example repo demonstrating this pattern and how it can be used at https://github.com/sibyllinesoft/smith-gateway

Re: MCP is dead; long live MCP

#167
post #88
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.”

MCP also doesn't work for coworkers that are technical. It works for their agents only.

CLI works for both agents and technical people. REST API works for both agents and technical people. MCP works only for agents (unless I can curl to it, there are some HTTP based ones)

Re: MCP is dead; long live MCP

#168
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 don't think so. There is no MCP standard for authentication, our infosec banned MCP because of that.

Re: MCP is dead; long live MCP

#169

Earlier quoted context omitted.

Write better CLIs for the agents of the less-technical people. The MCPs you're talking about don't exist yet either. This doesn't seem complicated; MCP seems like a real dead end.

How are those CLIs being installed and run on hosted services? You'll need to sandbox them and have a way to install them automatically which seems difficult. How does the auth flow work? You'd need to invent some convention or write glue for each service. These are far more complicated than just using MCP, regardless of the benefits of the protocol itself.

If one doesn't sandbox agent run environment then there is a problem there already.

Re: MCP is dead; long live MCP

#170

Earlier quoted context omitted.

I mean, CLI tool is also “reusable communication abstraction”, innit?

Tell me how many ways that print help message for a command you have seen and say "reusable" again. Mcp is exactly exists to solve this. The rest is just json rpc with simple key value pairs. You can probably let llm guess the help flag and try to parse help message. But the success rate is totally depends on model you are using.

Most CLIs use `--help`, any other are just plain hostile to the users.

`-h` is also popular, but there is also possible issue of that shorthand, hence `--help`.

Post reply on HN