It is amazing that folks getting paid several hundred thousand dollars a year...reinvented RPC-over-HTTP/JSON. You too, fellow web developers, are smart enough to work at Anthropic.
I would love to see a proper engineering post-mortem for how this happened.
They didn't reinvent it, it's literally using JSONRPC. The thing they "invented" was coming up with a loose standard for how to implement your RPC endpoints in a way that the AI was pre-trained to interact with.
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.
> was coming up with a loose standard for how to implement your RPC endpoints in a way that the AI was pre-trained to interact with.
Why not just pre-train the model to interact with JSONRPC endpoints?
There's more to it than that. MCP adds the concept of the API endpoints describing themselves (giving agents context), standardizes how auth works, and so on. This could all be done by packaging existing standards, but MCP in many ways is packaging and organizing existing standards, minus the previous stateful-first design.
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.
MCP is invisible to the LLM, or should be, under normal use
Not sure I understand what you mean. MCP servers and methods available do have to be visible to the model in some way so that it can spit out tool calls instructions to be executed by the orchestration layer around it. But you probably meant something else?
MCP is the protocol by which the harness can connect with additional tools. The harness does the work of discovering the tools, the model is then fed a description of what tools it has available, with zero awareness of whether those tools are MCP or built into the harness itself (except for by the mcp__ prefix in the tool’s name, which a harness could choose to strip off)
By this statement, do you mean that LLMs really just know about "Tool Calling Tokens" or something else?
Essentially, MCP is the harness’ wheelhouse, not the model’s
They also reinvented CORBA and DCOM, as MCP now supports gRPC as optional protocol.
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.
If only they could ask for history lessons from an LLM!
(To your point...having knocked out CORBA and DCOM, perhaps we may next look forward to SOAP.)
I always have to smile that the whole microservices, isn't much different from "The network is the computer", Taligent, CORBA/DCOM, WebServices, SOA,.... with iPaaS products being another go at BPEL.
Maybe Microsoft should bring back Biztalk for agentic workflows.
As a veteran of JSF - it is similar, but done better, I think. It's only the frontend. Those technologies were more heavyweight, where each component had a lifecycle it went though on each render, and you needed the backend and frontend to support them. HTMX just takes whatever HTML your backend cares to generate, using whatever method it likes, and does the needful with it.
Maybe Greenspun's Tenth Rule applies to anything "common".
oh no, all of those technologies die on their own merits a long time ago. they were basically over engineered and bloated and horrible to work with.
It was a vibe protocol and with the hindsight glasses on it is obvious.
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.
OpenAPI already exists, you can serve it on an endpoint for tool descriptions. Why did we need MCP again?
that would be tokens, vibes and guesses all the way down
As is the entirety of using an LLM? If you want something deterministic and efficient you get the agent to write a script, verify it, then run it yourself.
Bring back FastCGI, enable the setting in Apache to list a directory, and point the agent to your cgi-bin directory full of all your tools. Calling the bin without any input provides the help text or the interface to the tool.
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?
What hindsight, this was obvious from day one.
It's still too early stage for me. Anthropic needs to mature for a little longer before they're enlightened enough to understand my kafka-based event sourcing model for cross-agent orchestration. Kafka, protobuf, functional domain modelling using F# as a DSL...the whole kit and kaboodle.
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.
I can't tell if this is sarcasm or an advertisement for your start up.
It does seem like a return to RPC/REST over HTTP (maybe I am missing some subtleties), which makes sense to me since I never really understood the advantage that MCP bestowed.
The core advantage MCP gave you was a standard that by virtue of being blessed by AI providers people had strong incentives to actually implement.
In fact this aspect of "re-inventing and then congratulating oneself for it" has been a factor in software since the dawn of the subject - it is now with AI/ML, becoming far more endemic across a far broader group of people, who ordinarily would not have done software development properly if it weren't for the immense power that comes from glib application of tooling, minus methodology.
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™ ..
It used to be partially because building tools is fun. Often more fun than building whatever the company actually needs. But now it’s not that fun.
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.
Coming up with solutions isn't so difficult, getting everyone behind one is the hard part. Obviously easier if you're one of the two biggest AI companies in the (Western) world.
The funny thing is that Anthropic and its boosters here framed MCP as a brilliant development.
It's a terrible protocol with zero value beyond bigtech sponsorship. We're all worse off for it.
I wonder if part of it was the bias of how the chat apps work with the streaming maybe they use SSE
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
the deployment targets that got cheap over the last five years are all stateless and a protocol that fights that gets no serverless implementations
I had to double take and say "I coulda dun that!!"
The Protocol is from the Linux Foundation
Maybe that's why they are being paid several hundred thousands of dollars. They get the new wave of programmers to implement their proprietary vendor locked protocol instead of industry standard protocols of the commons.