MCP是什么？一文读懂协议原理、API 区别与安全边界

当 AI 应用需要调用你的工具、读取你的数据时，MCP 才派得上用场；单纯使用 AI，并不需要它。要弄清“MCP是什么”，先看 3 个部分：你使用的应用、应用内部负责连接的组件，以及对外提供特定能力的服务器。这套结构让集成可以复用，底层工作仍由现有的软件接口（API）和权限机制承担。

MCP是什么？它在 AI 中起什么作用？

Model Context Protocol（MCP，模型上下文协议）是一套连接 AI 应用与工具、数据的开放标准。 它让兼容的应用以统一方式发现可用能力、请求信息和执行操作。MCP 官方入门文档介绍了如何连接文件、数据库、工具等外部系统。

对创业者来说，好处很直接：助手可以使用业务系统中的信息，不必只依赖你粘贴到聊天框里的内容。对开发者来说，价值在于复用：通过 MCP 服务器开放一项能力，兼容的 AI 应用就能接入同一接口。

比如，让助手整理一份客户简报。集成程序可以获取客户档案和近期的支持工单，再把结果交给助手汇总。MCP 提供统一的连接格式，但具体操作仍需有人实现，访问仍需授权，结果是否有用也仍需检查。

MCP 属于基础设施。 它不会替代 AI 模型、存放业务记录的应用，也不会替代负责授权的人。

现在是谁在维护 MCP？

MCP 由其开源项目维护者负责维护，Agentic AI Foundation（AAIF）提供组织层面的支持；AAIF 隶属于 Linux Foundation。 Anthropic 创建了这项协议，并于 2025 年 12 月 9 日宣布将其捐赠给该基金会。基金会提供中立的组织归属，项目本身仍掌握技术方向。查看项目公告。

经 2026 年 10 月 13 日核实，MCP 治理页面列出的首席维护者为 David Soria Parra 和 Den Delimarsky。首席维护者、核心维护者和维护者共同组成 MCP 指导小组。成员以个人身份参与，并非代表公司占有固定席位。

对正在评估厂商依赖的采购方来说，这意味着使用 MCP 不会把你绑定到 Anthropic 的 AI 应用上。但这也不代表基金会维护或认可所有采用该标准的第三方服务器。协议如何治理，与某项集成是否可信，是两回事。

MCP 的工作原理：宿主、客户端与服务器

宿主是你使用的应用；其中的客户端与服务器通信，服务器负责提供能力。 这些是软件角色，并不意味着你要分别购买几台机器。官方架构文档说明，宿主会为每个连接的服务器创建一个客户端。

宿主：你使用的 AI 应用

**宿主（host）**统筹整个使用过程，包括对话、模型和可用连接。可以把它理解为你工作的办公室。哪些工具可用、何时需要请求批准，都受到宿主设置和策略的影响。

MCP 客户端是什么？

**MCP 客户端（client）**是宿主内部负责连接的组件，按协议与某个特定服务器通信。通常你只需在应用内配置连接，无须另装一款“客户端”产品。

分清这一点，就能避免架构图中一个常见错误：客户端位于宿主内部。语言模型本身并不是网络连接组件。

MCP服务器是什么？

**MCP 服务器（server）**是通过 MCP 开放特定能力的程序。“服务器”描述的是它的角色，因此它既可以是笔记本电脑上的一个进程，也可以是运行在其他地方的服务。

在客户简报的例子中，它可以只开放一个范围有限的客户查询功能。服务器执行查询并返回结果，宿主再把结果用于 AI 的工作。它不必开放整个客户数据库。

服务器能提供什么：工具、资源与提示词

服务器可以提供 3 类能力。 不必全部实现，但宿主必须支持你打算使用的功能。服务器概念文档对它们作了如下区分：

工具既可以读取信息，也可以修改信息。搜索操作即使不写入任何数据，也仍然是工具。资源是一份可访问的上下文，提示词则是一种可复用的任务发起方式。

开发者要分清“发现操作”和“执行操作”：tools/list 提供可用工具的定义，tools/call 才会调用其中一个。清楚的描述和受约束的输入有助于宿主选对操作，但不能替代应用中的访问权限检查。

MCP 和 API 有什么区别？

MCP 不会替代 API，MCP 服务器往往是在封装 API。 应用程序编程接口（API）让软件能够向另一个系统请求数据或操作。MCP 则为兼容的 AI 应用提供统一方式，让它们发现并使用建立在这些接口之上的能力。

沿着一次请求，看清 MCP 与 API 的分工

