Proposal: add StreamableServerTransport.JSONResponse to support application/json format messages in StreamableHTTP Transport

[sushi-small]

When I use Cursor to get the tools from my MCP server, the server responds with a text/event-stream format message. Cursor can't parse this message and then displays no tools. The Python SDK responds with an application/json format message, which Cursor can parse and display tools.

[findleyr]

We can absolutely support returning application/json, but if Cursor behaves that was I don't think it is compliant with the spec, which states:

The client MUST include an Accept header, listing both application/json and text/event-stream as supported content types.

The question is how to choose between application/json and text/event-stream. I suppose we'd need an option to indicate preference for one over the other.

[findleyr]

Aha, this is exactly how the typescript SDK does it: an 'enableJsonResponse' option.
https://github.com/modelcontextprotocol/typescript-sdk/blob/31acdcbb189056ec83d14a4f7a37ae2b1c67680e/src/server/streamableHttp.ts#L69

[sushi-small]

Thanks for looking into this! The enableJsonResponse option from the typescript SDK sounds like exactly what we need. Would it be possible to add a similar option to the go-sdk?

[findleyr]

Yes, I am adding such an option, though I'm calling it JSONResponse. Working on it today.

[findleyr]

Concretely, the proposal is this:

type StreamableServerTransportOptions struct {
   ...

  // When set, JSONResponse causes the transport to return responses to POST requests with a single 
  // application/json payload rather than text/event stream. This is incompatible with batched requests,
  // supported in the 2025-03-16 version of the spec.
  //
  // Any non-response messages from the server are delivered to the hanging GET stream.
  JSONResponse bool
}

[samthanawalla]

I'd like to push back on this proposal. I think our API should abstract away the underlying transport details and this flag exposes a choice that I don't think users should need to make.

Moreover, I think accommodating a non-complaint client by deviating from the spec sets a bad precedent.

[findleyr]

@samthanawalla to be clear, the spec allows for this behavior (returning application/json), and we're simply adding a way to activate it, and the typescript SDK provides an equivalent option.

[findleyr]

We also need this behavior for writing integration tests for our client, so I'd advocate for implementing it even if we don't expose it :)