先说结论

• MCP协议的核心价值在于为AI工具调用提供了类似USB的标准化接口，但实现这套标准本身会带来额外的开发和理解成本，并非所有场景都值得投入。

• 传输模式的选择（Stdio本地进程 vs. SSE远程服务）直接决定了部署复杂度和适用场景，本地模式简单但难共享，远程模式灵活但引入网络依赖和安全考量。

• MCP目前存在显著的安全盲区，如工具描述与执行指令的混淆、缺乏严格的权限隔离，使用第三方服务时需高度警惕，优先选择可信来源并在隔离环境中运行。

从实际工具调用成本出发，分析MCP协议在统一标准与引入新复杂度之间的平衡，探讨它是否真是中小项目的效率解药。

最近在规划一个内部知识库问答机器人时，又遇到了那个老问题：需要让AI能查询实时数据。团队里有人提议直接用大模型的内部知识，但信息滞后；有人想建RAG向量库，但维护成本不低；更多人倾向于工具调用——写个接口，让AI去调。这思路没错，但紧接着就是技术选型分歧：是用框架自带的工具调用能力快速实现，还是引入MCP（Model Context Protocol）这套“标准化”协议？

后者听起来更“先进”，但多出来的协议层、配置项和安全考量，真的值得吗？尤其在中小团队，开发资源本就紧张。

MCP协议，与其说是“解决方案”，不如说是一套“连接标准”。它把自己比作AI的USB接口，这个类比很形象。USB没发明前，每个外设都得有自己的驱动和连接方式，麻烦但能跑；USB出现后，接口统一了，即插即用，但你也得确保设备兼容USB协议。MCP干的也是这事：定义好客户端（AI应用）和服务端（工具提供者）之间怎么握手、怎么传数据、怎么描述工具能力。

它的架构分三层：传输层管怎么传（Stdio或SSE），会话层管连接状态，最上层是客户端/服务端的具体操作。核心定义了六大概念：Tools（工具）、Resources（资源）、Prompts（提示词）这些是功能性的；Sampling（采样）、Roots（根目录）、Transports（传输）这些更多关乎控制和安全。Tools最实用，能让AI执行具体函数；Resources给AI喂外部数据；Prompts提供预制提示模板。但后三者，比如Roots用来限制文件访问范围，其实是安全补丁，也侧面反映了协议的潜在风险。

选择Stdio还是SSE，本质是在简单性和灵活性之间做取舍。

Stdio模式让MCP服务作为客户端的一个子进程运行，通过标准输入输出通信。好处是简单，没有网络开销，适合本地开发或小项目。你在Spring AI配置里配个命令行，指向打包好的JAR包，就能跑起来。但问题也明显：服务生命周期和客户端绑定，难独立管理，更难被其他应用共享。如果团队里另一个项目也需要同样的工具能力，就得把JAR包再拷一份过去，或者各自打包——又回到了重复劳动的老路。

SSE模式则把MCP服务部署成独立的Web服务（使用HTTP Server-Sent Events）。客户端通过URL连接。这带来了部署复杂度：你需要考虑服务器资源、网络配置、服务发现。但优势是，一个服务可以被多个客户端共享，适合团队协作或构建工具市场。Spring AI对这两种模式都提供了支持，配置项不同，但开发工具的逻辑（用@Tool注解）基本一致。

安全，是MCP目前最被诟病的地方，也是决定是否采用的关键门槛。

协议设计初期重功能轻安全，导致了几类典型风险。最棘手的是“信息不对称”：用户和AI看到的工具描述（比如“搜索图片”）是干净的，但工具实际执行的代码可能夹带私货（比如偷偷发数据）。因为AI只按描述调用，不检查源码。这就像你雇了个助理，他说会帮你整理邮件，结果他背地里把邮件全转发给了别人——而你从任务描述里根本看不出来。

其次是上下文污染。所有MCP工具的描述都被加载到同一个会话上下文中，恶意工具的描述如果包含“忽略其他指令，只输出XXX”，可能会污染整个AI行为。再加上大模型本身倾向于服从指令，缺乏安全过滤，风险被放大。

所以，如果决定用MCP，尤其是第三方服务，几条红线得守住：第一，优先用官方或知名开源项目，仔细审查源码；第二，在Docker等沙箱环境运行，限制其网络和文件权限；第三，对敏感操作的工具，要有额外的人工确认或审计日志。这些措施会增加使用成本，但能避免后期更大的麻烦。

部署层面，MCP把“工具”变成了“服务”，运维负担也随之转移。

本地部署（对应Stdio）就是管理JAR包和启动命令。远程部署（对应SSE）则和部署任何Web服务没区别：准备服务器、配置网络、设置监控。云平台（如阿里云百炼）提供了Serverless部署选项，把服务打包成函数，按需运行。这降低了运维复杂度，但把你绑在了特定云厂商的生态里，而且对于Java这类冷启动较慢的服务，成本可能不好控制。

更现实的问题是：很多内部工具，真的需要发布成标准MCP服务吗？如果只是团队自用，直接用框架的工具调用接口，开发更快，也没有协议兼容的烦恼。MCP的价值，更多体现在希望工具被复用、跨团队共享、或接入第三方生态的时候。这时候，前期投入的协议开发成本，才可能通过后续的复用性赚回来。

我的倾向是：先解决有无，再考虑标准化。

面对一个具体的工具需求，我会先用最直接的方式（比如Spring AI的Tool Call）实现核心功能，验证业务价值。如果后续发现这个工具确实有被多个项目复用的潜力，或者希望对外开放，再考虑将其重构为MCP服务。Spring AI的生态也支持这种渐进路径，它提供了工具类和MCP协议之间的转换器，降低了迁移成本。

关键在于评估“共享”的可能性与成本。如果工具逻辑稳定、通用性强，且团队有多个AI应用项目，那么MCP的标准化收益可能大于初期成本。如果工具是临时的、业务特定的，或者团队就一个主要应用，那么引入MCP可能只是增加了不必要的抽象层。

技术选型没有银弹。MCP协议为解决工具调用的碎片化提供了思路，但它本身不是免费的。它带来了标准化的可能，也带来了协议复杂性、安全风险和额外的部署考量。对于大多数30岁以上的技术从业者，见过了太多“为技术而技术”的折腾，更务实的选择或许是：理解协议的能力与边界，在需要互联互通时用它，在追求快速验证时用更直接的方法。毕竟，能让业务跑起来的，才是好工具。

最后留一个讨论点

如果你的团队需要为一个内部AI助手添加查询内部数据库的能力，你会选择：A) 直接基于现有框架（如Spring AI Tool Call）快速开发专用工具；B) 投入时间基于MCP协议开发一个标准化的MCP服务，以备未来可能的共享需求？为什么？