以查询客户为例。直接集成时，AI 应用需要工具定义，以及调用客户系统 API 的代码。采用 MCP 后，服务器可以提供工具定义，并负责执行 API 调用。Anthropic 的 MCP 课程介绍了这种封装方式。

请求最终仍会到达客户系统，其授权规则、用量限制和业务逻辑也仍然有效。标准化的是面向 AI 的集成接口，底层依赖并没有消失。

MCP 服务器也可以直接操作本地文件或数据库。因此，封装 API 是常见实现方式，并非必需条件。

什么时候用 MCP，什么时候直接用 API？

需要让兼容的 AI 应用复用同一项访问能力时，适合用 MCP。流程已经固定、额外接口带来的价值有限时，直接用 API 更合适。

例如，定时将已批准的发票记录复制到财务软件，用普通应用代码实现可能更清楚：输入、目标和执行顺序都已经确定。而对话式助手需要在客户查询、文档搜索和任务创建之间选择，就更有理由使用可发现的工具。

对产品开发者来说，先想清楚谁会使用这项集成。如果客户希望在现有 AI 应用中使用你的服务，MCP 服务器可以成为一个有价值的产品接入渠道。如果只有自己的后端会调用该操作，直接用函数或 API 可能就够了。

MCP 与 RAG 有什么区别？

检索增强生成（RAG）把检索到的信息提供给模型，MCP 则提供连接协议。 RAG 原始论文介绍了如何利用检索材料辅助生成。

你可以将文档检索封装成 MCP 工具。但搜索系统仍需找到有用的段落、遵守文档权限，并返回足够的上下文。加上 MCP 不会自动提高检索质量。

MCP 在 AI 智能体中负责什么？

MCP 可以让智能体访问工具，但不负责制定智能体的行动计划。 智能体是利用模型选择行动、推进任务的软件。MCP 的架构明确将模型使用和上下文管理留给应用负责。

在生成客户简报时，智能体可能先获取客户档案，再搜索相关支持工单。协议负责传递请求，应用仍需负责工作流、控制措施和故障处理。

本地与远程 MCP 服务器有什么区别？

本地和远程只说明服务器在哪里运行，并不说明所有数据会留在哪里。 MCP 的标准传输方式包括 stdio 和 Streamable HTTP：前者用于同一台机器上的进程间通信，后者通过 HTTP 通信，常用于远程服务器。查看 MCP 传输方式概览。

本地服务器通常通过一条命令，在运行客户端的机器上启动。这适合需要处理本地文件的开发者，但也意味着要对所安装的程序及其执行权限负责。

远程服务器通过网络地址访问。对企业来说，它能让共享服务更容易运维，同时也引入了托管、身份验证和可用性方面的依赖。HTTP 也能用于本地通信，因此“HTTP”本身并不等于公网。

本地运行的服务器可能调用外部 API，其输出也可能进入云端 AI 对话。反过来，远程托管的服务器也可以严格限制权限。需要评估的是从源数据到服务器，再到 AI 应用的完整路径。

MCP 连接器是什么？

“连接器”通常是产品对某项集成的命名。 它不是宿主、客户端、服务器之外的额外架构角色。例如，Claude将远程 MCP 集成称为自定义连接器，而 ChatGPT当前文档则通过插件提供 MCP 访问。配置时应遵循具体应用支持的接入方式。

目前哪些应用支持 MCP？

Claude、ChatGPT、Cursor、Visual Studio Code 和 Codex 都在文档中说明了对 MCP 的支持。 以下信息于 2026 年 10 月 13 日根据各厂商页面核实。核实的是文档所述能力，并非对每台服务器都做过兼容性实测，也不意味着所有账户都拥有相同的访问权限。

Claude

Anthropic 的 AI 助手 Claude 支持远程 MCP 自定义连接器，也支持通过 Claude Desktop 扩展连接本地服务器。 远程连接器文档列出了 Free、Pro、Max、Team 和 Enterprise 的支持情况，其中 Free 可使用 1 个自定义连接器，企业类套餐提供组织级控制。

一个关键限制是网络可达性：即使用的是桌面应用，远程连接器请求也来自 Anthropic 云端。只有你的笔记本电脑能访问的服务器，并不会因此自动对该连接器可达。另一条独立路径是本地桌面扩展，入口位于设置中的扩展页面（Settings > Extensions）。

ChatGPT

OpenAI 的 AI 应用 ChatGPT 通过插件支持基于 MCP 的工具。 OpenAI 当前的快速入门指南介绍了这条流程：在 ChatGPT Plugins 中连接自定义服务器，安装生成的插件，再在网页版 ChatGPT Work 中调用。自定义可视化界面是可选项。

