MCP 解析：它连接什么、不做什么以及它适用于何处

模型上下文协议（MCP）是一种开放协议，用于通过标准化的客户端-服务器契约将 AI 应用程序连接到外部能力和信息。MCP 服务器可以暴露工具、资源和提示；兼容 MCP 的主机或客户端代表 AI 应用程序发现并使用这些能力。MCP 不要求服务器运行自己的语言模型，也不取代所暴露能力背后的代理运行时、业务授权、租户隔离、应用程序 API 或领域架构。

MCP 真正标准化的内容

在 MCP 之前，每个 AI 应用程序都可以通过自己的工具模式、插件格式、身份验证约定和连接代码来集成外部系统。同一个服务可能需要为桌面 AI 客户端、IDE 代理和自定义应用程序使用不同的适配器。

MCP 创建了一个可复用的协议边界。外部系统通过 MCP 服务器暴露能力，而兼容的 AI 主机实现 MCP 客户端。这减少了 AI 应用程序与底层工具或数据提供者之间的集成耦合。

该协议并不标准化整个应用程序。它标准化的是能力在该边界上如何被描述、发现和调用。

最简单的示例

假设一个 AI 编码应用程序需要访问本地项目目录。没有 MCP 时，该应用程序可能会直接实现自己的文件系统集成。

使用 MCP 时，文件系统服务器可以暴露诸如列出目录、读取经批准的文件或在允许的工作区内写入等能力。AI 主机通过 MCP 客户端连接，并将这些能力呈现给模型或代理运行时。

服务器不需要理解用户的自然语言请求。主机/模型决定哪个能力有用；MCP 服务器根据自身的安全规则执行结构化请求。

一个基本的 MCP 工具调用

1

1. 主机连接到服务器

支持 MCP 的应用程序配置对外部 MCP 服务器的访问。

2

2. 发现能力

客户端了解服务器暴露了哪些工具、资源或提示。

3

3. 模型或运行时选择能力

AI 应用程序决定需要某个已暴露的能力。

4

4. 客户端发送结构化请求

参数通过 MCP 发送到服务器。

5

5. 服务器授权并执行

服务器验证请求并调用其底层系统。

6

6. 结果返回主机

结果成为观察或上下文输入。

7

7. 主机决定下一步

模型/运行时可以回答、调用另一个工具或继续工作流。

简单示例止步之处

MCP 不定义主机如何选择工具、代理如何规划、业务工作流如何建模，或发票、部署等领域对象应如何表现。

协议可以使集成具有互操作性，而底层应用程序仍然不正确、不安全或设计糟糕。一个完全有效的 MCP 请求仍然可能调用错误的业务能力。

核心边界是：MCP 标准化的是集成语义，而不是应用真相或业务正确性。

MCP 架构：主机、客户端和服务器

一个主机可以连接多个 MCP 服务器，而一个 MCP 服务器可以对接一个或多个底层系统。主机仍然负责将 MCP 结果集成到更广泛的 AI 应用中。

服务器可以位于主机本地、作为独立进程运行，或通过网络传输远程运行。托管拓扑和模型位置是相互独立的决策。

三个核心服务器原语

工具、资源和提示词解决不同的需求

	工具	资源	提示词
主要目的
典型交互
示例
典型风险

工具：可调用的能力

工具是 MCP 服务器提供给主机的结构化操作。工具具有名称、描述和输入模式；现代实现还可以提供结构化输出。

示例包括搜索仓库、读取客户记录、创建工单、运行构建或发送消息。工具可以是只读的，也可以具有副作用。

良好的 MCP 工具界面应代表连贯的用户或代理目标，而不是机械地镜像每个内部 API 端点。具有不同权限、确认要求或影响范围的操作通常应作为单独的工具。

资源：可读的上下文和数据

资源暴露客户端可以列出或读取的数据或内容。当语义操作是“给我这个工件或信息”而不是“执行这个动作”时，它们自然适用。

资源 URI 不是授权许可。服务器仍然拥有访问控制权，并且必须验证哪个主体可以读取底层对象。

2026-07-28 协议修订版为列表和资源读取响应增加了缓存语义，包括新鲜度和缓存范围，使缓存行为更加明确。

提示词：可复用模板

MCP 提示词允许服务器向兼容的客户端发布可复用的提示词模板。这可以使特定领域的指令靠近能力提供者。

MCP 服务器提供的提示词不会自动优先于主机的系统或安全指令。主机决定提示词材料如何进入其上下文层次结构。

因此，协议提供的提示内容应被视为具有明确信任语义的能力数据，而不是不受限制的指令权限。

工具还是资源？

AI 模型在哪里？

MCP 不要求模型在 MCP 服务器上运行。模型可以托管在云端、本地托管、嵌入桌面应用程序中，或通过其他提供商访问。

主机通常负责模型交互。MCP 服务器暴露外部能力。因此，本地 MCP 服务器可以被模型运行在云端的主机使用，而远程 MCP 服务器也可以被模型运行在本地的主机使用。

如果 MCP 服务器本身在内部调用 LLM，该模型是协议边界之后服务器实现的一部分；MCP 并不要求这样做。

MCP 不会取代 API

MCP 服务器通常封装现有的 API 或服务。REST、GraphQL、SQL、SDK 调用和内部服务契约可以保持原样。

MCP 增加了一个面向 AI 的互操作性层。底层领域 API 仍然可以作为普通确定性客户端的权威应用程序契约。

因此，通常的架构是 API/服务优先，选定的面向 AI 的能力其次——而不是“用 MCP 替换所有 API”。

MCP 与函数调用

函数调用和 MCP 相关但不完全相同

	函数调用	MCP
范围
工具定义
可移植性
它们可以共存吗？

OpenAI 目前将远程 MCP 服务器作为一种工具类型，与普通函数调用、网络搜索、shell 和其他工具并列。该实现说明了架构关系：MCP 连接和模型自身的工具调用接口可以组合使用。

MCP 不会创建代理循环

AI 代理需要一个运行时，能够决策、调用工具、观察结果、更新状态并继续或停止。MCP 可以提供该循环使用的一些工具和数据。

MCP 服务器不会自动成为规划器、记忆系统或编排器。这些职责通常保留在主机或代理运行时中。

非代理型应用程序也可以使用 MCP。一次确定性的 MCP 工具调用并不需要自主的多步骤代理。

MCP 与 A2A

MCP 主要将 AI 主机或代理连接到工具、资源和数据等能力。A2A 则面向独立代理系统之间的协作。

远程代理可以在内部使用 MCP 访问数据库和工具，同时向其他代理暴露 A2A 接口。因此，这些协议可以分层使用，而不是相互替代。

现有的协议栈文章负责更广泛的 MCP/A2A/UCP/AP2/A2UI 对比；G02 仍是 MCP 的规范定义。

本地和远程 MCP 使用不同的传输现实

MCP 可以连接到本地和远程服务器。本地桌面集成通常使用进程级传输，例如 stdio；远程服务器则使用面向 HTTP 的传输。

2026-07-28 修订版使协议核心变为无状态。请求携带协议处理所需的信息，而不再依赖早期的协议级会话模型。

当前修订版还将方法和能力名称放入 HTTP 头，使网关、WAF、限流器和负载均衡器能够更自然地路由和计量 MCP 流量。

为什么 MCP 版本感知很重要

SDK 版本和协议版本也是不同的东西。当前的 TypeScript v2 SDK 是 2026-07-28 修订版的稳定线，而较旧的 v1.x 仍是 2025 时代行为的维护线。

当互操作性行为依赖于 SDK/库版本和协议修订版时，架构文档应同时记录两者。

MCP 2026-07-28 有哪些变化

Roots、采样和日志记录不再是新实现的方向

2026-07-28 版本将 roots、采样和日志记录标记为已弃用的协议能力，并设定了明确的兼容窗口。

较旧的教程可能仍将这些功能展示为核心原语。新的实现工作应遵循当前规范，而不是盲目复制旧的生命周期图。

弃用并不意味着立即移除。它意味着新系统应避免对协议正在淘汰的能力产生不必要的新依赖。

长时间运行的工作与普通的 MCP 工具调用不同

长时间运行的操作需要超越简单即时工具结果的生命周期语义。在当前生态系统中，Tasks 已移入专门的 MCP 扩展。

这强化了一个有用的设计原则：基础协议不需要吸收每一个代理运行时关注点。

应用程序也可以将长时间运行的工作流所有权完全保留在自己的运行时中，并使用普通的 MCP 工具作为底层操作。

MCP Apps 扩展 UI 能力而不重新定义核心协议

MCP Apps 通过扩展模型将更丰富的交互式 UI 体验与 MCP 工具关联起来。

宿主仍然控制该 UI 的嵌入、沙箱化和安全保护方式。

因此，核心能力交换和 UI 渲染应保持为独立的架构职责。

MCP 授权不是您完整的授权模型

远程 MCP 需要协议级别的身份验证和授权机制，以便客户端和服务器能够建立可信访问。当前规范继续强化 OAuth/OIDC 相关行为。

该层回答的是客户端是否被允许连接或请求协议范围。它不会自动回答 Alice 是否可以退款订单 123、代理是否可以写入生产配置，或租户 A 是否可以读取租户 B 的数据。

这些领域决策属于服务器/应用程序授权模型，并且必须在调用底层操作之前强制执行。

身份可以跨越多个边界

一个 MCP 请求可能涉及 MCP 客户端应用程序、已登录的人类用户、代理/会话身份以及下游服务账户。

服务器需要明确的策略来确定操作代表哪个主体执行。否则，强大的服务凭证可能成为混淆代理路径。

对于企业使用而言，用户身份、代理身份、MCP 连接与下游授权之间的关联，与协议兼容性同样重要。

租户隔离仍处于 MCP 能力发现范围之外

多租户 MCP 服务器在读取或更改租户拥有的资源时，必须应用租户范围。返回一个名为 search_documents 的工具，并不能定义哪些租户的文档符合条件。

租户范围应源自可信身份或成员关系，并传递到数据库、缓存、向量搜索、对象存储和下游 API 中。

检索跨租户内容，然后要求模型不要使用它，这本身就已经是隔离失败。

MCP 未定义事实来源

MCP 服务器可以暴露数据库、文档存储库、网络搜索服务或 AI 生成的摘要。协议并未声明哪个来源对某项主张具有权威性。

事实来源规则属于应用/领域架构。主机或服务器可以通过工具设计、元数据、访问策略或验证来编码权威性，但 MCP 本身并不会让某个能力变得“真实”。

因此，一个工具可以通过 MCP 完全可调用，却仍然返回过时、次要或非权威的信息。

MCP 与上下文工程

MCP 可以增加 AI 应用可用的能力和信息，但上下文工程仍然决定什么内容会到达模型。

在许多主机中，工具目录会消耗模型可见的上下文。工具结果可能很大。资源可能很多。主机需要选择、过滤、动态加载和压缩，而不是在每一轮都暴露所有内容。

因此，能力可用性和模型可见上下文应被视为不同的层。

围绕结果和风险边界设计 MCP 工具

审批属于执行架构

主机可以在调用选定的 MCP 工具之前要求用户批准。OpenAI 当前的 MCP 集成支持自动或显式批准的执行模式。

主机批准很有用，但不应成为服务器的唯一保护，因为另一个兼容的 MCP 客户端可能使用不同的批准模型。

对于破坏性或具有财务影响的行动，应采用纵深防御：清晰的工具契约、适当的运行时审批、服务端授权、业务校验和审计。

MCP 可观测性应将协议调用与领域操作关联起来

当 MCP 追踪能够与底层应用调用、数据库变更或业务事务相关联时，其价值最大。

2026-07-28 生态系统标准化了 W3C Trace Context 传播约定，使得跨主机、客户端、服务端和下游服务跟踪请求变得更加容易。

仅靠协议日志不足以应对具有重大影响的操怍。审计证据还应记录相关主体、租户、目标资源、审批以及由此产生的状态变更。

MCP 无法解决的问题

原始实现证据：Aaasaasa AI Client

该应用可以在回环地址上运行经过身份验证的 Streamable HTTP MCP 端点。该端点仅暴露通过中央工作区权限代理选择的目录。

本地端点和远程路由是相互独立的关注点：本地连接器可以仅绑定到回环地址，而 Secure MCP Tunnel 可以使已批准的 MCP 服务对获准的外部 AI 客户端可达，同时不暴露整个本地机器。

中央权限模型区分仅聊天、只读、项目写入和自定义目录配置文件。Direct Chat 没有文件系统或 shell 访问权限；具备工具能力的智能体运行时使用所选的权限配置文件。

这是 G02 边界的直接实现：MCP 提供标准化的能力连接，而应用自有的权限代理决定服务器可以暴露哪些目录。

MCP 何时适合使用

何时不需要 MCP

不要仅仅因为应用程序使用了 AI 就添加 MCP。如果你的后端已经调用了一个内部 API，并且没有独立的 MCP 客户端需要该能力，那么普通的函数或服务调用可能更清晰。

MCP 在互操作性边界处增加价值。没有该边界，协议可能变成一个不必要的适配层。

架构问题不是“这个项目有 AI 吗？”，而是“独立演进的 AI 主机和能力提供者是否能从标准契约中受益？”

MCP 安全检查清单

常见误解

实用的 MCP 设计顺序

在实现服务器之前设计边界

1

1. 确定互操作性边界

确认独立的 AI 主机确实需要可重用访问。

2

2. 保持域 API 权威

在 MCP 背后保留真实的应用程序/服务契约。

3

3. 有意识地选择原语

根据语义使用工具、资源和提示。

4

4. 按风险和权限拆分

分离读取、写入、破坏性和需要审批的操作。

5

5. 定义身份传播

了解每次调用代表哪个客户端、用户、代理和下游主体。

6

6. 执行业务授权

验证权限、租户范围和目标所有权。

7

7. 选择本地或远程传输

使部署拓扑与实际需求匹配。

8

8. 固定协议/SDK 预期

记录 2026-07-28 与旧版本的兼容性。

9

9. 为重要操作添加审批

使用与风险相适应的确认控制。

10

10. 设计结构化输出

返回简洁的机器可用结果。

11

11. 添加跟踪和审计关联

将 MCP 调用连接到下游服务/业务事件。

12

12. 测试可移植性

在互操作性为明确要求时，验证多个客户端。

MCP 架构检查清单

边缘情况和限制

本地 stdio MCP 服务器可能几乎没有网络暴露，但如果进程本身具有过多的文件系统或 shell 权限，仍然可能很危险。

远程 MCP 服务器可能只暴露公共文档或高度敏感的企业操作。如果没有能力和授权上下文，“远程 MCP”几乎不能说明风险。

一些服务器可能只使用工具而忽略资源/提示。MCP 兼容性并不要求每个可选原语都同等重要。

主机可以在其内部工具模型和 MCP 之间进行转换。用户可能永远不会直接看到协议边界，只要安全性和归属仍然清晰，这是可以接受的。

MCP 继续快速发展。扩展、授权模式、SDK API 和生态系统约定可能比核心架构区别变化得更快。

什么会改变这个答案？

未来的 MCP 修订可能会改变生命周期、传输方式、授权和扩展机制。2026 年 7 月的修订已经表明，为什么特定于实现的声明必须注明日期。

只有当 MCP 从互操作性协议扩展为端到端应用/代理架构标准时，其规范边界才会改变。而当前协议定义的并非如此。

对于实现工作，应始终检查当前规范和确切的 SDK 版本，而不是从旧教程中复制对版本敏感的示例。

相关规范知识

MCP 属于 Agentic AI 的下游：首先理解代理/运行时/工具边界，然后当外部能力需要可移植的协议契约时使用 MCP。

MCP 还依赖于 RBAC 和租户隔离，因为协议级别的能力暴露并不决定应用授权。

更广泛的协议栈文章解释了 MCP 与 A2A、UCP、AP2 和 A2UI 并列的位置。G02 仍然是 MCP 本身的规范来源。

常见问题

模型上下文协议常见问题

什么是 MCP？

模型上下文协议是一种开放的客户端-服务器协议，用于通过标准化契约将 AI 应用连接到外部工具、资源、提示和能力提供者。

MCP 服务器需要 AI 模型吗？

不需要。MCP 服务器可以是完全确定性的软件。模型通常在 AI 主机或代理运行时中运行，尽管服务器可以选择在内部使用 AI。

MCP 客户端和服务器有什么区别？

客户端是 AI 主机用于与能力提供者通信的协议组件。服务器发布并执行其暴露的能力。

MCP 会取代函数调用吗？

不会。函数/工具调用是模型调用已配置能力的方式。MCP 标准化了与外部能力服务器的发现和通信。主机可以桥接两者。

MCP 会取代 REST API 吗？

不会。MCP 服务器经常包装现有的 REST、GraphQL、数据库或服务 API，并提供面向 AI 的互操作性层。

MCP 是代理框架吗？

不是。MCP 暴露能力。代理规划、状态、记忆、上下文管理、重试、编排和停止属于周围的运行时。

MCP 和 A2A 有什么区别？

MCP 主要将 AI 主机或代理连接到工具和数据提供者。A2A 连接独立的代理系统以进行协作和委托。

MCP 处理授权吗？

MCP 包含协议级别的授权机制，尤其是对于远程服务器，但应用仍必须执行业务权限、资源所有权和租户隔离。

MCP 可以与本地模型一起使用吗？

可以。模型位置与 MCP 无关。本地模型主机可以调用本地或远程 MCP 服务器，云模型主机可以通过适当的连接架构使用经批准的本地或远程 MCP 服务器。

当前的 MCP 规范版本是什么？

截至 2026 年 10 月 8 日，当前规范修订版为 2026-07-28。较旧的 2025 时代实现仍在使用，因此必须检查兼容性。

术语表

关键 MCP 术语

MCP

模型上下文协议，一种用于 AI 主机/客户端与外部能力服务器之间互操作连接的开放协议。

MCP 主机

拥有模型交互并使用 MCP 客户端连接到服务器的 AI 应用或运行时。

MCP 客户端

主机侧与 MCP 服务器通信的协议组件。

MCP 服务器

实现 MCP 并暴露工具、资源、提示或受支持扩展的能力提供者。

工具

由 MCP 服务器暴露的可调用结构化能力。

资源

通过 MCP 资源方法暴露的可读数据或内容。

提示

由 MCP 服务器为兼容主机暴露的可重用提示模板。

可流式 HTTP

用于远程/网络服务器通信的面向 HTTP 的 MCP 传输。

stdio

常用于本地 MCP 服务器集成的进程标准输入/输出传输。

server/discover

现代 MCP 方法，允许客户端在 2026-07-28 协议时代检查服务器能力。

MRTR

多轮往返请求，一种在 2026-07-28 协议时代在请求期间获取额外输入的机制。

MCP 扩展

与基础协议组合且可以单独演进/版本化的能力，例如 Tasks 或 MCP Apps。

结论

当 MCP 的边界保持狭窄时最容易理解：它通过标准协议将 AI 应用连接到外部能力。

模型不必位于 MCP 服务器上。服务器不会成为代理运行时。列出的工具不会成为已授权的业务操作。而且 MCP 不会取代底层 API、真相来源、租户隔离或领域架构。

这种狭窄性正是该协议的优势。MCP 可以标准化 AI 系统访问工具和数据的方式，同时将应用所有权、安全性、业务语义和模型选择留给真正拥有它们的层。

主要来源和当前文档

MCP 发展迅速，因此本文中对版本敏感的声明均以 2026 年 10 月 8 日的状态为准。Aaasaasa AI Client 部分是原始实现证据，并明确限于已验证的 MCP 连接器和权限代理范围。

模型上下文协议 — TypeScript SDK v2

当前稳定的 TypeScript SDK 文档，实现了 2026-07-28 MCP 规范以及服务器/客户端原语。

模型上下文协议 — 2026-07-28 规范发布

当前 MCP 协议修订版的官方发布说明，包括无状态核心、MRTR、路由、缓存、授权加固、扩展和弃用。

MCP TypeScript SDK — 支持协议修订版 2026-07-28

针对当前协议修订版及早期版本兼容性的特定版本实现指南。

OpenAI — MCP 服务器

OpenAI 当前关于通过 Secure MCP Tunnel 将模型连接到远程 MCP 服务器以及本地/私有 MCP 服务器的指南。

OpenAI — Agents API 的 MCP 连接

当前 MCP 连接指南，涵盖服务、环境和 stdio 位置以及允许工具控制。

OpenAI — 工具

当前概述，将远程 MCP 服务器与函数调用、网络搜索、shell 和其他模型工具并列。

OpenAI — MCP 服务器概念

当前关于 MCP 服务器暴露工具、资源和提示以用于外部服务集成的描述。