目录前言1. 先搞清楚Tool Calling和MCP不是一回事Tool Calling解决什么MCP解决什么2. 今天要做一个什么Demo3. 第一步创建MCP Server4. 第二步把现有OrderService包装成MCP Tool5. 再暴露一个库存Tool6. 为什么我建议增加Adapter而不是直接改Service7. Tool Description千万不要随便写8. 第三步创建MCP Client9. 第四步把MCP Tool交给ChatClient10. 到这里MCP到底帮我们做了什么直接Tool CallingMCP11. REST API已经有了还有必要做MCP吗12. 一个Agent可以连接多个MCP Server吗13. MCP并不意味着“所有Service都暴露出去”14. MCP、Tool Calling、Agent之间到底是什么关系Tool CallingMCPAgent15. 总结前言很多 Java 开发者第一次接触 MCP会觉得它是一个全新的 AI 技术体系。但如果你已经做了很多年 Spring Boot其实完全可以换一个角度理解。假设公司现在已经有一套订单系统OrderController ↓ OrderService ↓ OrderRepository ↓ MySQL以前调用它的是前端 第三方系统 其他微服务现在我们想增加一个 AI 助手让用户可以直接问帮我查询订单 A1001 现在是什么状态甚至查一下订单 A1001如果还没发货再帮我看看商品 SKU1001 还有多少库存。问题来了大模型怎么调用我们已经存在的 Java 业务能力难道为了 AI 再重写一套订单服务当然没必要。MCP 真正有价值的地方之一就是可以把现有业务能力包装成一种 AI 客户端能够发现和调用的标准能力。最终链路可以变成用户 ↓ AI应用 ↓ LLM ↓ 发现需要查询订单 ↓ MCP Client ↓ MCP Server ↓ OrderService ↓ 数据库所以这一篇不先讲复杂的 MCP 协议细节。我们直接解决一个问题如何使用 Spring AI 2.0把现有 Spring Boot Service 变成 AI 可以调用的 MCP Tool1. 先搞清楚Tool Calling和MCP不是一回事在写代码之前这两个概念一定要先分清。很多刚开始学习的人会把Tool Calling MCP混在一起。实际上它们解决的问题并不完全相同。Tool Calling解决什么Tool Calling 解决的是模型如何表达“我现在需要调用一个工具”。例如用户问查询订单 A1001。模型发现自己不知道实时订单状态于是返回一个 Tool Call{ name: queryOrder, arguments: { orderNo: A1001 } }注意模型只是说我要调用queryOrder。真正执行 Java 方法的依然是我们的应用系统。所以 Tool Calling 的基本流程是User ↓ LLM ↓ 决定调用queryOrder ↓ Application执行Tool ↓ 返回Tool Result ↓ LLM生成最终答案MCP解决什么当系统越来越复杂以后问题来了。今天订单系统自己定义一套 ToolqueryOrder明天库存系统又定义queryInventory后天 CRM、工单、知识库都要给 AI 用。如果每个 AI 应用都自己重新接一遍就会变成AI应用A → 订单接口 AI应用A → 库存接口 AI应用A → CRM AI应用B → 订单接口 AI应用B → 库存接口 AI应用B → CRM耦合越来越重。MCP——Model Context Protocol——解决的一个核心问题就是用统一协议把 Tool、Resource、Prompt 等能力暴露给 AI Client。所以可以简单理解成Tool Calling 解决 模型什么时候调用工具 MCP 解决 这些工具如何被标准化暴露、发现和调用两者不是竞争关系。而是经常组合使用。2. 今天要做一个什么Demo我们模拟一个最常见的企业场景。现有系统已经有订单服务 OrderService 库存服务 InventoryService里面已经存在业务代码Service public class OrderService { public OrderInfo queryOrder(String orderNo) { // 实际项目中这里查询数据库 return new OrderInfo( orderNo, PAID, SKU1001, 2 ); } }库存服务Service public class InventoryService { public InventoryInfo queryInventory(String skuCode) { return new InventoryInfo( skuCode, 128 ); } }以前这些 Service 可能被 Controller 调用HTTP Request ↓ Controller ↓ Service现在我们的目标是AI ↓ MCP ↓ Service重点是原有业务逻辑不重写只增加一层 MCP Adapter。最终用户可以说查询订单 A1001 的状态并告诉我这个订单对应商品还有多少库存。然后模型自己完成queryOrder(A1001) ↓ 得到SKU1001 ↓ queryInventory(SKU1001) ↓ 生成自然语言回答这就是一个最基础的 Agent MCP 使用场景。3. 第一步创建MCP Server首先创建一个新的 Spring Boot 服务。如果我们使用传统 Spring MVC可以加入dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-mcp-server-webmvc/artifactId /dependencySpring AI 2.0 已经支持STDIO SSE Streamable HTTP Stateless对于一个独立部署的 Spring Boot MCP Server我更建议直接使用Streamable HTTP配置server: port: 8081 spring: ai: mcp: server: name: business-mcp-server version: 1.0.0 type: SYNC protocol: STREAMABLE streamable-http: mcp-endpoint: /mcp这样一个基础 MCP Server 就已经准备好了。4. 第二步把现有OrderService包装成MCP Tool这里我不建议直接把 AI 注解全部塞进原来的业务 Service。例如原来Service public class OrderService { public OrderInfo queryOrder(String orderNo) { // 业务逻辑 } }最好继续保持它只负责业务。然后单独增加OrderMcpTools作为 MCP Adapter。代码Component public class OrderMcpTools { private final OrderService orderService; public OrderMcpTools(OrderService orderService) { this.orderService orderService; } McpTool( name query_order, description 根据订单编号查询订单当前状态、商品SKU和购买数量, generateOutputSchema true ) public OrderInfo queryOrder( McpToolParam( description 订单编号例如A1001, required true ) String orderNo ) { return orderService.queryOrder(orderNo); } }Spring AI 2.0 的 MCP Annotation 会自动扫描这个 Bean并把方法注册成 MCP Tool。所以我们不需要自己写Tool JSON Schema Tool Registry Tool Definition框架会根据方法 参数 注解自动完成注册。5. 再暴露一个库存Tool库存服务同样处理Component public class InventoryMcpTools { private final InventoryService inventoryService; public InventoryMcpTools( InventoryService inventoryService) { this.inventoryService inventoryService; } McpTool( name query_inventory, description 根据商品SKU查询当前可用库存数量, generateOutputSchema true ) public InventoryInfo queryInventory( McpToolParam( description 商品SKU编码例如SKU1001, required true ) String skuCode ) { return inventoryService.queryInventory(skuCode); } }现在 MCP Server 对外已经提供两个 Toolquery_order query_inventory启动 Spring Boot 后MCP Client 就可以发现这些能力。于是原来的Spring Boot Service已经变成Spring Boot Service ↓ MCP Adapter ↓ MCP Tool ↓ AI可发现能力6. 为什么我建议增加Adapter而不是直接改Service这是一个很小但很重要的设计。当然你完全可以这样写Service public class OrderService { McpTool(...) public OrderInfo queryOrder(...) { } }Demo 没问题。但是企业项目里我更倾向于OrderService ↓ OrderMcpTools原因是业务能力和AI暴露边界不是一回事。一个 Service 里可能有queryOrder createOrder cancelOrder refundOrder deleteOrder但我们并不一定希望 AI 全部看到。通过 MCP Adapter可以明确控制哪些方法暴露 Tool叫什么 参数如何描述 返回什么结构 哪些字段允许给AI这样业务层完全不用为了 AI 改造。这和 Controller 很像Controller 是HTTP适配层 MCP Tools 是AI适配层底层复用的依然是Service对于 Java 开发者来说这样理解其实就简单很多了。7. Tool Description千万不要随便写做到这里以后经常会遇到一个问题Tool明明注册成功了为什么模型就是不用一个非常常见的原因就是Description写得太差。例如McpTool( name query_order, description 查询 )对于模型来说查询什么什么时候调用返回什么它根本不知道。更合理的描述应该是McpTool( name query_order, description 根据订单编号查询订单当前状态、商品SKU和购买数量 )参数同样如此。不要只写McpToolParam(description id) String orderNo而应该写McpToolParam( description 订单编号例如A1001, required true ) String orderNo因为模型选择 Tool 的依据本质上就是Tool Name Tool Description Input Schema 当前用户问题所以Tool Description本身就是Prompt的一部分。这也是 Tool Calling 开发中非常容易被低估的地方。8. 第三步创建MCP Client现在服务端已经完成。下一步创建 AI 应用。加入dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-mcp-client/artifactId /dependency然后配置 MCP Serverspring: ai: mcp: client: enabled: true name: business-ai-client version: 1.0.0 type: SYNC streamable-http: connections: business: url: http://localhost:8081 endpoint: /mcp客户端启动以后会连接business-mcp-server然后获取它当前暴露的 Tool。比如query_order query_inventorySpring AI 会把这些 MCP Tools 转换成自己能够使用的ToolCallback到这里 MCP 和 Spring AI Tool Calling 就真正接上了。9. 第四步把MCP Tool交给ChatClientMCP Client 会提供一个 ToolCallbackProvider。我们可以直接注入Service public class AiAssistantService { private final ChatClient chatClient; public AiAssistantService( ChatClient.Builder builder, SyncMcpToolCallbackProvider mcpTools) { this.chatClient builder .defaultTools(mcpTools) .build(); } public String chat(String question) { return chatClient.prompt() .user(question) .call() .content(); } }现在我们调用aiAssistantService.chat( 查询订单A1001的状态 并告诉我对应商品还有多少库存 );整个过程就可能变成1. 用户提问 查询订单A1001的状态 并告诉我商品还有多少库存 ↓ 2. LLM分析 需要先知道订单信息 ↓ 3. Tool Call query_order( orderNo A1001 ) ↓ 4. MCP Client 调用远程MCP Server ↓ 5. OrderService 返回 { orderNo: A1001, status: PAID, skuCode: SKU1001, quantity: 2 } ↓ 6. LLM继续判断 还需要查询SKU1001库存 ↓ 7. Tool Call query_inventory( skuCode SKU1001 ) ↓ 8. 返回 { skuCode: SKU1001, availableStock: 128 } ↓ 9. LLM生成最终答案最终用户看到订单 A1001 当前状态为已支付购买商品 SKU1001 共 2 件。目前该商品可用库存为 128 件。注意整个过程中我们并没有在代码里写if (question.contains(库存)) { queryInventory(); }到底需不需要调用 Tool、调用哪个 Tool是模型根据问题和 Tool 定义决定的。10. 到这里MCP到底帮我们做了什么如果不用 MCP我们当然也可以写Tool public OrderInfo queryOrder(...) { }然后直接chatClient.prompt() .tools(orderTools) .call();完全可以。所以很多人会问既然Spring AI Tool Calling已经能调用Java方法为什么还需要MCP关键区别在于能力边界。直接Tool Calling通常更像AI Application ├── OrderTools ├── InventoryTools └── CustomerTools工具和 AI 应用部署在一起或者至少由 AI 应用自己维护。适合单个项目 本地业务能力 简单AI应用MCP则可以变成┌─ Order MCP Server AI Application ───┼─ Inventory MCP Server ├─ CRM MCP Server └─ Knowledge MCP Server工具提供方和 AI 应用可以完全分开。一个 MCP Server 也可以被多个 AI Client 使用AI客服 ↘ Order MCP Server ↗ AI运营助手所以我更倾向于这样理解Tool Calling解决“AI怎么调用能力”。MCP解决“能力怎么标准化提供给AI”。11. REST API已经有了还有必要做MCP吗还有一个 Java 开发者很容易问的问题我们系统已经有 REST API 了为什么不让 Agent 直接调用 RESTREST 当然不会消失。而且 MCP 并不是来替代 REST 的。原来的业务结构完全可以继续存在┌→ REST Controller → 前端 │ OrderService ──┤ │ └→ MCP Tools → AI Client真正复用的是业务 Service。也就是说REST 面向传统系统集成 MCP 面向AI能力发现和调用二者可以同时存在。我反而不推荐MCP Tool ↓ HTTP调用自己Controller ↓ Service如果就在同一个系统内部完全可以直接调用 Service。少绕一层 HTTP。12. 一个Agent可以连接多个MCP Server吗当然可以。Spring AI MCP Client 本身就支持配置多个连接。例如spring: ai: mcp: client: streamable-http: connections: order: url: http://order-mcp:8081 endpoint: /mcp inventory: url: http://inventory-mcp:8082 endpoint: /mcp customer: url: http://customer-mcp:8083 endpoint: /mcp最终 AI 可以获得订单Tool 库存Tool 客户Tool用户说查询客户 C1001 最近一个订单如果还没有发货再检查一下商品库存。Agent 就有可能完成queryCustomer ↓ queryLatestOrder ↓ queryInventory ↓ Final Answer这时候 MCP 的价值就开始明显了。我们不再是在给某一个ChatBot写几个Function。而是在给AI系统建设可以重复使用的业务能力接口。13. MCP并不意味着“所有Service都暴露出去”写到这里也要提醒一个非常重要的问题。千万不要看到 MCP 方便就开始OrderService所有方法 全部MCP化 UserService所有方法 全部MCP化 AdminService所有方法 全部MCP化MCP Server 应该暴露的是经过设计的AI业务能力。而不是整个Service层。例如订单系统可能只暴露query_order query_order_logistics而不是直接暴露delete_order force_refund modify_payment_status update_databaseTool 越多也不一定越好。大量名称相近的 Tool 反而可能增加模型选择错误的概率。所以设计 MCP Tool 时我一般会优先考虑职责是否单一 名字是否清晰 Description是否明确 参数是否最小 返回是否结构化 是否真的需要AI调用至于更进一步的权限 鉴权 审计 敏感Tool确认 超时 限流属于 MCP 真正进入企业生产后的下一层问题。这篇先不展开。14. MCP、Tool Calling、Agent之间到底是什么关系最后再把三个经常混在一起的概念串一下。Tool Calling是一种能力模型可以请求调用工具。MCP是一套协议Tool、Resource、Prompt 等能力可以通过统一方式提供给 AI Client。Agent是一种任务执行模式根据当前目标不断决定下一步做什么。它可能思考 ↓ 调用Tool ↓ 拿到结果 ↓ 继续判断 ↓ 再调用Tool ↓ 完成任务所以三者可以组合成Agent 负责决策 ↓ Tool Calling 负责表达工具调用 ↓ MCP 负责连接标准化工具能力 ↓ Spring Boot Service 负责真正业务执行这个关系理解以后MCP 就没有那么玄学了。15. 总结如果你本身就是 Java / Spring Boot 开发者我认为学习 MCP 最好的方式并不是先研究一大堆协议字段。而是先完成这样一个改造已有Spring Boot Service ↓ MCP Adapter ↓ MCP Server ↓ MCP Client ↓ Spring AI ChatClient ↓ LLM整个过程中原来的Controller Service Repository Database都不用推倒重来。我们只是给现有系统增加了一种新的能力出口以前业务能力主要给人和传统系统调用现在也可以标准化地提供给AI。如果只记住一句话我觉得可以记这个Tool Calling让AI知道“我要调用一个工具”MCP让这个工具可以用标准方式被AI发现和调用。而对于 Java 开发者来说MCP Server并不是重新写一套AI业务系统本质上是在现有Spring Boot业务能力之上增加一层AI Adapter。先把这一层跑通后面再继续讨论MCP权限怎么做 多个MCP Server怎么管理 Tool是否需要鉴权 敏感Tool怎么人工确认 MCP Gateway有没有必要就会容易很多。 AI项目实战我也在持续维护一个面向企业真实业务场景的Java AI 开源项目Spring AI Business Copilot。项目基于Java Spring AI构建包含知识库、数据分析NL2SQL、客服、报表、招聘等典型企业 AI 场景并持续实践RAG、Tool Calling、Workflow、Agent、Human-in-the-loop、Guardrails、调用审计与工程治理。如果你正在学习 Java AI 应用开发或者想看看一个 AI 项目如何从 Demo 逐步走向完整业务系统可以作为学习和项目实践参考。 GitHubqcodingdev/spring-ai-business-copilot如果项目对你有帮助欢迎Star支持。 关于作者QCoding专注AI应用开发与Java技术实践。持续分享Spring AI、RAG、 Agentic、Agent Evaluation、企业AI架构、工程治理与AI转型实践
