[tedivm]

I'm not saying MCP is perfect, but it's better than OpenAPI for LLMs for a few reasons.

* MCP tools can be described simply and without a lot of text. OpenAPI specs are often huge. This is important because the more context you provide an LLM the more expensive it is to run, and the larger model you need to use to be effective. If you provide a lot of tools then using OpenAPI specs could take up way too much for context, while the same tools for MCP will use much less.

* LLMs aren't actually making the calls, it's the engine driving it. What happens when an LLM wants to make a call is it responds directly with a block of text that the engine catches and uses to run the command. This allows LLMs to work like they're used to: figuring out text to output. This has a lot of benefits: less tokens to output than a big JSON blob is going to be cheaper.

* OpenAPI specs are static, but MCP allows for more dynamic tool usage. This can mean that different clients can get different specs, or that tools can be added after the client has connected (possibly in response to something the client sent). OpenAPI specs aren't nearly that flexible.

This isn't to say there aren't problems. I think the transport layer can use some work, as OP sent, but if you play around in their repo you can see websocket examples so I wouldn't be surprised if that was coming. Also the idea that "interns" are the ones making the libraries is an absolute joke, as the FastMCP implementation (which was turned into the official spec) is pretty solid. The mixture of hyperbole with some reasonable points really ruins this article.

[smartvlad]

If you look at the actual raw output of tools/list call you may find it surprisingly similar to the OpenAPI spec for the same interface. In fact they are trivially convertible to each other.

Personally I find OpenAPI spec being more practical since it includes not just endpoints with params, but also outputs and authentication.

Know all that from my own experience plugging dozens of APIs to both MCP/Claude and ChatGPT.

[9dev]

> OpenAPI specs are static, but MCP allows for more dynamic tool usage.

This is repeated everywhere, but I don’t get it. OpenAPI specs are served from an HTTP endpoint, there’s nothing stopping you from serving a dynamically rendered spec depending on the client or the rest of the world?

[armdave]

What does it mean that "different clients can get different specs"? Different in what dimension? I could imagine this makes creating repeatable and reliable workflows problematic.

[tedivm]

Using MCP you can send "notifications" to the server, and the server can send back notifications including the availability of new tools.

So this isn't the same as saying "this user agent gets X, this gets Y". It's more like "this client requested access to X set of tools, so we sent back a notification with the list of those additional tools".

This is why I do think websockets make more sense in a lot of ways here, as there's a lot more two way communication here than you'd expect in a typically API. This communication also is very session based, which is another thing that doesn't make sense for most OpenAPI specs which assume a more REST-like stateless setup.