SpringAI MCP Server开发实战：工具声明与SSE服务启动

从零理解 MCP Server 的开发思路

MCP（Model Context Protocol，模型上下文协议）正在成为 AI Agent 对接外部工具的重要标准。在这节基于 SpringAI 的实战教程里，讲解者围绕一个具体的股票分析场景，演示了如何声明工具、组织服务并对外提供能力。

整个 Demo 的核心是三个相互衔接的服务：第一个通过装饰器完成工具声明，把普通函数暴露成 MCP 可调用的工具；第二个负责计算近三天某只股票的实际行情情况；第三个则在前两者的基础上生成投资建议报告。这三个服务串联起来，恰好构成了一个「数据获取 → 数据分析 → 结论输出」的小型 Agent 工作流，是理解 MCP Server 职责划分的好例子。

工具声明：装饰器是关键一步

在 MCP Server 中，工具（Tool）是暴露给上层 Agent 调用的最小能力单元。教程里用装饰器的方式进行工具声明——这意味着开发者只需在普通的函数上加一个标注，框架就能自动识别其输入输出，并在协议层面注册为可被调用的工具。

这种声明式写法降低了接入成本：开发者把精力放在业务逻辑（比如抓取股票数据、计算走势、拼装报告）上，而工具的注册、参数解析和调用路由交给框架处理。对于零基础的学习者来说，先理解「装饰器 = 工具入口」这个映射关系，再去扩展具体业务，是比较顺的学习路径。

MCP（Model Context Protocol）由 Anthropic 于 2024 年底提出并开源，目标是为 AI 模型与外部工具、数据源之间的交互建立统一标准。在此之前，每个 AI 应用往往需要为不同工具单独编写接入逻辑，协议不统一导致大量重复工作。MCP 的设计类似 USB 接口的理念：服务端（MCP Server）负责把能力封装并声明出来，客户端（MCP Client，通常是 Agent 或 LLM 宿主程序）按照协议格式调用即可，双方不需要了解彼此的内部实现。SpringAI 是 Spring 生态对接大模型的官方框架，内置了对 MCP 协议的支持，使得 Java/Kotlin 开发者可以用熟悉的注解风格快速构建 MCP Server，而无需从零解析协议报文。

用 SSE 协议对外启动服务

完成三个工具的实现后，教程选择以 SSE（Server-Sent Events）协议的形式将这三个服务统一启动起来。SSE 是 MCP 常见的传输方式之一，适合服务端向客户端持续推送事件，Agent 调用工具并获取流式返回时体验较好。

讲解者的做法是把三个服务一次性全部拉起，然后逐个确认服务是否正常运行。这种「先全部启动、再检查状态」的方式在本地调试阶段很实用，能快速验证各个工具是否都注册成功、端口是否被占用等常见问题。

SSE（Server-Sent Events）是基于 HTTP 的单向实时通信协议——服务端可以在一条长连接上持续向客户端推送文本事件流，而无需客户端反复轮询。与 WebSocket 的双向通信不同，SSE 仅支持服务端到客户端方向的推送，但实现更轻量，天然兼容标准 HTTP 基础设施（如反向代理、负载均衡）。在 MCP 语境中，Agent 发出工具调用请求后，工具执行结果（尤其是 LLM 生成的流式文本）可以通过 SSE 逐步返回，用户看到的就是「打字机」式的逐字输出效果。MCP 规范同时支持 Stdio（标准输入输出，适合本地进程间通信）和 SSE 两种传输方式，面向网络服务场景时 SSE 是更常见的选择。

运行环境之争：UV 还是 Conda？

教程中一个值得关注的细节，是关于 MCP Server 运行环境的选择。讲解者提到，MCP 官方文档其实并不建议用他演示的这种方式直接起服务，而是推荐使用 UV 来启动。

官方推荐：UV 方式

UV 是近年流行的 Python 包与环境管理工具，速度快、依赖解析清晰。如果采用 UV 的方式，安装依赖包、创建虚拟环境都走 UV 这一套，启动命令也相应变成 uv run（配合 nohup uv run 可以让服务在后台持续运行）。它依托的是 Linux 或 Windows 系统自身的虚拟环境，而不走 Conda 的那一套激活流程。

UV 由 Astral 团队（也是代码格式化工具 Ruff 的开发者）用 Rust 编写，于 2024 年正式发布。它的核心优势在于：依赖解析速度比 pip 快数十倍，内置虚拟环境管理（类似 venv），同时支持通过 pyproject.toml 锁定依赖版本，方便复现环境。对于 MCP Server 这类需要在不同机器间快速部署的场景，UV 可以在没有预装任何依赖的环境下，通过 uv run script.py 一条命令完成依赖安装并执行脚本，极大降低了环境配置的心智负担。官方文档倾向于推荐 UV，部分原因也在于 MCP Server 的很多示例本身是用 Python 编写的，而 UV 已逐渐成为 Python 现代工具链的事实标准之一。

实际选择：Conda 同样可行

不过讲解者也坦言，用不用 UV「因人而异」。他本人习惯用 Conda 来管理这些依赖包，直接在激活的虚拟环境里用一行命令就能把服务起来，同样能正常工作。换句话说，官方推荐 UV 更多是出于一致性和便利性的考量，而非硬性要求——学习阶段用自己熟悉的工具链即可，关于 UV 运行 MCP 的资料网上也非常丰富，可作为课后拓展。

小结：这节课到底教了什么

抛开工具链的细枝末节，这节教程的主线其实很清晰：

• 用装饰器声明工具，把业务函数变成 MCP 可调用能力；
• 围绕股票场景设计三个协作服务，构成一个最小 Agent 工作流；
• 以 SSE 协议统一对外提供服务，并在本地逐一验证运行状态；
• 环境管理上，官方倾向 UV，但 Conda 等自有环境方案同样可行。

对于想入门 AI Agent 开发的读者，MCP Server 是绕不开的一环。理解「工具声明—服务编排—协议暴露」这条链路，比纠结于用哪种虚拟环境更重要。建议动手把三个服务跑通，再去对照官方文档尝试 UV 启动方式，加深对运行环境差异的理解。