MCP协议是什么？它常和 Agent、MCP Server、API 一起出现，第一次接触时容易把几个概念混在一起。MCP 是一套开放协议，规定 AI 应用如何发现、读取外部数据，以及如何调用外部工具。 它不负责思考，也不等于某个具体产品。
MCP 的全称是 Model Context Protocol，中文常译为模型上下文协议。日常说的 MCP 协议，指的就是这套协议。
它由 Anthropic 在 2024 年 11 月 25 日开源，2025 年 12 月 9 日被捐赠给 Linux 基金会旗下的 Agentic AI Foundation。今天讨论 MCP，已经超出某一家公司的接口规范，成为 AI 应用连接外部系统的一种公共约定。
如果你正在搭建企业级 AI Agent，大概会遇到一个现实问题：每接一个数据库、一个工单系统、一个内部 API，就要单独写一套连接逻辑。系统越多，维护成本越高。MCP 想解决的，就是这类重复连接的问题。
MCP 协议到底是什么
用一个具体场景会更容易理解。假设一家企业有 5 个 AI 应用，内部有 20 个常用系统。如果每个应用都单独对接每个系统，最多要维护 100 条连接。每新增一个系统，所有应用都要跟着改。MCP 的做法是先把连接方式统一起来：AI 应用按协议实现一次，系统侧也按协议暴露一次，之后的组合就能复用。
这里统一的是通信规则，不是具体业务。MCP 规定消息怎么发、能力怎么描述、工具怎么调用、版本怎么协商；至于某个工具是查订单还是开发票，由 MCP Server 自己定义。协议层负责连接，业务层负责做事，两者分开。
MCP 的官方规范把它描述为一套开放协议，用来把 AI 应用和外部数据源、工具连接起来。它采用 JSON-RPC 2.0 作为消息格式。JSON-RPC 2.0 是一种用 JSON 表达请求和响应的远程调用约定，开发者通常不需要手写这些消息，SDK 会处理大部分细节。
需要分清三个东西。MCP 是协议，是一套规则；MCP Server 是按这套规则提供工具和数据的程序；Agent 是使用这些工具去完成任务的 AI 应用。三者经常一起出现，但处在不同层。
一次 MCP 调用里，谁在做什么
MCP 采用 Host、Client、Server 三层角色。理解这三个角色，基本就能看懂大多数 MCP 产品的介绍。
图 1：MCP 的 Host、Client、Server 连接关系。Host 为每个 Server 创建独立 Client，Server 对外提供工具、资源和提示模板。
Host 是发起连接的 AI 应用
Host 是你实际打开和使用的 AI 应用，比如 Claude Desktop、VS Code、Cursor，或者企业自己的客服助手、数据分析助手。Host 负责管理一个或多个 MCP Client，决定什么时候连接哪个 Server，以及把模型产生的工具调用请求转给谁。
Client 是 Host 内部的一对一连接器
每一个 MCP Client 只维护与一个 MCP Server 的连接。Host 连接两个 Server，就会创建两个 Client。这样设计的好处是边界清楚，某个 Server 断开，不会影响其他连接；不同 Server 的能力也可以分别管理。
Server 把工具和数据暴露出来
MCP Server 是对外提供上下文和能力的程序。它可以在本地运行，通过标准输入输出与 Client 通信，也就是常说的 stdio 传输；也可以部署在远端，通过 Streamable HTTP 传输。Server 可以暴露工具、资源和提示模板，供 Host 侧的 AI 应用发现和使用。
举个例子，VS Code 作为 Host，一边连接 Sentry 的 MCP Server 查线上错误，一边连接本地文件系统 Server 读取代码。VS Code 会为这两个 Server 分别创建 Client。对用户来说，看到的是一个统一的 AI 助手；对系统来说，背后是两条独立的连接。
MCP Server 不是 Agent。 Server 的职责是提供能力和数据，它不负责理解业务目标，也不负责规划下一步。Agent 的思考和执行顺序发生在 Host 和它调用的模型那一侧。把 Server 当成 Agent，是理解 MCP 时常见的混淆。
| 角色 | 主要职责 | 常见例子 |
|---|---|---|
| Host | 管理连接、调度 Client、承接模型调用 | Claude Desktop、VS Code、企业 AI 助手 |
| Client | 维护与单个 Server 的连接 | Host 内部为每个 Server 创建的连接器 |
| Server | 提供工具、资源、提示模板 | 数据库 Server、工单系统 Server、文件系统 Server |
Tools、Resources、Prompts 分别解决什么
MCP Server 对外提供的能力，主要落在三类原语上。原语可以理解为协议规定的基础能力单元。
| 能力 | 解决什么问题 | 典型例子 |
|---|---|---|
| Tools | 让 AI 应用执行一个动作 | 查询订单、创建工单、发送消息、调用内部 API |
| Resources | 给 AI 应用提供可读取的上下文 | 文件内容、数据库表结构、接口返回的数据 |
| Prompts | 提供可复用的提示模板或工作流 | 客服回复模板、分析报告框架、少样本示例 |
Tools 是讨论较多的一类。它把一个可执行函数暴露给 AI 应用，函数有名称、说明和输入参数结构。Host 在调用工具前，需要让用户知道要执行什么，并取得确认。MCP 官方规范把工具视为任意代码执行，提醒实现方谨慎处理。
Resources 更像可读的资料。它不执行动作，只提供上下文。比如一个数据库 Server 可以暴露表结构，让 AI 应用知道有哪些字段；一个文件 Server 可以暴露文档内容，让 AI 应用在回答时引用。
Prompts 则是可复用的指令模板。它适合把一套固定的工作流封装起来，减少每次对话都要重复描述的成本。
除了这三类，MCP 还定义了 Client 侧的能力。比如 Elicitation，允许 Server 在需要更多信息时向用户发起补充询问。协议还支持进度通知、取消、错误报告等基础工具，以及可按需启用的扩展。扩展需要 Client 和 Server 双方明确支持，在初始化时协商。
MCP 的传输层支持两种方式。stdio 适合本地进程之间的直接通信，开销小；Streamable HTTP 适合远程 Server，支持标准的 HTTP 认证方式。官方建议远程场景使用 OAuth 获取认证令牌。协议只规定怎么交换上下文，不规定 AI 应用怎么使用模型，也不规定它怎么管理上下文。 这句话划出了 MCP 的能力边界。
MCP 和 Agent、API、Function Calling 怎么区分
这几个概念经常被放在同一段话里，实际解决的是不同问题。
MCP 和 Agent 是什么关系
Agent 通常包含目标、计划、记忆、工具调用和执行循环。它要决定做什么、先做哪一步、做到什么程度算完成。MCP 负责把可用的工具和数据以统一方式接进来。Agent 决定做什么，MCP 负责把工具和数据接进来。 一个 Agent 可以不用 MCP，直接调用 API；用了 MCP，工具接入会更统一，但 Agent 的规划、记忆和治理仍然要由平台自己解决。在智能体协议的话题里，MCP 经常被提到，因为它解决了 Agent 使用工具时的连接问题。
MCP 和 API 有什么区别
API 是某个系统对外提供的具体接口，比如查询订单的 HTTP 接口、写入用户的数据库接口。MCP 改变的是 AI 应用发现和调用能力的方式，企业已有的 API 仍然承担实际的数据操作。多数 MCP Server 在内部仍然要调用 API、数据库或业务系统，只是对外用统一的 MCP 方式描述能力。有了 MCP，API 仍然在下面干活；变的是上面的连接方式。
MCP 和 Function Calling 怎么配合
Function Calling 是模型侧的一种能力。大模型根据上下文，输出“我要调用某个函数、参数是什么”的结构化意图。MCP 解决的是工具如何被描述、发现和调用，以及 AI 应用如何与外部 Server 建立连接。两者经常配合使用。模型通过 Function Calling 表达调用意图，Host 再把请求通过 MCP 发给对应的 Server。MCP 负责跨系统的工具连接，Function Calling 负责模型侧的调用意图。
| 概念 | 主要解决什么 | 不解决什么 |
|---|---|---|
| MCP | AI 应用与外部工具、数据源之间的标准化连接 | 业务目标、任务规划、模型能力 |
| Agent | 围绕目标进行规划、调用工具、执行任务 | 工具接入的跨系统标准 |
| API | 某个系统对外提供的具体接口 | AI 应用如何发现和选择工具 |
| Function Calling | 模型输出结构化的工具调用意图 | 跨应用、跨系统的连接和权限治理 |
把一次调用串起来看。用户提出“查一下昨天失败订单的原因”，Agent 决定先查订单库，再查日志；模型通过 Function Calling 输出查询意图；Host 通过 MCP 找到对应的 Server；Server 在内部调用数据库和日志 API，把结果返回；Agent 再根据结果决定下一步。这个链路里，每一层各做各的事。
MCP 为什么被广泛采用
MCP 在 2024 年 11 月 25 日由 Anthropic 开源。发布时，Anthropic 同时提供了规范、SDK、Claude Desktop 的本地 Server 支持，以及一个开源 Server 仓库。早期的采用者包括 Block、Apollo，以及 Zed、Replit、Codeium、Sourcegraph 等开发工具。
2025 年 12 月 9 日，Anthropic 把 MCP 捐赠给 Linux 基金会旗下的 Agentic AI Foundation。这个基金会由 Anthropic、Block 和 OpenAI 共同发起，Google、Microsoft、AWS、Cloudflare、Bloomberg 等提供支持。治理交给中立基金会，降低了单一厂商控制协议的风险，也让企业在做长期技术选择时少了一层顾虑。
截至 2025 年 12 月，Anthropic 公布的数据显示，活跃的公共 MCP Server 已超过 1 万个；ChatGPT、Cursor、Gemini、Microsoft Copilot、Visual Studio Code 等产品已经采用 MCP；Python 和 TypeScript 的官方 SDK 月下载量超过 9700 万次。这些数字来自 Anthropic 的公告，用来说明生态规模，不代表第三方审计结果。本文没有找到 2026 年更新的公开总数，因此沿用这一口径。
规范本身也在演进。MCP 的版本号按日期命名，本文核对时，官方规范页面显示的最新修订为 2026 年 7 月 28 日。这个版本强调无状态请求、按请求进行能力协商，并引入了服务发现和扩展机制。企业在对接时，按双方支持的版本协商即可，不必盲目追新。协议版本可以演进，连接层的基本分工没有变，Host 发起，Client 连接，Server 提供能力。
采用范围扩大，不等于每个 Server 都可靠。协议中立解决的是治理归属问题，具体工具是否安全、数据是否合规，仍然要看实现方。
企业什么时候值得用 MCP
MCP 适合解决连接重复的问题，不适合所有场景。可以用三个问题来判断。
第一，是否有多个 AI 应用要接同一批系统。如果只有一个小助手接一个固定 API，直接调用 API 更简单，排查链路也更短。第二，工具和数据源是否会持续增加。如果连接数量会增长，统一协议的价值才会显现。第三，是否需要保留替换模型、替换工具的余地。MCP 把应用侧和工具侧分开，替换其中一侧时，另一侧的改动会更少。
如果三个问题的答案都是肯定的，MCP 通常值得进入技术评估。反过来，实时性要求极高、系统数量很少、团队没有权限和审计能力时，先直接用 API 更稳妥。
企业还要准备的不只是协议本身，还有治理。可以从五个方面检查。
- 身份与权限：每个用户和服务都要有明确身份，工具调用遵循最小权限，避免一个令牌打通所有系统。
- 数据边界：区分只读数据和可写数据，标记敏感字段，明确哪些数据可以出企业网络。
- 工具准入：建立允许使用的 Server 清单，审核来源和版本，不把未经评估的公共 Server 直接接进生产环境。
- 审计与确认：记录谁在什么时间调用了哪个工具、参数是什么、结果如何；高风险动作要求人工确认。
- 网络与供应链：远程 Server 要走加密通道，评估第三方依赖和更新机制，防止供应链风险。
MCP 解决的是连接层，Agent 平台解决的是上层。以 ThinkingAI 为例，Agentic Engine 负责企业级 Agent 的创建、管理、多 Agent 协作和私有化部署，已服务全球超过 1500 家企业；如果企业需要把内部工具和系统接入 Agent，可以了解 ThinkingAI 的 MCP 服务。两者配合，前者管怎么连，后者管谁来用、怎么管。
使用 MCP 要留意哪些风险
MCP 官方规范在安全部分写得很直接。协议能带来任意的数据访问和代码执行路径，因此实现方必须处理安全与信任问题。协议本身不能在协议层强制这些原则，需要 Host、Server 和企业自己的系统共同落实。
第一类风险来自工具描述。工具的说明、参数和注解，可能被恶意篡改，诱导模型调用不该调用的工具。官方规范提醒，除非来自可信 Server，工具描述应当被视为不可信内容。企业接入公共 Server 前，要像审查第三方软件一样审查它。
第二类风险来自权限过宽。为了让 Agent 什么都能做，有些实现会给一个很大的令牌，结果一个工具被攻破，影响面覆盖多个系统。更稳妥的做法是按工具、按数据范围拆权限，并把高风险动作放到人工确认之后。
第三类风险来自数据边界。Agent 可能同时连接内部数据库、客服工单和外部工具。如果没有明确的数据分类和出站规则，敏感数据可能在一次工具调用里被带到不该去的地方。
第四类风险来自供应链。远程 Server 可能依赖第三方包、第三方模型或第三方云服务。版本锁定、依赖扫描、变更记录和应急下线机制，都需要提前准备。
能连上只是第一步，能不能放心用，取决于权限、审计和人工接管。 对多数企业来说，先从只读、低风险、高频的查询场景开始，再逐步放开写操作，比一开始就追求全自动更稳。
MCP 常见问题
MCP 是 Anthropic 的私有协议吗？
不是。MCP 由 Anthropic 在 2024 年开源，2025 年 12 月捐赠给 Linux 基金会旗下的 Agentic AI Foundation。协议治理交给中立基金会，符合规范的实现都可以使用。Anthropic 仍然是主要贡献者之一，但不拥有排他控制权。
MCP 只能给 Claude 用吗？
不是。MCP 是 Client 和 Server 之间的协议，不绑定某一个模型或某一个 AI 应用。官方资料列出的采用者包括 Claude、ChatGPT、Visual Studio Code、Cursor 等。具体产品支持哪些能力、支持到什么程度，仍要以该产品的文档为准。
MCP Server 一定要自己开发吗？
不一定。可以使用公开的 Server，也可以使用软件厂商提供的 Server；涉及企业内部系统、特殊权限和私有数据时，通常需要自己开发或做适配。无论来源如何，接入前都要检查权限、数据范围和更新机制。
MCP 会取代 API 吗？
不会。MCP 改变的是 AI 应用发现和调用能力的方式，实际执行往往仍然通过 API、数据库或业务系统完成。企业已有的 API 不需要推倒重来，可以在上面增加一层 MCP Server，把能力以统一方式暴露给 AI 应用。
参考资料
- Model Context Protocol 官方规范，2026-07-28 版本，https://modelcontextprotocol.io/specification/2026-07-28
- Model Context Protocol 官方架构说明，https://modelcontextprotocol.io/docs/learn/architecture
- Anthropic，Introducing the Model Context Protocol，2024-11-25，https://www.anthropic.com/news/model-context-protocol
- Anthropic，Donating the Model Context Protocol and establishing the Agentic AI Foundation，2025-12-09，https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
