MCP 是什么？为什么每个做 AI 应用的人都应该了解它

每个构建过不止一个 AI 应用的开发者都写过同样的代码三遍。

连数据库那段，给它访问文件那段，让它调内部 API 那段。每次实现略有不同，错误处理不一样，认证方式不一样，需要单独维护。这是每个 AI 项目从原型走向上线时要付的隐性税。

MCP 要解决的就是这件事：让你只写一次。

一句话解释 MCP

模型上下文协议是连接 AI 应用和外部数据与工具的开放标准。Anthropic 团队用"AI 的 USB-C 接口"来描述它，这个类比准确在一个地方：接口定义一次，任何支持这个协议的东西都能插进来用，不需要双方提前约定专有格式。

没有 MCP 之前的集成路径：你想让助手访问 Notion，就写代码对接 Notion API，解析响应，处理限流和认证。然后想访问数据库，同样的流程再来一遍。有多少数据源，就要维护多少套逻辑。

有了 MCP：你为每个数据源写一个服务器，声明它能提供什么能力。任何支持 MCP 的客户端（Claude Desktop、VS Code Copilot、Cursor、Claude Code）都可以直接使用。为内部工具写的服务器，对所有这些 AI 工具都有效，不需要额外适配。

工具是 AI 可以主动调用的函数：跑数据库查询、创建日历事件、发 Slack 消息、触发部署。服务器定义工具做什么、需要什么参数，AI 根据任务自己判断什么时候用哪个。

资源是 AI 可以读取的数据：文件内容、数据库记录、API 返回值。资源是被动的，AI 读它；工具是主动的，AI 调它。真正有意思的工作大多通过工具来完成，因为工具是 AI 从知道事情变成能做事情的路径。

提示是可复用的指令模板：定义分析某类文档的方式，或者公司特定的写作风格。AI 按名称调用，你不需要每次重复相同的指令。

MCP 使用 JSON-RPC 2.0 通信。客户端连接服务器时先握手，声明各自支持的能力，协商协议版本。连接建立后，客户端调 tools/list 查可用工具，调 tools/call 带参数执行工具，调 resources/read 读取数据。

传输方式有两种：本地服务器用标准输入输出（AI 应用启动子进程，通过管道传数据），远程服务器用 HTTP，支持流式传输。两种用相同的消息格式，同一套服务器代码可以同时支持。

和简单 API 封装的一个区别：服务器可以主动推通知给客户端。工具列表变了（权限被撤销或新服务上线），服务器立刻告知所有连接的客户端，客户端不需要来轮询。

VS Code with Copilot、Claude Desktop、Cursor、Claude Code 都已支持 MCP。Anthropic 发布了文件系统、数据库、GitHub、Slack 的参考实现，社区还在持续贡献。

工具、资源、本地传输这三块已经稳定，可以直接用于生产。远程服务器的认证方案和长时间运行任务的支持（规范里标注为实验性）还在成熟中，用之前需要评估风险。稳定的核心已经够用，实验性的功能应该被当作实验性的对待。

MCP 创造了一个重要的分离：AI 模型按自己的节奏迭代，数据源留在原地，MCP 是两者之间的连接层，双方都不需要为对方做特定适配。

没有 MCP，更好的模型意味着可能要重建集成，因为新客户端需要为同样的系统重新写胶水代码。有了 MCP，更好的模型直接通过同一套协议连接同一批服务器。

对小团队来说这意味着：为内部系统写一次 MCP 服务器，之后每次模型升级自动受益，不需要额外集成工作。集成税不消失，但从"每个 AI 工具各交一次"变成"每个数据源只交一次"。

服务器还是要写，这部分工作是真实的。但只写一次，在所有支持这个协议的地方都能用。