MCP 是什么：AI Agent 连接外部工具和数据的标准协议
做 AI Agent 时，很多人会先接 Tool Calling。
模型终于可以请求调用工具：
查订单 发邮件 查数据库 创建工单到这里，Agent 已经不只是聊天。
但项目继续往下做，很快会遇到另一个问题：
GitHub 怎么接？ 文件系统怎么接？ 企业内部数据库怎么接？ Notion、Google Drive 这些外部系统怎么接？每个系统都有自己的 API、鉴权方式、参数结构和错误处理。
更麻烦的是，一个系统接到 A 应用里，换到 B 应用里可能还要再接一遍。
MCP 要解决的，就是这类重复接入问题。
它不是某个具体工具。
也不是一个新的 Agent 框架。
它是一套开放协议：
MCP 让 AI 应用能用统一方式连接外部工具、数据和资源。
一、有了 Tool Calling，为什么还需要 MCP
Tool Calling 解决的是：
模型怎么告诉应用“我要调用哪个工具、参数是什么”。
比如模型判断：
我要调用 queryOrder 参数是 orderId=12345这是模型和应用之间的协作。
但它没有回答这些问题：
这些工具从哪里来？ GitHub 谁来封装？ 文件系统怎么暴露？ 公司内部 API 怎么接入？ 换一个 AI 应用后，这些能力能不能复用？MCP 关注的是外部能力怎么标准化接入。
可以这样区分：
Tool Calling：模型怎么选工具 MCP：工具怎么接进来Tool Calling 更像“模型发起调用请求”。
MCP 更像“外部能力接入 AI 应用的标准插口”。
二、MCP 到底是什么
MCP 的全称是 Model Context Protocol。
它可以理解成：
把 AI 应用连接到外部系统的一套开放标准。
MCP Server 可以暴露三类常见能力：
- Tools：执行动作，比如查订单、发邮件、调用接口；
- Resources：提供上下文，比如文件、数据库记录、业务文档；
- Prompts：提供可复用的提示词模板或任务模板。
没有 MCP 时，每个 AI 应用都要自己接各种系统。
接 GitHub，写 GitHub API 适配。
接数据库，写数据库适配。
接公司内部系统，再写一套内部接口适配。
有了 MCP 后，外部系统可以按统一协议把能力暴露出来。
AI 应用只要会连接 MCP Server，就能发现这些能力，并在需要时使用。
可以把 MCP 理解成 AI 应用里的 USB-C。
USB-C 不负责拍照、充电、传文件。
它只定义连接方式。
设备按这个标准接入，使用方就不用为每个设备单独发明一根线。
MCP 也是这个思路。
三、MCP Client 和 MCP Server 怎么协作
MCP 里最常见的两个角色是：
MCP Client MCP ServerMCP Client 在 AI 应用这一侧。
比如 IDE 助手、桌面 AI 工具、后端 Agent 服务。
更严谨一点说，AI 应用通常是 Host，里面可以管理一个或多个 MCP Client。
MCP Server 负责暴露某类外部能力。
比如：
GitHub MCP Server → 暴露仓库、Issue、PR 等能力 Filesystem MCP Server → 暴露文件读取、目录查询等能力 Company MCP Server → 暴露公司内部业务系统能力一次协作大概是这样：
AI 应用启动 → MCP Client 连接 MCP Server → Client 发现 Server 提供的能力 → 用户提出任务 → 模型判断需要某个能力 → AI 应用通过 MCP 调用 Server → Server 返回结果 → 模型基于结果回答举个代码助手的例子。
用户问：
帮我看看这个 PR 改了哪些文件，有没有明显风险？
背后可能是：
代码助手连接 GitHub MCP Server → 发现 listChangedFiles、getFileContent 等工具 → 模型判断需要读取 PR 变更 → 应用通过 MCP 调用这些工具 → GitHub MCP Server 请求 GitHub API → 返回文件列表和 diff → 模型基于结果做代码评审这里，代码助手不需要自己写一整套 GitHub API 适配。
它只要会连接这个 MCP Server，就能复用它暴露出来的能力。
注意，MCP Server 不是模型。
它是外部能力的提供方。
真正怎么鉴权、怎么连接系统、怎么执行操作，仍然要由 AI 应用和 MCP Server 负责。
四、MCP 和 Tool Calling 的关系
一个 GitHub MCP Server 可以告诉 AI 应用：
我这里有这些工具： - 查询仓库 - 查看 Issue - 创建 PR 评论AI 应用拿到这些工具定义后，再交给模型。
模型通过 Tool Calling 请求调用。
应用再通过 MCP 去执行。
完整链路更像这样：
MCP Server 暴露工具 → MCP Client 发现工具 → AI 应用把工具交给模型 → 模型通过 Tool Calling 请求调用 → AI 应用通过 MCP 执行调用所以不要把 MCP 理解成“更高级的 Tool Calling”。
它们分工不同：
Tool Calling 管模型怎么发起调用 MCP 管外部能力怎么标准化接入五、什么时候适合用 MCP
MCP 最大的价值，不是让模型更聪明。
而是让外部能力更容易复用。
比如你做了一个公司内部 MCP Server，暴露这些能力：
查询订单 查询库存 创建工单 查询知识库 触发审批流程以后换模型、换 IDE、换桌面 AI 应用、换后端 Agent 服务，只要还能作为 MCP Client 连接它，这些能力就可以继续复用。
但 MCP 不是万能的。
它不会自动帮你做好权限控制。
哪些用户能调用？
哪些参数合法？
哪些操作需要二次确认？
这些仍然要在应用和服务端做。
它也不会保证模型选对工具。
工具描述写得不清楚，工具太多太像，模型仍然可能选错。
另外，MCP 会带来工程复杂度。
你多了一层 Server、连接、协议、鉴权、部署和监控。
如果项目只有两三个本地工具，直接用 Tool Calling 可能更简单。
如果工具很多，要被多个 AI 应用复用，或者要接外部工具生态，MCP 的价值才会更明显。
六、小结
MCP 解决的是：
AI 应用怎么用统一方式连接外部工具、数据和资源。
几个概念可以放在一起看：
RAG：让模型查资料 Memory：让模型接前文 Tool Calling：让模型请求调用工具 MCP：让工具和资源标准化接入 AI 应用MCP 有价值的地方，不是让一个 Demo 看起来更酷。
而是当工具越来越多、系统越来越复杂时，它给 AI 应用提供了一种更标准的连接方式。
边界也要记住：
MCP 负责标准化连接，不负责替你做权限、业务规则和安全兜底。
这些仍然要回到工程里解决。
后续会继续更新 AI Agent、RAG、Memory、Tool Calling、MCP 等工程化内容。
