You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the base module (mcp) can provide the basic functionality for:
creating a STDIO-based server and client
creating a JDK HttpClient-based SSE client
creating a Servlet-based SSE server
It would probably be a good idea to not have framework-specific transport implementations inside the java-sdk.
In the case of mcp-spring-* modules, they would be moved to the spring-ai project and can be used as part of the Spring AI integration with the MCP Java SDK. The question remains whether there are existing users of these modules that do not rely on Spring AI itself. If there are, their input can be used to consider publishing these modules as independent artifacts as they currently are but under a different group.
Inside the mcp core module we can focus on providing the core protocol implementation and maintain these basic transport implementations. While they are quite verbose and require a lot of ceremony, they can provide the minimal set of functionalities to allow users to be framework-agnostic if they so choose.
Suggest HttpClientSseClientTransport HttpServletSseServerTransportProvider, StdioServerTransportProvider independence for the module. The user can choose according to the freedom.
With these implementation adaptations out of the way, we expect the cmp module to support jdk8
Projects like solon and vert.x. They don't need java-ee, they don't need servlets and HttpClient... The mcp module integrates servlets and HttpClient, which is redundant and limits the jdk version
@Aliaksie Yes. Like langchain4j, might only need mcp-core.
Also, there is a real need for jdk8 support in mcp-core. After splitting, mcp can achieve this effect better. There can be adaptations for jdk8, as well as adaptations for jdk17 and jdk21.
Activity
noear commentedon Apr 10, 2025
That's a good IDEA!! We want mcp modules to focus on protocol description and keep implementation separate.
noear commentedon Apr 10, 2025
Suggest HttpClientSseClientTransport HttpServletSseServerTransportProvider, StdioServerTransportProvider independence for the module. The user can choose according to the freedom.
With these implementation adaptations out of the way, we expect the cmp module to support jdk8
noear commentedon Apr 10, 2025
Projects like solon and vert.x. They don't need java-ee, they don't need servlets and HttpClient... The mcp module integrates servlets and HttpClient, which is redundant and limits the jdk version
Aliaksie commentedon Apr 11, 2025
I think it makes sense to make more granular modules, for example
mcp-specmcp-core(optional)mcp-clientmcp-servernoear commentedon Apr 11, 2025
@Aliaksie Yes. Like langchain4j, might only need mcp-core.
Also, there is a real need for jdk8 support in mcp-core. After splitting, mcp can achieve this effect better. There can be adaptations for jdk8, as well as adaptations for jdk17 and jdk21.
[-]Consider moving the mcp-spring-* modules[/-][+]Move the mcp-spring-* modules[/+]chemicL commentedon Feb 17, 2026
spring-projects/spring-ai#5423
chemicL commentedon Feb 20, 2026
#804
Address review comments and improve docs structure and content
Move mcp-spring-webflux and mcp-spring-webmvc to Spring AI 2.0
Move mcp-spring-webflux and mcp-spring-webmvc to Spring AI 2.0 (model…