feat: Add MCP server endpoint for dynamic tool discovery and invocation

[syn-zhu]

Current Limitation

The kmcp controller manages the MCPServer CRD lifecycle — creating Deployments, Services, and ConfigMaps for MCP servers deployed in the cluster. However, it provides no runtime API for interacting with the MCP servers it manages.

Today, agents must statically bind MCP tool references at deploy time via the Agent CR's tools section. There is no way for an agent to dynamically discover or invoke tools on MCP servers without being redeployed with updated tool bindings.

Parallel with kagent-controller

The kagent-controller already exposes a Streamable HTTP MCP endpoint at :8083/mcp with two tools:

• list_agents — list invokable agents in the cluster
• invoke_agent — invoke an agent via A2A

This enables dynamic agent-to-agent communication. There is no equivalent for MCP server-to-server communication. The kmcp controller should provide the same capability for MCP server interactions.

Proposed Solution

Add a Streamable HTTP MCP server endpoint to the kmcp controller (:8083/mcp) exposing three tools:

Tool	Purpose
list_mcp_servers	List MCPServer CRs in the cluster (name, namespace, status, port, transport type)
list_tools	Connect to a specific MCPServer and return its available tools
call_tool	Invoke a specific tool on a specific MCPServer and return the result

Implementation approach

• Uses the same MCP Go SDK (github.com/modelcontextprotocol/go-sdk) and patterns as kagent-controller
• MCP handler wraps mcpsdk.StreamableHTTPHandler and registers tools via mcpsdk.AddTool
• HTTP server wrapper implements manager.Runnable for lifecycle integration with controller-runtime
• Session caching via sync.Map (same pattern as kagent's A2A client cache)
• Configurable via --mcp-bind-address flag (default :8083, set to 0 to disable)
• Helm chart updates: values, deployment port, dedicated ClusterIP service

Use Cases

1. Dynamic tool composition: An orchestrator agent discovers MCP servers via an agent registry (list_deployments), then dynamically calls their tools without redeployment:

   list_deployments → finds weather-mcp → list_tools("default/weather-mcp") → sees get_weather → call_tool("default/weather-mcp", "get_weather", {"city": "NYC"})
   

2. Admin/debugging agents: An admin agent can inspect what tools are available on any deployed MCP server in the cluster without static bindings.

3. Runtime adaptation: Agents can adapt their capabilities based on which MCP servers are currently available, enabling flexible multi-tool workflows.

Additional Context

A PR implementing this feature is available at #123.