Because it's about the MCP Host <-> LLM interaction. Not how a vanilla server and client communicate to each other and have done so for the last 5+ decades.
This really is not that hard to understand. The LLM must be "bootstrapped" with tool definitions and it must retain stable enough context to continue to call those tools into the future.
This will fail at some point, with any model. It will pretend to do a tool call, it will simply not do the tool call, or it will attempt to call a tool that does not exist, or any of the above or anything else not listed here. It is a statistical certainty.
I don't know why people are pretending MCP does something to fix this, or that MCP is special in anyway. It won't, and it's not.
Oh, so you're not talking about json validation inside the mcp server, you're talking about the contract between the LLM and the MCP server potentially changing. This is a valid issue the same as other APIs that must be written against, the same as you would with other external API connections. Mcp does not solve this correct, just the same as swagger does not solve it.
As for your comments on LLM pretending to do tool calls, sure. That's not what the original thread comments were discussing. There are ways to mitigate this with proper context and memory management but it is more advanced.
>That's not what the original thread comments were discussing. There are ways to mitigate this with proper context and memory management but it is more advanced.
That is what the original article is describing, and what the comments misunderstood or purposefully over-simplified, and extends it to being able to trace these issues across a large amount of calls/invocations at scale.
>MCP has none of this richness. No machine-readable contracts beyond basic JSON schemas means you can’t generate type-safe clients or prove to auditors that AI interactions follow specified contracts.
>MCP ignores this completely. Each language implements MCP independently, guaranteeing inconsistencies. Python’s JSON encoder handles Unicode differently than JavaScript’s JSON encoder. Float representation varies. Error propagation is ad hoc. When frontend JavaScript and backend Python interpret MCP messages differently, you get integration nightmares. Third-party tools using different MCP libraries exhibit subtle incompatibilities only under edge cases. Language-specific bugs require expertise in each implementation, rather than knowledge of the protocol.
>Tool invocations can’t be safely retried or load-balanced without understanding their side effects. You can’t horizontally scale MCP servers without complex session affinity. Every request hits the backend even for identical, repeated queries.
Somehow comments confused a server <-> client interaction which has been a non-issue for decades with making the rest of the "call stack" dependable. What leads to that level of confusion, I can only guess it's inexperience and religious zealotry.
It's also worth noting that certain commenters saying I "should" (I'm using this word on purpose) read the spec is also pretty laughable, considering how vague the "protocol" itself is.
>Clients SHOULD validate structured results against this schema.
Have fun with that one. MCP could have at least copied the XML/SOAP process around this and we'd be better off.
Which again, leads back to the articles ultimate premise. MCP does a lot of talking and not a lot of walking, it's pointless at best and is going to lead to A LOT of integration headaches.
I don't think people in this thread aren't really confused about MCP. They are confused that you claimed, or at least insinuated that an LLM might skip the schema validation portion of an MCP tool call request/response, which was originally demonstrated via Claude Code. Hopefully you can understand why everyone seems so confused, since that claim doesn't make any sense when the LLM doesn't really have anything to do with schema validation at all.
This really is not that hard to understand. The LLM must be "bootstrapped" with tool definitions and it must retain stable enough context to continue to call those tools into the future.
This will fail at some point, with any model. It will pretend to do a tool call, it will simply not do the tool call, or it will attempt to call a tool that does not exist, or any of the above or anything else not listed here. It is a statistical certainty.
I don't know why people are pretending MCP does something to fix this, or that MCP is special in anyway. It won't, and it's not.
Make sure you have a good understanding of the overall model: https://hackteam.io/blog/your-llm-does-not-care-about-mcp/
Then take a look at research like this: https://www.archgw.com/blogs/detecting-hallucinations-in-llm...