In the current implementation of McpClientAutoConfiguration, there are two critical issues:

  1. When using type: ASYNC, both SSE implementations (WebFlux and HttpClient) attempt to establish connections to the same server endpoint simultaneously. This occurs because the auto-configuration allows both transports to be registered:

java @AutoConfiguration(after = { StdioTransportAutoConfiguration.class, SseHttpClientTransportAutoConfiguration.class, SseWebFluxTransportAutoConfiguration.class })

This results in: - Duplicate SSE connections to the same endpoint - Unnecessary resource consumption - Potential message duplication

  1. When using type: SYNC, the application fails to start. This appears to be related to the order of auto-configuration initialization specified in the @AutoConfiguration(after = {...}) annotation.

Example configuration where these issues occur:

yaml spring: ai: mcp: client: type: ASYNC # or SYNC server: endpoint: "http://localhost:8080/"

Questions: 1. Why are both SSE implementations allowed to register and connect simultaneously? 2. Could we implement a mechanism to ensure only one SSE implementation is active at a time? 3. What is the recommended approach for handling these transport implementations to avoid duplicate connections? 4. Why does SYNC mode fail to start, and what is the proper way to handle the auto-configuration order?

Environment: - Spring AI version: [1.0.0 M6] - Spring Boot version: [3.4.3] - Java version: [JDK 17]

Comment From: devnomad-byte

I have closed the duplicate questions. This one is kept and I have already written the code and am ready to submit it.

Comment From: devnomad-byte

Current Issues

  1. Duplicate SSE Connections Problem
  2. When both WebFlux and HTTP Client are available, McpClientAutoConfiguration loads both implementations
  3. SseWebFluxTransportAutoConfiguration and SseHttpClientTransportAutoConfiguration create duplicate connections

  4. Results in unnecessary resource consumption and potential performance issues

  5. Duplicate MCP Tools Creation

  6. Multiple identical MCP tools are created due to duplicate transport implementations
  7. Affects system efficiency and resource utilization
  8. May cause confusion in tool management and callbacks

Proposed Solution

  1. Transport Mode Configuration java public enum SseTransportMode { WEBFLUX, // Default implementation HTTP_CLIENT }

  2. Configuration Property properties spring.ai.mcp.client.sse.transport-mode=WEBFLUX # Default # or spring.ai.mcp.client.sse.transport-mode=HTTP_CLIENT

  3. Implementation Details

  4. Add transport mode selection in McpSseClientProperties
  5. Use conditional loading to ensure single implementation
  6. Optimize tool creation process
  7. Maintain backward compatibility

Benefits

  1. Resource Efficiency
  2. Single SSE connection per endpoint
  3. Optimized tool initialization

  4. Reduced memory footprint

  5. Better Configuration Control

  6. Explicit transport mode selection
  7. Clear configuration options

  8. IDE support with metadata

  9. Improved Stability

  10. Prevents duplicate connections
  11. Streamlined tool management
  12. Better error handling

Testing Requirements

  1. Verify single transport initialization
  2. Test tool creation and management
  3. Validate configuration switching
  4. Check backward compatibility

Related Files

  • McpClientAutoConfiguration.java
  • McpSseClientProperties.java
  • SseWebFluxTransportAutoConfiguration.java
  • SseHttpClientTransportAutoConfiguration.java

Labels: enhancement, optimization, configuration

Comment From: devnomad-byte

I apologize for the previous incomplete submission. I have created a new PR (spring-projects/spring-ai#2493) with a more comprehensive solution:

Improvements in the New PR

  1. More Complete Solution:
  2. Added transport mode configuration (WEBFLUX/HTTP_CLIENT)
  3. Optimized connection management

  4. Provided explicit configuration options

  5. Better Implementation: properties spring.ai.mcp.client.sse.transport-mode=WEBFLUX # Default # or spring.ai.mcp.client.sse.transport-mode=HTTP_CLIENT

  6. Comprehensive Testing:

  7. Verified single transport initialization
  8. Tested configuration switching
  9. Ensured backward compatibility

I suggest closing this issue (#2486) and moving the discussion to the new PR: https://github.com/spring-projects/spring-ai/pull/2493

2493

Thank you for your understanding and support.

Signed-off-by: aliyun1024qjc qjc1024@aliyun.com

Comment From: ilayaperumalg

@devnomad-byte Thanks for the detailed write up and submitting the PR as well. Based on the discussions from https://github.com/spring-projects/spring-ai/pull/2493, marking this as complete. Please feel free to re-open if you still see any issues.