[deleted]
A critical look at MCP
201–210 of 348 posts
Re: A critical look at MCP
#202> "In HTTP+SSE mode, to achieve full duplex, the client sets up an SSE session to (e.g.) GET /sse for reads. The first read provides a URL where writes can be posted. The client then proceeds to use the given endpoint for writes, e.g., a request to POST /a-endpoint?session-id=1234. The server returns a 202 Accepted with no body, and the response to the request should be read from the pre-existing open SSE connection on /sse."
This just seems needlessly complicated. Performing writes on one endpoint and reading the response on another just seems so wrong to me. An alternative could be that the "client" generates a session id and the start of the chat and make http calls to the server passing that ID in a query string or header. Then, the response is sent back normally instead of just sending 202.
What benefit is SSE providing here? Let the client decide when a session starts/ends by generating IDs and let the server maintain that session internally.
Re: A critical look at MCP
#203Earlier quoted context omitted.
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 jus…
Do you think WebTransport and HTTP3 could provide better alternatives for transport?
Re: A critical look at MCP
#204This is a part of the bigger problem. Near all of AI is done by mathematicians, (data) scientists, students and amateur enthusiasts. Not by professional software engineers. This is why nearly everything looks like a one weekend pet project by the standards of software engineering.
Speak for yourself. I see the majority of work being done by professional software engineers.
"professional software engineer" is a meaningless title because the industry has no professional standards.
Re: A critical look at MCP
#205I’ve been toying with building remote MCPs on Cloudflare workers. I came in with the idea that “you could probably use REST APIs for everything” then implemented both REST, and MCPs side by side. Also built an SSE and a “streamable http” version. For building apps that call the server, using the APIs was way easier. For building an LLM system for figure out what API tool calls to make, it’s quite a bit of work to rec…
Cloudflare + SSE with any substantial delay is a nightmare
Re: A critical look at MCP
#206Earlier quoted context omitted.
DeepSeek's documentation has a different problem, which is that there are spelling errors and weird grammatical constructions everywhere: "DeepSeek API does NOT constrain user's rate limit. We will try out best to serve every request. However, please note that when our servers are under high traffic pressure, your requests may take some time to receive a response from the server. During this period, your HTTP request…
What’s the problem? Can you point out a specific thing you would change from that quote?
I'd just shorten it:
DeepSeek API does NOT have rate limits.
However, when our servers are under high traffic,
your requests may take some time. During this period,
you will continuously receive the following responses:Re: A critical look at MCP
#207Earlier quoted context omitted.
> 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 tools that depend 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.
Could you throw on a couple of examples of calcified early mistakes of Python? GIL is/was one, I presume?
Static functions (len, map/filter,...) that should have been methods on objects.
Re: A critical look at MCP
#208Earlier quoted context omitted.
To this date I have not found a good explanation what an MCP is. What is it in old dev language?
If you know JSON-RPC: it's a JSON-RPC wrapper exposed for AI use and discovery. If you know REST / http request: it's single endpoint-only, partitioned / routed by single "type" or "method" parameter, with some different specification, for AI.
Wasn't the point of REST supposed to be runtime discoverability though? Of course REST in practice just seems to be json-rpc without the easy discoverability which seems to have been bolted on with Swagger or whatnot. But what does MCP do that (properly implemented) REST can't?
Re: A critical look at MCP
#209In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". 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 t…
> 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 tools that depend 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.
Hey there, expecting basically literacy or comprehension out of a sub-industry seemingly dedicated to minimising human understanding and involvement is bridge too far.
Clearly if these things are problems, AI will simply solve them, duhhh.
/s
Re: A critical look at MCP
#210> "In HTTP+SSE mode, to achieve full duplex, the client sets up an SSE session to (e.g.) GET /sse for reads. The first read provides a URL where writes can be posted. The client then proceeds to use the given endpoint for writes, e.g., a request to POST /a-endpoint?session-id=1234. The server returns a 202 Accepted with no body, and the response to the request should be read from the pre-existing open SSE connection…
> What benefit is SSE providing here? Let the client decide when a session starts/ends by generating IDs and let the server maintain that session internally.
The response is generated asynchronously, instead of within the HTTP request/response cycle, and sent over SSE later. But emulating WS with HTTP requests+SSE seems very iffy, indeed.