什么是 MCP 服务器？2026 年 MCP 与 MCP UI 如何运作

2025年4月1日，Invariant Labs 发布了一个名为 add 的工具。它接收两个数字，返回它们的和。但它的描述里还藏着一段标记为 IMPORTANT 的内容，在客户端界面上看不到。这段内容要求模型读取 ~/.cursor/mcp.json 和 ~/.ssh/id_rsa，再通过一个闲置参数把两个文件传出去。模型照做了。用户看到的只是一道加法。

在我知道的材料里，这次演示是理解 MCP 服务器最有用的入门，因为它同时展示了两面。协议完全按设计运行：AI 客户端发现了一个工具，读取了它的描述，然后调用了它。还没有人建好的，是信任模型。

MCP 服务器是什么

MCP 服务器是一个程序，它通过 Model Context Protocol（MCP）向 AI 应用提供工具、数据和提示词。官方文档把 MCP 定义为“一个将 AI 应用连接到外部系统的开源标准”。Claude、ChatGPT、Visual Studio Code 或 Cursor 等 AI 客户端连接到服务器，询问它提供什么，再代表用户调用这些能力。

Anthropic 于 2024年11月25日发布 MCP，同时推出六个预置服务器：Google Drive、Slack、GitHub、Git、Postgres 和 Puppeteer。OpenAI 在 2025年3月采用了它，Google DeepMind 在 4月跟进。2025年12月，Anthropic 把协议捐赠给 Agentic AI Foundation。这是 Linux Foundation 旗下的一个定向基金，由 Anthropic、Block 和 OpenAI 共同创立。

它解决的是连接数量膨胀的问题。过去，每个要接入 GitHub 的 AI 应用都要写自己的连接器，每个服务商也要为各个 AI 应用提供对接。十个模型和十种工具最多需要一百项集成。MCP 将其降为二十项：每个客户端实现一次协议，每个系统提供一个服务器。

可以把它看作 AI 集成领域的集装箱。集装箱出现之前，每个港口都靠人工装卸每一批货，各有各的吊车，各有各的工人。集装箱把箱子标准化了，于是任何船、吊车和卡车都能运任何货物。但它没有标准化箱子里装什么，也从不检查里面的货。MCP 是同样的交易。记住后半句，它会在安全一节再次出现。

MCP 服务器如何运作

当前规范的版本是 2026-07-28，它在三种角色之间传递 JSON-RPC 2.0 消息。规范自己的描述只有三行：宿主是“发起连接的 LLM 应用”，客户端是“宿主应用内部的连接器”，服务器是“提供上下文和能力的服务”。

宿主、客户端、服务器

宿主就是你在里面打字的应用：Claude Desktop、IDE，或你自己的代理。在宿主内部，每个服务器连接对应一个客户端。服务器在另一端，和真实系统打交道，可能是 Postgres 数据库、GitHub API，也可能是你磁盘上的一个文件夹。宿主决定模型能看到什么、用户必须批准什么。服务器决定底层系统会做什么。

1. 宿主 Claude Desktop · IDE · 你自己的代理

   向模型展示工具，向用户征求同意

2. 客户端 每个服务器连接一个

   通过 stdio 或 Streamable HTTP 使用 JSON-RPC 通信

3. MCP 服务器 工具 · 资源 · 提示词

   描述自己提供什么，并执行调用

4. 底层系统 数据库 · SaaS API · 本地文件

   真正干活

工具、资源和提示词

服务器可以提供三类东西：

• 工具是模型可以执行的函数，例如 create_issue、query_orders、send_email。每个工具都有名称、描述和一份用于输入的 JSON Schema。
• 资源是供用户或模型读取的上下文和数据：一个文件、一份数据库结构、一条记录。
• 提示词是用户可以选择的模板化消息和工作流，比如“总结这个拉取请求”。

工具最受关注，因为它们会采取行动。也正因如此，它们承担了大部分风险。

一次工具调用，逐步拆解

