MCP与工具协议高频术语速查：从协议到连接的15个关键词

大模型与外部工具交互时，MCP、工具协议、函数调用等术语经常出现。下面用名词小词典的形式，逐一解析15个高频关键词，帮你快速建立清晰的技术认知。

1. MCP（Model Context Protocol）—— Agent与工具的通信协议

MCP，全称Model Context Protocol，是一种用于大模型与外部工具之间交换上下文信息的标准化协议。你可以把它想象成Agent世界的HTTP协议——HTTP让浏览器和服务器通信，MCP则让模型和工具（如数据库、API、文件系统）互相理解。MCP定义了消息格式、请求-响应流程、错误处理等规则，使不同的工具只要遵循MCP就能被模型调用。

核心机制

• 会话层：MCP基于长连接或短连接，维护一次交互的会话ID，用于追踪连续的工具调用。
• 上下文包裹：模型发出的每个工具请求都携带当前对话的上下文摘要，工具端处理后返回更新后的上下文。
• 工具发现：MCP支持工具端主动广播自己的功能列表，模型端动态获取可用工具。

实际场景中，一个客服Agent需要查询订单、修改地址、计算运费，如果每个工具都用自己的API格式，模型就得写大量适配代码。MCP统一了接口，Agent只需学会MCP一种语法就能操控所有兼容工具。2026年，主流Agent框架几乎都内置了MCP支持，开发者不用再为协议适配头疼。

2. 工具协议（Tool Protocol）与函数调用（Function Calling）

工具协议是一个更广泛的概念，指模型和工具之间约定好的调用方式，包括请求格式、参数映射、返回结构。函数调用是工具协议的一种具体实现，常见于OpenAI等模型API——模型输出一个包含函数名和参数的JSON对象，然后由宿主代码执行。

两者的区别与联系

• 协议层次：工具协议是架构层面的约定，函数调用是协议在某个模型上的适配形式。
• 灵活性：工具协议可以支持同步和异步、流式和非流式；函数调用通常只处理同步请求。
• 互操作性：遵循同一工具协议的不同模型和工具可以互换，而函数调用往往紧耦合于特定模型供应商。

举个例子，一个天气查询工具如果按OpenAI的函数调用格式暴露接口，那么换用Claude模型时就得重写调用逻辑。而如果该工具实现的是标准MCP协议，任何支持MCP的模型都能直接使用。因此，2026年的社区更倾向于推广通用工具协议，以降低锁定风险。

3. 工具描述文件（Tool Descriptor）—— 让模型知道工具有什么

工具描述文件是附带在工具端的一份元数据文档，告诉模型“我能做什么、需要什么输入、会返回什么”。格式通常是JSON Schema或OpenAPI的子集。一个典型的工具描述包含：

• name：工具名称，如get_weather。
• description：自然语言说明，例如“根据城市名称查询当前气温和天气状况”。
• parameters：输入参数的JSON Schema，包括类型、是否必填、取值范围等。
• returns：返回数据的结构描述（可选）。

模型在决定是否调用工具前，会先读取这些描述。好的描述能大幅提高调用准确率。比如，如果一个工具描述写的很模糊“传入参数”，模型可能会传错类型；而细致描述“city（字符串，必填，例：北京）”就能引导模型正确填充。2026年，许多自动标注工具可辅助生成精准的描述文件，减少人工编写的工作量。

4. 工具注册与发现—— 模型如何找到可用的工具

工具注册是指工具端向一个集中的注册中心（Registry）上报自己的地址、能力、版本等信息。发现则是指Agent或模型运行时查询注册中心，获取当前可调用的工具列表。这个过程通常分为两种模式：

静态注册

• 在Agent启动时，从配置文件加载一批工具描述，加载后不再变化。适合工具数量少、环境稳定的场景。

动态发现

• 工具端每隔一段时间广播心跳，注册中心维护一个实时列表。Agent需要某个能力时，发送“查询意图”给注册中心，返回匹配的工具列表。
• 例如，一个物流Agent接到“查询订单状态”的请求，注册中心返回三个接口：快递100、顺丰开放平台、菜鸟裹裹。Agent根据上下文选择其中一个。

动态发现的好处是灵活，新工具上线后立刻可用；坏处是增加了网络开销和延迟。实际部署中，很多团队采用混合策略：核心工具静态注册，第三方工具动态发现。

5. 上下文传递（Context Passing）—— 让工具知道对话背景

上下文传递是指模型在和工具交互时，把当前对话的关键信息（如用户身份、历史操作、目标意图）一并发送给工具，使工具能做出更准确的响应。这是MCP协议里最核心的设计之一。

传递的内容通常包括：

• 会话摘要：本轮对话的核心任务、已经执行过的步骤。
• 安全约束：比如用户权限、允许调用的资源范围。
• 临时变量：模型计算出的中间结果，像“用户输入的地址经过标准化后的格式”。

一个典型场景：用户问“帮我把上一单的收货地址改成新地址”。Agent调用修改地址工具时，上下文里必须包含“上一单的订单ID”和“新地址”。如果上下文传递不完整，工具可能不知道改哪个订单。

上下文传递也会带来隐私问题——工具端可能拿到不该知道的对话细节。所以MCP协议支持细粒度的上下文剪裁，模型只发送必要的最小信息。2026年，许多框架默认开启上下文脱敏，自动过滤掉敏感字段。

6. 工具执行与结果返回—— 从意图到行动的闭环

工具执行是将模型生成的工具调用请求实际交给工具端处理，并获取结果。这个过程涉及几个关键环节：

执行引擎

• Agent内嵌一个轻量的执行引擎，负责解析模型输出的工具调用JSON，创建HTTP请求或本地函数调用，并管理超时和重试。

结果格式化

• 工具返回的原始数据（如JSON）需要转换成模型能理解的文本描述。例如，天气API返回{"temp":22, "humidity":60}，格式化后变成“当前气温22℃，湿度60%”。
• 好的格式化能减少模型二次追问的概率。

错误处理

• 工具可能超时、返回错误码或空数据。Agent需要有一套兜底逻辑：是重试、换工具还是如实告诉用户。2026年，常见做法是让模型在工具描述中声明错误码含义，模型根据错误信息决定下一步。

整个闭环的执行时间直接影响用户体验。因此，好的工具协议会支持流式返回：让模型在工具还没完成时就开始生成中间结果，降低等待感。

小节

从MCP到工具描述文件，这些术语构成了Agent调用工具的完整链路。理解每个环节的作用，能帮助你在设计和调试工具时少走弯路。2026年，随着MCP生态的成熟，工具协议正变得像网络协议一样标准化，开发者只需要聚焦业务逻辑即可。

常见问题