读完Google这份Agent白皮书,我才理解了什么是MCP

Google和Kaggle之前联合办了一个5天的AI Agent课程，本文章是第二天提供的文档《Agent Tools & Interoperability with Model Context Protocol (MCP) 》的内容梳理和总结。

本文并非单纯的翻译，而是在个人理解的基础上归纳总结。

本次的MCP白皮书并非单纯的介绍MCP，Google点出了其应用场景中很关键的安全问题，这对Agent从个人应用走向企业应用十分重要，十分推荐详细阅读原文的最后两章。

获取原文在我的公众号回复：Google Agent Course

同时如果不想看长文，我从开发，运维和项目负责人的三个角度总结了这份文档，需要的话，公众号回复：Google Agent Course Summary

在之前的文章 读完Google这份Agent白皮书，我才理解了什么是Agent 中，我们提到过大语言模型（LLLM）是通过一定的语料训练出来的一个下一个词源预测模型。

因此其无法知道他语料外的事情，比如今天NBA 湖人vs猛龙的比分；同时在早期他的数学能力也很差，基于其技术原理就像一个复读机，你告诉他1 + 1 = 2，他就回答你1 + 1 =2；当你问他1 + 2的时候他因为没见过，就开始胡说八道。

因此为了扩展LLM的能力边界，我们通过引入工具，来让他做更多的事情。

工具是基于大型语言模型的应用程序可以使用的一种函数或程序，用于完成模型能力范围之外的任务。

一般而言，工具满足两个特性：

• 他让模型可以了解（To Know）一下额外的信息；

• 他让模型可以去做（To Do）一些事情；

工具的基本构成三要素

• 工具名（即函数名）

• 参数（即函数参数）

• 自然语言描述的用途和使用方法（详细的注释）

一般而言我们将工具划分为如下三种类型：

1. 函数工具（Function Tools）

由开发者定义的外部函数，工具的定义应提供模型使用该工具的基本细节；这作为请求上下文的一部分提供给模型。

一个标准的提供给模型使用的函数应该如下所示：

2. 内嵌工具（Build-in Tools）

一些模型会通过隐式或后台服务的形式，为自己的模型提供一些能力。

以Google的Gemini API 为例，其提供了查询，代码执行，URL上下文和计算机使用的功能。

如下代码所示，展示了一个对比两个URL内容的案例：

3. 代理工具（Agent Tools）

对智能体（Agent）工具进行分类不仅是为了组织和管理，更在设计指导、性能优化、安全治理以及人机协作等方面具有核心价值，不同类别的工具其侧重点存在不同，白皮书中根据其主要功能或其所促进的各种类型的交互将工具划分为如下的四类：

• 信息检索：允许智能体从各种来源获取数据，例如网络搜索、数据库或非结构化文档。

• 行动/执行：允许智能体执行现实世界操作：发送电子邮件、发布消息、启动代码执行或控制物理设备。

• 系统/API集成：允许智能体执行现实世界操作：发送电子邮件、发布消息、启动代码执行或控制物理设备。

• HITL：促进与人类用户的协作：请求澄清、寻求关键操作的批准，或移交任务供人类判断。

进一步的，Google将信息检索类进行了进一步的划分，并给出了关键设计建议。

这份表格根据工具的主要功能及其促进的交互类型对智能体工具进行了分类，并为开发者提供了确保工具高效、可靠且安全的实战指南：

1. 数据检索的差异化处理

• 对于结构化数据，重点在于"契约"的清晰度（即 Schema 定义）和查询效率，以确保模型能准确提取字段信息。

• 对于非结构化数据，设计者必须意识到模型"上下文窗口"的物理限制，不能盲目喂入大量文本，而应通过高质量的检索算法和指令来精简信息。

2. 安全与授权的重要性

• 在涉及 Google 连接器或第三方服务时，文档特别强调了身份验证（Authentication）和授权（Authorization）的重要性。

• 开发者需要确保 API 密钥的管理是安全的，且必须考虑 API 的"速率限制（Rate Limits）"，防止 Agent 在自动化执行时因触发限制而导致任务失败。

3. 确定性与容错性

