MCPs don't really need this level of technical explanations (it's basically just a REST API with standardized endpoints for discovery aimed at agents), and AI agents really do lack in the taste dimension when it comes to these things.
The opening has 1 paragraph and 5 table entries. One of them is “Not REST”
It’s a little scary that this was considered too dense or complex because the basics were explained in something that could be read in 1 minute. That still wasn’t enough to stop the top HN comment (as I write this) from calling it too dense and giving incorrect information that is immediately refuted by skimming the top part of the article.
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
Yeah, I can click around and follow what's going on. But I'm with GP: this is not making it easier to understand. It's great at being Hollywood UX: looks pretty, stuff moving everywhere. One click on "step" makes the image animate, and change the text in the left sidebar, top middle, and right sidebar, in addition to stepping the table in the bottom middle. But it's almost the opposite of distilling information
If the article said, "It's basically just REST". There'd be no need to comment as such.
They both provide stateless RPC methods and human readable metadata that makes them easy to route.
You could ask why json-rpc was even necessary for 2.0. I think mostly just for stdio and backwards compatibility.
Maybe it was written for an AI? :)
Or by an AI? Or both?
From your comment, I expected to be annoyed by a bunch of slop or obscurities.
My guess is the writing did not come straight out of an LLM and was carefully curated.
If I’m wrong I’d love to have the style prompt.
In theory the agents could just natively know how to do this better, to get exactly the composability you want. In fact, you could probably just write a CLI mcp-caller and tell the agent to only call MCPs via that, and boom you're done.
Where MCP does come back into the picture even for coders is a more controlled way to break a sandbox.
What I will also say is it matters less and less. It's the usual bitter lesson. The models are just getting so much better all attempts to optimize everything are a drop in the bucket.
Consider an agent which doesn’t have those tools though. MCPs are a great way to give them constrained access to remote resources.
Internally at my startup, I built an interpreter for a subset of Javascript where the agent can compose its tools and MCPs. The cool thing about it is that it can create durable workflows and automations from these same scripts.
"Find the latest prod JIRAs and analyze the related logs"
Don't believe me? Try connecting Blender to Codex.
Their secret, which is not very secret, is to ask the AI to help them set it up.
I think this might follow that bell curve meme where people on the unsophisticated and highly sophisticated ends of the curve are leveraging the LLM for MCP setup (and other routine tasks) while some in the middle are making it more complicated than it needs to be because they still think of it as outside the domain of AI-assisted work.
The biggest problem I see isn’t getting MCP set up, it’s people getting stuck using the wrong tools for the job. I’ve improved a lot of workflows by observing what someone is doing and suggesting a better tool for the job.
At my job we maintain an MCP for our admin portal/prod data and it's seen a lot of use. Our admin side was a mess to use so allowing admins to ask questions about prod data has been a huge help for everyone.
And for myself personally, connecting MCPs to Claude has also been an insanely huge productivity boost. It's really nice to just ask for a link to Datadog when I want to monitor some change I made, instead of trying to craft a query myself.
Is it that bad? I have Blender connected to Claude (and my mind is quite blown by how great it is to use) and it was quite easy if you could follow the tutorial (the hardest part was reading that you have to click on something twice)
Now a Claude/Codex/etc user installs a few MCP servers and before they know it their context is already largely used up with tool schemas and guidance before they’ve sent their first prompt.
In response to this harnesses aggressively “hide” most of this to agents, so the agents land up doing best guesses on how to use tools, doing things like sending wrong argument names, etc.
Turns out that a really effective strategy to deal with this is to make two tools only, one to execute a script (eg in JS) and another on how to get guidance on how to craft a script.
When an agent needs to use the tool, they look at the “help” and then craft JavaScript (something they’re already very good at). If the execute endpoint returns adequately descriptive errors with stack traces then the agent can pretty much always self fix their mistake.
We worked this out for ourselves in our own product and we found out after that Cloudflare wrote a blog post on how they use the same strategy.
Also, Apple just announced their preview for new Siri AI capabilities and part of that is they seemingly are going to add MCP to apps (if developers of the apps want to) as tools, which would enable Siri to use functions of apps, similarly to Claude Desktop using functions of services through MCP tool calls.
Just like us to take something and limit it back to being useless until we implement the feature (tools).
The real "race to market" winners will just throw the credentials into the SQL connector and let 'er rip like a real man.
That's what we started doing... and never looked back. Now we're thinking of exposing parts of the database in readonly mode to in-house staff (non-developers) so they can vibe code whatever the hell kind of tools they want...
No it doesn't. It adds yet another Nth "API standardization" spec.
MCP has its place. It should not be the default for many use cases, but if you need to expose specific tools in a secure way to agents that are not trusted to run shell commands then MCP is great. Developers need to think beyond their own use cases and consider architecture patterns if they're going to build, not just consume, AI systems.
This was just to avoid MCP infra, but the newer stateless protocol makes that much more trivial.
People make the argument that it doesn't matter for non-programmers. I use Bluebeam (a pdf editor which is standard in the construction industry) daily, and it has an MCP, but a big problem is that if the agent wants to import or export a large amount of data from a document, then it has to regurgitate a bunch of tokens into or out of the MCP. If it were a CLI, then it would just pipe things in and out as it needs.
I ended up just having the agent make a script that wraps the MCP so it can use it as a CLI instead.
Tool calls being composable or not are a property of the harness being used, not of MCP servers
There are usecases of MCPs (e.g. serving outside customers via proprietary tools), but composability has not been in the minds of the early users of MCP and it is one of the hundreds of little practical drawbacks they have when used in house.
It is the same with a wepapp: You could argue you don't neex browser apps if the user just install a software on their computer, but we feel better using the sandboxing environment of your browser.
Be surprised how far apps can get with just solid & well documented APIs. Modern agents are smart!
Then you don't need an MCP server per service anymore, you just need one and a whitelist of authorized services.
I swear when I see stuff like this is makes me depressed about the future of our industry. Pick up an Edward Tufte book or something and use your brain