Consider moving the mcp-spring-* modules

[chemicL]

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.

[noear]

That's a good IDEA!! We want mcp modules to focus on protocol description and keep implementation separate.

[noear]

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]

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]

I think it makes sense to make more granular modules, for example

• mcp-spec
• mcp-core (optional)
• mcp-client
• mcp-server

[noear]

@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.