• 使用内置模板可以增加模型输出的确定性，前提是模板的参数必须定义得非常明确。

• 错误处理被视为一种"沟通渠道"，开发者应通过描述性的错误消息指导模型在遇到 API 调用失败时如何进行自我修正或重试。

通过这些分类建议，研发人员可以根据具体的业务场景（如信息查询、现实动作执行或系统集成）采用针对性的设计策略，从而构建更加健壮的智能体系统。

对于工具的设计，白皮书将其精炼成为七条重要原则，接下来我们将一一拆解这些原则，并将其与我们软件开发中的相关内容做一些映射。抽象的来看很多原则上或者说本质上的内容是没有改变的。

1. 文档至关重要

2. 描述动作而非实现

3. 发布任务而非API调用

4. 保持工具颗粒度尽可能细

5. 设计简洁的输出

6. 有效利用验证

1. 适当的报错信息

工具文档中的三要素都会被送入模型的上下文，供模型决策应该如何使用。因此一个好的文档十分重要，其一般满足如下要求：

• 清晰的名字：具有清晰的描述性、易于人类阅读且具有特异性，以帮助模型决定使用哪种工具。这对于治理也很重要；如果工具调用被记录，清晰的名称将使审计日志更具信息价值。

• 描述清楚所有输入输出参数：所有输入到工具的内容都应清晰描述，包括所需的类型以及工具对该参数的用途。

• 简短的参数列表：长参数列表会使模型感到困惑；应保持参数列表简短，并给参数起清晰的名称。

• 清晰的工具描述：请清晰、详细地描述输入和输出参数、工具的用途以及有效调用该工具所需的其他任何细节。避免使用缩写或技术术语；重点用简单的术语进行清晰的解释。（和代码要求里面的略有区别，代码要求不要过长，很多时候我们会用缩写替代2 as to ，Number as num）

• 添加有针对性的示例：示例有助于解决歧义、展示如何处理复杂请求或阐明术语差异。它们也可以作为一种无需借助微调等更昂贵方法来优化和定向模型行为的方式。你还可以动态检索与当前任务相关的示例，以最大程度减少上下文冗余。

• 为关键参数提供默认值：为关键参数提供默认值，并确保在工具文档中记录和描述这些默认值。如果文档记录完善，大型语言模型（LLMs）通常能够正确使用默认值。

这是两个十分直观的例子，第一个你根据他的注释以及函数名可以很快的知道其内容，第二个找不到这个的开发者，甚至是找到了你都可能不知道这个函数在干嘛！！

模型的指令应描述操作，而非特定工具。这对于消除工具使用说明之间可能存在的冲突（可能会使LLM感到困惑）非常重要。在可用工具可能动态变化的情况下（如MCP），这一点尤为相关。

• 描述要做什么，而非怎么做：解释模型需要做什么，而不是如何做。

• 不要重复指令：不要重复或重述工具指令或文档。这可能会使模型混淆，并在系统指令和工具实现之间造成额外的依赖关系。

• 不要规定工作流程：描述目标，并为模型自主使用工具留出空间，而不是规定特定的操作顺序。

• 务必解释工具间的交互：如果一个工具具有可能影响另一个工具的副作用，请记录这一点。例如，fetch_web_page工具可能会将检索到的网页存储在文件中；记录这一点，以便智能体知道如何访问数据。

工具应封装智能体需要执行的任务，而非外部API。

仅仅编写现有API表层的简单包装工具很容易，但这是一个错误。工具开发者应该定义能够清晰捕捉智能体可能代表用户执行的特定操作的工具，并记录具体操作和所需参数。

API旨在供人类开发人员使用，他们完全了解可用数据和API参数；复杂的企业级API可能有数十甚至数百个可能影响API输出的参数。相比之下，面向智能体的工具预计会被智能体动态使用，智能体需要在运行时决定使用哪些参数以及传递什么数据。如果该工具代表智能体应完成的特定任务，智能体更有可能正确调用它。

这使得工具的文档记录更加容易，并使智能体在判断何时需要使用该工具时更加一致。

• 定义清晰的职责：确保每个工具都有清晰、详细记录的用途。它的功能是什么？应在何时调用？是否有任何副作用？将返回哪些数据？

