AI之Course之MCP/Agent：智能体工具与模型上下文协议（MCP）互操作性 —— 深入解析工具生态，理解AI智能体如何借助外部功能与API实现“行动”，并探索通过MCP轻松发现与使用工具的方

AI之Course之MCP/Agent：智能体工具与模型上下文协议（MCP）互操作性 —— 深入解析工具生态，理解AI智能体如何借助外部功能与API实现“行动”，并探索通过MCP轻松发现与使用工具的方法—— 从集成爆炸到治理可控：在 Model Context Protocol（MCP）之上构建安全、可审计且可演化的 Agent 平台

导读：本文中讨论了把大型模型（LLM）变成可感知/可执行/可治理的 Agent，需要把“模型”与“工具”标准化互操作（MCP），从而解决 N×M 集成、工具发现与复用问题；但协议的开放性同时带来新的安全、身份与观测挑战，企业应在 MCP 之上构建 Gateway/Registry/Control-Plane 做治理与防护。

>> 价值命题：工具把“预测式 AI”转为“代理式 AI”；MCP 能显著降低集成成本并促进可复用工具生态。

>> 架构三角：Model（推理）、Tools（执行/检索）、Orchestration（控制/会话/治理）。

>> 工具工程实践：任务化（Publish tasks）、小粒度、结构化 I/O、示例输出、强校验与错误建议。

>> 协议作用：MCP 提供 Host/Client/Server 与 JSON-RPC 交互规范，支持运行时发现与动态能力加载。

>> 主要风险：动态能力注入（Dynamic Capability Injection）、Tool Shadowing、恶意工具定义/返回、敏感信息泄露、权限/审计/观测不足。

>> 落地路径：企业不应“裸用 MCP”；推荐在其上加 Gateway/Registry/Pinning/Scoped Credentials + taint-tracking + HIL（人为确认）等防护层。
对工程/产品的可执行落地清单（优先级排序）

• 先试点、后普及：内部 Registry 上先包装 3-5 个关键工具，跑 discovery → call → audit 流程。
• 建 Gateway（必须）：实现 allowlist、schema pinning、变更通知、流量/速率控制与审计日志。
• Credential 策略：采用短期、scope-bound token（per-call）与 audience 校验；Secrets 不进上下文。
• Context 管理：tool-retrieval → subset-load，不把全部 tool defs 注入 prompt；对大返回采用 artifact/ref 模式。
• 安全防护：名称相似检测、mTLS、taint-tracking、输入/输出净化、HIL 强制（高风险 sink）。
• 测试与监控：建立回归集、LM Judge、trace（prompt、tool calls、results、errors）与报警（工具失败率、异常调用等）。
• 组织治理：明确谁能注册工具、谁审核、谁有审批权（agent registry 的审核流程与 SLA）。

目录

智能体工具与模型上下文协议（MCP）互操作性 —— 深入解析工具生态，理解AI智能体如何借助外部功能与API实现“行动”，并探索通过MCP轻松发现与使用工具的方法—— 从集成爆炸到治理可控：在 Model Context Protocol（MCP）之上构建安全、可审计且可演化的 Agent 平台

1、Introduction: Models, Tools and Agents

核心要点

经验 / 实战技巧

2、Tools and tool calling

2.1、What do we mean by a tool?

核心要点

经验/技巧

2.2、Types of tools

核心要点（按类）

经验 / 技巧

2.2.1、Built-in tools

核心要点

经验/技巧

2.2.2、Agent Tools

核心要点

经验/技巧

2.3、Best Practices（工具设计最佳实践）

2.3.1、Documentation is important

核心要点

经验/技巧

2.3.2、Describe actions, not implementations

核心要点

经验/技巧

2.3.3、Publish tasks, not API calls

核心要点

经验/技巧

2.3.4、Make tools as granular as possible

核心要点

经验/技巧

2.3.5、Design for concise output

核心要点

经验/技巧

2.3.6、Use validation effectively

核心要点

经验/技巧

3、Understanding the Model Context Protocol

3.1、The "N x M" Integration Problem and the need for Standardization

核心要点

经验/技巧

3.2、Core Architectural Components: Hosts, Clients, and Servers

核心要点

经验/技巧

3.3、The Communication Layer: JSON-RPC, Transports, and Message Types

