MCP 到底解决了什么问题

过去一年用 AI 工具最大的别扭，不在模型能力，而在”它够不着我的东西”。它能在对话框里滔滔不绝，但读不到我本地那个目录、连不上我们内部的接口。

过去的解决办法是给每个客户端各写一套适配：给 A 工具写个插件，给 B 工具写个扩展，再来个 C 又得重写一遍。MCP 就是冲着这件事来的。

它解决的是什么问题

MCP（Model Context Protocol）把这件事拆成两端：客户端是模型所在的宿主（对话应用、编辑器、命令行工具），服务端是提供能力的一方（文件系统、数据库、代码仓库、内部 API）。

两边遵守同一套协议，于是：

说白了，就是把”给 AI 装工具”从”每个工具焊死在每个客户端上”，改成了”统一插槽”。

协议层面的概念不多，主要是几类东西：

Tools（工具）：可以调用的动作，比如读文件、查数据库、创建一个 issue。模型能主动发起调用，通常需要用户确认。

Resources（资源）：可以被读取的数据，比如某个文件、一段配置、一条记录。更接近”参考资料”。

Prompts（提示模板）：服务端预置的、常用的提示词模板，供客户端选择。

传输方式有本地进程的 stdio（服务端作为子进程跑在本机），也有基于网络的 HTTP/SSE 方式，用来连远程服务。今年协议本身更新了几次，网络传输的方案也在调整，具体细节建议看官方文档，我不逐条抄。

协议是 2024 年 11 月发布的，一开始主要在几家客户端里用。真正改变局面的是 2025 年 3 月——另一家大厂宣布支持，等于承认了它的事实标准地位。

标准的命运往往就是这样：技术设计好不好只是一半，另一半是有没有人跟。一旦主流客户端都支持，写服务端的人就有了动力；服务端多了，客户端不支持的代价就变大。这个正反馈起来之后，剩下的竞争就不在协议本身了。

权限是真问题。 一个能读你整个文件系统的服务端，本质上就是把家门钥匙交出去了。协议本身规定了用户确认环节，但实际使用里确认弹窗会疲劳——多的时候人会一路点同意，这就把安全设计架空了。

工具占上下文。 每个工具的描述、每个资源的说明都要占 token。装十几个服务端之后，还没开始干活，上下文已经被工具体系吃掉一大块。装得多不等于能力强。

错误处理比较糙。 工具调用失败的时候，返回的信息经常只是一句报错，模型拿不到足够信息去纠正。结果就是它反复试同一个错误调用。

调试麻烦。 客户端、模型、服务端三个环节，出问题的时候要一层层排。好在本地 stdio 的方式可以直接看日志，比早期的插件体系好一点。

我判断的标准是”重复”和”内部”这两个词。

如果你的团队反复在做同一类查询——查某个内部系统、拉一份固定格式的报表、按规则创建工单——那就值得写个服务端，省下来的是每天几十次手工操作。

如果你的知识只存在于内部系统里（wiki、工单、监控、配置中心），那么把这些接进模型比接一堆公开工具更有价值。

反过来，如果只是想让它读本地文件，现成的服务端已经够用，没必要自己写。

MCP 这个方向是对的：模型能力在快速上涨，但”能拿到什么”决定了它到底能不能干活。协议标准化是基础设施，基础设施的价值在它变得无聊之后才最大——就像现在没人会讨论 HTTP 是个多么聪明的设计。

但我对它短期内的实际收益保持谨慎。工具生态现在处于”数量优先”的阶段，装十个能用两个。真正值得期待的，是内部系统对接那部分——公开工具人人能装，把自家系统接进来这件事，才是别人抄不走的。