• 不要创造多个工具：一般来说，不要创建需要依次执行多个步骤或封装冗长工作流程的工具。这类工具的文档编写和维护可能会很复杂，大型语言模型也难以始终如一地使用它们。在某些场景下，这样的工具可能会很有用——例如，如果一个常用的工作流需要按顺序进行多次工具调用，那么定义一个封装了多个操作的单一工具可能会更高效。在这些情况下，务必非常清晰地记录该工具的功能，以便LLM能够有效地使用该工具。

大量的返回数据会对性能和成本产生不利的影响。

• 不要返回大量的数据：返回的内容会在本次的上下文，也会在历史中，影响模型的推理。（后面会写Transformer的原理）

• 使用外部系统：利用外部系统进行数据存储和访问。例如，不要直接将大型查询结果返回给LLM，而是将其插入临时数据库表并返回表名，以便后续工具可以直接检索数据。一些AI框架本身也提供持久化的外部存储，例如Google ADK中的Artifact Service。

这也是我之前在开发的时候踩过的大坑，想要了解的请看Agent 开发实战

AI应用开发实战：从0到0.8，构建一个高精度数据问答AI Agent的全流程复盘与思考

大多数工具调用框架都包含对工具输入和输出的可选模式验证，尽可能使用这种验证功能。

• 明确的规范：让大型语言模型更清楚何时以及如何使用该工具；

• 运行时纠错机制：让模型在调用时可以判断是否正确，以及根据错误适当的修改。

• 规范的作用：通过 required 字段明确告知模型 symbol 是必须提供的，而 date 的描述则规范了输入格式必须为 YYYY-MM-DD，这降低了模型胡乱猜测参数或提供错误格式的概率。

运行环境错误（策略引导） 当遇到 API 频率限制时，描述性的消息可以防止模型盲目重试：

• 工具返回：{"isError": true, "content": [{"type": "text", "text": "获取天气数据失败：已超过 API 频率限制。请等待 15 秒后再调用此工具。"}]}

• 作用：这告诉模型失败是暂时的，并明确了等待时间，模型可以据此向用户解释情况或在 15 秒后重试。

文档中提出的 Agent 工具设计最佳实践与传统软件开发中的设计模式及指导原则高度契合，本质上是将结构化编程的严谨性引入到了自然语言交互的语境中。以下是这些最佳实践与软件开发原则的详细对比：

1. 单一职责原则 (SRP) 与 工具粒度 (Granularity)

文档强调“使工具尽可能细粒度”，建议函数保持简洁并限制为单一功能。

• 对比： 这直接对应了 SOLID 原则中的单一职责原则 (Single Responsibility Principle)。

• 深度洞察： 在传统软件中，SRP 是为了提高代码的可维护性和测试性；而在 Agent 开发中，细粒度的工具是为了提高模型的确定性。复杂的“多功能工具”会增加模型理解的难度，导致调用一致性下降。

2. 门面模式 (Facade Pattern) 与 任务导向接口 (Task-based Publishing)

文档建议“发布任务，而非 API 调用”，强调工具应封装具体的任务，而不是简单地包装底层的企业级 API。

• 对比： 这与门面模式 (Facade Pattern) 异曲同工。门面模式旨在为复杂的子系统提供一个简化的接口。

• 深度洞察： 企业级 API 可能拥有成百上千个参数，供具有完全背景知识的开发者使用。Agent 需要在运行时动态决策，因此开发者必须通过工具层隐藏底层复杂性，提供更符合用户意图（Task-oriented）的逻辑抽象。

3. 面向接口编程与工具契约 (Tool Contract)

文档指出，工具定义声明了模型与工具之间的契约，包括名称、参数和自然语言描述。

• 对比： 这种思想类似于契约式设计 (Design by Contract) 和面向接口编程。

• 深度洞察： 在传统开发中，契约由编译器检查；在 Agent 开发中，“文档即契约”。工具的名称、描述和参数 Schema 共同构成了模型感知该能力的接口。文档建议使用清晰、具有描述性的名称（如 create_critical_bug_in_jira_with_priority），实际上是在定义一套强语义的接口规范。

