MCP是什么？与 API 有何区别，产品该如何选择

MCP是什么，和 API 又是什么关系？MCP 并不替代 API，而是让 AI 客户端能够用统一的方式，发现并调用基于你现有服务提供的工具。如果产品同时面向应用程序和 AI 助手，MCP 与 API 的选择往往意味着：用 2 套接口，共享一套业务规则。保留 API 来支持应用集成；当现有 AI 客户端确实能解决某个具体的客户工作流需求时，再增加 MCP。

MCP是什么，和 API 有什么区别？

比较 MCP 和 API，实际是在比较一类通用的软件接口与一种面向 AI 集成的具体协议。 API，即应用程序编程接口，规定软件如何请求数据或执行操作。REST，即表述性状态转移，是 HTTP API 常用的一种架构风格。MCP，即 Model Context Protocol（模型上下文协议），则统一了兼容的 AI 应用访问外部能力的方式。

可以把产品想象成一家工坊。API 是配有操作说明的业务入口，MCP 服务器则像新增的接待台，能用 AI 客户端已经理解的格式，介绍这里能做哪些事。真正执行任务的人和后台规则，依然不可或缺。

对开发者而言，这是包在现有功能外的一层适配器；对产品负责人而言，这是客户使用产品的另一个入口；对运维人员而言，这又是一套需要有人负责访问控制和故障处理的接口。

MCP 也可以直接暴露本地功能，无须调用 HTTP API。封装现有 API 是实用的模式，但并非硬性要求。MCP 架构文档区分了 AI 应用与提供能力的服务器。如果想先了解协议全貌，可以阅读 MCP 入门介绍。

MCP 和 REST API 有哪些具体差异？

REST 适合应用直接集成；MCP 则增加了一套兼容 AI 客户端都能使用的工具接口。 无论选哪种方式，授权检查和业务行为的正确性都仍由你负责。

以上差异依据 REST API 设计指南、MCP 传输机制和 MCP 授权规范整理。其中，共享业务规则是架构建议。

API 本来就可以提供机器可读的模式定义。 OpenAPI 规范描述的 HTTP 接口，既供人阅读，也供程序使用。MCP 的特点是为 AI 集成提供共同的运行时契约，而不是只有它才能描述参数。

现有 API 接入 MCP协议后，多了什么？

MCP 让同一套工具接口能够被不同的兼容宿主复用。 宿主指负责协调模型及其连接的 AI 应用。你实现服务器提供的能力，宿主提供自己的 MCP 客户端。

具体增加的能力包括：

• 工具发现： tools/list 告诉已连接的客户端有哪些操作可用。
• 标准工具定义： 包含名称、描述，以及用 JSON Schema 定义的输入。JSON Schema 用于说明预期字段及其类型。工具也可以声明输出模式。
• 统一调用方式： tools/call 携带工具名称和参数，结果通过 MCP 的消息格式返回。

这些操作由工具规范定义。例如，工单服务可以公布 create_ticket 工具，说明何时使用、需要哪些字段。客户端可以直接使用这份定义，无须在宿主内部专门编写该工单服务的插件。

价值有多大，取决于谁在使用。如果调用方只有你自己的后端，集成两端可能本来就由你掌控。如果客户希望在不同的受支持 AI 应用中执行同一项任务，统一协议的价值就更明显。

MCP服务器和 API 怎么部署，是另一个问题

增加 MCP 不一定意味着再部署一个服务。 可以将 MCP 处理程序和 API 放在一起，也可以单独部署调用 API 的适配器，还可以直接暴露现有服务层。如何选择，取决于隔离要求、责任归属和发布需求。

使用 stdio 时，客户端启动一个进程，通过标准输入和标准输出与它交换消息。使用 Streamable HTTP 时，客户端通过 HTTP 访问 MCP 端点。这两种方式是标准传输绑定；采用网络连接时，端点仍须能被实际使用的客户端访问。

图中展示的是封装 API 的方案。直接调用共享的内部服务同样可行，前提是 MCP 这条路径保留相同的授权和校验逻辑。

用 API 和 MCP 创建同一张工单，会有什么不同？

无论请求从哪个接口进入，创建出的工单都应该相同。 假设有一个问题跟踪系统，客户希望在 EXAMPLE 项目中创建标题为“登录按钮失灵”的工单。下面的名称和字段仅用于演示应用接口契约，并非某个第三方 API。

