Support application/json responses in Streamable HTTP transport (opt-in JSON response mode)

Expected Behavior

An opt-in configuration to return application/json for JSON-RPC requests within the Streamable HTTP transport, even with active sessions. Example:

HttpServletStreamableServerTransportProvider.builder()
    .jsonMapper(mapper)
    .mcpEndpoint("/mcp")
    .jsonResponse(true)    // opt-in, default false
    .build();

When enabled, doPost() for JSONRPCRequest would buffer the response from session.responseStream() and return it as application/json instead of opening an SSE stream. Server-initiated notifications would go through the standalone SSE stream (GET on the same /mcp endpoint, as defined in the Streamable HTTP spec).

All other official MCP SDKs already support this as an opt-in option:

Current Behavior

In HttpServletStreamableServerTransportProvider.doPost(), session-bound JSONRPCRequest messages always get text/event-stream:

else if (message instanceof McpSchema.JSONRPCRequest jsonrpcRequest) {
    // For streaming responses, we need to return SSE
    response.setContentType(TEXT_EVENT_STREAM);   // ← always SSE
    // ...
}

There is no way to get application/json for session-bound requests. The initialize request (line 461) and HttpServletStatelessServerTransport (line 173) already return application/json - so the pattern exists in the codebase.

Context

The MCP Streamable HTTP spec (2025-06-18, §2.1.5) states:

"If the input is a JSON-RPC request, the server MUST either return Content-Type: text/event-stream [...] or Content-Type: application/json, to return one JSON object."

This means session management does not require SSE for every response. There are scenarios where a server benefits from sessions (capability negotiation, logging, server-initiated notifications via GET) but its tool handlers produce simple single-message responses that don't need SSE framing.

The existing STATELESS mode (HttpServletStatelessServerTransport) does return application/json, but it removes session management entirely - no server-to-client notifications, no sampling, no capability tracking. This feature request is about supporting application/json responses within the Streamable transport, with sessions, as the spec allows and as the other SDKs already implement.

In local benchmarks comparing MCP server implementations across different SDKs, we observed that switching from SSE-only to JSON responses for simple tool calls (single request-response, no intermediate notifications) resulted in significant performance improvements, primarily due to eliminating chunked transfer encoding, AsyncContext lifecycle overhead, and SSE framing/parsing on both server and client sides.

Would it make sense to add this? Happy to contribute a PR if the maintainers agree.

從 HttpServletStreamableServerTransportProvider.doPost() 開始，將其繫結工作階段的 JSON-RPC 路徑與 initialize 路徑及 HttpServletStatelessServerTransport 中對 application/json 的處理進行比較。完成的標準是：可選擇啟用的 jsonResponse 設定預設為 false，啟用後為繫結工作階段的請求回傳緩衝的 JSON，並保留用於伺服器通知的獨立 SSE 路徑。