4. 关注点分离 (SoC) 与 解耦架构 (Decoupling)

MCP 协议的核心目标是通过标准化通信层来解决“N x M”集成问题，将 AI 代理与其使用的工具的具体实现解耦。

• 对比： 这反映了关注点分离 (Separation of Powers) 和插件架构 (Plugin Architecture) 的思想，类似于语言服务器协议 (LSP) 对 IDE 的影响。

• 深度洞察： 这种解耦使得系统具备架构灵活性和未来证明性 (Future-Proofing)。组织可以在不重新构建整个集成层的情况下，自由更换底层的 LLM 提供商或后端服务。

5. 错误处理即流程控制 (Error Handling as Flow Control)

文档建议提供描述性的错误消息，并将其视为指导模型纠错的通道。

• 对比： 传统软件开发中，错误处理通常遵循“快速失败 (Fail-fast)”原则，返回代码或异常。

• 深度洞察： 在 Agent 开发中，错误消息不仅是终止符，更是模型推理的补丁。高效的错误消息应包含改进建议（例如：提示模型确认名称并按名称重新搜索），从而引导 Agent 自行修复运行时的错误。

6. 输入验证与模式约束 (Validation & Schema)

文档极力推荐使用 JSON Schema 进行输入输出验证。

• 对比： 对应软件开发中的强类型定义 (Strong Typing) 和输入清洗 (Input Sanitization)。

• 深度洞察： Schema 在这里承担双重职责：一是作为运行时检查确保安全性；二是作为补充文档，给 LLM 提供一个更清晰的“调用视图”，帮助其理解参数的确切结构。

? 总结对比表

这种对比揭示了一个关键转变：在 AI 代理时代，“清晰的文档”已经从一种辅助性的开发习惯转变为核心的系统逻辑组件，因为模型是通过阅读这些“文档”来决定如何执行程序的。

• 标准化需求：在 MCP 出现之前，将 LLM 与外部工具集成通常需要为每对“模型-应用”编写定制的连接器。

• 集成爆炸：随着模型 (N) 和工具 (M) 数量的增加，定制连接带来的开发工作呈指数级增长，即 “N x M”集成问题。

• 创新速度缓慢：开发者长时间将精力投入在无意义的集成工作上，而非构建处理业务。

• 生态系统碎片化：一个好的工具出现无法立即复用，形成了技术孤岛。

为此Anthropic 于 2024 年推出的 MCP 旨在建立一个通用的、“即插即用”的标准协议，将 AI 代理从工具的具体实现细节中解耦出来，实现模块化和可扩展的生态系统。

MCP 采用了受语言服务器协议 (LSP) 启发的客户端-服务器模型，包含三个核心角色：

• Hosts：发起并管理客户端的应用程序（如多智能体系统），负责用户体验、工具调度及执行安全策略。

• Clients：嵌入在主机内，负责维持与服务器的连接、发布指令并管理会话生命周期。

• Servers：对外发布能力的程序，作为外部工具、数据库或 API 的代理，负责工具发现、指令执行及数据格式化。在企业环境中，服务器还负责安全性、可扩展性和治理。

基于此人工智能代理开发人员应能够专注于其核心能力——推理和用户体验，而第三方开发人员可以为任何可想象的工具或API创建专门的MCP服务器。

MCP使用 JSON-RPC 2.0作为基本的消息格式，该协议具有轻量、文本化和语言无关的特性。

1. 基本消息

该协议定义了四种基本消息类型，用于控制交互流程。

• 请求（Requests）： 一方发送给另一方的远程过程调用（RPC），期望获得响应。

• 结果（Results）：包含相应请求成功结果的消息。

• 错误（Errors）：指示请求失败的消息，包含代码和描述。

• 通知（Notifications）：一种不需要响应且无法回复的单向消息。

2.传输机制

指的是MCP沟通客户端与服务器之间的通信方式，共有两种。

（1）本地通信：stdio (Standard Input/ Output，标准输入输出)

• 用于在MCP服务器作为Host应用程序的子进程运行的本地环境中进行快速直接的通信；

