Support application/json responses in Streamable HTTP transport (opt-in JSON response mode)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 64/100
Direzione di ricerca
Inizia da HttpServletStreamableServerTransportProvider.doPost() e confronta il relativo percorso JSON-RPC associato alla sessione con la gestione di application/json nel percorso initialize e in HttpServletStatelessServerTransport. Il lavoro è completo quando un’impostazione jsonResponse opt-in ha false come valore predefinito, restituisce JSON memorizzato nel buffer per le richieste associate alla sessione quando è abilitata e mantiene il percorso SSE autonomo per le notifiche del server.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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:
| SDK | Config option | Default |
|---|---|---|
| Go | StreamableHTTPOptions.JSONResponse bool |
false |
| Python | is_json_response_enabled: bool |
False |
| TypeScript | enableJsonResponse?: boolean |
false |
| Rust | StreamableHttpServerConfig.json_response: bool |
false |
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[...] orContent-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.
- Lingua principale
- Java
- Stelle
- 3.7k
- Fork
- 1.1k
- Merge medio
- 1g 15h
- PR unite (30g)
- 9
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di modelcontextprotocol/java-sdk
-
area/transport bug P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
modelcontextprotocol/java-sdk#1136 ·
-
area/client bug P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
modelcontextprotocol/java-sdk#1124 · 1 commento ·
-
ServerCapabilities.logging is added unconditionally, overriding the caller's explicit capabilities Apertabug P2 ready for work
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
modelcontextprotocol/java-sdk#1086 · 1 commento ·
-
enhancement good first issue P3
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
modelcontextprotocol/java-sdk#1067 ·
-
bug P2 ready for work
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
modelcontextprotocol/java-sdk#898 · 1 commento ·
Tutte le issue di modelcontextprotocol/java-sdk
Issue simili
-
Leftover LGPLv3 reference Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
OpenHFT/Chronicle-Map#622 ·
-
Bug Java Platform: Java
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
getsentry/sentry-java#6138 · 1 commento ·
-
bug needs triage p2
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
GoogleCloudPlatform/DataflowTemplates#4273 · 1 commento ·
-
[LNG prod] Release 2.4.6 Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100