* 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.
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.
In a literal sense it's easier, safer, faster, etc for an LLM to remember "use server Foo to do X" than "I read a document that talks about calling api z with token q to get data b, and I can combine three or four api calls using this http library to...."
Not that the list of tools and their behavior should be static (which would be much less capable)
OpenAI plugins flopped back in 2023 because the LLMs at the time weren't reliable enough for tool usage to be anything more than interesting-but-flawed.
MCP's timing was much better.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Basic Math Server")
@mcp.tool()
def multiply(a: int, b: int) -> int:
return a * b
mcp.run()
The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that they exist.
Give it more than a couple months though and I think we'll see it mature some more. We just got their auth patterns to use existing rails and concepts, just have to eat the rest of the camel.
Is it sufficient to put a agents.json file in the root of the /.well-known web folder and let agents just "figure it out" through semantic dialogue?
This forces the default use of HTTP as Agent stdio.
Because one is made for local and the other for connecting through the internet.
Exactly.
MCP is one of the worst 'standards' that I have seen come out from anywhere since JSON Web Tokens (JWTs) and the author rightfully points out the lack of engineering practices of a 'standard' that is to be widely used like any properly designed standard with industry-wide input.
> Increased Attack Surface: The multiple entry points for session creation and SSE connections expand the attack surface. Each entry point represents a potential vulnerability that an attacker could exploit.
JWTs have this same issue with multiple algorithms to use including the horrific 'none' algorithm. Now we have a similar issue with MCP with multiple entry points to chose from which is more ways to attack the protocol.
This one is the most damning.
> Python and JavaScript are probably one of the worst choices of languages for something you want to work on anyone else's computer. The authors seem to realize this since all examples are available as Docker containers.
Another precise point and I have to say that our industry is once again embracing the worst technologies to design immature standards like this.
The MCP spec appears to be designed without consideration for security or with any input from external companies like a normal RFC proposal should and is quite frankly repeating the same issues like JWTs.
Many pass REST responses directly to LLMs that quickly leads to token burn. Wish providers took a closer look on the actual engineering practices for the servers.
Has someone seen a good implementation of an MCP server with a comprehensive test suite?
moralestapia•1h ago
"It kind of breaks the Unix/Linux piping paradigm using these streams for bidirectional communication."
Uhm ... no? They were meant for that.
But the rest of the critique is well founded. "Streamable HTTP" is quite an amateurish move.
OJFord•1h ago