Live data from Hacker News

MCP is dead; long live MCP

chrlschn.dev

171–180 of 231 posts

Re: MCP is dead; long live MCP

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

There is no standard for MCP authentication, because of that it is e.g. blocked in my enterprise. Basically they want to avoid non-technicals installing random MCPs and exposing internals to internet.

Re: MCP is dead; long live MCP

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

The biggest disappointment I have with MCP today is that many clients are still half-assed on supporting the functions outside of MCP tools.

Namely, two very useful features resources and prompts have varying levels of support across clients (Codex being one of the worst).

These two are possibly the most powerful ones since they allow consistent, org-level remote delivery of context and I would like to see all major clients support these two and eventually catch up on the other features like elicitation, progress, tasks, etc.

Re: MCP is dead; long live MCP

#173
post #152
post #148

Earlier quoted context omitted.

You should read the article, it explains very well why that is completely wrong. cLIs don’t have a good story about security, are you serious?? They either use a secret , in which case the LLM will have the exact same permission as you as a user, which is bonkers (not to mention the LLM can leak your secret now to anyone by making a simple curl request) and prevents AI auditing since it’s not the AI that seems to use…

OP never mentioned letting the agent run as him or use his secrets. All of the issues you mention can be solved by giving the agent it’s own set of secrets or using basic file permissions, which are table stakes. Back to the MCP debate, in a world where most web apis have a schema endpoint, their own authentication and authorization mechanisms, and in many instances easy to install clients in the form of CLIs … why d…

    > OP never mentioned letting the agent run as him or use his secrets
That is implicit with a CLI because it is being invoked in the user session unless the session itself has been sandboxed first. Then for the CLI to access a protected resource, it would of course need API keys or access tokens. Sure, a user could set up a sandbox and could provision agent-specific keys, but everyone could always enable 2FA, pick strong passwords, use authenticators, etc . and every org would have perfect security.

That's not reality.

Re: MCP is dead; long live MCP

#174
Yet another problem with MCP: every LLM harness that does support it at all supports it poorly and with bugs.

The MCP spec allows MCP servers to send back images to clients (base64-encoded, some json schema). However:

1) codex truncates MCP responses, so it will never receive images at all. This bug has been in existence forever.

2) Claude Code CLI will not pass those resulting images through its multi-modal visual understanding. Indeed, it will create an entirely false hallucination if asked to describe said images.

3) No LLM harness can deal with you bouncing your local MCP server. All require you to restart the harness. None allow reconnection to the MCP server.

I assure you there are many other similar bugs, whose presence makes me think that the LLM companies really don't like MCP, and are bugly-deprecating it.

Re: MCP is dead; long live MCP

#175
post #169

Earlier quoted context omitted.

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.

I think a big part of why this discussion is coming up again and again is that people assume the way they are using AI is universal, but there's a bunch of different ways to leverage it. If you have an agent which runs within a product it usually cannot touch the outside world at all by design, you do not need an explicit sandbox (i.e. a VM or container) at all because it lives in an isolated environment. As soon as you say "we use CLIs not MCP" well now you need a sandbox and everything else that goes along with it.

If you can tell ahead of time what external connectors you need and you're already sandboxing then by all means go with CLIs, if you can't then MCP is literally the only economical and ergonomic solution as it stands today.

Re: MCP is dead; long live MCP

#178
I still think MCP is completely unnecessary (and have from the start). The article correctly points out where CLI > MCP but stops short on 2 points:

1. Documenting the interface without MCP. This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs (or any other integration). Agents only load the relevant details when needed. This also makes it easy to customize the docs for the specific cases you are working with and build skills that use a subset of the tools.

2. Regarding all of the centralization benefits attributed to remote MCPs - you can get the same benefits with a traditional centralized proxy as well. MCP doesn't inherently grant you any of those benefits. If I use AWS sso via CLI, boom all of my permissions are tied to my account, benefit from central management, and have all the observability benefits.

In my mind, use Skills to document what to do and benefit from targeted progressive disclosure, and use CLIs and REST APIs for the actual interaction with services.

Re: MCP is dead; long live MCP

#180
Finally, I have been saying this for months and generally to big backlash. The only two aspects missing are the role of central mcp gateways and code mode. We don't know 100% how these will be used optimally but thats what the future will look like for 90% of usecases. I would go so far to say that someone will have to make a bash to js compiler for simple cases like piping common commands like cat ls rg grep, because that would allow using all the RL and training data and save all the overhead of steering away from them. Once there are virtually no local tools left, we can just scale up agent servers like opencode serve to just serve agents like a web server.
Post reply on HN