A critical look at MCP
raz.sh
A critical look at MCP
1–10 of 348 posts
Re: A critical look at MCP
#2Context is stdin and stdio.
"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.
Re: A critical look at MCP
#3It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.
Re: A critical look at MCP
#4Context is stdin and stdio. "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.
I think 'bidirectional' is unclear there, they really mean a back and forth dialogue, interactive bidirectional communication. Which, yeah, a socket (as they said) seems a better choice.
Re: A critical look at MCP
#5This all sounds valid, but it’s also the least interesting part of the whole thing. As a developer I’m expecting to be able to reach for a framework that’ll just abstract away all the weird design decisions that he mentions.
Re: A critical look at MCP
#6It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.
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.
Re: A critical look at MCP
#7MCP is the moat to keep small players outside of the AI market. Not only does implementing it require a team, it is a tarpit of sabotage, where logging and state are almost impossible to track.
Re: A critical look at MCP
#8It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.
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 cont…
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.
Re: A critical look at MCP
#9It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.
This is one of the few places I think it's obvious why MCP provides value - an OpenAPI document is static and does no lifting for the LLM, forcing the LLM to handle all of the call construction and correctness on its own. MCP servers reduce LLM load by providing abstractions over concepts, with basically the same benefits we get by not having to write assembly by hand.
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...."
Re: A critical look at MCP
#10It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.
My theory is that a lot of the buzz around MCP is actually buzz around the fact that LLM tool usage works pretty well now.
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.