I would love to see a proper engineering post-mortem for how this happened.
The actual implementation may have been very janky but the idea itself is sound: If you want to interact with arbitrary services then providing one single protocol (ideally not JSONRPC but hey) with a standard api discovery method and standard starting method call means your super-intelligent machine god can connect to any MCP service with just a URL and figure everything out from there.
Why not just pre-train the model to interact with JSONRPC endpoints?
I do think a lot of the standard would have been easier if they'd been stateless first, and allowed for GET requests, but it evolved from a starting point that has since evolved.
The reason is that these "folks getting paid several hundred thousand dollars a year" are mostly youngsters without any care to learn about computing history, which is why IT is a fashion industry.
See HTMX as another example, that is basically ASP.NET Ajax or JSF Ajax.
(To your point...having knocked out CORBA and DCOM, perhaps we may next look forward to SOAP.)
Maybe Microsoft should bring back Biztalk for agentic workflows.
Someone should have said to the llm coming up with it -- "that sounds like an API with extra steps ... how about we keep these things (tool descriptions) and get rid of all this irrelevant - this will look good in my promotion meeting - overengineering (everything else)"
You are absolutely right is what it would have replied with.
You can probably throw together a passible auth system on top of it that works with the htaccess format. Which is another cgi script but chowned so it can't be called from the outside. If not that, public key crypto - give your agents certificates that are part of the chain of trust. Mint those out of band and give them an insanely short TTL. Fail2ban or something like that to prevent abuse (agent getting handsy with the server gets blocked, credentials revoked).
The side benefit is that everybody starts writing perl and awk again. Who needs a JS runtime when you have CGI?
Only when my AI and its subagents are modelled through a graph of producing agents, consuming agents, and agentic mailboxes, will Claude Code truly shine.
It's a terrible protocol with zero value beyond bigtech sponsorship. We're all worse off for it.
I have long observed that tooling+methodology is a very distinct skillset in software developers - those who treat both subjects with appropriate governance, excel - those who ignore one for the other, tend to make a mess of it.
If you don't have the methods, you will re-invent tools to find those methods. If you don't have tools, you will develop methods sufficient to the creation of those tools. Too many times, folks who have no method of finding existing tools, will instead just build a duplicate tool .. which they will use until they learn the tool-discovery method.
I think AI/ML is really turning the tooling+methodology equation into a maelstrom. Apropos proper engineering post-mortem, I would question the impact on AI/ML-derived riches on the drive to turn standard methods into Subscription Services© behind Yet Another Tool™ ..
LLMs need to say stuff like “your company sells sparkling water, you should not build and maintain another in-house product board and CRM”, and then stand their ground.
But yes, that is the crux of the problem indeed. Agency is nothing if you don't have methods to turn it into tool-use.
But I wouldn't discount how uphill it was to probably even argue for something like MCP cause the labs still very scientist-driven and focused on solving everything in token space. The idea that tool use could be super transformative probably wasn't obvious from inside before Claude Code