Yes, the protocol seems fine to me in and of itself. It's the transport portion that seems to be a dumpster fire on the HTTP side of things.

I'm confused by the "old timer" comment, as SSE not only predates WebSockets, but the techniques surrounding its usage go really far back (I was doing SSE-like things--using script blocks to get incrementally-parsed data--back around 1999). If anything, I could see the opposite issue, where someone could argue that the spec was written by someone who just doesn't want to learn how WebSockets works, and is stuck in a world where SSE is the only viable means to implement this? And like, in addition to the complaints from this author, I'll note the session resume feature clearly doesn't work in all cases (as you can't get the session resume token until after you successfully get responses).

That all said, the real underlying mistake here isn't the choice of SSE... it is trying to use JSON-RPC -- a protocol which very explicitly and very proudly is supposed to be stateless -- and to then use it in a way that is stateful in a ton of ways that aren't ignorable, which in turn causes all of this other insanity. If they had correctly factored out the state and not incorrectly attempted to pretend JSON-RPC was capable of state (which might have been more obvious if they used an off-the-shelf JSON-RPC library in their initial implementation, which clearly isn't ever going to be possible with what they threw together), they wouldn't have caused any of this mess, and the question about the transport wouldn't even be an issue.

> I'm confused by the "old timer" comment

SSE only gained traction after HTTP/2 came around with multiplexing.

HTTP call may be blocked by firewalls even internally, and it's overkill to force stdio apps to expose http endpoints for this case only.

As in, how MCP client can access `git` command without stdio? You can run a wrapper server for that or use stdio instead

> As in, how MCP client can access `git` command without stdio?

MCP clients don't access any commands. MCP clients access tools that MCP servers expose.

Here's a custom MCP tool I use to run commands and parse stdout / stderr all the time:

    try {
        const execPromise = promisify(exec);
        const { stdout, stderr } = await execPromise(command);
        if (stderr) {
            return {
                content: [{
                    type: "text",
                    text: `Error: ${stderr}`
                }],
                isError: true
            };
        }
        return {
            content: [{
                type: "text",
                text: stdout
            }],
            isError: false
        };
    } catch (error: any) {
        return {
            content: [{
                type: "text",
                text: `Error executing command: ${error.message}`
            }],
            isError: true
        };
    }

Yeah, if you want to be super technical, it's Node that does the actual command running, but in my opinion, that's as good as saying the MCP client is...

The point is that MCP servers expose tools that can do whatever MCP servers want them to do, and it doesn’t have to have anything to do with stdio.

Must have used GraphQL as a role model no doubt

GraphQL is transport agnostic

Indeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.

I think JSON is preferred because it adds more complexity.

I think it works because json is verbose and reinforces what everything is in each record.

From this point of view XML offers all that and named brackets.

True. Even better with inline attributes.

I Wanna Be <![CDATA[ Sung to the tune of “I Wanna Be Sedated”, with apologies to The Ramones. ]]>

https://donhopkins.medium.com/i-wanna-be-cdata-3406e14d4f21

Hey, at least they didn't use yaml-rpc.

toml-rpc anyone? :)

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.

Or is is because most text in existence is XML - or more specifically HTML.