分类：AI编程
从“模型看不到数据库”开始
当运维同事想在 Claude 中查询一笔订单时，他能做的只是把订单 ID 粘贴到聊天框，等待模型回复无法访问数据库，再手动把日志贴回去。这类场景暴露出一个现实问题：企业内部有订单服务、库存服务和日志平台，但 AI 客户端并不能直接触达这些系统。
Dev.to AI 的一篇技术文章给出的方案，是用 Spring AI 构建一个 MCP Server，把 Java 端点转换成 Claude 和 Cursor 可以直接调用的工具。按照文章说法，示例代码是一个完整项目，即使没有 LLM API key 也可以运行。对于需要让 AI 调用内部订单或运维 API 的团队，这提供了一个不必逐个修改客户端的接入路径。
MCP 解决的不是智能，而是连接
文章将问题拆开：MCP 不是为了解决“模型不够聪明”，而是解决“模型够不到你的系统”。如果产品经理使用 Claude Desktop 查询数据，后端工程师使用 Cursor 写代码并顺带查看生产订单，自研支持代理也需要查订单，那么三种客户端就意味着三种集成方式。
其中，Claude Desktop 需要 MCP 配置，Cursor 需要 .cursor/mcp.json，自研代理需要 JSON Schema 完成 function calling。开发者要为每种客户端写三套描述、三套参数校验和三套错误处理。如果下个月出现第四种客户端，集成工作还要再来一次。
MCP 的价值在于把 M×N 变成 M+N：所有 M 个客户端实现同一协议，所有 N 个系统也暴露同一协议，中间不再需要两两配对。文章用充电接口作类比：在 USB-C 出现之前，圆口、扁口、排线各自对应特定设备；接口统一后，充电器只需要供电，手机只需要接收。MCP 在 AI 工具调用中扮演的，就是这种统一接口角色。
- Host：用户直接交互的 AI 应用，例如 Claude Desktop、Cursor 或自研支持控制台。
- Client：Host 内部的连接器，一个 Client 连接一个 Server，由 Host 启动时根据配置创建。
- Server：开发者编写的程序，负责对外暴露工具和数据。文中示例是一个订单管理 Server。
一个 Host 可以打开多个 Client，并连接多个 Server。若在 Claude Desktop 中配置三个 MCP Server，就会运行三个 Client。Server 对外提供的内容分为三类：工具、资源和提示。区别在于控制权：工具由模型自行判断是否调用；资源由客户端放入上下文；提示则由人在界面中点击触发。
JSON-RPC 2.0 上的握手、列表与调用
文章还纠正了两个常见误解。第一，MCP 不是模型能力，而是一种传输协议，和 HTTP 处于类似层级。模型并不知道 MCP 存在，它看到的只是“这里有一些工具，以及这些工具参数长什么样”。真正把 MCP 工具列表转换成模型可理解的 Function Calling 格式的，是 Host。
第二，写好 MCP Server 并不意味着模型一定会正确使用它。工具名称、描述和参数文档是否清晰，会直接影响模型选择。例如，一个查询接口如果只写成“query order”，模型在想查用户时也可能调用；如果写成“按订单号查询订单详情；订单号以 SO 开头”，命中率会发生变化。因此，文章强调的重点不仅是“如何暴露 API”，还包括“如何让模型正确调用”。
在通信层，MCP 消息使用 JSON-RPC 2.0。第一步是握手：客户端发送 initialize，告知服务器自己支持的 capabilities 和协议版本；服务器返回自身能力列表。文中示例包含 protocolVersion 为 2025-06-18、clientInfo 为 cursor 1.0。服务器响应里，Mcp-Session-Id 响应头尤其重要，后续请求都要携带它，服务器据此识别这是同一个客户端会话。
第二步是工具列表：客户端发送 tools/list，服务器返回工具数组。每个工具包含 name、description 和 inputSchema，其中 inputSchema 是标准 JSON Schema。模型最终看到的工具，是 Host 对这个数组进行转换后的结果。
第三步是调用：当模型决定使用某个工具，Host 会发送 tools/call，并携带工具名和参数对象。文中示例调用 get_order，参数为 orderNo: SO20261027001。Server 执行完成后返回 content 数组，内容条目可以是文本、图片或资源引用，模型再读取这些内容继续推理。握手完成后，Client 还会发送 notifications/initialized 通知；它不带 id，也无需响应。
传输层面，同一套消息可以走两种管道：一种是 stdio，Host 生成子进程并通过 stdin/stdout 交换数据，适合本地工具和单一用途场景；另一种是 Streamable HTTP，通过 HTTP POST 发送消息，服务器以 SSE 流式返回响应。
对 Java 团队的意义
这篇实践文章把 MCP 从协议概念落到了 Java 工程语境。对于已有 Spring AI 和内部 API 体系的团队，真正的变化不在于让模型“更会回答”，而在于把订单、库存、日志等系统以统一方式暴露给多个 AI 客户端。
这也把接口设计的要求前移了。过去，API 文档主要给人看；在 MCP 场景中，工具描述还要给模型看。命名是否准确、参数说明是否足够具体、错误返回是否可被理解，都会影响 AI 是否能正确执行任务。对于需要在 Claude、Cursor 和自研控制台之间复用内部能力的团队来说，MCP Server 更像是一层新的接口治理。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/spring-ai-rang-nei-bu-ding-dan-he-yun-wei-api-bei-claude