核心要点

经验/技巧

3.4、Key Primitives: Tools and others

3.4.1、Tool Definition

核心要点

经验/技巧

3.4.2、Tool Results

核心要点

经验/技巧

3.4.3、Structured Content

核心要点

经验/技巧

3.4.4、Error Handling

核心要點

经验/技巧

3.5、Other Capabilities

3.5.1、Resources

要点/风险

经验/技巧

3.5.2、Prompts

要点/风险

经验/技巧

3.5.3、Sampling

要点/风险

经验/技巧

3.5.4、Elicitation

要点/风险

经验/技巧

3.5.5、Roots

要点/风险

经验/技巧

4、Model Context Protocol: For and Against

总体核心要点

4.1、Capabilities and Strategic Advantages

4.1.1、Accelerating Development and Fostering a Reusable Ecosystem

核心要点

经验/技巧

4.1.2、Architectural Flexibility and Future-Proofing

核心要点

经验/技巧

4.1.3、Foundations for Governance and Control

核心要点

经验/技巧

4.2、Critical Risks and Challenges

4.2.1、Enterprise Readiness Gaps

核心要点

经验/技巧

5、Security in MCP

5.1、New threat landscape

核心要点

经验/技巧

5.2、Risks and Mitigations

5.2.1、Tool Shadowing

缓解措施（核心）

经验/技巧

5.2.2、Malicious Tool Definitions and Consumed Contents

缓解措施（核心）

经验/技巧

5.2.3、Sensitive information Leaks

缓解措施（核心）

经验/技巧

5.2.4、No support for limiting the scope of access

风险说明

缓解措施（核心）

经验/技巧

6、Conclusion

智能体工具与模型上下文协议（MCP）互操作性 —— 深入解析工具生态，理解AI智能体如何借助外部功能与API实现“行动”，并探索通过MCP轻松发现与使用工具的方法—— 从集成爆炸到治理可控：在 Model Context Protocol（MCP）之上构建安全、可审计且可演化的 Agent 平台

1、Introduction: Models, Tools and Agents

基金模型（foundation model）本质上是模式预测引擎，不能主动访问实时世界或直接执行外部动作；工具（tools）为模型提供“眼睛与双手”，使 agent 能检索实时数据或执行操作，从而把模型从“生成”变成“行动”的主体。
概述：模型本身是无状态预测器，工具赋予它“看/做”的能力，从而构成 agent。
核心要点：模型有限性；工具分“know/do”；Agent = Model + Tools + Orchestration。
谁读：产品经理、架构师、技术领导。
立刻行动：列出业务场景中的“必须由工具实现”的能力清单（下单、写 DB、发邮件、检索事实等）。

核心要点

>>模型的局限：模型只能基于请求上下文输出，无法直接访问实时数据或修改外部系统。

>>工具的双重角色：一类是“让模型知道（know）”的检索型工具；另一类是“让模型做（do）”的执行/行动型工具（API 调用、外部执行等）。

>>Agent 的定义：Agent = 模型（推理）+ 工具（感知/执行）+ 编排（orchestration），工具在 agent 中决定了是否能达成现实世界的目标。

经验 / 实战技巧

>>先从业务目标出发：不要先选模型再倒推工具；先明确要解决的业务动作（比如“下单”“检索合同”），再定义工具接口。

>>把复杂/高风险操作交给工具实现的确定性代码（权限校验、事务控制、回退机制），把“模糊决策/规划”留给 LLM。

2、Tools and tool calling

工具在 LLM-应用中等同于函数契约：名称、参数、自然语言说明是最小要素；工具分多类（Function Tools、Built-in Tools、Agent Tools），并需要良好设计与文档以便模型在运行时选择与正确调用。
概述：把工具当作带 schema 的契约（name/description/inputSchema/outputSchema），并设计为“任务化、小粒度、可验证”。
核心要点：Function / Built-in / Agent Tools 三类；文档、示例、校验至关重要。
谁读：后端工程、API 设计者、LLM 工程师。
立刻行动：为一两个高频后端能力写出 task-level tool 定义（含示例返回与错误建议）。

2.1、What do we mean by a tool?

