The official Java SDK for Model Context Protocol servers and clients. Maintained in collaboration with Spring AI
by modelcontextprotocolLast 12 weeks · 61 commits
5 of 6 standards met
Add explicit UTF-8 charset to InputStreamReader in StdioServerTransportProvider. Resolves #295 Motivation and Context The input stream in StdioServerTransportProvider was missing explicit UTF-8 charset, while the output stream already specifies it. How Has This Been Tested? Added a subprocess-based integration test that spawns a child JVM with and verifies multi-byte UTF-8 characters are preserved through StdioServerTransportProvider. This test fails without the fix and passes with it. Breaking Changes No Types of changes [x] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed Additional context AI tools were used for drafting the PR description.
https://github.com/modelcontextprotocol/java-sdk/blob/c3a0b1855ab2ac18a2b6120773ac4e5060285d8b/mcp-spring/mcp-spring-webflux/src/main/java/io/modelcontextprotocol/client/transport/WebClientStreamableHttpTransport.java#L204-L207 It currently shows "Session not found" even when the HTTP endpoint doesn't exist, which can be misleading for developers.
Repository: modelcontextprotocol/java-sdk. Description: The official Java SDK for Model Context Protocol servers and clients. Maintained in collaboration with Spring AI Stars: 3205, Forks: 822. Primary language: Java. Languages: Java (100%). License: MIT. Homepage: https://java.sdk.modelcontextprotocol.io/latest/ Latest release: v1.0.0 (5d ago). Open PRs: 100, open issues: 152. Last activity: 1d ago. Community health: 87%. Top contributors: tzolov, chemicL, Kehrlann, markpollack, LucaButBoring, sdelamo, CrazyHZM, jitokim, quaff, codeboyzhou and others.
Java
Fix protocol version resolution to return the latest supported version instead of defaulting to the first declared constant. Motivation and Context The default implementation returned the earliest protocol version, leading to incorrect version negotiation. This ensures the latest supported version is selected dynamically. How Has This Been Tested? Build locally Breaking Changes Types of changes [x] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [ ] I have added appropriate error handling [ ] I have added or updated documentation as needed Additional context Latest version is derived from the centralized supported versions list to avoid hardcoded defaults.
This change allows clients to register subscriptions for resource updates. This PR aims to supersede #838 and resolve #837 and #776. Motivation and Context This functionality was missing. How Has This Been Tested? Unit and integration tests added. New API Nothing breaking but new API is introduced: New default method New constructor in that accepts a callback New constructor in that accepts a Behaviour changes Previously, broadcast to all connected clients. Now it only notifies sessions that have subscribed to the specific resource URI. ` Types of changes [x] Bug fix (non-breaking change which fixes an issue) [x] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [ ] I have added or updated documentation as needed
Please do a quick search on GitHub issues first, the feature you are about to request might have already been requested. Expected Behavior McpAsyncClient caches tools locally, there is no need to request the MCP server every time. Current Behavior Every time McpAsyncClient. listTools() is called, an HTTP request is sent, but the probability of tool changes is very small, which is very wasteful. Context** Add a parameter “cache=true” to McpAsyncClient to automatically cache the tool list, and periodically request MCP Server to refresh the cache, or refresh the local cache through the notify mechanism.