MCP is dead; long live MCP

This is confused and misguided.

The fundamental proposal here is that despite being bad MCP is the correct choice for Enterprise because:

> Organizations need architectures and processes that start to move beyond cowboy, vibe-coding culture to organizationally aligned agentic engineering practices. And for that, MCP is the right tool for orgs and enterprises.

…but, you can distill this to: the “cowboys” are off MCP because they've moved to yolo openclaw, where anything goes and there are no rules, no restrictions and no auditing.

…but thats a strawman from the twatter hype train.

Enterprises are not adopting openclaw.

It’s not “MCP or Openclaw”.

Thats a false dichotomy.

The correct question is: has MCP delivered the actual enterprise value and actual benefits it promised?

Or, were those empty promises?

Does the truely stupid MCP ui proposal actually work in practice?

Or, like the security and auditing, is it a disaster in practice, which was never really thought through carefully by the original authors?

It seems to me, that vendors are increasingly determining that controlled AI integrations with rbac are the correct way forward, but MCP has failed to deliver that.

Thats why MCP is dying off.

…because an open plugin ecosystem gives you broken crap like the Atlassian MCP server, and a bunch of maybe maybe 3rd party hacks.

Thats not what enterprises want, for all the reasons in the article.

As someone charged with enabling users across an enterprise with AI tooling, the majority of whom are not in the software dev category, this article is perfectly mirroring my approach. Which is reassuring!

Challenges we are solving with centralised MCP are around brand guardianship, tone of voice, internal jargon and domain context, access to common data sources, and via the resources methods in MCP access to “skills” that prescribe patterns and shims for expected paths and ways of connecting/extracting data.

CLI’s and shell commands can be wrapped by and packaged into scripts, those scripts can have meaningful names. On Windows at least you can assign special icons to shortcuts to those scripts.

I’ve used that approach to get non-technical near-retirees as early adopters of command line tooling (version control and internal apps). A semantic layer to the effect of ‘make-docs, share-docs, get-newest-app, announce-new-app-version’.

The users saw a desktop folder with big buttons to double click. Errors opened up an email to devs/support with full details (minimizing error communication errors and time to fix). A few minutes of training, expanded and refined to meet individual needs, and our accountants & SME’s loved SVN/Git. And the discussion was all about process and needs, not about tooling or associated mental models.

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 the secret, it’s just you! And the other alternative is to run OAuth flows by making you authorize in the browser :). That at least allows some sort of auditing since the agent can use a specific OAuth client to authorize you. But now you have no ability to run the agent unattended, you will need to log in to every possible CLI service before you let the agent work, which means your agent is just sitting there with all your access. Ignorance about best security practices really makes this industry a joke. We need zero standing trust. Auditability. Minimum access required for a task. By letting your agent use your CLIs as if it was you, you throw away all of that.

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

That sounds like a hack to get around the lack of MCP. If your goal is to expose your tools through an interface that a coding agent can easily parse and use, what compels you to believe throwing amorphous structured text is a better fit than exposing it through a protocol specially designed to provide context to a model?

> The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly.

I think you got it backwards. Early agents couldn't handle, and the problem was solved with the introduction of an interface that models can easily handle. It became a solved problem. Now you only argue that if today's models work hard enough, they can be willed into doing something with tools without requiring a MCP. That's neat, but a silly way to reinvent the wheel - poorly.