2026-07-28 修订版让 MCP 变成了无状态协议。initialize 握手不再存在；每个请求都在 _meta 字段里携带协议版本和客户端能力，服务器必须实现 server/discover 方法，让客户端可以预先询问它支持什么。现在，一次工具调用是这样进行的：

1. 用户提出：为这个 bug 建一个工单

2. 第 1 步

   发现

   • 客户端可以调用 server/discover 获取版本和能力
3. 第 2 步

   列出工具

   • tools/list 返回名称、描述和输入结构
4. 第 3 步

   模型选择工具

   • 宿主把工具定义交给模型
5. 第 4 步

   用户同意

   • 规范规定宿主在调用任何工具之前必须获得明确同意
6. 第 5 步

   调用

   • 带参数执行 tools/call，协议版本放在 _meta 中

7. 缺少输入？服务器返回 input_required，客户端补上答案后重试

   第 6 步

   结果

8. 结果作为上下文返回给模型

第 6 步是这次修订新增的。需要更多信息的服务器不再向客户端反向发出自己的请求，而是返回一个标记为 input_required 的结果，由客户端收集答案，再重试原来的调用。规范把这称为 Multi Round-Trip Request 模式。

传输方式：stdio 和 Streamable HTTP

规范定义了两种标准传输方式：

• stdio：客户端把服务器作为子进程启动，通过标准输入和标准输出交换按换行分隔的 JSON-RPC 消息。大多数本地服务器都这样运行，这意味着服务器在你的机器上、以你的权限运行。
• Streamable HTTP：每条消息都是发往单一端点的 HTTP POST，回复以 JSON 对象或请求级事件流的形式返回。远程托管的服务器都这样运行。

旧的 HTTP+SSE 传输方式已被正式弃用。2026-07-28 修订版还移除了协议层的会话和 Mcp-Session-Id 请求头；需要跨调用保持状态的服务器，现在要自己生成一个句柄，并把它作为普通的工具参数接收回来。

授权

MCP 的授权是可选的，而且只适用于 HTTP。在 stdio 下，规范说服务器应当从环境中获取凭据。在 HTTP 下，受保护的 MCP 服务器扮演 OAuth 2.1 资源服务器。它必须发布 OAuth Protected Resource Metadata（RFC 9728），让客户端能找到它的授权服务器。客户端必须指明令牌是给哪一个服务器用的（RFC 8707 资源指示符）。服务器必须拒绝任何不是为它签发的令牌，安全指南还把“令牌透传”，也就是把客户端的令牌原封不动转发给下游 API，列为明确禁止的做法。

最后这条规则比看上去重要。一个收到什么令牌就转发什么令牌的服务器，会变成任何持有令牌的人的代理。

MCP UI 带来了什么：返回界面的服务器

一旦用户需要比较四十行数据、调整一个有十二个字段的表单，或者逐条批准一批变更，纯文本回答就不管用了。“MCP UI”是人们搜索这个解决办法时用的名字：服务器返回一个交互式界面，在 AI 客户端里、紧挨着对话渲染出来。

这里的进展值得说清楚。MCP-UI 最初是一个社区项目。OpenAI 在 Apps SDK 中构建了类似机制。MCP 项目于 2025 年 11 月 21 日与双方提出共同标准，并于 2026 年 1 月 26 日发布 MCP Apps，作为首个正式 MCP 扩展。MCP-UI 软件包现在实现该规范，仍是社区探索后续改进的场所。

所以今天说 MCP UI，指的就是 MCP Apps。它是官方的，但它是扩展，不是核心协议。扩展需要主动启用：客户端和服务器都必须支持，文档也明说“宿主支持情况因客户端而异”。MCP Apps 文档列出的支持宿主有 Claude、Claude Desktop、VS Code GitHub Copilot、Microsoft 365 Copilot、Goose、Postman、MCPJam 和 Archestra.AI。一个工具会返回 UI 的服务器，仍然必须能在只显示文本的客户端里正常工作。

在机制上，它复用了 MCP 自己的组件：

1. 工具的描述中包含一个 _meta.ui.resourceUri，指向一个 ui:// 资源。
2. 宿主获取这个资源，也就是一个带脚本的 HTML 页面，并且可以在工具被调用之前预先加载。
3. 宿主在一个沙盒 iframe 中渲染它，这个 iframe 无法读取父页面、父页面的 Cookie 或存储。
4. 应用和宿主通过 postMessage 使用 MCP 的一种 JSON-RPC 方言通信。应用可以请求工具调用，由宿主决定允许哪些。

代价是实打实的。你现在是在别人的应用里交付一个 Web 前端：要声明内容安全策略，要接受自己控制不了的渲染规则，还要为每个忽略 UI 的宿主准备文本后备方案。收获是审批工作不再是一段聊天记录。文档自己列出的适用场景，最后几项是“审批报销单、审查代码变更或分拣问题”，这说出了它真正的重心：MCP UI 最擅长的是决策，不是装饰。

一个只读的 Tajo 示例

Tajo 的 Alto MCP 接口包含 query_contacts，可搜索已连接工作区中保存的联系人。按邮箱查找一位现有联系人，核对返回的 ID、邮件同意状态和最近记录时间。另一个工具 get_contact_topic_status 读取该联系人的主题订阅状态。

这些操作只读取工作区。它们不会从服务商拉取最新快照、启动同步或发送消息，也不能证明所有服务商连接器已上线。应从来源调查缺失或过期的数据。空结果不能证明此人在 Brevo 中不存在。

按照 Tajo MCP 文档连接受支持的客户端，查看已授权工作区实际提供的工具。如果宿主支持 MCP Apps，交互面板可以帮助审查；文字结果仍须说明执行结果。

工具调用不等于持久同步

定期同步还需要调度、稳定的记录身份、保存进度、重试决策和已完成写入的记录。这些由执行任务的应用负责。MCP 标准化的是工具访问；列出工具并不会自动提供这些业务规则。

超时后，读取通常可以重试；发送或付款却可能已经发生。再次尝试前，应保留执行记录并核实结果。模型的置信度不能授权操作，也不能保证重试安全。

具体联系人写入可参考 Brevo API 指南；何时应为计算字段维护独立同步，可参考 reverse ETL 指南。

安全账单随协议一起到来

反对意见值得完整说出来：“MCP 把一份能删除数据、能发邮件的函数清单交给一个概率模型，然后信任陌生人写的文字来描述这些函数。这不是集成标准，这是一套带规范的供应链攻击。”这些话大部分是对的。规范也认同这个前提。它的安全部分写道，工具“代表任意代码执行，必须以适当的谨慎对待”，工具描述“除非来自可信服务器，否则应视为不可信”，而且 MCP“无法在协议层面强制执行这些安全原则”。

到目前为止的记录是这样的：

• 工具投毒。 Invariant Labs 2025年4月的披露，也就是上文那个 add 工具。同一篇文章还描述了“地毯式抽离”（rug pull），即服务器在你批准之后修改工具描述；以及“工具遮蔽”（shadowing），即一个恶意服务器改写模型对另一个可信服务器的行为。
• 本地服务器被攻破。 2025年7月，JFrog 披露了 mcp-remote 0.0.5 到 0.1.15 版本中的 CVE-2025-6514，它让恶意服务器能在用户机器上执行命令。同一个夏天，CVE-2025-49596 波及 Anthropic 自家的 MCP Inspector，它默认发布时没有任何身份验证。
• 权限范围膨胀。 官方的安全最佳实践点名了这种模式：因为服务器列出了所有权限范围、客户端又全部申请，令牌一开始就被授予了 files:* 或 admin:*。
• 官方担忧。 2026年5月，美国国家安全局（NSA）表示，MCP 的“快速扩散已经超过了其安全模型的发展速度”。

反对意见错在结论。解决办法从来不是停止把模型连接到系统；团队早就在这么做了，把原始 API 密钥贴进提示词和脚本里，没有任何审计记录。解决办法是把 MCP 服务器当作任何其他高权限依赖来对待：