• 当工具需要访问用户文件系统等本地资源时使用。

（2）远程连接：Streamable HTTP(流式传输的HTTP)

• 推荐的远程客户端-服务器协议。它支持SSE流式响应，但也允许无状态服务器，并且可以在普通HTTP服务器中实现，无需SSE。

在计算机科学中，“原语”通常指由若干条指令组成的程序段，用来完成特定的功能，且在执行过程中不可分割。在 MCP 这种通信协议中，它更倾向于指代最基本的语义构建块。

如下图所示，实际上MCP为我们提供了多种的基本原语，但在实践中只有工具这一个得到了广泛的支持，其余的功能是否会发挥重要作用，仍有待观察。

MCP中的 Tool实体是服务器向客户端描述其可用功能的标准化方式。MCP服务器会发布其可用工具列表，包括描述和参数模式，供智能体发现。

工具定义必须符合 JSON schema，包含以下字段：

• name: 工具的唯一标识符

• title:  [可选]用于显示的人类可读名称（请注意，此标题不必与工具定义中提供的标题一致）

• description: 人类（和LLM）可读的功能描述

• inputSchema: 定义预期工具参数的JSON模式

• outputSchema:  [可选]定义输出结构的JSON模式 （对于确保工具的正确使用至关重要，它们的表述应清晰、准确，并且在两个模式中定义的每个属性都应有一个描述性名称和清晰的描述。）

• annotations:  [可选]描述工具行为的属性（一种接口声明）

• destructiveHint: 可能执行破坏性更新（默认值：true）。

• idempotentHint: 重复使用相同参数调用不会产生额外效果（默认值：false）。（幂等性）

• openWorldHint: 可与外部实体的“开放世界”交互（默认值：true）

• readOnlyHint: 不修改其环境（默认值：false）

标题和描述等属性在模式中可能是可选的，但应始终包含它们。它们为向客户端大型语言模型提供更详细的工具有效使用说明提供了重要渠道。

如下给出一个函数的文档示例：

MCP工具的调用返回结果有多种。结果可以是结构化的，也可以是非结构化的，并且可以包含多种不同的内容类型。结果可以链接到服务器上的其他资源，也可以作为单个响应或响应流返回。

• 非结构化：Text类型表示非结构化字符串数据；Audio和Image内容类型包含带有适当MIME类型标记的base64编码图像或音频数据。资源既可以作为指向存储在其他URI的资源实体的链接返回，包括标题、描述、大小和MIME类型；也可以完全嵌入工具结果中。无论哪种情况，客户端开发人员都应非常谨慎地以这种方式检索或使用从MCP服务器返回的资源，并且只应使用来自可信来源的资源。

• 结构化数据：结构化数据始终按照JSON格式返回。工具实现者应始终使用outputSchema功能来提供JSON模式，供客户端用于验证工具结果，客户端开发人员应根据提供的模式验证工具结果。已定义的输出模式有双重目的：它允许客户端有效地解释和解析输出，并向调用的LLM传达如何以及为何使用此特定工具。

MCP还定义了两种标准错误报告机制。

• JSON-RPC错误：服务器可以针对协议问题返回的。例如未知工具、无效参数或服务器错误。

• 结果对象错误：在结果对象中设置“isError”: true参数，在工具结果中返回错误消息。这些错误用于工具自身运行时产生的错误，例如后端API故障、无效数据或业务逻辑错误。

相比于正确结果，错误结果往往是一种被忽视的上下文。

MCP工具开发人员应考虑如何最好地利用此渠道来帮助其客户从错误中进行故障转移。

除核心原语工具外，MCP还定义了另外五个原语。虽然这些原语旨在增强智能体的能力，但目前其支持率远低于工具，且存在显著的风险点。

以下是这些原语的概要总结及其未被大面积使用的原因分析：

1. 服务器端原语 (Server-side Primitives)

• 资源 (Resources)

概要总结：提供给主机应用程序访问的上下文数据，如日志文件、数据库记录、配置数据或静态 blob（如 PDF、图像）。

风险与挑战：将任意外部内容引入 LLM 上下文会带来显著的安全风险；协议要求消费的资源必须经过验证并来自可信 URL。