配置时应按该产品文档中的路径操作。从另一个应用的配置里复制本地启动命令，并不等同于添加托管服务器的 URL；协议层面的支持，也不能直接说明你的工作区拥有哪些权限。

Cursor

AI 代码编辑器 Cursor 支持本地 stdio 服务器，也支持通过 Streamable HTTP 或 Server-Sent Events（SSE，服务器发送事件）建立远程连接。 其 MCP 文档还列出了工具、资源和提示词支持。项目级配置可写入 .cursor/mcp.json，全局配置可写入 ~/.cursor/mcp.json。

默认情况下，Cursor 会在使用 MCP 工具前请求批准。启用的工具应与项目相关：只有描述、权限和输出符合任务需要，让应用发现这项能力才有意义。

VS Code

代码编辑器 Microsoft Visual Studio Code（VS Code）在 AI 智能体功能中支持 MCP 工具，也支持资源、提示词和交互式应用。 Microsoft 的配置文档提供了 MCP: Add Server 命令，并建议为新增服务器选择便于迁移的配置存放位置。

信任某个工作区之前，先检查其代码仓库中的 MCP 配置。Microsoft 当前文档说明，工作区 MCP 服务器会继承 Workspace Trust（工作区信任），无需单独弹出服务器信任提示即可启动。对于会在本地执行的代码，这是安装时必须重视的信任边界。

Codex

OpenAI 的编程智能体 Codex 在命令行界面和代码编辑器扩展中支持本地 STDIO 服务器及 Streamable HTTP 服务器。 官方 MCP 文档介绍了位于 ~/.codex/config.toml 的共享配置，以及 HTTP 服务器的 Bearer 令牌和 OAuth 身份验证。OAuth 让你通过授权流程授予访问权限，无须把账户密码交给集成程序。

Codex 文档也说明了工具允许列表和拒绝列表的用法。应利用这些控制，只开放工作流需要的操作。连接成功之后，还要决定它究竟可以做什么。

MCP 要花多少钱，价值体现在哪里？

MCP 没有统一的月度订阅价格。 预算需要包含 AI 应用或模型、服务器托管或托管服务费、上游软件，以及维护成本。协议开放，不代表这些依赖项免费。

以一个具体的计费边界为例，OpenAI 表示，Responses API 会对导入 MCP 定义或发起调用时使用的 token 计费，每次 MCP 工具调用不另收费。这项说明仅适用于该 API，并不免除服务器提供方的费用。查看 OpenAI 的 MCP 计费说明。

集成工作量怎么算，前提又是什么？

假设 3 个 AI 应用都需要连接 4 个业务系统。如果为每一对组合单独编写适配器，就需要 3 × 4 = 12 个接口。在理想化的统一标准设计下，则是 3 个宿主实现 + 4 个服务器实现 = 7 个接口。

这意味着少实现 5 个接口，并不是实测节省了多少工程工时。这个例子假设所有组合都必需，且所需功能能够互通。身份验证、权限、测试和各服务特有的逻辑仍然要做。如果 AI 应用已经支持 MCP，宿主端可能已经实现，你的工作就主要集中在服务器和部署上。

如果只有一个应用调用一个服务，直接集成可能更简单。真正让额外这一层有吸引力的，是复用。

MCP 安全：连接之前，先检查服务器

接入 MCP，就等于让另一个程序参与 AI 工作流。发布者是否可信、权限是否合适、返回内容是否可靠，需要分别判断。 单靠协议标准无法为这些问题背书。

提示词注入，是把指令藏进模型本应当作数据处理的内容中。例如，检索到的支持工单可能夹带文字，要求助手忽略当前任务，把客户导出文件发送到别处。危险在于，助手将工具输出当成有权下达指令的内容，并调用另一项可用能力执行它。

OpenAI 的 MCP 安全指南明确提醒了恶意服务器内容中的隐藏指令、敏感数据泄露，以及服务器行为变化等风险。即使服务器可信，也可能检索到不可信的文档。文档中的指令不应获得与提出摘要请求的用户相同的权限。

安装服务器或为其授权之前，应检查：

• 发布者与数据去向。 从服务厂商自己的文档进入软件包或服务器地址。确认第三方中间服务由谁运营、会保留哪些数据。
• 本地执行。 读清启动命令、参数和请求的文件系统访问范围。安装本地服务器可能以该进程的权限执行代码；“本地”不等于有沙箱保护。
• 账户范围。 从受限账户和满足任务所需的最小数据范围开始。提示词里写“只使用这位客户的记录”，约束力弱于由后端权限强制执行这一边界。
• 可用操作。 试点优先选择只读操作。对影响重大的写入或导出，要求先复核，并检查实际目标地址和参数。
• 更新与撤销。 明确负责人，审查变更，并确认如何停用服务器、撤销凭据。卸载按钮有效，并不能证明上游令牌已经失效。