工具 = LLM 无法直接做但能调用的外部函数/程序；按功能粗分为“检索型（让模型获得外部事实）”与“执行型（对系统/世界进行操作）”。
把“工具”定义为模型不能直接完成、必须外部执行的功能（检索/执行）。
立刻行动：把业务能力映射为“tool required / tool optional”

核心要点

工具定义本身是「模型与外部系统之间的契约」，该契约应当在请求上下文中被传给模型，以指导模型何时以及如何调用。

经验/技巧

在需求阶段就把“哪些能力必须通过工具实现”列清单（例如：实时价格、数据库写操作、文件上传等），把这些能力优先以 tool 接口形式封装。

Figure 1: Weather agent tool-calling example

2.2、Types of tools

文档将工具分为 Function Tools（开发者定义的函数）、Built-in Tools（模型服务端隐式提供）、Agent Tools（把子 agent 封装为工具） 三类，并给出分类下的常见用途与设计考量。
Built-in：平台端提供（便捷但不可见实现）；Agent Tools：子 agent 作为工具。
立刻行动：对平台的 built-in 能力做能力/风险矩阵。。

核心要点（按类）

Function Tools：开发者显式定义的函数（用 function-calling、schema 描述输入输出），由 Host/Client 在请求中注入给模型。

Built-in Tools：由模型平台（如 Gemini）在服务端提供，工具定义对开发者“不可见”但对模型可用（如搜索、代码执行、URL 上下文提取等）。优点是便捷，缺点是开发者对实现细节可控性低。

Agent Tools：把一个专责子 agent 当做工具供主 agent 调用（例如用 AgentTool 或 A2A 协议），常用于多 agent 协作与能力分担。

经验 / 技巧

Function Tools：务必把 inputSchema/outputSchema写清楚，并给出示例返回（example return），帮助模型正确解析。

Built-in Tools：使用时注意审视平台文档（它们可能会返回 metadata、自动抓取的上下文等），并设计对这些返回的后续处理流程。

Agent Tools：在使用子 agent 时保持主 agent 的“控制权”，把子 agent 的输出作为材料而不是自动信任的断言；并对子 agent 做能力/权限约束。

2.2.1、Built-in tools

示例：Google Gemini 的内置工具包括 Google Search Grounding、Code Execution、URL Context、Computer Use 等；这些工具由模型服务端提供，开发者调用时只需指明使用该工具。

核心要点

优点：立即可用、能增强模型的实时性与执行能力。

风险：实现细节对开发者不可见；在安全/审计上需额外设计。

经验/技巧

在设计调用这些工具的 agent 时，把返回的 metadata / url_context 等当作“证据”和“信任级别”一起记录并审计。

2.2.2、Agent Tools

把一个“专责 agent”封装为工具（例如 ADK 的 AgentTool 或 A2A 协议），便于主 agent 调用并在主流程中检视/过滤子 agent 的输出。

核心要点

通过 Agent-as-Tool 可以实现“分工 + 可审计”的多 agent 协作模式，便于能力复用与治理。

经验/技巧

权限隔离：为子 agent 设定权限边界（read-only vs read-write）；

调用后验证：主 agent 在接受子 agent 输出前要做 schema/信任验证与高风险动作的 HIL。

2.3、Best Practices（工具设计最佳实践）

文档列出若干成熟且可立即落地的设计规则：清晰文档、描述动作而非实现、发布任务级工具、工具粒度小、输出精简、使用校验/验证 等。以下分项逐条展开。
工具应是“任务”（not raw API），小粒度、返回简洁并有 schema 校验与示例。
立刻行动：为关键工具引入 outputSchema，并在客户端强制校验。

2.3.1、Documentation is important

工具的 name/title/description、参数说明、示例返回都会被注入模型上下文；清楚的文档直接提升模型选择工具与生成正确参数的概率。

核心要点

工具名应可读且具描述性（便于模型/审计）；参数描述要说明类型、用途与默认值；给出示例返回。

经验/技巧

示例优先：对复杂 outputSchema 给出“Example return”，对模型有明显效果。

参数精简：避免长参数列表；对复杂 API 做“任务抽象”而非裸露 API 字段。

2.3.2、Describe actions, not implementations

在系统指令或高层说明中，应描述“目标/动作”（what），不要在指令中写如何调用具体工具（how），以避免与工具定义冲突并提升可移植性（尤其在 MCP 动态工具场景）。

核心要点

描述目标（如“创建一条 bug 报告”），让模型决定最合适的工具/顺序；不要重复工具的实现细节或 API 文档。

经验/技巧

在 system prompt 中写清业务意图 + 约束（例如 “优先使用公司内部 issue tracker；如无则询问用户”），而非硬编码工具名。

2.3.3、Publish tasks, not API calls

工具应代表“用户可理解的任务”（task），而非简单封装后端 API（API 参数复杂、对 agent 动态决策不友好）。

核心要点

任务化工具更适合 agent 在运行时做参数选择；过多的底层 API 参数会使 agent 难以正确调用。

经验/技巧

把常见复杂工作流封装为“高阶任务工具”（但要写明副作用、所需权限、失败回退）。

2.3.4、Make tools as granular as possible

工具职责单一、粒度细小，便于文档、测试与模型一致地判断何时调用。

核心要点

单一职责降低模型误用风险；仅在常见多步序列频繁出现时才考虑将多个步骤合并为一个“高阶工具”。

经验/技巧

对每个工具写清楚：用途、调用条件、返回数据结构与副作用（是否修改状态、是否会产生外部可观察变化）。

2.3.5、Design for concise output

工具应避免返回过大的数据块（大表、原始文件、图片 base64 等），以免占用 context tokens、降低性能并影响后续推理。

核心要点

若结果巨大，应把数据存到临时存储并返回引用 ID；或提供分页/摘要返回。

经验/技巧

使用 Artifact/临时表/云存储返回小引用（如 artifact_id），在需要时再让 agent 调用工具取回详细数据。

2.3.6、Use validation effectively

在工具定义中使用 inputSchema/outputSchema 做运行时校验，以同时充当文档与防错层。

核心要点

schema 既指导模型生成参数，也提供客户端对工具调用结果的结构化检验，从而防止格式/类型错误及潜在注入风险。

经验/技巧

强制校验链：客户端在把 tool result 写回会话/上下文前应校验 outputSchema；对不合规范的结果触发补救（重试、询问用户或切换备用工具）。

3、Understanding the Model Context Protocol

MCP 是为了解决模型与大量外部工具之间“N×M”集成爆炸问题而提出的开放标准（类似 LSP），通过 Host/Client/Server 的架构与 JSON-RPC/传输规范，提供工具发现、工具声明（schema）、结果格式与若干扩展能力（Resources、Prompts、Sampling、Elicitation、Roots）。下文按小节详细拆解。
概述：MCP 是为了解决 N×M 集成而设计的协议（Host/Client/Server + JSON-RPC），它支持动态工具发现与运行时注入。
核心要点：N×M 问题；JSON-RPC/Streamable HTTP；Tool 定义/结果/结构化内容/错误处理为核心原语。
谁读：架构师、平台工程、安全工程师。
立刻行动：搭建内部 Registry PoC 并定义 tool pinning/whitelist 流程；实验 tool-retrieval → subset-load 模式减少上下文膨胀。

3.1、The "N x M" Integration Problem and the need for Standardization

每个模型要对接每个工具会产生大量one-off 连接（N×M），难以维护；MCP 的目标是用统一协议把工具注册、发现与调用标准化，降低集成成本并促进工具生态。

核心要点

MCP 可使 agent 在运行时发现并加载工具定义（而非硬编码），从而动态增强能力并支持可替换后端。

经验/技巧

即便采用 MCP，也建议在企业侧建设 Registry + Gateway（allowlist/pinning），以避免随时暴露的不受控能力注入风险（见安全章节）。

3.2、Core Architectural Components: Hosts, Clients, and Servers

MCP 模型采用类似 LSP 的三层：Host（应用/Orchestrator）、Client（嵌入 Host 的组件，维护与 Server 的通道）、Server（提供工具和资源并发布工具声明）。

核心要点

Host 负责用户体验、策略与 guardrails；Client管理会话与工具生命周期；Server 广告工具并执行请求。企业部署中 Server 还承担治理/可扩展性职责。

经验/技巧

在企业环境中，不要直接信任外部 MCP Server：在 Gateway/Client 层做 allowlist、版本 pinning 与变更通知。

Figure 2: MCP Host, Client and Server in an Agentic Application

3.3、The Communication Layer: JSON-RPC, Transports, and Message Types

MCP 采用 JSON-RPC 2.0 为基本消息格式；定义四类消息（Requests/Results/Errors/Notifications）；支持两种传输：本地 stdio（subprocess）和远程 Streamable HTTP（推荐）。

核心要点

JSON-RPC 提供语言无关的轻量化交互；Streamable HTTP 支持 SSE 风格流返回并兼顾无状态服务器实现。

经验/技巧

对于需要文件系统访问或较低延迟的本地工具，优先 stdio（注意权限边界）；对远程工具使用 Streamable HTTP 并在 Gateway 做流量与安全策略。

3.4、Key Primitives: Tools and others

MCP 的核心原语是 Tool（广泛被支持），另有 Resources/Prompts（服务器端）和 Sampling/Elicitation/Roots（客户端），但这些扩展能力当前支持度较低。本文重点聚焦 Tools 并解释其 schema、结果类型、结构化内容与错误处理。

3.4.1、Tool Definition

MCP 中 Tool 必须遵守 JSON schema，关键字段包括 name、title（可选但建议）、description、inputSchema（必须）、outputSchema（建议）、annotations（可选的行为提示）。

核心要点

inputSchema/outputSchema 应被视为必需：它们既是文档又是运行时校验依据。

annotations（如 destructiveHint、idempotentHint、readOnlyHint）仅为提示，不可盲目信任来自非受信 server 的注释。

经验/技巧

在企业端对接 MCP server 时，对每个 tool 做schema 校验 & pinning（版本或哈希），并拒绝没有 outputSchema 的工具或将其仅限低信任模式。

3.4.2、Tool Results

MCP 工具返回可以是结构化 JSON或非结构化（text/audio/image/base64），也可以返回对外资源的引用或采用流式（stream）返回；客户端需谨慎处理资源引用与嵌入内容。

核心要点

建议工具提供 outputSchema 以便客户端验证；资源类结果（Resource）应仅从受信任 URL 拉取。

经验/技巧

客户端在把工具返回插入会话上下文前先做输出净化（敏感信息检测）与 schema 验证；对大结果采用“引用 + 后续 pull”模式。

3.4.3、Structured Content

结构化内容指返回 JSON 且遵循 outputSchema，便于自动解析、验证与下游消费；这是对 LLM-Client 交互最友好的返回形式。

核心要点

OutputSchema 不仅帮助解析，也教育 LLM 如何使用结果（因为 schema 也进入模型上下文）。

经验/技巧

在工具定义中把“关键字段”标为必需（required）并提供示例，有助于减少模型误解析或 downstream 错误。

3.4.4、Error Handling

MCP 支持两层错误：协议层 JSON-RPC error（如 unknown tool、bad args）和工具执行层 isError: true 的业务错误（如 API rate limit）。错误消息是指导模型故障恢复的重要渠道。

核心要點

设计错误时应给出可操作性建议（例如“等待 15 秒后重试”或“询问用户确认参数”），便于模型自动选择下一步动作。

经验/技巧

把“常见失败模式”列入错误返回的建议动作中，并在客户端实现基于错误码的 fallback 策略（重试/降级/询问用户）。

3.5、Other Capabilities

MCP 还定义若干服务器/客户端能力：Resources、Prompts（服务器端）；Sampling、Elicitation、Roots（客户端）。当前这些扩展支持度普遍较低，且在企业场景存在显著安全/治理疑虑。

3.5.1、Resources

Resources 是服务器端可供客户端使用的静态数据（文件、记录、图像等），可嵌入或以 URI 引用返回。

要点/风险

引入任意外部 content 到 LLM 上下文带来注入与泄露风险，客户端应只从 allowlist/受信 URL 拉取并做净化。

经验/技巧

对资源拉取实现显式用户确认/白名单策略，并在 Gateway 做内容扫描。

3.5.2、Prompts

Server 可向客户端提供 prompts 模板或示例，客户端可用它们直接调用 LLM（相当于 server 注入使用说明）。

要点/风险

Prompts 会引入“第三方注入执行流”风险（prompt injection），在分布式企业场景风险尤大。文件建议“谨慎/尽量少用”直到安全模型成熟。

经验/技巧

默认禁用外部 prompts；如必须使用，先在 Gateway 通过内容审查/模板白名单过滤。

3.5.3、Sampling

Sampling 允许 server 请求客户端发起 LLM 完成（把 LLM 调用“反向”到 client），适合 server 需要 client-side LLM 做子任务的场景。MCP 建议对 Sampling 插入 HITL。

要点/风险

优点：client控制 LLM provider、成本、guardrails；风险：prompt injection 通道 & 用户可能被要求批准不安全请求。

经验/技巧

对 Sampling 请求做严格 prompt 过滤并保证清晰的用户审批 UI（显示意图、来源、是否含敏感请求）。

3.5.4、Elicitation

Elicitation 允许 server 暂停并请求客户端向用户收集额外信息（动态 UI 交互）。规范要求 server 不应请求敏感信息，但无法系统性强制。

要点/风险

风险在于恶意 server 借此向用户诱导泄露敏感数据；客户端必须实现 UI 层面的保护与显式同意。

经验/技巧

对所有 elicitation 请求在 UI 中以明确、逐项的方式展示“要收集什么、为什么、将如何使用”，并允许拒绝/审计。

3.5.5、Roots

Roots 用于界定服务器在文件系统或 URI 空间的操作边界（当前仅支持 file: URI 的 root），但规范对 server 遵守 roots 的行为只有“建议（SHOULD）”，因此客户端不应过度依赖。

要点/风险

由于缺乏强制性保障，Servers 可能越界访问；客户端应在本地代理/Gateway 做进一步限制。

经验/技巧

把 Root 交给受控容器环境或在 Gateway 做文件系统代理，避免直接把本地路径暴露给远端 Server。

4、Model Context Protocol: For and Against

本章先肯定 MCP 在减少集成成本、推动工具生态与模块化架构方面的价值，再审视其在企业生产化过程中暴露的性能、安全与治理短板——特别是当 MCP 从“本地开发/实验”推进到“远程/企业级服务”时所带来的新挑战。
概述：评估 MCP 的利与弊：加速开发/弹性/治理基础 VS 企业就绪差距与安全风险。
核心要点：生态与替换性的战略价值；需要 Gateway/Control Plane 才能企业化。
谁读：技术决策层、信息安全/合规团队。
立刻行动：制定 MCP 接入的“信任分级”策略（trusted/untrusted）与变更通知机制。

总体核心要点

MCP 带来动态发现、标准化工具描述和生态化复用三大战略优势。

同时引入了上下文窗口膨胀（context bloat）、状态管理复杂性和企业级就绪（身份/审计/可观测）缺口等问题。

企业通常不会直接采用“裸 MCP”；更实际的路径是把 MCP 嵌入到带有 Gateway / Registry / Control Plane 的治理层。

4.1、Capabilities and Strategic Advantages

本节系统说明 MCP 在技术与战略层面的正面影响：它能降低 N×M 集成复杂度、支持运行时能力扩展并为企业构建可替换/可演进的 agent 架构提供基础。

4.1.1、Accelerating Development and Fostering a Reusable Ecosystem

核心要点

>>减少重复开发：MCP 以统一协议替代一对一连接，降低每增加新模型或工具时的集成成本（解决 N×M 问题）。

>>工具即资产：通过 Registry / marketplace，工具（MCP server）可以被发现、复用与共享，形成网络效应。

经验/技巧

>>试点阶段优先把最常用/高价值的几个内部服务包装为 MCP server 并在内部 Registry 上线，以快速验证“发现→调用”闭环的稳定性与安全模型。

>>在 Registry 中对每个工具做 metadata 标注（风险等级、side-effects、需要的权限），便于后续做 allowlist/自动化审计。

4.1.2、Architectural Flexibility and Future-Proofing

核心要点

>>解耦能力实现替换性：MCP 把 agent 与后端能力解耦，便于替换 LLM 供应商或 backend，实现长期演进而无需大规模重构。

>>支持模块化/agentic-mesh 架构：逻辑、记忆、工具可作为独立组件组合，降低维护复杂度并助力分层治理。

经验/技巧

>> 采用“接口优先（contract-first）”策略：先用 MCP schema 明确工具契约（input/output/annotations），再实现后端；这样切换实现只需确保契约兼容。

