modelcontextprotocol / modelcontextprotocol/java-sdk

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

オープン
#844 コメント 11 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

enhancement P2
主要言語
Java
スター
3.7k
フォーク
1.1k
平均マージ
1日 15時間
マージ済み PR(30日)
9

説明

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 [...] 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.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

HttpServletStreamableServerTransportProvider.doPost() から開始し、そのセッションにバインドされた JSON-RPC パスを、initialize パスおよび HttpServletStatelessServerTransport における application/json の処理と比較します。jsonResponse 設定がオプトインでデフォルトでは false になり、有効時にはセッションにバインドされたリクエストに対してバッファリングされた JSON を返し、サーバー通知用のスタンドアロン SSE パスを維持すれば完了です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
java
領域
api, backend
issue の種類
機能追加
難易度
4/5
見積もり時間
3〜5日
活発さ
静か
明瞭さ
明確に書かれている
初心者へのやさしさ
64/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。