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.
I think that no one (including me) anticipated just how much attention this will get straight out the door. When I started working on the registry, there were fewer than a few dozen servers. Then suddenly a few weeks later there was a thousand, and numbers just kept growing.
However, lots and lots of those servers do not work. Majority of my time has gone into trying to identify servers that work (using various automated tests). All of this is in large part because MCP got picked up by the mainstream AI audience before the protocol reached any maturity.
Things are starting to look better now though. We have a few frameworks that abstract the hard parts of the protocol. We have a few registries that do a decent job surfacing servers that work vs those that do not. We have a dozen or so clients that support MCPs, etc. All of this in less than half a year is unheard of.
So yes, while it is easy to find flaws in MCP, we have to acknowledge that all of it happened in a super short amount of time – I cannot even think of comparisons to make. If the velocity remains the same, MCP future is very bright.
For those getting started, I maintain a few resources that could be valuable:
> 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.
Just focusing on worst-case scenarios tends to spread more FUD than move things forward. If you have specific proposals for how the protocol could be designed differently, I’m sure the community would love to hear them – https://github.com/orgs/modelcontextprotocol/discussions
The worst case scenario being, what, someone implementing the spec instead of using the SDK and doing it in a way you didn't anticipate? Security and interoperability will not yield to concerns about generating FUD. These concerns are important whether you like them or not. You might as well be whispering that ill news is a ill guest.
At the least, MCP needs to clarify things like "SHOULD rate limit" in more precise terms. Imagine someone who is NOT YOU, someone who doesn't go to your offsites, someone who doesn't give a fuck about your CoC, implementing your spec TO THE LETTER in a way you didn't anticipate. You going to sit there and complain that you obviously didn't intend to do the things that weird but compliant server is doing? You don't have a recourse.
The recent MCP annotations work is especially garbage. What the fuck is "read only"? What's "destructive"? With respect to what? And hoo boy, "open world". What the fuck? You expect people to read your mind?
What would be the point of creating GH issues to discuss these problems? The kind of mind that writes things like this isn't the kind of mind that will understand why they need fixing.
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.
Yup. It's easy to focus on what’s missing or broken in early-stage tech, but I’m more excited about where this kind of standardization could take us. Sometimes you need to look beyond imperfections and see the possibilities ahead.
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
Whatever the transport evolves to, it is easy to create proxies that convert from one transport to another, e.g. https://github.com/punkpeye/mcp-proxy
As an example, every server that you see on Glama MCP registry today is hosted using stdio. However, the proxy makes them available over SSE, and could theoretically make them available over WS, 'streamable HTTP', etc
Glama is just one example of doing this, but I think that other registries/tools will emerge that will effectively make the transport the server chooses to implement irrelevant.
Then have a convo with all your devs to stop spamming the glory of MCP all over the damn place. Have some patience and finish writing and testing it first.
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.
I think that no one (including me) anticipated just how much attention this will get straight out the door. When I started working on the registry, there were fewer than a few dozen servers. Then suddenly a few weeks later there was a thousand, and numbers just kept growing.
However, lots and lots of those servers do not work. Majority of my time has gone into trying to identify servers that work (using various automated tests). All of this is in large part because MCP got picked up by the mainstream AI audience before the protocol reached any maturity.
Things are starting to look better now though. We have a few frameworks that abstract the hard parts of the protocol. We have a few registries that do a decent job surfacing servers that work vs those that do not. We have a dozen or so clients that support MCPs, etc. All of this in less than half a year is unheard of.
So yes, while it is easy to find flaws in MCP, we have to acknowledge that all of it happened in a super short amount of time – I cannot even think of comparisons to make. If the velocity remains the same, MCP future is very bright.
For those getting started, I maintain a few resources that could be valuable:
* https://github.com/punkpeye/awesome-mcp-servers/
* https://github.com/punkpeye/awesome-mcp-devtools/
* https://github.com/punkpeye/awesome-mcp-clients/