>> 在早期设计中明确哪些能力需要“高信任 / 高审计”通路（例如支付）并单独走受控 MCP server 或 Gateway。

4.1.3、Foundations for Governance and Control

核心要点

>>集中治理点：虽然 MCP 本身轻量，但其架构提供将策略/访问控制内嵌到 MCP server 的可能性，从而形成单点策略执行（policy enforcement）。

>>促进 HITL（Human-in-the-loop）：规范推荐在执行敏感工具前需用户同意，这为实现可控自动化提供制度基础。

经验/技巧

>>把“是否需要用户确认（HIL）”作为工具 metadata/annotations 的必检项，并在 Gateway 层强制执行（高风险操作一律 HIL）。

>>对外部 MCP server 做分级信任（trusted / untrusted）：trusted server 可被允许更多 capability，但必须先经过审计与 pinning。

4.2、Critical Risks and Challenges

本节罗列 MCP 在转企业级部署时的主要风险点：不仅是技术（性能、状态管理），更有安全（动态能力注入、shadowing）、治理（身份/审计）等多维挑战。

4.2.1、Enterprise Readiness Gaps

核心要点

>>认证/授权不足：早期 MCP 规范对企业级 authN/authZ 的覆盖不够（OAuth 实现与部分企业实践冲突），缺乏 per-tool/per-resource 级别的细粒度控制。

>>身份传播模糊：协议尚未定义清晰的“谁在发起操作”（终端用户 / agent / system），影响审计与问责。

>>缺少原生观测能力：协议没定义 logging/tracing/metrics 原语；企业需在上层构建可观测平台（如用 API Gateway/Apigee）。

>>上下文窗口膨胀（Context Window Bloat）：把所有工具定义预加载到 prompt 会耗尽 token，影响模型推理与成本。

经验/技巧

>>不要“裸用”MCP：在企业内部放置 Gateway + Registry + Pinning，Gateway 做 allowlist、变更通知、审计与速率控制。

>>对 tool definitions 采用“tool-retrieval → subset-load”策略：首先检索相关工具索引（RAG 风格），只把最相关的少量定义注入上下文，缓解 token 膨胀与混淆。

>>设计身份链路：把用户身份/权限以短期、受约束的 scoped token 形式传给 MCP server（并在 server 端校验 audience/scope）。

5、Security in MCP

本章系统描述 MCP 引入的新威胁面（既有来自其作为新 API 表面的风险，也有来自其作为去中心化协议带来的供应链与注入风险），并针对主要风险提出一系列工程化缓解措施（包括 allowlist、pinning、taint-tracking、HIL、网关过滤等）。
概述：列出 MCP 引入的新威胁（shadowing、malicious definitions、sensitive leaks、no scope control）并提供缓解（allowlist、pinning、taint-tracking、scoped credentials、HIL）。
核心要点：协议开放带来供应链与注入风险；必须设计 perimeter（Gateway）与 runtime policy。
谁读：安全团队、平台团队。
立刻行动：在 Gateway 实现 tool name collision 检测、output sanitization 与 high-risk HIL 策略。

5.1、New threat landscape

核心要点

>>两类来源：一是 MCP 作为新的 API 表面（缺乏内置 auth/quotas/observability）；二是作为标准协议（易被滥用、出现供应链与注入攻击）。

>>高风险后果：未经授权操作、敏感数据泄露、confused-deputy（代理被利用完成越权操作）等。文档用“代码库泄露”示例详细说明了 confused deputy 攻击路径。

经验/技巧

把安全策略写入设计规范：在每个 MCP 对接项目启动前列出授权范围、审计要求、和 HIL 触发条件，并把这些要求做成自动检测/测试项。

5.2、Risks and Mitigations

原文把若干高风险类别逐一列出（Dynamic Capability Injection、Tool Shadowing、Malicious Tool Definitions、Sensitive Info Leaks、No scope limiting），并给出可执行缓解措施。下面分别按子项展开。

5.2.1、Tool Shadowing

风险说明

定义：恶意/未受信工具通过语义或触发条件覆盖（shadow）合法工具，使 planner 误选并造成数据泄露或误动作。示例：恶意 save 工具覆盖企业 secure_storage_service。

缓解措施（核心）