对开发者来说，应在服务器和底层系统中强制执行授权检查。MCP 的安全最佳实践明确反对令牌透传：接收原本发给其他服务的令牌，再原样转发，并不是合理的授权设计。

对业务使用者来说，先用不涉及敏感信息的文档集试验，核验返回的依据，再接入敏感系统。只读能限制修改源系统的能力，却不能阻止敏感内容被检索出来或转发到其他地方。同一试点中，不要混入与任务无关、权限强大的工具。

关于 MCP，哪些说法被夸大了？

统一协议能减少集成方式的差异，但不能让每项集成都自动变得可靠、安全或可以相互替换。 一句“支持 MCP”仍留下很多问题：支持哪种传输方式、哪些功能？使用谁的凭据？在哪里执行？需要哪些批准？

同样，安装更多服务器也不等于有了落地策略。工具描述不清，可能导致选错工具；凭据权限过宽，可能暴露过多数据；上游服务不可用，仍然会让工作流中断。

MCP 的实际价值更具体：兼容的宿主和服务器可以复用同一套接口。你仍然需要明确的任务、负责的人，以及识别错误结果的方法。应衡量的是完成并核验过的工作，而不是工具目录有多长。

谁适合现在用，谁应该等一等？

对创业者来说，如果重复复制信息或访问入口分散妨碍了高价值工作流，就值得着手尝试。 先选定工作流，再选基础设施。如果已有获批的集成能完成任务，多加一层并不会自动带来回报。

对业务团队来说，信息来源和权限边界清楚时，适合开展试点。 如果凭据管理、撤销授权或重要操作的复核无人负责，就应暂缓大范围部署。这些运营决策，协议无法替你做。

对开发者来说，当多个兼容宿主需要同一项能力，或客户明确希望从自己的 AI 应用访问服务时，值得增加 MCP 支持。 已经可靠运行的固定 API 自动化流程，不必轻易改动，除非你能明确说明复用价值或产品收益。

决定下一步如何实现时，可以用 MCP 服务器推荐列表查找现成集成；需要开放自己的能力时，参考 Python MCP 服务器开发指南；当统一访问控制成为运维需求时，再看 MCP 网关指南。

下一步怎么做：从一次只读试点开始

在你已经使用的 AI 应用里，试点一个边界清楚的读取操作。 例如，获取一份获准访问的客户档案，并与源数据核对。

1. 1

   明确任务和边界

   写清要回答的问题、允许使用的数据，以及预期结果。选择只读操作和受限身份，并指定一位有权停用连接的负责人。

2. 2

   按厂商文档接入

   确认需要的是本地命令还是远程 URL，完成身份验证，再检查可用能力。只启用任务必需的功能。

3. 3

   检查成功、拒绝访问和故障情况

   先请求权限范围内的信息，再请求账户权限之外的信息，确认后者被拒绝。断开服务器，检查助手是否如实报告无法访问，而不是给出缺乏依据的答案。

4. 4

   工作确有改善，再保留这项集成

   记录获取、核验和纠正结果所花的时间。撤销试点凭据，并确认访问随之停止。只有收益和控制边界都清楚，才扩大使用范围。

常见问题

MCP 怎么配置？

在 AI 宿主中配置：为受支持的本地服务器提供启动命令，或为远程服务器提供 URL，然后完成身份验证并启用所需工具。不同应用的文件名和设置不同，应以其厂商当前文档为准。

MCP 的全称是什么？

在 AI 软件领域，MCP 是 Model Context Protocol 的缩写，中文称为模型上下文协议。它就是本文介绍的、用于连接 AI 应用与外部工具和数据的开放标准。

怎么用大白话理解 MCP？

可以把它想成统一的服务窗口：AI 应用能了解另一个程序提供什么，按约定格式提出请求，再收到结果。窗口背后的权限规则仍然有效。

为什么需要 MCP？

它能减少重复的集成工作，让兼容的 AI 应用复用工具。但 MCP 并非必需：对于固定工作流，直接用 API 或已有的获批集成，可能更合适。

MCP 能用来做什么？

MCP 用于把外部上下文和获准执行的操作接入 AI 应用，例如查询记录、检索文档，或通过服务器开放的工具创建任务。

想了解 AI 工具和业务工作流的实用决策建议，可以订阅邮件简报。