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 dead; long live MCP
171–180 of 231 posts
Re: MCP is dead; long live MCP
#172Earlier 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…
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
#173Earlier 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
#174The 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
#175Earlier 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.
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
#176Re: MCP is dead; long live MCP
#177Re: MCP is dead; long live MCP
#1781. 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.