Skip to content

Conversation

tzolov
Copy link
Contributor

@tzolov tzolov commented Aug 21, 2025

  • Consolidate multiple MCP server modules into unified webmvc/webflux modules
  • Move properties classes from separate module into mcp-server-common
  • Merge stateless auto-configuration into common module
  • Replace transport-specific modules with protocol-based configuration
  • Add ServerProtocol enum (SSE, STREAMABLE, STATELESS) for protocol selection
  • Rename ServerType to ApiType for clarity
  • Update conditional configuration to use protocol-based conditions
  • Remove separate streamable/stateless starter modules
  • Update documentation to reflect unified protocol-based approach
  • Simplify module structure while maintaining backward compatibility through configuration

This refactoring reduces complexity by consolidating 7+ modules into 3 main modules (common, webmvc, webflux) while providing the same functionality through the spring.ai.mcp.server.protocol configuration property.

…introduce protocol-based configuration

- Consolidate multiple MCP server modules into unified webmvc/webflux modules
- Move properties classes from separate module into mcp-server-common
- Merge stateless auto-configuration into common module
- Replace transport-specific modules with protocol-based configuration
- Add ServerProtocol enum (SSE, STREAMABLE, STATELESS) for protocol selection
- Rename ServerType to ApiType for clarity
- Update conditional configuration to use protocol-based conditions
- Remove separate streamable/stateless starter modules
- Update documentation to reflect unified protocol-based approach
- Simplify module structure while maintaining backward compatibility through configuration

This refactoring reduces complexity by consolidating 7+ modules into 3 main modules
(common, webmvc, webflux) while providing the same functionality through the
spring.ai.mcp.server.protocol configuration property.

Signed-off-by: Christian Tzolov <[email protected]>
Co-authored-by: yinh <[email protected]>
@tzolov tzolov force-pushed the another-mcp-autoconfiguration-improvement branch from 6a48c45 to f4b9088 Compare August 21, 2025 10:13
Signed-off-by: Christian Tzolov <[email protected]>
tzolov added a commit that referenced this pull request Aug 21, 2025
…introduce protocol-based configuration (#4211)

- Consolidate multiple MCP server modules into unified webmvc/webflux modules
- Move properties classes from separate module into mcp-server-common
- Merge stateless auto-configuration into common module
- Replace transport-specific modules with protocol-based configuration
- Add ServerProtocol enum (SSE, STREAMABLE, STATELESS) for protocol selection
- Rename ServerType to ApiType for clarity
- Update conditional configuration to use protocol-based conditions
- Remove separate streamable/stateless starter modules
- Update documentation to reflect unified protocol-based approach
- Simplify module structure while maintaining backward compatibility through configuration

This refactoring reduces complexity by consolidating 7+ modules into 3 main modules
(common, webmvc, webflux) while providing the same functionality through the
spring.ai.mcp.server.protocol configuration property.

Signed-off-by: Christian Tzolov <[email protected]>
Co-authored-by: yinh <[email protected]>
@tzolov tzolov marked this pull request as ready for review August 21, 2025 11:16
@tzolov tzolov added this to the 1.1.0.M1 milestone Aug 21, 2025
@tzolov
Copy link
Contributor Author

tzolov commented Aug 21, 2025

Rebased and merged at e71da4e

@Fottas
Copy link
Contributor

Fottas commented Aug 22, 2025

Hi @tzolov,
I've created PR #4218 that consolidates the configuration into a single unified structure to avoid the "Duplicated prefix" warnings. This approach draws inspiration from Spring's patterns like CacheProperties. Do you think this approach is suitable?

@Fottas
Copy link
Contributor

Fottas commented Aug 25, 2025

Hi @tzolov,
I noticed PR #4218 had build failures due to NullPointerException in McpToolUtils, so I fixed that issue.
I see another fix was submitted later for the same NPE, but checking the MCP SDK source code, it's still using the deprecated call() parameter in AsyncToolSpecification. The runtime actually only uses callHandler() (see McpAsyncServer.java).
While working on that, I noticed PR #4218 is still pending - it addresses both the NPE fix with correct API usage and the "Duplicated prefix" warnings we discussed. Would you like me to rebase it on the latest changes?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants