Should Spring AI MCP Client support Service Discovery integration?

[SkyeBeFreeman]

Background

As Spring AI is increasingly adopted in enterprise microservices environments, a common pain point emerges: MCP client connections require statically configured URLs in application properties.

spring.ai.mcp.client.sse.connections.order-service.url=http://192.168.1.100:8080
spring.ai.mcp.client.sse.connections.inventory-service.url=http://192.168.1.101:8080

In a dynamic microservices landscape powered by service registries (Nacos, Consul, Eureka, Kubernetes), this approach has clear limitations:

• Scalability: Managing dozens of MCP server URLs manually is error-prone
• Availability: No automatic failover when an MCP server instance goes down
• Dynamism: New MCP servers cannot be discovered without restarting the consumer application

The Question

Should Spring AI provide first-class support for integrating MCP client transports with service discovery?

Option A: Interceptor-based (minimal, flexible)

Introduce a lightweight McpSseConnectionInterceptor / McpStreamableHttpConnectionInterceptor that lets users plug in any service discovery mechanism at startup:

@Bean
List<McpSseConnectionInterceptor> mcpDiscoveryInterceptors(DiscoveryClient discoveryClient) {
    return List.of((name, params) -> {
        ServiceInstance instance = discoveryClient.getInstances(name)
            .stream().findFirst()
            .orElseThrow();
        String resolvedUrl = "http://" + instance.getHost() + ":" + instance.getPort();
        return new SseParameters(resolvedUrl, params.sseEndpoint());
    });
}

Pros: Zero extra dependency, works with any registry, composable with Spring Cloud LoadBalancer
Cons: Requires user code; resolution happens at startup, not per-request

Option B: Dedicated spring-ai-mcp-client-spring-cloud module

Provide an optional auto-configuration module that bridges DiscoveryClient with MCP transport creation automatically, similar to how Spring Cloud OpenFeign integrates with Ribbon/LoadBalancer.

Pros: Zero boilerplate for Spring Cloud users; can support per-request resolution and load balancing
Cons: Additional dependency on spring-cloud-commons; adds maintenance burden

Option C: Dynamic MCP client management

Go further: support hot-plugging MCP servers at runtime by watching the service registry for changes, dynamically creating/destroying McpClient beans as services register and deregister.

Pros: True dynamic tooling — AI agents can discover new capabilities without restart
Cons: Significantly more complex; requires lifecycle management of McpClient beans

My Current Proposal

I've submitted PRs #5549 (1.1.x) and #5578 (main) implementing Option A as a low-risk first step. This unblocks enterprise users immediately while leaving the door open for Options B and C in the future.

Questions for the Community

1. Which option best fits Spring AI's design philosophy?
2. Is there appetite for a dedicated spring-ai-mcp-client-spring-cloud integration module?
3. Are there other service discovery patterns (e.g., DNS-based, K8s headless services) that should be considered?
4. Should dynamic runtime discovery (Option C) be on the roadmap?

Would love to hear thoughts from both the Spring AI team and the community!