18 ms·

MCP overlooks hard-won lessons from distributed systems

409 points by yodon 1y ago

al2o3cr 1y ago
IMO worrying about type-safety in the protocol when any string field in the reply can prompt-inject the calling LLM feels like putting a band-aid on a decapitation, but YMMV
- ComputerGuru 1y ago
  They’re 100% orthogonal issues.
gjsman-1000 1y ago
… or we’ll just invent MCP 2.0. On that note; some of these “best practices” arguably haven’t worked out. “Be conservative with what you send, liberal with what you receive” has turned even decent protocols into a dumpster fire, so why keep the charade going?
- rcarmo 1y ago
  I’d rather we ditched MCP and used something that could leverage Swagger instead….
  - bharatgel 1y ago
    UTCP ? https://utcp.io/ https://utcp.io/
- jmull 1y ago
  Right... Failed protocols such as TCP adopted Postel's law as a guiding principle, and we all know how that worked out!
  - dragonwriter 1y ago
    A generalized guiding principle works in one particular use case, so this proves it is a good generalized guiding principle?
  - gjsman-1000 1y ago
    Survivor’s bias.
    - jmull 1y ago
      Circular argument.
  - oblio 1y ago
    TCP is basically the only example of that principle that works and it only works because the protocol is low level and constrained. Almost all the implementations of that principle from close to the app layer are abominations we're barely keeping running.
