MCP: Sharing Tools Across Apps, Teams & Models

Two Teams, One Order-Lookup Tool

OrderTools.getRefundStatus from the first guide in this phase lives inside the support bot's codebase, as a @Component only that app can see. Then the Platform team, building an internal Slack bot for support staff, asks for the same capability — "can we look up refund status too?" The easy answer is copy-pasting OrderTools into their codebase. The correct answer is recognizing that's how two implementations quietly drift apart the first time the order schema changes.

Model Context Protocol (MCP), the open standard from Anthropic, exists for exactly this: expose a tool once, over a structured protocol, and let any MCP-compatible client — a different Java service, Claude Desktop, a Python agent, the Slack bot — call it without depending on your Java classes at all. It cuts both ways: your support bot can just as easily become a client, consuming tools someone else already built and exposed, instead of hand-writing an @Tool wrapper for every external capability it needs.

1. Exposing a Tool: Building an MCP Server

The annotation is @McpTool — deliberately similar to the @Tool annotation from the first guide, but scanned and exposed over the MCP protocol instead of registered directly on a ChatClient.

// build.gradle
implementation 'org.springframework.ai:spring-ai-starter-mcp-server-webmvc'

@Component
public class OrderMcpTools {
 
    private final OrderRepository orderRepository;
 
    public OrderMcpTools(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }
 
    @McpTool(name = "getRefundStatus", description = "Look up the current status of a refund by order ID")
    public RefundStatus getRefundStatus(
        @McpToolParam(description = "The order ID", required = true) Long orderId
    ) {
        return orderRepository.findRefundStatus(orderId)
            .orElseThrow(() -> new IllegalArgumentException("No order found with ID " + orderId));
    }
}

# application.yml
spring:
  ai:
    mcp:
      server:
        annotation-scanner:
          enabled: true

That's the entire server. Spring Boot scans for @McpTool-annotated methods on startup, generates the same kind of JSON schema @Tool does, and serves it over HTTP — the Platform team's Slack bot (or Claude Desktop, or anything else speaking MCP) can now discover and call getRefundStatus without ever seeing OrderRepository or a line of your Java source.

2. Consuming Tools: Building an MCP Client

Now the other direction — your support bot connecting out to tools it didn't write. Two connection types cover most real cases: STDIO for a locally-launched process (like the official filesystem server), and streamable HTTP for a deployed service (like an internal policy-docs MCP server run by another team).

// build.gradle
implementation 'org.springframework.ai:spring-ai-starter-mcp-client'

# application.yml
spring:
  ai:
    mcp:
      client:
        enabled: true
        stdio:
          connections:
            filesystem:
              command: npx
              args:
                - "-y"
                - "@modelcontextprotocol/server-filesystem"
                - "/data/policy-archive"
        streamable-http:
          connections:
            platform-orders:
              url: https://internal-mcp.acme.dev
              endpoint: /mcp

Two servers, two different transports, configured declaratively — no Java code needed just to establish the connections. Spring Boot auto-creates an McpSyncClient per configured connection and, from it, a SyncMcpToolCallbackProvider bean that wraps every discovered tool as a Spring AI ToolCallback.

@Service
public class SupportAgentService {
 
    private final ChatClient chatClient;
 
    public SupportAgentService(ChatClient.Builder builder, SyncMcpToolCallbackProvider mcpTools) {
        this.chatClient = builder
            .defaultToolCallbacks(mcpTools.getToolCallbacks())
            .build();
    }
}

mcpTools.getToolCallbacks() returns everything discovered across both configured servers — the filesystem tools and whatever platform-orders exposes — as ordinary ToolCallbacks. From here, they behave exactly like the @Tool-annotated methods from the first guide: the model decides when to call them, ToolCallingAdvisor runs the loop, and your application code never distinguishes "a local Java tool" from "a tool discovered from a remote MCP server."

3. Combining Local Tools and MCP Tools on the Same Agent

A ChatClient doesn't care whether a tool came from a local @Tool class or a remote MCP server — both are just ToolCallbacks by the time they reach ToolCallingAdvisor:

this.chatClient = builder
    .defaultTools(new CalculatorTools(), new EscalationTools(ticketService)) // local
    .defaultToolCallbacks(mcpTools.getToolCallbacks())                       // remote, via MCP
    .build();

One agent, calculating refunds locally, escalating locally, and pulling live order status or archived policy documents from two entirely separate teams' services — none of which needed to know this agent exists ahead of time.

What's Next

Your agent can now act on its own tools and on tools it discovered from other teams and services. The last guide in this phase closes the loop on quality: how do you actually know an agent's answers — retrieved, tool-assisted, or both — are correct, before a customer or Legal finds out otherwise?