• 只从你在 MCP 之外也愿意托付同样凭据的来源安装服务器。
• 优先选择使用 OAuth 和窄权限范围的远程服务器，而不是持有长期密钥的本地二进制程序。
• 每次写入都要求人工审批，并记录谁批准了什么。
• 固定服务器版本，工具描述一变就重新审查。
• 暴露围绕任务的工具，而不是完整的 API；从未暴露的删除端点，模型就无从滥用。

协议标准化了箱子。检查货物，仍然是你的工作。

自己构建 MCP 服务器，还是使用现成的

mcp.so 这样的公共目录收录了社区构建的服务器，许多 SaaS 供应商也会发布自己的服务器。比如 Brevo 提供了一个 MCP 服务器，它还被拆分成多个独立服务器，所以你可以只给代理联系人权限，而不给营销活动权限。这个决定与其说关乎工作量，不如说关乎谁来决定工具的形态。

你的代理应该使用哪个 MCP 服务器？

1. 供应商发布了覆盖该任务的服务器

   使用供应商的服务器

   它跟随 API 更新，并由供应商维护。

2. 只有一个系统，但你需要更少或更安全的操作

   使用它，但收窄范围

   授予最小权限范围，只暴露代理需要的工具组。

3. 内部数据，或没有服务器的系统

   构建一个小型服务器

   在你自己的 API 之上，用你自己的认证，提供少量围绕任务的工具。

4. 任务跨越两个或更多系统

   构建或采用一个受治理的层

   在所有系统之上使用同一套工具、同意规则和审计历史。

构建一个基础服务器是简单的部分。用官方 SDK，一个带一个工具、能跑起来的 stdio 服务器，一个下午就能写完。代价在后面：HTTP 版本要做 OAuth，要处理弃用（2026-07-28 修订版弃用了 Roots、Sampling、Logging 以及 Dynamic Client Registration），还要持续撰写模型能正确理解的工具描述。最常见的错误是把 API 按一个端点一个工具来封装。每一条工具描述都是模型必须阅读和权衡的文字，所以一份简短的、围绕任务的工具清单，胜过整个 API。

MCP、API、集成与 iPaaS

MCP 不会取代 API。几乎每个 MCP 服务器都是对某个 API 的封装。真正干活的地方仍然是 API，它有自己的速率限制、数据模型和各种怪癖。MCP 改变的是谁能调用它：由模型在运行时根据描述来选择调用，而不是由开发者提前写死。

这个区别能把 MCP 和另外两个常被混为一谈的东西清楚地分开：

• 集成和 iPaaS（主要平台对比见这里）按计划或触发器确定性地移动数据，不管有没有人在聊天。每晚把 40,000 笔订单同步进 CRM，不应该取决于模型是否决定发起 40,000 次工具调用。
• 反向 ETL 把数据仓库里建模好的数据推回业务工具。反向 ETL 是什么、适合什么场景是另一个话题，它是一条管道，不是一场对话。
• MCP 用于人或代理需要跨这些系统按需提问、查看或操作的时刻。

这个错误在两个方向上都会发生。有的团队用 MCP 服务器做批量同步，得到的是缓慢、昂贵、不可重复的管道。另一些团队精心搭好了集成，然后把一把原始 API 密钥交给 AI 助手去查询，得到的是一道无人管控的侧门。

对于受支持的集成，持久任务及其检查工具应共用明确的权限边界。针对具体流程，核实连接器、允许的操作和记录的结果。集成文档区分设置指导与仍需生产证据的路径。MCP 可以提供单独获批的工具；工具列表不能证明定期同步或所有必要控制已启用。

22 个月里，MCP 从六个参考服务器发展成一个 Linux Foundation 项目，Claude、ChatGPT、VS Code 和 Cursor 都在使用它。把模型连接到系统，现在是便宜的部分。决定它在那里被允许做什么，才是真正的工作。