为什么需要 MCP

一句话理解：MCP 把“每个 AI 产品各自对接每个系统”的 N × M 问题，变成“系统实现一次 MCP Server、AI 产品实现一次 MCP Client”的 N + M 问题，就像 USB-C 统一了设备接口。

上一模块里，你为天气 Agent 写了 get_weather 工具。现在设想公司里有五个团队都想用“查订单”这个能力：客服 Agent 要用，工程师在 Claude Code 里排查问题要用，运营在 Cursor 里写脚本要用，数据团队自研的分析 Agent 要用，业务同事还想在 ChatGPT 或 Claude 里直接问。

没有统一协议时，你要为每个产品写一遍适配：不同的工具定义格式、不同的调用方式、不同的认证流程。系统一多，适配工作呈乘法增长。MCP 要解决的就是这个问题。

N × M：没有标准时的集成困境

下图对比了两种情况：

图 1 · 从 N × M 到 N + M：连线从乘法变成加法

MCP 官网用的类比是 USB-C：USB-C 为电子设备提供了标准化的连接方式，MCP 为 AI 应用连接外部系统提供了标准化的方式。设备厂商只要支持 USB-C，就能接上任何符合标准的配件；系统只要提供 MCP Server，就能被任何支持 MCP 的 AI 产品使用。

另一个常被引用的参照是 LSP（Language Server Protocol）。MCP 规范里明确写道，它受到 LSP 的启发：LSP 让“每种编程语言 × 每个编辑器”的适配变成各实现一次，MCP 对 AI 应用和外部工具做了同样的事。

MCP 标准化了什么

MCP（Model Context Protocol，模型上下文协议）是一个开放协议，基于 JSON-RPC 2.0 消息格式。它把 AI 应用连接外部系统时反复遇到的问题统一了下来：

问题	没有标准时	MCP 的做法
有哪些能力可用？	各产品各自的插件清单格式	统一的发现接口，如 `tools/list`
怎么调用？	各自的请求与返回格式	统一的 `tools/call` 请求与结果结构
除了工具还能提供什么？	通常只有“函数”	工具、资源、提示模板三类原语，见三类原语
怎么通信？	自定义 HTTP 或 SDK	本地 stdio 与远程 Streamable HTTP，见本地与远程 MCP
怎么授权？	各自的 API Key 与登录流程	远程 Server 基于 OAuth 2.1 的授权规范，见 MCP 的认证与安全

注意 MCP 和上一模块讲的 Function Calling 是 上下两层 的关系，而不是替代关系：

图 2 · 上下两层：Function Calling 管模型与 Host，MCP 管 Host 与外部系统

Host（比如 Claude Code）从 MCP Server 拿到工具列表，转换成模型 API 需要的工具定义；模型发起调用后，Host 再通过 MCP 把请求转给 Server。模型本身并不知道工具来自 MCP。

对不同角色的价值

系统提供方（比如公司的订单中台团队）：实现一次 MCP Server，就能被所有支持 MCP 的 AI 产品使用，不用为每个产品单独开发插件。
AI 产品方（比如 Claude Code、Cursor）：实现一次 MCP Client，就能接入整个生态里的 Server，能力边界随生态扩张。
使用者（工程师、业务人员）：在自己习惯的 AI 工具里接入需要的系统，不用等产品方官方适配。

MCP 官方文档列出的主流支持方包括 Claude、ChatGPT、Visual Studio Code、Cursor 等。截至 2026 年 9 月，官方还维护着一个 MCP Registry，集中登记公开 MCP Server 的元数据（名称、安装方式、远程地址等），目前仍处于预览阶段。

生态现状：从一家公司的协议到行业标准

MCP 最初由 Anthropic 开源发布，2025 年 12 月被捐赠给 Linux Foundation 旗下新成立的 Agentic AI Foundation（AAIF），由中立组织治理。
规范按日期命名版本。截至 2026 年 9 月，最新正式版是 2026-07-28，此前的版本包括 2025-11-25、2025-06-18 等。
2026-07-28 版是一次较大的升级：协议核心变为无状态，去掉了早期版本的初始化握手与会话，更容易在普通 HTTP 基础设施上水平扩展；同时引入了正式的扩展框架（如长任务的 Tasks 扩展、在对话中渲染交互界面的 MCP Apps 扩展），并建立了弃用政策：功能被标记弃用后，至少保留 12 个月才可能被移除。

版本演进很快，但对产品判断影响最大的是这件事：不同 Host 支持的规范版本与能力并不完全一致。 官方 SDK 可以同时兼容新旧版本，但接入具体产品前，仍要确认它支持哪些原语和传输方式。

MCP 不解决什么

MCP 是连接标准，不是质量保证。以下问题它都不替你解决：

工具设计得好不好。 把 50 个接口原样包装成 50 个 MCP 工具，问题和上一模块讲的一样多，见工具设计原则。
业务权限怎么划分。 协议规定了授权流程，但“客服能不能看客户手机号”仍要你的 Server 自己判断。
Server 可不可信。 接入第三方 MCP Server，就等于把一段外部代码和外部描述引入 Agent，存在工具投毒等风险。
该不该用 MCP。 很多场景直接用 API 或确定性 Workflow 更合适，见 API、MCP、Connector 与 Workflow。

常见误区

“MCP 是一种新的 API，要替代 REST。” MCP Server 内部通常还是调用你已有的 REST 或数据库。MCP 是面向 AI 应用的接入层，不是业务 API 的替代品。
“用了 MCP，模型就更聪明了。” 模型看到的仍然是工具名称、描述和 Schema。MCP 只让工具更容易被复用，不会让工具变好用。
“所有 Agent 都应该用 MCP。” 只有一个产品、几个固定工具时，直接写 Function Calling 更简单。需要跨产品复用、或者要开放给外部 AI 产品时，MCP 的价值才明显。

产品经理检查清单

这个能力会被几个 AI 产品或 Agent 使用？只有一个的话，MCP 带来的收益有多大？
目标 Host（Claude Code、Cursor、ChatGPT 等）支持哪些 MCP 能力和传输方式？
这个 Server 由谁维护？版本升级、下线、兼容旧客户端的流程是什么？
数据权限在 Server 里怎么落地？谁能看到什么？
如果要接入第三方 Server，谁来评估它的来源与风险？

练习

盘点你们团队（或设想的电商公司）的 AI 集成现状（30 分钟）：

列出正在使用或计划使用的 AI 产品（如 Claude Code、Cursor、自研客服 Agent）。
列出它们需要访问的内部系统（订单、CRM、数据库、工单、知识库）。
画出当前的 N × M 连线图，标出哪些已经有定制集成。
挑出一个被 3 个以上产品需要的系统，写一段话论证它是否值得做成 MCP Server。

下一步

知道了 MCP 为什么存在，下一课「MCP 架构」拆开 Host、Client、Server 三个角色，看一次调用到底经过了谁。

为什么需要 MCP