• 提示词模板 (Prompts)

概要总结：服务器提供的可重用提示词示例或模板，用于指导客户端 LLM 如何更有效地利用该服务器提供的工具和资源。

风险与挑战：存在严重的安全隐患，允许第三方服务向应用程序的执行路径注入任意指令（指令注入风险）。来源建议在建立更强大的安全模型之前，应极少使用甚至不使用此原语。

2. 客户端端原语 (Client-side Primitives)

• 采样 (Sampling)

概要总结：允许服务器反向请求客户端执行 LLM 补全（即“工具反向调用 AI”），例如让模型总结服务器刚刚获取的长文档。

风险与挑战：为客户端应用程序开启了潜在的提示词注入（Prompt Injection）通道。此外，为了安全，通常需要引入“人机回环（Human-in-the-loop）”环节，这增加了交互的复杂性。

• 启发 (Elicitation)

概要总结：允许服务器通过客户端 UI 动态请求用户提供额外信息，以完成当前的工具调用请求。

风险与挑战：隐私提取风险巨大。恶意服务器可能利用此机制诱导用户提供敏感信息，而协议中“禁止请求敏感信息”的规定在系统层面上是无法强制执行的。

• 根目录 (Roots)

概要总结：定义服务器在文件系统中操作的边界范围，以限制其访问权限。

风险与挑战：缺乏强制性约束。MCP 规范仅规定服务器“应该（SHOULD）”遵守根目录边界，但没有任何技术手段确保服务器一定会遵守。

3. 未被大面积使用的通用原因总结

除了上述各原语特有的风险外，以下是导致它们（除工具外）支持率普遍较低的通用因素：

• 安全模型不成熟：MCP 诞生于去中心化、以开发者为中心的场景，在身份管理、细粒度授权和原生可观测性方面存在“企业就绪差距”。

• 上下文窗口膨胀 (Context Window Bloat)：加载过多的原语定义（元数据和 Schema）会占用大量 Token，增加成本和延迟，甚至导致模型推理质量下降或忽略关键意图。

• 状态管理复杂性：MCP 涉及持久的状态化连接，这与目前主流的无状态 REST API 架构集成时，会增加开发维护难度，并阻碍系统的水平扩展。

• 工具原语的全能性：由于“工具”原语功能强大且支持率极高（99%），开发者往往倾向于通过设计精巧的工具来模拟资源获取或启发交互，从而避免实现其他复杂的协议原语。

结论：目前的 MCP 生态处于“工具主导”阶段。其他原语虽然在理论上增强了灵活性，但由于安全性控制不足和实现成本过高，尚未在生产环境中得到广泛应用。

1. 主要优势

• 解决“N x M”集成难题：MCP 作为一个开放标准，通过统一的插拔式协议，取代了原本需要为每种模型和工具组合编写定制连接器的做法，极大降低了开发成本。

• 加速生态系统建设：标准化通信层促进了工具的复用，开发者可以从 MCP 注册表（Registry）发现预建连接器，从而缩短产品上市时间。

• 动态能力增强：支持运行时动态工具发现，使智能体无需硬编码即可感知可用工具，增强了系统的自主性和灵活性。

• 架构灵活性与前瞻性：通过解耦智能体与工具实现，MCP 支持“智能体 AI 网格（Agentic AI Mesh）”架构。这使得企业可以在不重构整个集成层的情况下，自由更换底层的 LLM 供应商或后端服务。

• 治理基础：协议架构为嵌入安全策略和访问控制提供了“钩子”，并倡导“人机回环（HIL）”的理念，要求在调用工具前获得用户授权。

2.主要弊端与挑战

• 上下文窗口膨胀：为了让大型语言模型（LLM）知晓可用的工具，来自每个连接的MCP服务器的所有工具的定义和参数模式都必须包含在模型的上下文窗口中。这些元数据会占用大量可用令牌，导致成本和延迟增加，并造成其他关键上下文信息的丢失。

• 推理质量下降：上下文窗口过载还会降低人工智能的推理质量。当提示词中包含许多工具定义时，模型可能难以确定给定任务最相关的工具，或者可能忘记用户的原始意图。这可能导致不稳定的行为，例如忽略有用的工具或调用不相关的工具，或者忽略请求上下文中包含的其他重要信息。

