pull down to refresh
150 sats \ 3 replies \ @k00b 11 Aug \ parent \ on: Why MCP’s Disregard for 40 Years of RPC Best Practices Will Burn Enterprises AI
I'd classify dangerous/inefficient things, especially when they're mostly experienced at the margins, as imperfections.
The best example I can think of for a limitation is something like a text-based wire format (like JSON) used in a context where more binary data (by volume) needs to be transported. The inefficiency here is beyond marginal imo and burdens both sides of the transport.
Put another way, these MCP issues are mostly a burden to the few providers that exist (relative to consumers) and can be solved by providers throwing more money at the problem. Naive consumers will just not cache, retry like hell, etc. In the JSON example, consumers (and providers) will need to support an orthogonal binary wire format which is beyond imperfect imo.
Hmm.. JSON is an encoding standard, like asn.1's encoding variants BER/DER/PER, or nastier things like XML. A protocol could specify an encoding standard, but it doesn't have to. This is the one thing that MCP does.
What is much more important is that the protocol solves domain-specific issues. No errors, no single-shot guarantee, no rollback... all this needs to be re-engineered in. And the result will be a spaghetti spec (which it kind of is already.. it's hard to actually make sense of the docs because it is oddly structured.) Spaghetti specs, like modern websites-over-http for which you need mozilla's security checker to check your live site (or CI) is an awful manufacturing pattern. And since many people are of the belief that all code will be done by LLMs, coding is manufacturing now.
Therefore I'm with the author:
When your protocol’s answer to critical enterprise requirements is a constellation of third-party libraries, you haven’t built a protocol. You’ve built a recipe for fragmentation.
But this is not something that MCP will solve. Maybe MCP's replacement in a few months will. I don't read this as a complaint, but as great advice for whatever comes next. Hopefully without throwing insane amounts of money at it: I'd rather have everyone throw some non-yolo, non-artificial brainpower at it instead.
reply
We don’t disagree about better specs being better or MCP having flaws (I haven’t looked very closely but it’s safe to assume it has many). Protocol economies just seem to have a mind of their own and produce spaghetti specs more often than not, so I see wanting a different spec (after one is widely adopted) like wanting an exception.
I don't read this as a complaint, but as great advice for whatever comes next.
That’s a fair reading. Complaint was a poor word choice. The author seemed frustrated was what I meant.
reply
I don't think you said complaint - I was just trying to put it in perspective, so it's my poor choice of words haha.
In the end, I've been on protocol design teams, lead them, and in an unfortunate situation been the whole team by myself. But I haven't jumped in to help. So ultimately the blame is on me, and every other experienced protocol designer that didn't help with me.
reply