mockingloris 1y ago
I read this thrice: ...When OpenAI bills $50,000 for last month’s API usage, can you tell which department’s MCP tools drove that cost? Which specific tool calls? Which individual users or use cases?... It seems to be a game of catch up for most things AI. That said, my school of thought is that certain technologies are just too big for them to be figured out early on - web frameworks, blockchain, ... - the gap starts to shrink eventually. With AI, we'll just have to keep sharing ideas and caution like you have here. Such very interesting times we live in.
zorked 1y ago
CORBA emerged in 1991 with another crucial insight: in heterogeneous environments, you can’t just “implement the protocol” in each language and hope for the best. The OMG IDL generated consistent bindings across C++, Java, Python, and more, ensuring that a C++ exception thrown by a server was properly caught and handled by a Java client. The generated bindings guaranteed that all languages saw identical interfaces, preventing subtle serialization differences. Yes, CORBA was such a success.
- antonymoose 1y ago
  To be charitable, you can look at a commercially unsuccessful project and appreciate its technical brilliance.
  - drweevil 1y ago
    Just an interesting bit of trivia, the Large Hadron Collider uses/used (don't know if it still does) CORBA in its distributed control system. (On the control system I worked on we use Sun RPC, which was fine as things go but doesn't have the language support that CORBA has. We used a separate SOAP interface to the system to allow for languages such as Python. Today I'd use gRPC, or the BEAM.) On a more general note, I see in many critical comments here what I perceive to be a category error. Using JSON to pass data between web client and server, even in more complex web apps, is not the same thing as supporting two-way communications between autonomous software entities that are tasked to do something, perhaps something critical. There could be millions of these exchanges in some arbitrarily short time period, thus any possibility of errors is multiplied accordingly, and the effect any error could cascade if it does not fail early. I really don't believe this is a case where "worse is better." To use an analogy, yes everyday English is a versatile language that works great for most use cases; but when you really need to nail things down, with no tolerance for ambiguity, you get legalese or some other jargon. Or CORBA, or gRPC, etc.
    - otterley 1y ago
      > but when you really need to nail things down, with no tolerance for ambiguity, you get legalese If only that were true. Litigation happens every single day over the meanings of contracts and laws that were drafted by well-trained and experienced attorneys.
abtinf 1y ago
I wish someone would write a clear, crisp explanation for why MCP is needed over simply supporting swagger or proto.
- nikanj 1y ago
  MCP is new
- dragonwriter 1y ago
  OpenAPI (or its Swagger predecessor) or Proto (I assume by this you mean protobuf?) don't cover what MCP does. It could have layered over them instead of using JSON-RPC, but I don't see any strong reason why they would be better than JSON-RPC as the basis (Swagger has communication assumptions that don't work well with MCP's local use case; protobuf doesn't cover communication at all and would require additional consideration in the protocol layered over it.) You'd still need basically the entire existing MCP spec to cover the use cases if it replaced JSON-RPC with Swagger or protobuf, plus additional material to cover the gaps and complications that that switch would involve.
  - vineyardmike 1y ago
    Proto has a full associated spec (gRPC) on communication protocols and structured definitions for them. MCP could easily have built upon these and gotten a lot “for free”. Generally gRPC is better than JsonRPC (see below). I agree that swagger leaves a lot unplanned. I disagree about the local use case because (1) we could just run local HTTP servers easily and (2) I frankly assume the future of MCP is mostly remote. Returning back to JSON-RPC, it’s a poorly executed RPC protocol. Here is an excellent HackerNews thread on it, but the TLDR is parsing JSON is expensive and complex, we have tons of tools (eg load balancers) that make modern services, and making those tools parse json is very expensive. Many people in the below thread mention alternative ways to implement J-RPC but that depends on new clients. https://news.ycombinator.com/item?id=34211796 https://news.ycombinator.com/item?id=34211796
  - SahAssar 1y ago
    I don't understand what MCP gives that a REST API with a OpenAPI definition would not give?
self_awareness 1y ago
What's new? - Electron disregards 40 years of best deployment practices, - Web disregards 40 years of best GUI practices, - Fast CPUs and lots of RAM disregards 40 years of best software optimization techniques, there are probably many more examples.
- xg15 1y ago
  Yeah, and all three have evidently made software more shitty. More profitable and easier to develop, sure, but also much more unpleasant to use.
  - wredcoll 1y ago
    vim is in fact easier to use than vi. windows 10 is easier to use than windows 95. osx is easier to use than mac.. whatever they named their old versions. It goes on and on. I can have 50 browser tabs open at the same time, each one hosting a highly complicated app, ranging from media playback to chat rooms to custom statistical calculators. I don't need to install anything for any of these apps, I just type in a short string in my url bar. And they all just work, at the same time. Things are in fact better now.
    - 0xbadcafebee 1y ago
      I have to keep buying a new computer every few years because software keeps getting slower. That machine still costs a thousand dollars, and my "low-end" internet connection now costs $100. My hypertext document viewer requires at least 8GB of RAM for normal use, with eight CPU cores. No new network protocol can exist without being tunneled over the hypertext document viewer's stateless application-layer network protocol. All of this so that I can click on a screen to read some text. The supercomputers in our pockets (that used to be telephones, but don't work well for that anymore) will let us run the programs that one of two companies allow us to run, which will run most apps... as long as the hardware is as recent as our laptops/desktops. Yes, we're very advanced. In the past 20 years, we have achieved... the same thing we had 20 years ago... only with more hardware requirements, programming languages, and frameworks. Today you can do anything... as long as it's on a web page, on recent hardware (and God help you if you haven't updated your software in the past month)
rickcarlino 1y ago
> SOAP, despite its verbosity, understood something that MCP doesn’t Unfortunately, no one understood SOAP back. (Additional context: Maintaining a legacy SOAP system. I have nothing good to say about SOAP and it should serve as a role model for no one)
- SoftTalker 1y ago
  I have found that any protocol whose name includes the word "Simple" is anything but. So waiting for SMCP to appear....
  - divan 1y ago
    No, letter S in MCP is reserved for "Security")
  - yjftsjthsd-h 1y ago
    I dunno, SMTP wasn't bad last time I had to play with it. In actual use it wasn't entirely trivial, but most of that happened at layers that weren't really the mail transfer protocol's fault (SPF et al.). Although, I'm extremely open to that being one exception in flood of cases where you are absolutely correct:)
  - sirtaj 1y ago
    I recall two SOAP-based services refusing to talk to each other because one nicely formatted the XML payload and the other didn't like that one bit. There is a lot we lost when we went to json but no, I don't look back at that stuff with any fondness.
- cyberax 1y ago
  This is a very hilarious but apt SOAP description: https://harmful.cat-v.org/software/xml/soap/simple https://harmful.cat-v.org/software/xml/soap/simple And I actually like XML-based technologies. XML Schema is still unparalleled in its ability to compose and verify the format of multiple document types. But man, SOAP was such a beast for no real reason. Instead of a simple spec for remote calls, it turned into a spec that described everything and nothing at the same time. SOAP supported all kinds of transport protocols (SOAP over email? Sure!), RPC with remote handles (like CORBA), regular RPC, self-describing RPC (UDDI!), etc. And nothing worked out of the box, because the nitty-gritty details of authentication, caching, HTTP response code interoperability and other "boring" stuff were just left as an exercise to the reader.
btown 1y ago
If you want the things mentioned in this article, I highly recommend looking at https://github.com/modelcontextprotocol/modelcontextprotocol/issues https://github.com/modelcontextprotocol/modelcontextprotocol... and https://modelcontextprotocol.io/community/sep-guidelines https://modelcontextprotocol.io/community/sep-guidelines and participating in the specification process. Point-by-point for the article's gripes: - distributed tracing/telemetry - open discussion at https://github.com/modelcontextprotocol/modelcontextprotocol/issues/246 https://github.com/modelcontextprotocol/modelcontextprotocol... - structured tool annotation for parallelizability/side-effects/idempotence - this actually already exists at https://modelcontextprotocol.io/specification/2025-06-18/schema#toolannotations https://modelcontextprotocol.io/specification/2025-06-18/sch... but it's not well documented in https://modelcontextprotocol.io/specification/2025-06-18/server/tools#tool https://modelcontextprotocol.io/specification/2025-06-18/ser... - someone should contribute to improving this! - a standardized way in which the costs associated with an MCP tool call can be communicated to the MCP Client and reported to central tracking - nothing here I see, but it's a really good idea! - serialization issues e.g. "the server might report a date in a format unexpected by the client" - this isn't wrong, but since the consumer of most tool responses is itself an LLM, there's a fair amount of mitigation here. And in theory an MCP Client can use an LLM to detect under-specified/ambiguous tool specifications, and could surface these issues to the integrator. Now, I can't speak to the speed at which Maintainers and Core Maintainers are keeping up with the community's momentum - but I think it's meaningful that the community has momentum for evolving the specification! I see this post in a highly positive light: MCP shows promise because you can iterate on these kinds of structured annotations, in the context of a community that is actively developing their MCP servers. Legacy protocols aren't engaging with these problems in the same way.
- cratermoon 1y ago
  I feel like the article addressed this response in the section titled 'The “Just Use This Library” Trap'
  - btown 1y ago
    These aren’t third-party libraries, these are RFP processes for adding to the official protocol, and standardizing the semantics of new fields and data types. A world of difference IMO.
calvinmorrison 1y ago
MCP, aka, WSDL for REST
- SigmundA 1y ago
  I thought that was OpenAPI?
- ElectricalUnion 1y ago
  Web Application Description Language is "WSDL for REST".
zwaps 1y ago
The author seems to fundamentally misunderstand how MCPs are going to be used and deployed. This is really obvious when they talk about tracing and monitoring, which seem to be the main points of criticism anyway. They bemoan that they cant trace across MCP calls, assuming somehow there would be a person administering all the MCPs. Of course each system has tracing in whatever fashion fits its system. They are just not the same system, nor owned by the same people let alone companies. Same as monitoring cost. Oh, you can’t know who racked up the LLM costs? Well of course you can, these systems are already in place and there are a million of ways to do this. It has nothing to do with MCP. Reading this, I think its rather a blessing to start fresh and without the learnings of 40 years of failed protocols or whatever
- oblio 1y ago
  > without the learnings of 40 years of failed protocols or whatever 1. Lessons. 2. Fairly sure all of Google is built on top of protobuf.
ComplexSystems 1y ago
I thought this article was going to be a bunch of security theater nonsense - maybe the relatively bland title - but after reading I found it to be incredibly insightful, particularly this: > MCP discards this lesson, opting for schemaless JSON with optional, non-enforced hints. Type validation happens at runtime, if at all. When an AI tool expects an ISO-8601 timestamp but receives a Unix epoch, the model might hallucinate dates rather than failing cleanly. In financial services, this means a trading AI could misinterpret numerical types and execute trades with the wrong decimal precision. In healthcare, patient data types get coerced incorrectly, potentially leading to wrong medication dosing recommendations. Manufacturing systems lose sensor reading precision during JSON serialization, leading to quality control failures. Having worked with LLMs every day for the past few years, it is easy to see every single one of these things happening. I can practically see it playing out now: there is some huge incident of some kind, in some system or service with an MCP component somewhere, with some elaborate post-mortem revealing that some MCP server somewhere screwed up and output something invalid, the LLM took that output and hallucinated god knows what, its subsequent actions threw things off downstream, etc. It would essentially be a new class of software bug caused by integration with LLMs, and it is almost sure to happen when you combine it with other sources of bug: human error, the total lack of error checking or exception handling that LLMs are prone to (they just hallucinate), a bunch of gung-ho startups "vibe coding" new services on top of the above, etc. I foresee this being followed by a slew of Twitter folks going on endlessly about AGI hacking the nuclear launch codes, which will probably be equally entertaining.
- throwawaymaths 1y ago
  i mean isnt all this stuff up to the mcp author to return a reasonable error to the agent and ask for it to repeat the call with amendments to the json?
  - dotancohen 1y ago
    Yes. And this is where culture comes in. The culture of discipline of the C++ and the JavaScript communities are at extreme odds of the spectrum. The concern here is that the culture of interfacing with AI tools, such as MCP, is far closer to the discipline of the JavaScript community than to the C++ community.
BLanen 1y ago
As I've been saying. MCP is not a protocol. It doesn't protocolize anything of use. It's just "here's some symbols, do with them whatever you want.", leaving it there but then advertising that as a feature of its universality. It provides almost just as much of a protocol as TCP, but rebuild on 5 OSI layers, again. It's not a security issue, it's a ontological issue.
- lsaferite 1y ago
  And yet, TCP powers the Internet. That being said. MCP as a protocol has a fairly simple niche. Provide context that can be fed to a model to perform some task. MCP covers the discovery process around presenting those tools and resources to an Agent in a standardized manner. An it includes several other aspects that are useful in this niche. Things like "sampling" and "elicitations". Is it perfect? Not at all. But it's a step in the right direction. The crowd saying "just point it at an OpenAPI service" does not seem to fully understand the current problem space. Can many LLMs extract meaning from un-curated API response messages? Sure. But they are also burning up context holding junk that isn't needed. Part of MCP is the acknowledgement that general API responses aren't the right way to feed the model the context it needs. MCP is supposed to be taking a concrete task, performing all the activities need to gather the info or affect the change, then generate clean context meant for the LLM. If you design an OpenAPI service around those same goals, then it could easily be added to an Agent. You'd still need to figure out.all the other aspects, but you'd be close. But at that point you aren't pointing an Agent at a random API, you're pointing it at a purpose made API. And then you have to wonder, why not something like MCP that's designed for that purpose from the start? I'll close by saying there are an enormous number of MCP Servers out there that are poorly written, thin wrappers on general APIs, or have some other bad aspects. I attribute a lot of this to the rise in AI Coding Agents allowing people with poor comprehension of the space enabling them to crank out this... Noise. There are also great examples of MCP Servers to be found. They are the ones that have thoughtful designs, leverage the spec fully, and provide nice clean context for the Agent to feed to the LLM. I can envision a future where we can simply point an agent at a series of OpenAPI services and the agent uses it's models to self-assemble what we consider the MCP server today. Basically it would curate accessing the APIs into a set of focused tools and the code needed to generate the final context. That's not quite where we are today. It's likely not far off though.
dragonwriter 1y ago
> MCP discards this lesson, opting for schemaless JSON with optional, non-enforced hints. Actually, MCP uses a normative TypeScript schema (and, from that, an autogenerated JSON Schema) for the protocol itself, and the individual tool calls also are specified with JSON Schema. > Type validation happens at runtime, if at all. That's not a consequence of MCP "opting for schemaless JSON" (which it factually does not), that's, for tool calls, a consequence of MCP being a discovery protocol where the tools, and thus the applicable schemas, are discovered aruntime. If you are using MCP as a way to wire up highly-static components, you can do discovery against the servers once they are wired up, statically build the clients around the defined types, and build your toolchain to raise errors if the discovery responses change in the future. But that's not really the world MCP is built for. Yes, that means that the toolchain needs, if it is concerned about schema enforcement, use and apply the relevant schemas at runtime. So, um, do that?
GeneralMayhem 1y ago
> MCP promises to standardize AI-tool interactions as the “USB-C for AI.” Ironically, it's achieved this - but that's an indictment of USB-C, not an accomplishment of MCP. Just like USB-C, MCP is a nigh-universal connector with very poorly enforced standards for what actually goes across it. MCP's inconsistent JSON parsing and lack of protocol standardization is closely analogous to USB-C's proliferation of cable types (https://en.wikipedia.org/wiki/USB-C#Cable_types https://en.wikipedia.org/wiki/USB-C#Cable_types); the superficial interoperability is a very leaky abstraction over a much more complicated reality, which IMO is worse than just having explicitly different APIs/protocols.
- cnst 1y ago
  I'd like to add that the culmination of USB-C failure was Apple's removal of USB-A ports from the latest M4 Mac mini, where an identical port on the exact same device, now has vastly different capabilities, opaque to the final user of the system months past the initial hype on the release date. Previously, you could reasonably expect a USB-C on a desktop/laptop of an Apple Silicon device, to be USB4 40Gbps Thunderbolt, capable of anything and everything you may want to use it for. Now, some of them are USB3 10Gbps. Which ones? Gotta look at the specs or tiny icons, I guess? Apple could have chosen to have the self-documenting USB-A ports to signify the 10Gbps limitation of some of these ports (conveniently, USB-A is limited to exactly 10Gbps, making it perfect for the use-case of having a few extra "low-speed" ports at very little manufacturing cost), but instead, they've decided to further dilute the USB-C brand. Pure innovation! With the end user likely still having to use a USB-C to USB-A adapters anyways, because the majority of thumb drives, keyboards and mice, still require a USB-A port — even the USB-C ones that use USB-C on the kb/mice itself. (But, of course, that's all irrelevant because you can always spend 2x+ as much for a USB-C version of any of these devices, and the fact that the USB-C variants are less common or inferior to USB-A, is of course irrelevant when hype and fanaticism are more important than utility and usability.)
  - mafuy 1y ago
    As far as I know, please correct me if I'm wrong, the USB spec does not allow USB-C to C cables at all. The host side must always be type A. This avoids issues like your cellphone power supplying not just your headphones but also your laptop.
zombiwoof 1y ago
[dead]
- dang 1y ago
  We've banned this account for posting unsubstantive comments and ignoring our requests to stop. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
ipython 1y ago
I am torn. I see this argument and intellectually agree with it (that interfaces need to be more explicit). However it seems that every time there is a choice between “better” design and “good enough”, the “good enough” wins handily. Multics vs Unix, xml based soap vs json based rest apis, xhtml’s failure, javascript itself, … I could keep going on. So I’ve resigned myself to admitting that we are doomed to reimplement the “good enough” every time, and continue to apply bandaid after bandaid to gradually fix problems after we rediscover them, slowly.
- deleted 1y ago
  [deleted]
- antonvs 1y ago
  It's the old Worse is Better observation, which is 36 years old now: https://en.m.wikipedia.org/wiki/Worse_is_better https://en.m.wikipedia.org/wiki/Worse_is_better It's been confirmed over and over since then. And I say that as someone who naturally gravitates towards "better" solutions.
  - xpe 1y ago
    It depends on system boundaries. If an actor doesn't face the consequences of a decision, but another does, that's an externality. When externalities are present, it is often rational (narrowly speaking) for an actor to accept designs that look awful from a broader perspective. In other words, many technical problems flow rather predictably from decision-making boundaries that don't internalize the externalities. Ever heard someone say "if you care about X, run for office"? The same applies to technology. If one cares about good designs, one must promote organizational and societal structures that actually have a fighting chance at bringing those about. The days of nerds and hackers not caring about broader dynamics and structures are long gone. Sitting back and letting the business folks have control is fine if you want them to optimize for the existing incentives. But if you want to change the rules of the game, you gotta jump in at the deep end.
- cookiengineer 1y ago
  Obligatory minute of silence for xforms 2.0 The world we could have lived in... working web forms validations, working microdata...
draw_down 1y ago
[dead]
mac-mc 1y ago
You're missing the most significant lesson of all that MCP knew. That all of those featureful things are way too overcomplicated for most places, so they will gravitate to the simple thing. It's why JSON over HTTP blobs is king today. I've been on the other side of high-feature serialization protocols, and even at large tech companies, something like migrating to gRPC is a multi-year slog that can even fail a couple of times because it asks so much of you. MCP, at its core, is a standardization of a JSON API contract, so you don't have to do as much post-training to generate various tool calling style tokens for your LLM.
- prerok 1y ago
  What are HTTP blobs? I think you meant that is why JSON won instead of XML?
  - mac-mc 1y ago
    JSON-over-HTTP blobs. Or blobs of schemaless json. Not just XML, but a lot of other serialization formats and standards, like SOAP, protobuf in many cases, yaml, REST, etc. People say REST won, but tell me how many places actually implement REST or just use it as a stand-in term for casual JSON blobs to HTTP URLs?
    - prerok 1y ago
      So, I just looked it up, thinking I might have overlooked something but, at least according to wikipedia, REST does not prescribe the format of the data transferred. So, I don't understand why you are comparing REST to xml, yaml, json or whatever. Now, YAML has quite a few shortcomings compared to JSON (if you don't believe me, look at its handling of the string no, discussed on HN), so, at least to me, it's obvious why JSON won. SOAP, don't get me started on that, it's worth less than XML, protobuf is more efficient but less portable, etc.
      - layer8 1y ago
        JSON won because it’s what JavaScript in browsers understands natively. That’s also the reason why JSON even exists in the first place.
