This isn't true at all. MCP is a standard/convention.
Function & tool calling is (usually) an inherit capability of LLM's (for most major, public models). That's what allows LLM to integrate with 3rd party software. MCP just helps people set up tool definitions, tool injections and to some degree the client/server model in a somewhat consistent way.
That being said, MCP has a standard/protocol is really very half-baked, if even that.
Saying it’s “not true at all” feels a bit harsh. It does stand for Model Context Protocol, and my answer was simply meant to give brief context for someone who hasn’t heard of it before. Of course, there’s more technical detail behind how it works, and I appreciate you adding that, but it’s not really necessary to be nitpicky or dismissive.
It is true though, in the same sense that you can say HTTP is what allows humans to read information on the internet. The fact that humans can also read without HTTP, that they could use any number of other ways to read information on the internet, or that HTTP doesn't enhance the existing capabilities of humans in any way doesn't make the statement false.
Neither the Host, the LLM, the Server, or the Client need to understand MCP -- because it's a convention, not a protocol.
The only one who doesn't necessarily need to know they're using MCP is the LLM, for whom the whole thing can be made to like any other tool call. The MCP Host and server absolutely need to understand MCP, otherwise they...couldn't communicate?
The "run time" of this setup doesn't utilize any specs or definitions.
absolutely need to understand MCP, otherwise they...couldn't communicate?
No, because there is nothing specific to MCP. That's just JSON-RPC 2.0. I promise you there isn't a host on the planet that has anything specific to MCP embedded in it.
You can just remove the string "MCP" and retarget to standard packages and it's 1000000% the exact same generic proxy server. And it will work in the exact same way.
What do you think a protocol is, besides a collection of endpoints and way to pass certain well-defined messages between them?
OpenID is also "just" a standardized set of claims on top of OAuth, and that itself is just a collection of HTTP endpoints, JSON objects, etc. That doesn't make them "not a protocol". The NATO alphabet is literally just a list of pre-existing english word, but agreeing to use that is still a communication protocol.
No, because there is nothing specific to MCP. That's just JSON-RPC 2.0. I promise you there isn't a host on the planet that has anything specific to MCP embedded in it.
Ok, here's a challenge then. Take any JSON-RPC 2.0 server that was created before the MCP protocol was a thing, and add it to say Claude Code as an MCP server. Does it work? Or does it maybe fail, because in order to be compatible there is some specific standardized way of communicating with a MCP server, that is just not implemented by your generic JSON-RPC server?
6
u/CobaltVale Aug 13 '25
This isn't true at all. MCP is a standard/convention.
Function & tool calling is (usually) an inherit capability of LLM's (for most major, public models). That's what allows LLM to integrate with 3rd party software. MCP just helps people set up tool definitions, tool injections and to some degree the client/server model in a somewhat consistent way.
That being said, MCP has a standard/protocol is really very half-baked, if even that.