第 4 章：MCP 把工具接入变成协议

在没有统一协议的情况下，每接一个外部系统都要写一套定制接口：鉴权、字段、错误语义都不一样。MCP 的意义是把这些差异压缩成标准层，让 agent 把外部系统视作统一的工具集合来使用。官方文档里的 MCP connector 与 remote MCP servers 对应“怎么接”和“怎么管”两个问题：前者让工具进入模型调用路径，后者让多个系统统一为可治理的服务端口。[16][17]

modelcontextprotocol.io 把 MCP 定位成开放协议。官方博客进一步解释了它的生态方向：降低接入成本、促成工具生态扩展，同时避免被单一厂商锁定，让协议能在不同平台之间复用。[18][44][45]

当工具数量成倍增长时，问题从“协议是否统一”变成“上下文是否可承受”。工程文章提出把 MCP 工具映射成可执行代码文件，让模型像浏览代码库一样发现工具，按需读取定义，再通过代码执行调用。这样工具定义与中间结果不必全部进入上下文，规模可以扩到上百上千工具。[59]

在这个模式里，工具不再是一段写进 prompt 的结构，而是一套可浏览的文件。模型先列目录找到相关服务器，再读具体文件确认接口，再通过执行环境完成调用。这种路径和 Tool Search 的“延迟加载”思路一致：都在强调按需加载，而不是一次性加载。[59][54]

MCP 也在客户端体验上做了工程化补齐。Desktop Extensions 把本地 MCP server 打包成可安装的扩展，用一键安装替代手动配置，让非开发者也能使用本地工具。它把“协议层”扩展到“分发层”，减少了工具接入的实际成本。[60]

把 MCP 放进 agent 体系里，核心价值不是“多了很多工具”，而是“所有工具都遵循同一个契约”。这样你可以把权限、审计、错误处理放在统一入口治理，而不是在每个系统里重复实现。扩展能力的成本下降了，但控制面没有被稀释。[16][17][29]