upghost 1y ago
So I'm in the "MCP is probably not a great idea" camp but I couldn't say "this is how it SHOULD be done", and the author makes great criticisms but falls short of actual suggestions. I'm assuming the author is not seriously recommending we go back to SOAP and I've never heard of CORBA. I've heard of gRPC but I can't tell if the author is saying it is good or bad. Also Erlang uses RPCs for pretty much all "synchronous" interactions but it's pretty minimal in terms of ceremony. Seems pretty reliable. So this is a serious question because hand rolling "40 years" of best practices seems hard, what should we be using for RPC?
- zaphar 1y ago
  To answer your serious questions, gRPC is actually not a bad choice if you are making at the beginning of your project. Migrating over to it is going to be a challenge if you were using something else because it's pretty opinionated but if you have a clean sheet that's what I would use. Cap-n-Proto or Thrift are also probably good choices. These are all solid RPC frameworks that give you everything you need for that out of the box at the expense of more complicated builds.
SillyUsername 1y ago
MCP is flawed but it learnt one thing correctly from years of RPC - complexity is the biggest time sink and holds back adoption in deference to simpler competing standards (cf XML vs JSON) - SOAP - interop needs support of DOC or RPC based between systems, or a combination, XML and schemas are also horribly verbose. - CORBA - libraries and framework were complex, modern languages at the time avoided them in deference to simpler standards (e.g. Java's Jini) - GPRC - designed for speed, not readability, requires mappings. It's telling that these days REST and JSON (via req/resp, webhooks, or even streaming) are the modern backbone of RPC. The above standards either are shoved aside or for GPRC only used where extreme throughput is needed. Since REST and JSON are the plat du jour, MCP probably aligns with that design paradigm rather than the dated legacy protocols.
- w10-1 1y ago
  > these days REST and JSON (via req/resp, webhooks, or even streaming) are the modern backbone of RPC No, they're the medium of the web. The author is specifically addressing enterprise integration into business workflows - not showing stuff in a browser.
  - SillyUsername 1y ago
    How is this browser specific or mentioned to be browser? The technologies can be purely "enterprise integration" of backend services. When was swagger (openapi) for example forbidden to be used for RPC? E.g. an endpoint that doesn't just support a crud op but take an event with an operation to execute?
cnst 1y ago
I think this article is missing the point that MCP is simply using the mainstream building blocks that have already regressed from what we've had previously, namely, JSON in place of proper RCP. The ISO8601 v Unix epoch example seems very weak to me. I'd certainly expect any model to be capable of distinguishing between these things, so, it doesn't seem like a big deal that either one would be allowed in a JSON. Honestly, my view that nothing of value ever gets published on medium, is strongly reinforced here.
- cratermoon 1y ago
  > is simply using the mainstream building blocks that have already regressed from what we've had previously, namely, JSON in place of proper RCP. But why did the designers make that choice when they had any of half a dozen other RCP protocols to choose from? > The ISO8601 v Unix epoch example seems very weak to me. I'd certainly expect any model to be capable of distinguishing between these things What about the medical records issue? How is the model to distinguish a weight in kgs from one in pounds?
  - cnst 1y ago
    Why would a hype protocol use outdated concepts instead of the hype JSON? Wouldn't medical records actually be better in JSON, because the field could expressly have "kg" or "lb" suffix within the value of the field itself, or even in the name of the field, like "weight-in-kg" or "weight-in-lb"? This is actually the beauty of JSON compared other formats where these things may end up being just a unitless integer. The biggest problem with medical data would probably remain the human factor, where regardless of the format used by the machines and by MCP, the underlying data may already be incorrect or not coded properly, so, if anything, AI would likely have a better chance of interpreting the data correctly than the API provider blindly mislabelling unitless data.
    - cratermoon 1y ago
      > This is actually the beauty of JSON compared other formats where these things may end up being just a unitless integer. A field name doesn't turn an integer field into a unit of anything. Suffixing a unit as part of the value only makes the field stringly-typed an complicates parsing. BTW weight can take fractional values. That might not matter much for a 125kg adult, but it certainly matters for a newborn weighing 3.1kg. And I bring up weight because I personally identified a unit conversion bug in a well-known medical records suite where a weight measured in pounds was displayed as kilograms. A dose of opioids sufficient to relieve traumatic pain in a 125kg person would kill someone who weighs 125lb. Medical record software is not in the move-fast-break-things category.
lowbloodsugar 1y ago
MCP is what we needed right now, and what most people will need forever. Some of us will need more so we’ll write it.
ramoz 1y ago
Many great points. I think we are thinking about MCP the wrong way. The greater problem is industry misunderstanding and misalignment with what agents are and where they are headed. Web platforms of the world believe agents will be embedded in networked distributed infrastructure. So we should ship an MCP platform in our service mesh for all of the agents running in containers to connect to. I think this is wrong, and continues to be butchered as the web pushes a hard narrative that we need to enable web-native agents & their sdks/frameworks that deploy agents as conventional server applications. These are not agents nor the early evolutionary form of them. Frontier labs will be the only providers of the actual agentic harnesses. And we are rapidly moving to computer use agents - MCP servers were intended to serve as single instance deployments for single harnesses. ie. a single mcp server on my desktop for my Claude Desktop.
- Eisenstein 1y ago
  Exactly. The problem isn't that MCP is poorly designed for enterprise uses, it is that LLMs are being used for things where they are not appropriate. > In financial services, this means a trading AI could misinterpret numerical types and execute trades with the wrong decimal precision. If you are letting an LLM execute trades with no guardrails then it is a ticking time bomb no matter what protocol you use for the tool calls. > When an AI tool expects an ISO-8601 timestamp but receives a Unix epoch, the model might hallucinate dates rather than failing cleanly. If your process breaks because of a hallucinated date -- don't use an LLM for it.
jongjong 1y ago
The stuff about the utility of machine-readable Web Service Description Language got me rolling my eyes. WSDL is just pure nonsense. The idea that software would need to decide which API endpoints it needs on its own, is just profoundly misguided... Literally nobody and nothing ever reads the WSDL definitions; it's just poor man's documentation, at best. LLMs only reinforce the idea that WSDL is a dumb idea because it turns out that even the machines don't care for your 'machine-friendly' format and actually prefer human-friendly formats. Once you have an MPC tool working with a specific JSON API, it will keep working unless the server makes breaking changes to the API while in production which is terrible practice. But anyway, if you use a server, it means you trust the server. Client-side validation is dumb; like people who need to put tape over their mouths because they don't trust themselves to follow through on their diet plans.
- layer8 1y ago
  WSDLs are routinely used to generate the language bindings for the SOAP actions. WSDL being language-agnostic ensures that bindings in different languages, and/on the client vs the server side, are consistent with each other. WSDLs being available from the servers allows (a) clients to validate the requests they make before sending them to the server, and (b) developers (or in principle even AI) with access to the server to create a client without needing further out-of-band specifications.
  - jongjong 1y ago
    I think this is unwise. There are a lot of things that clients need to take into account which cannot be described by WSDLs (e.g. timing related or language specific considerations which require careful thinking through). I don't buy this idea that code should be generated automatically without a human involved (at least as a reviewer). I also don't buy the idea that clients should validate their requests before sending to the server. The client's code should trust itself. I object to any idea of code (or any entity) not trusting itself. That is a flawed trust model.
  - zaphar 1y ago
    > WSDL being language-agnostic ensures that bindings in different languages, and/on the client vs the server side, are consistent with each other. In theory. In reality java could talk to java. M$ stuff could talk to other M$ stuff. And pretty much everyone else was left out in the cold. consistent cross language interop never actually happened despite the claims that it would.
holografix 1y ago
Author disregards why none of these technologies are relevant in the modern web. Sure, they might still find themselves in highly regulated industries where risk avoidance trumps innovation everyday, all day. MCP is for _the web_ , it started with stdio only because Anthropic was learning lessons from building Claude Code. Author also seems to expect that the result from MCP tool usage will feed directly to an LLM. This is preposterous and a recipe for disaster. Obviously you’d validade structured response against a schema, check for harmful content, etc etc.
- desolate_muffin 1y ago
  I am not sure what you mean. Stateless RPCs, cache controls, client-side typing, tracing/observability, and bidirectional streaming are all things that strike me as very relevant to the modern web for all but the smallest of toy projects, let alone projects in serious engineering organizations. > Author also seems to expect that the result from MCP tool usage will feed directly to an LLM Isn't this exactly what MCP is for? Most tools I've come across are to feed context from other sources directly to the LLM. I believe this is the most common use-case for the protocol.
- zaphar 1y ago
  So far every single use of mcp's I've seen in the wild is that the response is sent straight to the LLM without doing any validation. Seems reasonable for the Author to expect that when it's exactly what is happening.
0xbadcafebee 1y ago
Am I the only person who thinks it's a bad idea for a hallucinating AI to have anything to do with financial services, healthcare, or manufacturing? Doesn't really matter what the RPC protocol looks like if the meat and potatoes of the tech will confidently make shit up. You can't hand-wave this away by saying "oh it's a reasoning AI". Albert Einstein may be real smart, but it's still a bad idea to take financial advice from him when he drops acid.
tarun_anand 1y ago
Very interesting... I have been contributing with the exact same interoperability issues to the MCP Community (Anthropic Google etc) https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1145 https://github.com/modelcontextprotocol/modelcontextprotocol... The Python Bindings PR is here modelcontextprotocol/rust-sdk#172 The Typescript Bindings PR is here modelcontextprotocol/rust-sdk#183 MCP Bench at https://github.com/unimcp/mcpbench https://github.com/unimcp/mcpbench
krawczstef 1y ago
I agree with this post. Otherwise the larger picture is that MCP is a land grab for building an eco-system around integrations to get access to data. Your LLM agent is not valuable if it can't access things for you... and from a market perspective enterprise pays a lot for this stuff already, and yes MCP is not thought out at all for Enterprise really... At least thankfully they added stateless connections to the spec...
bionhoward 1y ago
gRPC might be great tech but it’s not accessible enough to have caught on. Those in charge didn’t do enough to make it widely usable by everyone. MCP started from an accessibility direction, which is why it’s catching on. Headaches are inevitable, but don’t network effects often dominate technological superiority?
mannyv 1y ago
Once you talk about CORBA being any kind of representation of something good you're done. CORBA did pretty much everything wrong, which makes it a great anti-example. Automatic client generation? Fuck that.
sporkland 1y ago
While I'm sure some of these predictions will come true and we'll have to layer some additional prompting and context engineering in here... MCP seems to be the ultimate inheritor of ReSTful architectural practices as described by Roy fielding but instead of needing a human on the other end to interact with links (hateos) you can have an LLM bridging the gap between user intent and concrete subsequent calls. So many issues around versioning and the fragility here will likely start to disappear. Like embeddings I'd put a bet on this being one of the major unexpected architectural improvements that lets us build our scaffolding a bit higher before it collapses to use a Steve Jobs analogy, LLM's at key glue points to create looser coupling.
snakepit 1y ago
Incredibly helpful. This article helped me to identify significant fundamental shortcomings in my first attempt to design an agent/tool arbitration protocol: https://github.com/nshkrdotcom/ALTAR https://github.com/nshkrdotcom/ALTAR

409 points by yodon 1y ago

IMO worrying about type-safety in the protocol when any string field in the reply can prompt-inject the calling LLM feels like putting a band-aid on a decapitation, but YMMV

ComputerGuru 1y ago
They’re 100% orthogonal issues.

gjsman-1000 1y ago

… or we’ll just invent MCP 2.0. On that note; some of these “best practices” arguably haven’t worked out. “Be conservative with what you send, liberal with what you receive” has turned even decent protocols into a dumpster fire, so why keep the charade going?

rcarmo 1y ago
I’d rather we ditched MCP and used something that could leverage Swagger instead….
- bharatgel 1y ago
  UTCP ? https://utcp.io/ https://utcp.io/
jmull 1y ago
Right... Failed protocols such as TCP adopted Postel's law as a guiding principle, and we all know how that worked out!
- dragonwriter 1y ago
  A generalized guiding principle works in one particular use case, so this proves it is a good generalized guiding principle?
- gjsman-1000 1y ago
  Survivor’s bias.
  - jmull 1y ago
    Circular argument.
- oblio 1y ago
  TCP is basically the only example of that principle that works and it only works because the protocol is low level and constrained. Almost all the implementations of that principle from close to the app layer are abominations we're barely keeping running.

mockingloris 1y ago

I read this thrice: ...When OpenAI bills $50,000 for last month’s API usage, can you tell which department’s MCP tools drove that cost? Which specific tool calls? Which individual users or use cases?... It seems to be a game of catch up for most things AI. That said, my school of thought is that certain technologies are just too big for them to be figured out early on - web frameworks, blockchain, ... - the gap starts to shrink eventually. With AI, we'll just have to keep sharing ideas and caution like you have here. Such very interesting times we live in.

zorked 1y ago

CORBA emerged in 1991 with another crucial insight: in heterogeneous environments, you can’t just “implement the protocol” in each language and hope for the best. The OMG IDL generated consistent bindings across C++, Java, Python, and more, ensuring that a C++ exception thrown by a server was properly caught and handled by a Java client. The generated bindings guaranteed that all languages saw identical interfaces, preventing subtle serialization differences. Yes, CORBA was such a success.

antonymoose 1y ago
To be charitable, you can look at a commercially unsuccessful project and appreciate its technical brilliance.
- drweevil 1y ago
  Just an interesting bit of trivia, the Large Hadron Collider uses/used (don't know if it still does) CORBA in its distributed control system. (On the control system I worked on we use Sun RPC, which was fine as things go but doesn't have the language support that CORBA has. We used a separate SOAP interface to the system to allow for languages such as Python. Today I'd use gRPC, or the BEAM.) On a more general note, I see in many critical comments here what I perceive to be a category error. Using JSON to pass data between web client and server, even in more complex web apps, is not the same thing as supporting two-way communications between autonomous software entities that are tasked to do something, perhaps something critical. There could be millions of these exchanges in some arbitrarily short time period, thus any possibility of errors is multiplied accordingly, and the effect any error could cascade if it does not fail early. I really don't believe this is a case where "worse is better." To use an analogy, yes everyday English is a versatile language that works great for most use cases; but when you really need to nail things down, with no tolerance for ambiguity, you get legalese or some other jargon. Or CORBA, or gRPC, etc.
  - otterley 1y ago
    > but when you really need to nail things down, with no tolerance for ambiguity, you get legalese If only that were true. Litigation happens every single day over the meanings of contracts and laws that were drafted by well-trained and experienced attorneys.

abtinf 1y ago

I wish someone would write a clear, crisp explanation for why MCP is needed over simply supporting swagger or proto.

nikanj 1y ago
MCP is new
dragonwriter 1y ago
OpenAPI (or its Swagger predecessor) or Proto (I assume by this you mean protobuf?) don't cover what MCP does. It could have layered over them instead of using JSON-RPC, but I don't see any strong reason why they would be better than JSON-RPC as the basis (Swagger has communication assumptions that don't work well with MCP's local use case; protobuf doesn't cover communication at all and would require additional consideration in the protocol layered over it.) You'd still need basically the entire existing MCP spec to cover the use cases if it replaced JSON-RPC with Swagger or protobuf, plus additional material to cover the gaps and complications that that switch would involve.
- vineyardmike 1y ago
  Proto has a full associated spec (gRPC) on communication protocols and structured definitions for them. MCP could easily have built upon these and gotten a lot “for free”. Generally gRPC is better than JsonRPC (see below). I agree that swagger leaves a lot unplanned. I disagree about the local use case because (1) we could just run local HTTP servers easily and (2) I frankly assume the future of MCP is mostly remote. Returning back to JSON-RPC, it’s a poorly executed RPC protocol. Here is an excellent HackerNews thread on it, but the TLDR is parsing JSON is expensive and complex, we have tons of tools (eg load balancers) that make modern services, and making those tools parse json is very expensive. Many people in the below thread mention alternative ways to implement J-RPC but that depends on new clients. https://news.ycombinator.com/item?id=34211796 https://news.ycombinator.com/item?id=34211796
- SahAssar 1y ago
  I don't understand what MCP gives that a REST API with a OpenAPI definition would not give?

self_awareness 1y ago

What's new? - Electron disregards 40 years of best deployment practices, - Web disregards 40 years of best GUI practices, - Fast CPUs and lots of RAM disregards 40 years of best software optimization techniques, there are probably many more examples.

xg15 1y ago
Yeah, and all three have evidently made software more shitty. More profitable and easier to develop, sure, but also much more unpleasant to use.
- wredcoll 1y ago
  vim is in fact easier to use than vi. windows 10 is easier to use than windows 95. osx is easier to use than mac.. whatever they named their old versions. It goes on and on. I can have 50 browser tabs open at the same time, each one hosting a highly complicated app, ranging from media playback to chat rooms to custom statistical calculators. I don't need to install anything for any of these apps, I just type in a short string in my url bar. And they all just work, at the same time. Things are in fact better now.
  - 0xbadcafebee 1y ago
    I have to keep buying a new computer every few years because software keeps getting slower. That machine still costs a thousand dollars, and my "low-end" internet connection now costs $100. My hypertext document viewer requires at least 8GB of RAM for normal use, with eight CPU cores. No new network protocol can exist without being tunneled over the hypertext document viewer's stateless application-layer network protocol. All of this so that I can click on a screen to read some text. The supercomputers in our pockets (that used to be telephones, but don't work well for that anymore) will let us run the programs that one of two companies allow us to run, which will run most apps... as long as the hardware is as recent as our laptops/desktops. Yes, we're very advanced. In the past 20 years, we have achieved... the same thing we had 20 years ago... only with more hardware requirements, programming languages, and frameworks. Today you can do anything... as long as it's on a web page, on recent hardware (and God help you if you haven't updated your software in the past month)

rickcarlino 1y ago

> SOAP, despite its verbosity, understood something that MCP doesn’t Unfortunately, no one understood SOAP back. (Additional context: Maintaining a legacy SOAP system. I have nothing good to say about SOAP and it should serve as a role model for no one)

SoftTalker 1y ago
I have found that any protocol whose name includes the word "Simple" is anything but. So waiting for SMCP to appear....
- divan 1y ago
  No, letter S in MCP is reserved for "Security")
- yjftsjthsd-h 1y ago
  I dunno, SMTP wasn't bad last time I had to play with it. In actual use it wasn't entirely trivial, but most of that happened at layers that weren't really the mail transfer protocol's fault (SPF et al.). Although, I'm extremely open to that being one exception in flood of cases where you are absolutely correct:)
- sirtaj 1y ago
  I recall two SOAP-based services refusing to talk to each other because one nicely formatted the XML payload and the other didn't like that one bit. There is a lot we lost when we went to json but no, I don't look back at that stuff with any fondness.
cyberax 1y ago
This is a very hilarious but apt SOAP description: https://harmful.cat-v.org/software/xml/soap/simple https://harmful.cat-v.org/software/xml/soap/simple And I actually like XML-based technologies. XML Schema is still unparalleled in its ability to compose and verify the format of multiple document types. But man, SOAP was such a beast for no real reason. Instead of a simple spec for remote calls, it turned into a spec that described everything and nothing at the same time. SOAP supported all kinds of transport protocols (SOAP over email? Sure!), RPC with remote handles (like CORBA), regular RPC, self-describing RPC (UDDI!), etc. And nothing worked out of the box, because the nitty-gritty details of authentication, caching, HTTP response code interoperability and other "boring" stuff were just left as an exercise to the reader.

btown 1y ago

If you want the things mentioned in this article, I highly recommend looking at https://github.com/modelcontextprotocol/modelcontextprotocol/issues https://github.com/modelcontextprotocol/modelcontextprotocol... and https://modelcontextprotocol.io/community/sep-guidelines https://modelcontextprotocol.io/community/sep-guidelines and participating in the specification process. Point-by-point for the article's gripes: - distributed tracing/telemetry - open discussion at https://github.com/modelcontextprotocol/modelcontextprotocol/issues/246 https://github.com/modelcontextprotocol/modelcontextprotocol... - structured tool annotation for parallelizability/side-effects/idempotence - this actually already exists at https://modelcontextprotocol.io/specification/2025-06-18/schema#toolannotations https://modelcontextprotocol.io/specification/2025-06-18/sch... but it's not well documented in https://modelcontextprotocol.io/specification/2025-06-18/server/tools#tool https://modelcontextprotocol.io/specification/2025-06-18/ser... - someone should contribute to improving this! - a standardized way in which the costs associated with an MCP tool call can be communicated to the MCP Client and reported to central tracking - nothing here I see, but it's a really good idea! - serialization issues e.g. "the server might report a date in a format unexpected by the client" - this isn't wrong, but since the consumer of most tool responses is itself an LLM, there's a fair amount of mitigation here. And in theory an MCP Client can use an LLM to detect under-specified/ambiguous tool specifications, and could surface these issues to the integrator. Now, I can't speak to the speed at which Maintainers and Core Maintainers are keeping up with the community's momentum - but I think it's meaningful that the community has momentum for evolving the specification! I see this post in a highly positive light: MCP shows promise because you can iterate on these kinds of structured annotations, in the context of a community that is actively developing their MCP servers. Legacy protocols aren't engaging with these problems in the same way.

cratermoon 1y ago
I feel like the article addressed this response in the section titled 'The “Just Use This Library” Trap'
- btown 1y ago
  These aren’t third-party libraries, these are RFP processes for adding to the official protocol, and standardizing the semantics of new fields and data types. A world of difference IMO.

calvinmorrison 1y ago

MCP, aka, WSDL for REST

SigmundA 1y ago
I thought that was OpenAPI?
ElectricalUnion 1y ago
Web Application Description Language is "WSDL for REST".

zwaps 1y ago

The author seems to fundamentally misunderstand how MCPs are going to be used and deployed. This is really obvious when they talk about tracing and monitoring, which seem to be the main points of criticism anyway. They bemoan that they cant trace across MCP calls, assuming somehow there would be a person administering all the MCPs. Of course each system has tracing in whatever fashion fits its system. They are just not the same system, nor owned by the same people let alone companies. Same as monitoring cost. Oh, you can’t know who racked up the LLM costs? Well of course you can, these systems are already in place and there are a million of ways to do this. It has nothing to do with MCP. Reading this, I think its rather a blessing to start fresh and without the learnings of 40 years of failed protocols or whatever

oblio 1y ago
> without the learnings of 40 years of failed protocols or whatever 1. Lessons. 2. Fairly sure all of Google is built on top of protobuf.

ComplexSystems 1y ago

I thought this article was going to be a bunch of security theater nonsense - maybe the relatively bland title - but after reading I found it to be incredibly insightful, particularly this: > MCP discards this lesson, opting for schemaless JSON with optional, non-enforced hints. Type validation happens at runtime, if at all. When an AI tool expects an ISO-8601 timestamp but receives a Unix epoch, the model might hallucinate dates rather than failing cleanly. In financial services, this means a trading AI could misinterpret numerical types and execute trades with the wrong decimal precision. In healthcare, patient data types get coerced incorrectly, potentially leading to wrong medication dosing recommendations. Manufacturing systems lose sensor reading precision during JSON serialization, leading to quality control failures. Having worked with LLMs every day for the past few years, it is easy to see every single one of these things happening. I can practically see it playing out now: there is some huge incident of some kind, in some system or service with an MCP component somewhere, with some elaborate post-mortem revealing that some MCP server somewhere screwed up and output something invalid, the LLM took that output and hallucinated god knows what, its subsequent actions threw things off downstream, etc. It would essentially be a new class of software bug caused by integration with LLMs, and it is almost sure to happen when you combine it with other sources of bug: human error, the total lack of error checking or exception handling that LLMs are prone to (they just hallucinate), a bunch of gung-ho startups "vibe coding" new services on top of the above, etc. I foresee this being followed by a slew of Twitter folks going on endlessly about AGI hacking the nuclear launch codes, which will probably be equally entertaining.

throwawaymaths 1y ago
i mean isnt all this stuff up to the mcp author to return a reasonable error to the agent and ask for it to repeat the call with amendments to the json?
- dotancohen 1y ago
  Yes. And this is where culture comes in. The culture of discipline of the C++ and the JavaScript communities are at extreme odds of the spectrum. The concern here is that the culture of interfacing with AI tools, such as MCP, is far closer to the discipline of the JavaScript community than to the C++ community.

BLanen 1y ago

As I've been saying. MCP is not a protocol. It doesn't protocolize anything of use. It's just "here's some symbols, do with them whatever you want.", leaving it there but then advertising that as a feature of its universality. It provides almost just as much of a protocol as TCP, but rebuild on 5 OSI layers, again. It's not a security issue, it's a ontological issue.

lsaferite 1y ago
And yet, TCP powers the Internet. That being said. MCP as a protocol has a fairly simple niche. Provide context that can be fed to a model to perform some task. MCP covers the discovery process around presenting those tools and resources to an Agent in a standardized manner. An it includes several other aspects that are useful in this niche. Things like "sampling" and "elicitations". Is it perfect? Not at all. But it's a step in the right direction. The crowd saying "just point it at an OpenAPI service" does not seem to fully understand the current problem space. Can many LLMs extract meaning from un-curated API response messages? Sure. But they are also burning up context holding junk that isn't needed. Part of MCP is the acknowledgement that general API responses aren't the right way to feed the model the context it needs. MCP is supposed to be taking a concrete task, performing all the activities need to gather the info or affect the change, then generate clean context meant for the LLM. If you design an OpenAPI service around those same goals, then it could easily be added to an Agent. You'd still need to figure out.all the other aspects, but you'd be close. But at that point you aren't pointing an Agent at a random API, you're pointing it at a purpose made API. And then you have to wonder, why not something like MCP that's designed for that purpose from the start? I'll close by saying there are an enormous number of MCP Servers out there that are poorly written, thin wrappers on general APIs, or have some other bad aspects. I attribute a lot of this to the rise in AI Coding Agents allowing people with poor comprehension of the space enabling them to crank out this... Noise. There are also great examples of MCP Servers to be found. They are the ones that have thoughtful designs, leverage the spec fully, and provide nice clean context for the Agent to feed to the LLM. I can envision a future where we can simply point an agent at a series of OpenAPI services and the agent uses it's models to self-assemble what we consider the MCP server today. Basically it would curate accessing the APIs into a set of focused tools and the code needed to generate the final context. That's not quite where we are today. It's likely not far off though.

dragonwriter 1y ago

> MCP discards this lesson, opting for schemaless JSON with optional, non-enforced hints. Actually, MCP uses a normative TypeScript schema (and, from that, an autogenerated JSON Schema) for the protocol itself, and the individual tool calls also are specified with JSON Schema. > Type validation happens at runtime, if at all. That's not a consequence of MCP "opting for schemaless JSON" (which it factually does not), that's, for tool calls, a consequence of MCP being a discovery protocol where the tools, and thus the applicable schemas, are discovered aruntime. If you are using MCP as a way to wire up highly-static components, you can do discovery against the servers once they are wired up, statically build the clients around the defined types, and build your toolchain to raise errors if the discovery responses change in the future. But that's not really the world MCP is built for. Yes, that means that the toolchain needs, if it is concerned about schema enforcement, use and apply the relevant schemas at runtime. So, um, do that?

GeneralMayhem 1y ago

> MCP promises to standardize AI-tool interactions as the “USB-C for AI.” Ironically, it's achieved this - but that's an indictment of USB-C, not an accomplishment of MCP. Just like USB-C, MCP is a nigh-universal connector with very poorly enforced standards for what actually goes across it. MCP's inconsistent JSON parsing and lack of protocol standardization is closely analogous to USB-C's proliferation of cable types (https://en.wikipedia.org/wiki/USB-C#Cable_types https://en.wikipedia.org/wiki/USB-C#Cable_types); the superficial interoperability is a very leaky abstraction over a much more complicated reality, which IMO is worse than just having explicitly different APIs/protocols.

cnst 1y ago
I'd like to add that the culmination of USB-C failure was Apple's removal of USB-A ports from the latest M4 Mac mini, where an identical port on the exact same device, now has vastly different capabilities, opaque to the final user of the system months past the initial hype on the release date. Previously, you could reasonably expect a USB-C on a desktop/laptop of an Apple Silicon device, to be USB4 40Gbps Thunderbolt, capable of anything and everything you may want to use it for. Now, some of them are USB3 10Gbps. Which ones? Gotta look at the specs or tiny icons, I guess? Apple could have chosen to have the self-documenting USB-A ports to signify the 10Gbps limitation of some of these ports (conveniently, USB-A is limited to exactly 10Gbps, making it perfect for the use-case of having a few extra "low-speed" ports at very little manufacturing cost), but instead, they've decided to further dilute the USB-C brand. Pure innovation! With the end user likely still having to use a USB-C to USB-A adapters anyways, because the majority of thumb drives, keyboards and mice, still require a USB-A port — even the USB-C ones that use USB-C on the kb/mice itself. (But, of course, that's all irrelevant because you can always spend 2x+ as much for a USB-C version of any of these devices, and the fact that the USB-C variants are less common or inferior to USB-A, is of course irrelevant when hype and fanaticism are more important than utility and usability.)
- mafuy 1y ago
  As far as I know, please correct me if I'm wrong, the USB spec does not allow USB-C to C cables at all. The host side must always be type A. This avoids issues like your cellphone power supplying not just your headphones but also your laptop.

zombiwoof 1y ago

[dead]

dang 1y ago
We've banned this account for posting unsubstantive comments and ignoring our requests to stop. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.

ipython 1y ago

I am torn. I see this argument and intellectually agree with it (that interfaces need to be more explicit). However it seems that every time there is a choice between “better” design and “good enough”, the “good enough” wins handily. Multics vs Unix, xml based soap vs json based rest apis, xhtml’s failure, javascript itself, … I could keep going on. So I’ve resigned myself to admitting that we are doomed to reimplement the “good enough” every time, and continue to apply bandaid after bandaid to gradually fix problems after we rediscover them, slowly.

deleted 1y ago
[deleted]
antonvs 1y ago
It's the old Worse is Better observation, which is 36 years old now: https://en.m.wikipedia.org/wiki/Worse_is_better https://en.m.wikipedia.org/wiki/Worse_is_better It's been confirmed over and over since then. And I say that as someone who naturally gravitates towards "better" solutions.
- xpe 1y ago
  It depends on system boundaries. If an actor doesn't face the consequences of a decision, but another does, that's an externality. When externalities are present, it is often rational (narrowly speaking) for an actor to accept designs that look awful from a broader perspective. In other words, many technical problems flow rather predictably from decision-making boundaries that don't internalize the externalities. Ever heard someone say "if you care about X, run for office"? The same applies to technology. If one cares about good designs, one must promote organizational and societal structures that actually have a fighting chance at bringing those about. The days of nerds and hackers not caring about broader dynamics and structures are long gone. Sitting back and letting the business folks have control is fine if you want them to optimize for the existing incentives. But if you want to change the rules of the game, you gotta jump in at the deep end.
cookiengineer 1y ago
Obligatory minute of silence for xforms 2.0 The world we could have lived in... working web forms validations, working microdata...

draw_down 1y ago

[dead]

mac-mc 1y ago

You're missing the most significant lesson of all that MCP knew. That all of those featureful things are way too overcomplicated for most places, so they will gravitate to the simple thing. It's why JSON over HTTP blobs is king today. I've been on the other side of high-feature serialization protocols, and even at large tech companies, something like migrating to gRPC is a multi-year slog that can even fail a couple of times because it asks so much of you. MCP, at its core, is a standardization of a JSON API contract, so you don't have to do as much post-training to generate various tool calling style tokens for your LLM.

prerok 1y ago
What are HTTP blobs? I think you meant that is why JSON won instead of XML?
- mac-mc 1y ago
  JSON-over-HTTP blobs. Or blobs of schemaless json. Not just XML, but a lot of other serialization formats and standards, like SOAP, protobuf in many cases, yaml, REST, etc. People say REST won, but tell me how many places actually implement REST or just use it as a stand-in term for casual JSON blobs to HTTP URLs?
  - prerok 1y ago
    So, I just looked it up, thinking I might have overlooked something but, at least according to wikipedia, REST does not prescribe the format of the data transferred. So, I don't understand why you are comparing REST to xml, yaml, json or whatever. Now, YAML has quite a few shortcomings compared to JSON (if you don't believe me, look at its handling of the string no, discussed on HN), so, at least to me, it's obvious why JSON won. SOAP, don't get me started on that, it's worth less than XML, protobuf is more efficient but less portable, etc.
    - layer8 1y ago
      JSON won because it’s what JavaScript in browsers understands natively. That’s also the reason why JSON even exists in the first place.

upghost 1y ago

So I'm in the "MCP is probably not a great idea" camp but I couldn't say "this is how it SHOULD be done", and the author makes great criticisms but falls short of actual suggestions. I'm assuming the author is not seriously recommending we go back to SOAP and I've never heard of CORBA. I've heard of gRPC but I can't tell if the author is saying it is good or bad. Also Erlang uses RPCs for pretty much all "synchronous" interactions but it's pretty minimal in terms of ceremony. Seems pretty reliable. So this is a serious question because hand rolling "40 years" of best practices seems hard, what should we be using for RPC?

zaphar 1y ago
To answer your serious questions, gRPC is actually not a bad choice if you are making at the beginning of your project. Migrating over to it is going to be a challenge if you were using something else because it's pretty opinionated but if you have a clean sheet that's what I would use. Cap-n-Proto or Thrift are also probably good choices. These are all solid RPC frameworks that give you everything you need for that out of the box at the expense of more complicated builds.

SillyUsername 1y ago

MCP is flawed but it learnt one thing correctly from years of RPC - complexity is the biggest time sink and holds back adoption in deference to simpler competing standards (cf XML vs JSON) - SOAP - interop needs support of DOC or RPC based between systems, or a combination, XML and schemas are also horribly verbose. - CORBA - libraries and framework were complex, modern languages at the time avoided them in deference to simpler standards (e.g. Java's Jini) - GPRC - designed for speed, not readability, requires mappings. It's telling that these days REST and JSON (via req/resp, webhooks, or even streaming) are the modern backbone of RPC. The above standards either are shoved aside or for GPRC only used where extreme throughput is needed. Since REST and JSON are the plat du jour, MCP probably aligns with that design paradigm rather than the dated legacy protocols.

w10-1 1y ago
> these days REST and JSON (via req/resp, webhooks, or even streaming) are the modern backbone of RPC No, they're the medium of the web. The author is specifically addressing enterprise integration into business workflows - not showing stuff in a browser.
- SillyUsername 1y ago
  How is this browser specific or mentioned to be browser? The technologies can be purely "enterprise integration" of backend services. When was swagger (openapi) for example forbidden to be used for RPC? E.g. an endpoint that doesn't just support a crud op but take an event with an operation to execute?

cnst 1y ago

I think this article is missing the point that MCP is simply using the mainstream building blocks that have already regressed from what we've had previously, namely, JSON in place of proper RCP. The ISO8601 v Unix epoch example seems very weak to me. I'd certainly expect any model to be capable of distinguishing between these things, so, it doesn't seem like a big deal that either one would be allowed in a JSON. Honestly, my view that nothing of value ever gets published on medium, is strongly reinforced here.

cratermoon 1y ago
> is simply using the mainstream building blocks that have already regressed from what we've had previously, namely, JSON in place of proper RCP. But why did the designers make that choice when they had any of half a dozen other RCP protocols to choose from? > The ISO8601 v Unix epoch example seems very weak to me. I'd certainly expect any model to be capable of distinguishing between these things What about the medical records issue? How is the model to distinguish a weight in kgs from one in pounds?
- cnst 1y ago
  Why would a hype protocol use outdated concepts instead of the hype JSON? Wouldn't medical records actually be better in JSON, because the field could expressly have "kg" or "lb" suffix within the value of the field itself, or even in the name of the field, like "weight-in-kg" or "weight-in-lb"? This is actually the beauty of JSON compared other formats where these things may end up being just a unitless integer. The biggest problem with medical data would probably remain the human factor, where regardless of the format used by the machines and by MCP, the underlying data may already be incorrect or not coded properly, so, if anything, AI would likely have a better chance of interpreting the data correctly than the API provider blindly mislabelling unitless data.
  - cratermoon 1y ago
    > This is actually the beauty of JSON compared other formats where these things may end up being just a unitless integer. A field name doesn't turn an integer field into a unit of anything. Suffixing a unit as part of the value only makes the field stringly-typed an complicates parsing. BTW weight can take fractional values. That might not matter much for a 125kg adult, but it certainly matters for a newborn weighing 3.1kg. And I bring up weight because I personally identified a unit conversion bug in a well-known medical records suite where a weight measured in pounds was displayed as kilograms. A dose of opioids sufficient to relieve traumatic pain in a 125kg person would kill someone who weighs 125lb. Medical record software is not in the move-fast-break-things category.

lowbloodsugar 1y ago

MCP is what we needed right now, and what most people will need forever. Some of us will need more so we’ll write it.

ramoz 1y ago

Many great points. I think we are thinking about MCP the wrong way. The greater problem is industry misunderstanding and misalignment with what agents are and where they are headed. Web platforms of the world believe agents will be embedded in networked distributed infrastructure. So we should ship an MCP platform in our service mesh for all of the agents running in containers to connect to. I think this is wrong, and continues to be butchered as the web pushes a hard narrative that we need to enable web-native agents & their sdks/frameworks that deploy agents as conventional server applications. These are not agents nor the early evolutionary form of them. Frontier labs will be the only providers of the actual agentic harnesses. And we are rapidly moving to computer use agents - MCP servers were intended to serve as single instance deployments for single harnesses. ie. a single mcp server on my desktop for my Claude Desktop.

Eisenstein 1y ago
Exactly. The problem isn't that MCP is poorly designed for enterprise uses, it is that LLMs are being used for things where they are not appropriate. > In financial services, this means a trading AI could misinterpret numerical types and execute trades with the wrong decimal precision. If you are letting an LLM execute trades with no guardrails then it is a ticking time bomb no matter what protocol you use for the tool calls. > When an AI tool expects an ISO-8601 timestamp but receives a Unix epoch, the model might hallucinate dates rather than failing cleanly. If your process breaks because of a hallucinated date -- don't use an LLM for it.

jongjong 1y ago

The stuff about the utility of machine-readable Web Service Description Language got me rolling my eyes. WSDL is just pure nonsense. The idea that software would need to decide which API endpoints it needs on its own, is just profoundly misguided... Literally nobody and nothing ever reads the WSDL definitions; it's just poor man's documentation, at best. LLMs only reinforce the idea that WSDL is a dumb idea because it turns out that even the machines don't care for your 'machine-friendly' format and actually prefer human-friendly formats. Once you have an MPC tool working with a specific JSON API, it will keep working unless the server makes breaking changes to the API while in production which is terrible practice. But anyway, if you use a server, it means you trust the server. Client-side validation is dumb; like people who need to put tape over their mouths because they don't trust themselves to follow through on their diet plans.

layer8 1y ago
WSDLs are routinely used to generate the language bindings for the SOAP actions. WSDL being language-agnostic ensures that bindings in different languages, and/on the client vs the server side, are consistent with each other. WSDLs being available from the servers allows (a) clients to validate the requests they make before sending them to the server, and (b) developers (or in principle even AI) with access to the server to create a client without needing further out-of-band specifications.
- jongjong 1y ago
  I think this is unwise. There are a lot of things that clients need to take into account which cannot be described by WSDLs (e.g. timing related or language specific considerations which require careful thinking through). I don't buy this idea that code should be generated automatically without a human involved (at least as a reviewer). I also don't buy the idea that clients should validate their requests before sending to the server. The client's code should trust itself. I object to any idea of code (or any entity) not trusting itself. That is a flawed trust model.
- zaphar 1y ago
  > WSDL being language-agnostic ensures that bindings in different languages, and/on the client vs the server side, are consistent with each other. In theory. In reality java could talk to java. M$ stuff could talk to other M$ stuff. And pretty much everyone else was left out in the cold. consistent cross language interop never actually happened despite the claims that it would.

holografix 1y ago

Author disregards why none of these technologies are relevant in the modern web. Sure, they might still find themselves in highly regulated industries where risk avoidance trumps innovation everyday, all day. MCP is for _the web_ , it started with stdio only because Anthropic was learning lessons from building Claude Code. Author also seems to expect that the result from MCP tool usage will feed directly to an LLM. This is preposterous and a recipe for disaster. Obviously you’d validade structured response against a schema, check for harmful content, etc etc.

desolate_muffin 1y ago
I am not sure what you mean. Stateless RPCs, cache controls, client-side typing, tracing/observability, and bidirectional streaming are all things that strike me as very relevant to the modern web for all but the smallest of toy projects, let alone projects in serious engineering organizations. > Author also seems to expect that the result from MCP tool usage will feed directly to an LLM Isn't this exactly what MCP is for? Most tools I've come across are to feed context from other sources directly to the LLM. I believe this is the most common use-case for the protocol.
zaphar 1y ago
So far every single use of mcp's I've seen in the wild is that the response is sent straight to the LLM without doing any validation. Seems reasonable for the Author to expect that when it's exactly what is happening.

0xbadcafebee 1y ago

Am I the only person who thinks it's a bad idea for a hallucinating AI to have anything to do with financial services, healthcare, or manufacturing? Doesn't really matter what the RPC protocol looks like if the meat and potatoes of the tech will confidently make shit up. You can't hand-wave this away by saying "oh it's a reasoning AI". Albert Einstein may be real smart, but it's still a bad idea to take financial advice from him when he drops acid.

tarun_anand 1y ago

Very interesting... I have been contributing with the exact same interoperability issues to the MCP Community (Anthropic Google etc) https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1145 https://github.com/modelcontextprotocol/modelcontextprotocol... The Python Bindings PR is here modelcontextprotocol/rust-sdk#172 The Typescript Bindings PR is here modelcontextprotocol/rust-sdk#183 MCP Bench at https://github.com/unimcp/mcpbench https://github.com/unimcp/mcpbench

krawczstef 1y ago

I agree with this post. Otherwise the larger picture is that MCP is a land grab for building an eco-system around integrations to get access to data. Your LLM agent is not valuable if it can't access things for you... and from a market perspective enterprise pays a lot for this stuff already, and yes MCP is not thought out at all for Enterprise really... At least thankfully they added stateless connections to the spec...

bionhoward 1y ago

gRPC might be great tech but it’s not accessible enough to have caught on. Those in charge didn’t do enough to make it widely usable by everyone. MCP started from an accessibility direction, which is why it’s catching on. Headaches are inevitable, but don’t network effects often dominate technological superiority?

mannyv 1y ago

Once you talk about CORBA being any kind of representation of something good you're done. CORBA did pretty much everything wrong, which makes it a great anti-example. Automatic client generation? Fuck that.

sporkland 1y ago

While I'm sure some of these predictions will come true and we'll have to layer some additional prompting and context engineering in here... MCP seems to be the ultimate inheritor of ReSTful architectural practices as described by Roy fielding but instead of needing a human on the other end to interact with links (hateos) you can have an LLM bridging the gap between user intent and concrete subsequent calls. So many issues around versioning and the fragility here will likely start to disappear. Like embeddings I'd put a bet on this being one of the major unexpected architectural improvements that lets us build our scaffolding a bit higher before it collapses to use a Steve Jobs analogy, LLM's at key glue points to create looser coupling.

snakepit 1y ago

Incredibly helpful. This article helped me to identify significant fundamental shortcomings in my first attempt to design an agent/tool arbitration protocol: https://github.com/nshkrdotcom/ALTAR https://github.com/nshkrdotcom/ALTAR