通过 REST API 创建

应用发送经过身份认证的 POST /tickets 请求，JSON 请求体为：{"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}。

API 识别调用者身份，检查其项目访问权限，校验标题，然后调用工单创建服务。该服务返回新工单的标识符和状态。

这里的 request_key 是应用自行定义的幂等键：同一个逻辑请求使用相同的键重试时，应返回原结果，而不是再创建一张工单。这是本例的设计选择，并不是 REST 自动提供的能力。

通过 MCP 服务器创建

服务器公布名为 create_ticket 的工具，其描述可以是：“在当前用户有权访问的项目中创建工单。”它的 inputSchema 要求提供 project_key、title 和 request_key 这几个字符串字段。

完成工具发现后，客户端发送 tools/call 请求，参数为 {"name":"create_ticket","arguments":{"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}}。这里展示的是调用参数，并非完整的协议消息封装。

适配器将参数映射到同一个工单服务，或者调用现有的 POST /tickets 端点，再通过工具结果返回工单标识符和状态。MCP 统一的是发现和调用方式；“创建工单”究竟要做什么，仍由应用定义。

两条路径必须共享哪些权限边界？

适配器不能成为绕过项目权限的捷径。 调用者身份及其所属组织应从可信的认证上下文中获取，再据此检查项目访问权限。不能仅因为模型提供了一个组织标识符，就信任它。

对同一个预期操作进行重试时，应保持幂等键不变。模型重复发出的请求如果使用不同的键，并不会自动被判定为重复操作，因此应用需要定义如何识别和审核重复写入。

哪些 AI 客户端在文档中明确支持 MCP？

Claude、ChatGPT、Cursor 和 GitHub Copilot 都在文档中说明支持 MCP，但接入方式各不相同。 以下信息于 2026 年 10 月 17 日依据各自的在线官方文档核对。它们只能确认文档声明的支持情况，并不代表对每个服务器、功能或协议修订版都做过实际互操作测试。

Claude

Claude 是 Anthropic 的 AI 助手，支持自定义远程 MCP 连接器。 其连接器文档指出，这类连接由 Anthropic 的云端基础设施发起。因此，如果端点只能从你的笔记本电脑访问，就无法满足这种接入方式的要求。组织层面的控制也会影响谁能添加连接器。

对于托管产品，在承诺集成可用之前，应先验证网络可达性和客户的认证流程。本地桌面端的服务器配置属于另一套机制。

ChatGPT

ChatGPT 是 OpenAI 的 AI 应用，其文档介绍了通过 Plugins 连接自定义 MCP 服务器的方式。 OpenAI 快速入门指南中的流程是：添加 HTTPS MCP URL，配置认证，创建并安装插件，然后在对话中调用。自定义可视化界面是可选项。

按照这条文档路径接入，服务器必须能被 ChatGPT 访问；开发说明要求将服务器暴露到公网。其他客户端配置中的本地启动命令，不能直接替代这套接入配置。

Cursor

Cursor 是 AI 代码编辑器，文档列出了 stdio、Server-Sent Events（SSE，服务器发送事件）和 Streamable HTTP 连接方式。 其 MCP 文档说明了工具支持情况、通过 mcp.json 进行配置的方法，以及为有需要的服务器使用 OAuth 的方式。SSE 是服务器以流式方式发送事件的一种机制。

因此，本地开发工具和托管服务可以采用不同的连接路径。应让部署方案匹配受支持的传输方式和认证配置，不能把“能在 Cursor 中使用”当作完整的兼容性说明。

GitHub Copilot

GitHub 的 AI 编程助手 GitHub Copilot，在多个产品入口的文档中说明了 MCP 支持情况。 其可用性文档涵盖集成开发环境（IDE）、命令行界面、Copilot 应用，以及用于云端智能体和代码审查的仓库配置。CLI 支持本地和远程服务器；各编辑器的具体支持情况不同，访问权限也可能受组织策略限制。

应明确写出打算支持的产品入口，例如某个特定编辑器中的 Copilot。CLI 连接成功，并不能证明客户的仓库配置或组织策略允许在其他入口使用同一个服务器。

想看已有集成的实例，可以阅读精选 MCP 服务器指南。本文要解决的问题则是：你自己的产品是否需要提供 MCP 服务器。

什么时候用 MCP，什么时候保留 API 就够了？

当 MCP 能让客户在已经使用的 AI 客户端中完成明确的工作流时，就值得提供。 仅仅对协议感兴趣，不足以成为长期支持另一套接口的理由。

以下情况适合提供 MCP：

• 客户希望在现有的 MCP 兼容 AI 应用中，搜索产品记录或执行范围明确的操作。
• 需要向多个兼容宿主提供同一组实用能力。
• 任务适合由助手根据对话上下文，从描述清楚的操作中做出选择。
• 能够支持目标客户端的传输方式、认证和安装路径，并明确由谁负责故障和变更。

以下情况只保留 API 即可：

• 调用方是应用程序、定时任务或合作伙伴集成，而且工作流已经明确。
• AI 应用及其 API 适配器都由你掌控，无须兼容外部宿主。
• 没有人能说清，把工具开放给另一个客户端，究竟会改善哪项客户任务。
• 授权逻辑或服务行为仍不稳定。应先稳定这些基础，再增加一套接口契约。

以下情况适合两者都提供： 常规集成仍然重要，客户也希望通过对话使用产品。例如，工单产品可以保留 API，继续服务 Web 应用和自动化，同时提供经过筛选的 MCP 工具，让助手搜索和创建工单。

开发者需要复用服务层；产品负责人需要明确支持哪些任务和客户端；运维人员需要能够确认每项操作由哪个用户发起，以及如何撤销访问权限。即使这些工作都由同一个人承担，也应分清各自的责任。

MCP、API 和 CLI 各适合谁？

同一个服务可以通过这些接口，面向不同的调用方。 命令行界面（CLI）为人和脚本提供可执行命令；API 为应用代码提供编程契约；MCP 为兼容的 AI 宿主提供通用工具接口。

如果部署脚本已经在调用可靠的 CLI 或 API，增加 MCP 未必能带来改善。如果客户希望在自己的助手中执行工单操作，MCP 则可能省去为该宿主单独开发集成的工作。保留适合调用方的接口，不必仅为统一技术名词而迁移运行良好的自动化流程。

多一个接口，就多一份安全和维护责任

主要代价是多了一条需要长期支持的系统边界，即使 MCP 代码与 API 部署在一起也是如此。 工具描述、模式定义、依赖、认证集成和客户端兼容性，都需要有人维护。

分清凭据与权限

MCP 的授权规范为 HTTP 实现描述了一套基于 OAuth 2.1 的框架。OAuth 用于授权应用有限度地访问某项服务。授权在协议层面是可选的，但这并不意味着可以不保护产品的私有数据。stdio 的凭据处理方式与 HTTP 框架不同。

适配器可能同时处理两类凭据：访问 MCP 服务器的入站凭据，以及访问底层服务的出站凭据。应校验令牌的预期受众，也就是令牌原本签发给哪个服务，并保留用户获准使用的权限范围。安全指南禁止盲目接受发给其他资源的令牌，再将其透传给下游。

回到工单示例，不能因为适配器持有权限宽泛的服务凭据，就悄悄把每个连接用户都变成项目管理员。无论适配器如何安排凭据，访问检查都应保留在共享的业务操作中。

围绕能够支持的任务设计工具

提供实用且边界清楚的操作。 可以从 create_ticket 或限定范围的搜索开始，而不是开放一个能接收任意 URL、方法和请求体的万能工具。

这是产品设计建议，并非协议限制。接口范围越小，越容易解释、授权和排障。不要仅因为生成器能产出定义，就把每个内部端点都复制进工具目录。

工具描述应说明操作目的和副作用。返回足以确认结果的信息，同时避免夹带无关的敏感字段。模式定义只能约束数据结构，不能证明请求的操作已获授权或确实合适。

让故障能在两套接口之间追踪

要能从工具调用一路追踪到底层操作。 记录获得授权的身份、工具名称、相关请求标识符和结果，同时避免记录凭据或不必要的敏感数据。

应区分校验失败、权限拒绝、限流和上游服务不可用。对于提交后超时的写入请求，应依据共享业务操作的重试规则，先判断是否已经完成，再决定是否重试。MCP 不会自动替你提供这种业务保证。

本地服务器需要维护依赖和执行权限；托管服务器需要维护部署和可用性。无论哪种方式，维护工作都不会消失。

版本与限制：两套契约都要保持兼容

协议兼容性与工具兼容性，是两项不同的工作。 根据 2026 年 10 月 17 日的核查，MCP 文档将 2026-07-28 标为当前协议修订版。版本文档介绍了按请求声明版本的方式，以及如何兼容此前基于握手的修订版。

这并不能证明前面列出的每个客户端都实现了该修订版。应选择受支持的软件开发工具包（SDK），并测试目标客户端实际使用的修订版和功能。

工具的业务契约还需要单独考虑。如果 create_ticket 原来接收项目键，后来改为要求另一个标识符，即使 MCP 协议修订版没有变化，这项变更也不会因此变得兼容。迁移期间应保留旧契约，或提供一个明确区分的新工具，并配套文档和退役策略。

同样，应根据实际支持的服务和宿主设定限制，包括结果大小、允许访问的数据范围、请求时长，以及上游限流规则。协议连接成功，不代表超大响应对模型有用，也不代表耗时较长的写入可以安全重试。

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

MCP 减少了集成方式的差异，但没有消除集成工作。 以下说法都需要加上更准确的限定：

• “AI 必须通过 MCP 才能调用 API。” AI 应用可以自行实现工具。OpenAI 的函数调用文档明确描述了模型请求调用工具后，由应用执行代码的流程。当目标是使用统一的客户端与服务器接口时，MCP 才体现出价值。
• “有了模式定义，操作就是安全的。” 结构完全正确的请求，仍可能指向无权访问的项目，或执行用户不想要的写入。权限检查和审核依然是应用的责任。
• “MCP 可以替代后端。” 协议负责传递能力，并不提供工单规则、数据库或服务可靠性。
• “MCP 总是有状态的。” 这样笼统地与 REST 对比，忽略了当前规范按请求处理的模型，以及它对早期连接级会话的处理方式。应核对实际实现的传输规范修订版。

更可靠的承诺其实很克制，也很实用：客户可以从兼容宿主复用一套受支持的工具接口，而底层服务仍由你掌控。

准备接入 MCP，下一步该做什么？

先选定客户任务和目标客户端，再开始编写 MCP 工具目录。 如果产品负责人正在评估创建工单这一场景，下一步应与现有 API 的负责开发者一起，列出一份简短的验收清单。

1. 1

   定义共享的业务操作

   明确输入、结果、权限边界，以及重复请求的处理行为。把这些规则保留在现有服务中。

2. 2

   提供范围明确的工具

   添加 MCP 工具定义和处理程序，选择客户端文档列出的连接方式，同时继续向原有调用方提供 API。

3. 3

   验证关键行为

   检查正常获准的请求、项目访问被拒绝、重复写入，以及上游请求失败等情况。确认两个接口都保留相同的业务结果。

实现细节可参考 Python MCP 服务器指南。等首个工作流证明值得持续支持后，再扩展工具目录。

常见问题

已经有 API，为什么还要用 MCP？

当标准化、可发现的工具接口能让客户从兼容的 AI 应用中使用你的服务时，就适合采用 MCP。MCP 往往封装在 API 外层，因此这项决策通常是增加一个访问入口，而不是替换底层服务。

API 和端点是一回事吗？

不是。API 是接口契约，端点是对外提供其中一部分能力的地址。在工单示例中，API 包含操作及数据规则，而 /tickets 是某项操作使用的资源路径。IBM 的 API 说明区分了接口契约与请求地址。

API 有哪些常见例子？

创建工单、查询订单状态和查询账户记录，都是 API 可以提供的能力。MCP 服务器可以选取其中一些能力作为工具开放，而具体实现仍留在底层应用中。

API 和代理有什么区别？

API 定义软件如何与服务交互；代理则是转发请求的中间层。MCP 适配器可以代表客户端调用 API，但它还会提供 MCP 工具契约。仅转发 HTTP 请求，并不能提供工具发现能力。

API 分为哪四种类型？

并不存在通用的四分类标准。公开、私有和合作伙伴描述的是面向谁开放；组合式描述的是把底层操作组合起来。IBM 的 API 概览将这些视为不同维度。它们并不能决定你是否应该在 HTTP API 之外增加 MCP。

想获取 AI 开发实践中的决策建议，可以订阅邮件通讯。