Earlier quoted context omitted.
Who is "they"?
The AI houses buying up the entire market of GPUs. Have you heard about them?
[deleted]
A critical look at MCP
71–80 of 348 posts
Re: A critical look at MCP
#72This 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.
You're not the intended audience for this blog post. The people who care about this are the kinds of people who have to implement the protocol on either end, and deal with all of those complexities. You won't be able to fully insulate yourself from those complexities, though. Unnecessary complexity causes user-visible bugs and incompatibilities. You want to reach for a framework that will abstract all this stuff away…
Just like I saw with protocols like ActivityPub and IPFS, what happens is the developers of these protocols do a couple of reference implementations in their favorite languages, which work, but then when they write the actual "spec" of what they think they did in the code, they never get it fully correct, or even if they do it's messy, incomplete, or not kept up to date.
So as long as you're a developer working in one of those two languages you just take their code and run it, and all is fine. However for someone coming along trying to implement the protocol in a brand new language, it gets discovered that the protocol is insufficient and horrible and attempts to build based on the protocol are therefore doomed to fail.
I'm not saying MCP has already reached this level of chaos, but I'm just saying this is the failure pattern that's fairly common.
Re: A critical look at MCP
#73MCP 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.
MCP is simple, as protocols go.
Re: A critical look at MCP
#74I am the founder of one of the MCP registries ( https://glama.ai/mcp/servers ). 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…
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
I think that transport is a non-issue.
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.
Re: A critical look at MCP
#75I am the founder of one of the MCP registries ( https://glama.ai/mcp/servers ). 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…
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 y…
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.
Re: A critical look at MCP
#76Earlier quoted context omitted.
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() If you have a large MCP server with many tools the amount of text sent to the LLM can be significant too. I've found that Claude works great with an OpenAPI spec if you provide it w…
That's kind of my point, that the protocols complexity is hidden in py sdk making it feel easy... But taking on large tech dept
The difficult part is figuring out what kind of abstractions we need MCP servers / clients to support. The transport layer is really not important, so until that is settled, just use the Python / TypeScript SDK.
Re: A critical look at MCP
#77Earlier quoted context omitted.
Who is "they"?
The AI houses buying up the entire market of GPUs. Have you heard about them?
This is paranoid drivel....
Tell me which is more likely.
1. There is a cabal of companies painstakingly working together to make the most convoluted software possible from scratch so they can dominate the market.
or
2. A few people threw together a bit of code to attempt to get something working without any deep engineering or systematic view of what they were trying to accomplish, getting something to work well enough that it took off quickly in a time where everyone wants to have tool use on LLMs.
I've been on the internet a long time and number 2 is a common software paradigm on things that are 'somewhat' open and fast moving. Number 1 does happen but it either is started and kept close by a single company, or you have a Microsoft "embrace, extend, extinguish" which isn't going on here.
Re: A critical look at MCP
#78Earlier quoted context omitted.
I understand those with experience have found that XML works better because it's more redundant.
Is it the redundancy? Or is it because markup is a more natural way to annotate language, which obviously is what LLMs are all about? Genuinely curious, I don’t know the answer. But intuitively JSON is nice for easy to read payloads for transport but to be able to provide rich context around specific parts of text seems right up XML’s alley?
The lack of inline context is a failing of JSON and a very useful feature of XML.
Two simple but useful examples would be inline markup to define a series of numbers as a date or telephone number or a particular phrase tagged as being a different language from the main document. Inline semantic tags would let LLMs better understand the context of those tokens. JSON can't really do that while it's a native aspect of XML.
Re: A critical look at MCP
#79my dude really got angry but forgot almost all cloud message queue offerings over HTTP works like this (minus SSE). Eventually MCP will take the same route as WS which started clunky with the http upgrade thing being standard but not often used and evolved. Then it will migrate to any other way of doing remote interface, as GRPC, REST and so on.
I mean…the cloud message queues that use HTTP are not good examples of quality software. They all end up being mediocre to poor on every axis: they’re not generalizable enough to be high quality low level components in complex data routing (e.g. SQS’s design basically precludes rapid redelivery on client failure, and is resistant to heterogenous workloads by requiring an up-front redelivery/deadletter timeout); simultaneously, HTTP’s statelessness at the client makes extremely basic use cases flaky since e.g. consumer acknowledgment/“pop” failures are hard to differentiate as server-side issues, incorrect client behavior, or conceptual partitions in the consume transaction network link…”conceptual” because that connection doesn’t actually exist, leading to all these problems. Transactionality between stream operations, too, is either a hell-no or a hella-slow (requiring all the hoop-jumping mentioned in TFA for clients’ operations to find the server session that “owns” the transaction’s pseudo connection) if built on top of HTTP.
In other words, you can’t emulate a stateful connection on top of stateless RPC—well, you can, but nobody does because it’d be slow and require complicated clients. Instead, they staple a few headers on top of RPC and assert that it’s just as good as a socket. Dear reader: it is not.
This isn’t an endorsement of AMQP 0.9 and the like or anything. The true messaging/streaming protocols have plenty of their own issues. But at least they don’t build on a completely self-sabotaged foundation.
Like, I get it. HTTP is popular and a lot of client ecosystems balk at more complex protocols. But in the case of stateful duplex communication (of which queueing is a subset), you don’t save on complexity by building on HTTP. You just move the complexity into the reliability domain rather than the implementation domain.
Re: A critical look at MCP
#80I am the founder of one of the MCP registries ( https://glama.ai/mcp/servers ). 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…
> 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 yo…
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