A Critical Look at MCP

> Give it more than a couple months though and I think we'll see it mature some more.

Or like the early Python ecosystem, mistakes will become ossified at the bottom layers of the stack, as people rapidly build higher level tooling that depends on them.

Except unlike early Python, the AI ecosystem community has no excuse, BECAUSE THERE ARE ALREADY HISTORICAL EXAMPLES OF THE EXACT MISTAKES THEY'RE MAKING.

Also missing in these strict, declarative protocols is a reliance on latent space, and the semantic strengths of LLMs.

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.

Bravo. Agree with both of your examples.

Isn't MPC based on JSON-RPC?

I wish there was a clear spec on the site but there isn't https://modelcontextprotocol.io/specification/2025-03-26

It seems like half of it is Sonnet output and it doesn't describe how the protocol actually works.

For all its warts, the GraphQL spec is very well written https://spec.graphql.org/October2021/

Agree... this is an important blog. People need to press pause on MCP in terms of adoption...it was simply not designed with a solid enough technical foundation that would make it suitable to be an industry standard. People are hyped about it, kind of like they were for LangChain and many other projects, but people are going to gradually (after diving into implementations) that it's not actually what they were looking for..It's basically a hack thrown together by a few people and there are tons of questionable decisions, with websockets being just one example of a big miss.

Glad to here, also thought I was alone :)

I thinks a lot is timing and also that it's a pretty low bar to write your first mcp server:

    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()

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.

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...."

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.

> I somewhat agree with author’s comments, but also want to note that the protocol is in the extremely early stages of development, and it will likely evolve a lot over the next year.

And that's why it's so important to spec with humility. When you make mistakes early in protocol design, you live with them FOREVER. Do you really want to live with a SSE Rube Goldberg machine forever? Who the hell does? Do you think you can YOLO a breaking change to the protocol? That might work in NPM but enterprise customers will scream like banshees if you do, so in practice, you're stuck with your mistakes.

Agree with basically all of this.

The actual protocol of MCP is…whatever. I’m sure it will continue to evolve and mature. It was never going to be perfect out of the gate, because what is?

But the standardization of agentic tooling APIs is mind bogglingly powerful, regardless of what the standard itself actually looks like.

I can write and deploy code and then the AI just..immediately knows how to use it. Something you have to experience yourself to really get it.

Kind of my fear exactly. We are moving so fast and that mcp would create an accept a transport protocol that might take years or decades to get rid off for something better.

Kind of reminds me of the browser wars during 90s where everyone tried to run the fastest an created splits in standards and browsers what we didn't really det rid of for a good 20 year or more. IE11 was around for far to long