• 有状态协议的挑战：将有状态的持久连接用于远程服务器可能会导致架构更加复杂，更难开发和维护。将这些有状态连接与以无状态为主的REST API集成时，开发人员通常需要构建和管理复杂的状态管理层，这可能会阻碍水平扩展和负载均衡。

• 与企业级的差距：

身份验证和授权：最初的MCP规范并未包含一个强大的、企业级的身份验证和授权标准。虽然该规范正在不断发展，但目前的OAuth实施已被指出与一些现代企业安全实践存在冲突。

身份管理模糊性：该协议目前尚未有清晰、标准化的身份管理与传播方式。当发起请求时，无法明确该操作是由终端用户、AI代理本身还是通用系统账户发起的。这种模糊性使得审计、问责以及细粒度访问控制的实施变得复杂。

原生可观测性缺失：基础协议未定义可观测性原语（如日志、追踪和指标）的标准，而这些是调试、健康监控和威胁检测的基本功能。为解决此问题，企业软件提供商正在MCP之上构建功能，例如Apigee API管理平台，该平台为MCP流量增加了一层可观测性和治理。

1.安全性来源

MCP的安全性问题，通过两个因素考虑新的API接口和标准协议

• 作为一种新的API接口，基础MCP协议本身并未固有地包含许多在传统API端点和其他系统中实现的安全功能及控制措施。如果MCP服务未实现强大的身份验证/授权、速率限制和可观测性功能，那么通过MCP暴露现有API或后端系统可能会导致新的漏洞。

• 作为一种标准的智能体协议，MCP正被广泛应用于各类场景，包括许多涉及敏感个人或企业信息的应用，以及智能体与后端系统交互以执行某些现实世界操作的应用。这种广泛的适用性增加了安全问题发生的可能性和潜在严重性，其中最突出的是未授权操作和数据泄露。

2.核心安全风险

• 动态能力注入 (Dynamic Capability Injection)：MCP 服务器可在不通知客户端的情况下动态更改工具集。例如，一个原本只负责查询的智能体可能突然获得“购买”能力，从而导致未经授权的财务交易。

• 工具遮蔽 (Tool Shadowing)：恶意工具可以通过语义相似的描述来覆盖合法工具的触发条件。例如，攻击者定义的 save_secure_note 工具可能拦截原本应由系统合法工具处理的敏感信息。

• 混淆代理问题 (Confused Deputy)：这是一个经典的风险，即拥有高权限的 MCP 服务器（副官）被低权限的 AI 模型（受攻击者提示词诱导）误导，从而利用服务器的权限执行越权操作，如在受限代码库中创建泄密分支。

• 敏感信息泄露：由于交互内容常被存储并传输给工具，且 Elicitation（启发）原语可能被恶意利用诱导用户输入私密数据，导致数据外泄。

• 访问范围控制不足：目前的 MCP 授权仅支持粗粒度的客户端-服务器认证，缺乏针对“单个工具”或“单个资源”的细粒度控制

3.企业的缓解措施

• 多层防御架构：企业不应采用“纯”协议，而应通过 API 网关（如 Apigee） 实施治理，进行工具过滤、速率限制和集中审计。

• 显式白名单与版本锁定：在 SDK 层强制执行经过验证的服务器和工具白名单，并对安装的服务器定义进行版本（Hash）锁定，防止未经授权的动态更新。

• 输入输出清洗：使用如 Model Armor 类的产品对输入提示词进行脱敏，并对工具返回的结果进行过滤（如拦截 API 密钥、社保号或恶意代码）。

• 最小特权原则：确保工具凭证受到严格限制（如只读权限），并将密钥等敏感数据保留在 agent 上下文之外，通过侧链传输。

• 强化身份验证：实施双向 TLS (mTLS) 验证连接双方身份，并要求在执行高风险操作（如删除文件或外网连接）时必须有“人机回环”确认。

• 动态注入和工具遮蔽的攻击方式

• 糊涂代理和数据泄露的攻击方式