java-sdk
The official Java SDK for Model Context Protocol servers and clients. Maintained in collaboration with Spring AI
by modelcontextprotocolCommit activity
Last 12 weeks · 68 commits
Community health
5 of 6 standards met
87
✓README✓License✓Contributing✓Code of Conduct○Issue Template✓PR Template
Recent PRs & issues
Active · Last activity 12h ago
See all on GitHub →Support application/json responses in Streamable HTTP transport (opt-in JSON response mode)OpenIssue
Expected Behavior An opt-in configuration to return for JSON-RPC requests within the Streamable HTTP transport, even with active sessions. Example: When enabled, for would buffer the response from and return it as instead of opening an SSE stream. Server-initiated notifications would go through the standalone SSE stream (GET on the same endpoint, as defined in the Streamable HTTP spec). All other official MCP SDKs already support this as an opt-in option: Current Behavior In , session-bound messages always get : There is no way to get for session-bound requests. The request (line 461) and (line 173) already return - 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 [...] or , 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 mode () does return , but it removes session management entirely - no server-to-client notifications, no sampling, no capability tracking. This feature request is about supporting 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, 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.
Recent fixes
I had mentioned this before in https://github.com/modelcontextprotocol/java-sdk/issues/562 but it seems that it wasn't addressed. mcp-spring-webmvc-0.18.1.jar has io.modelcontextprotocol.server.transport package and mcp-core-1.0.0.jar also has io.modelcontextprotocol.server.transport package In my particular application I need both transports so I am currently forced to copy the source of one of the transports into my code base which is not at all ideal. Ideally if a class is in a different jar it should have a different package to support osgi constructs. i.e: one of them should be changed to be io.modelcontextprotocol.server.webmvc.transport or io.modelcontextprotocol.server.core.transport
Structured data for AI agents
Repository: modelcontextprotocol/java-sdk. Description: The official Java SDK for Model Context Protocol servers and clients. Maintained in collaboration with Spring AI Stars: 3225, Forks: 830. Primary language: Java. Languages: Java (100%). License: MIT. Homepage: https://java.sdk.modelcontextprotocol.io/latest/ Latest release: v1.0.0 (1w ago). Open PRs: 100, open issues: 155. Last activity: 12h ago. Community health: 87%. Top contributors: tzolov, chemicL, Kehrlann, markpollack, LucaButBoring, sdelamo, CrazyHZM, jitokim, quaff, codeboyzhou and others.