>>名称冲突检测（semantic）：在 Client/Gateway 过滤新工具时，做语义相似度检测，阻止潜在“影子”工具注册。

>>mTLS 与身份验证：对高敏感 MCP 连接使用 mutual TLS 和强身份验证以确保 server 身份。

>>策略执行点：在发现/调用/返回等关键拦截点强制策略检查（plugin/callback）。

>>HIL 强制：对所有高风险 sink（删除、写 DB、外部传输）要求人工确认，无论是哪个工具发起。

经验/技巧

把工具“信任等级”做成显式字段（trusted / semi-trusted / untrusted），在 planner 层与 Gateway 做分流策略（例如 untrusted 只能提供 readonly/preview 功能）。

5.2.2、Malicious Tool Definitions and Consumed Contents

风险说明

恶意工具描述或工具返回内容可通过 prompt injection、恶意 schema 或恶意资源让模型执行非预期动作或泄露敏感信息。工具本身或其返回的资源都可能成为攻击载体。

缓解措施（核心）

>>输入/输出净化：对 tool inputs 做严格校验，对 tool outputs 进行敏感数据/注入检测（例如去掉 active HTML、脚本、Token 样式字符串）。

>>分离 system prompts：避免 server 提供的 prompts 直接注入模型 system 指令；Prompts 应受白名单与审计。

>>trusted vs untrusted planners：引入双 planner 架构：trusted planner 访问受信工具，untrusted planner 访问第三方工具，二者通信受限且经过审计。

经验/技巧

在 Gateway 实施“工具描述清洗”流程：把 server 提供的 tool definitions 先通过过滤器/LLM-safe-checker（或正则 + ML）清洗，再注入 client。并对 outputSchema 缺失的工具限制其能力。

5.2.3、Sensitive information Leaks

风险说明

工具可能无意或恶意返回含敏感数据（PII、凭证、内部文件路径等）；Elicitation 功能甚至能诱导用户提供敏感信息。

缓解措施（核心）

>>标注与 taint-tracking：把输入/输出标记为 tainted/untrusted，传播时触发策略（阻断或 HIL）。

>>输出字段注释：使用工具 annotations 或自定义字段来标注可能携带敏感信息的字段并在客户端严格处理。

>>UI 层的用户同意：任何 Elicitation 请求必须通过清晰 UI 展示“为何收集、如何使用”，并取得用户明确同意。

经验/技巧

对工具返回做自动敏感数据检测（电话号码、信用卡、SSN、JWT-like tokens），一旦检测到“敏感片段”自动 redact 并记录审计事件。

5.2.4、No support for limiting the scope of access

风险说明

MCP 原生仅支持粗粒度授权（一次性 client↔server 授权），缺乏本地对每个工具/资源的细粒度 scope 授权与可替代的 credential 传递机制，容易导致 confused-deputy 类越权。

缓解措施（核心）

>>Scoped / Audience-bound Credentials：在客户端对每次调用生成短期、范围受限（scoped）凭证并要求 server 在每次执行时校验 audience 与 scope。

>>最小权限原则：每个工具只被授予必要最少权限（read-only vs read-write），并对权限作频繁审计。

>>Secrets 不进入上下文：把密钥、token 保留在 MCP client 本地，通过安全 side-channel 传递，不要把 secrets 写入 agent 会话或工具定义。

经验/技巧

在 Gateway 层实现“per-tool policy mapping”：把企业角色和工具权限映射为策略，并在调用时做 policy-as-code 验证；对高风险调用启用多重签名或 HIL。

6、Conclusion

概述：MCP 是强工具，但“无治理即风险”；企业应在 MCP 之上构建统一控制面并把安全/审计当作第一阶工程任务。
谁读：高层决策者、实施负责人。
立刻行动：把 MCP 相关的合规/安全要求写入项目启动清单（SoW / SRS）。

>>价值：MCP 通过标准化工具发现/描述/调用，能显著降低集成成本、催生工具生态并为模块化 agent 架构提供基础（动态能力扩展、替换性强）。

>>代价：原生 MCP 在企业级部署面临实质性挑战——安全（动态注入、shadowing、confused deputy）、性能（上下文膨胀、stateful 调度）与可观测/身份治理缺口。企业通常会把 MCP 嵌入到受控 Gateway/Registry/Control Plane 之下以补齐这些短板。