MCP工具调用五步拆解：AI如何真正执行操作

一个被忽视的真相：模型本身不会调用任何工具

AI模型能查GitHub上的bug、能发邮件、能操作数据库——这是很多人的直觉。但事实是，模型只会写文本，它无法执行任何操作。

那么，是谁在替你调用工具？YouTube上一条技术讲解视频用一次完整的请求链路，把MCP（Model Context Protocol）的工具调用机制拆成了五步。理解这五步，你就能看清AI Agent「行动能力」的真正来源，也能明白为什么工具描述的质量直接决定了Agent的可靠性。

五步链路：从提问到答案

视频用一个具体场景贯穿始终：你对AI说「找出关于登录的未修复bug」。接下来发生的每一步，都值得仔细看。

第一步：客户端向服务器索取工具清单

请求的起点不是模型，而是客户端（client）。客户端先向GitHub服务器（server）请求可用工具的列表。每个工具返回三样东西：名称、描述，以及输入参数的schema（模式定义）。

这一步是整个机制的基石。工具清单不是硬编码在模型里的，而是运行时动态获取的——这意味着服务器的工具集可以随时增删改，模型看到的世界也随之更新。

MCP（Model Context Protocol） 是由 Anthropic 于 2024 年底提出的开放协议，旨在标准化 AI 模型与外部工具、数据源之间的交互方式。它借鉴了语言服务器协议（LSP）的设计思想，将“模型如何发现和调用工具”抽象为客户端-服务器架构：MCP 服务器暴露工具、资源和提示模板，MCP 客户端（通常由宿主应用实现）负责连接服务器并将能力转译给模型。协议定义了基于 JSON-RPC 的通信格式，使得同一个服务器可以被不同模型、不同宿主复用。理解 MCP 的定位很重要——它不执行工具，也不增强模型，而是解决“模型如何以统一方式获知并请求外部能力”的标准化问题，这正是五步链路得以成立的前提。

第二步：宿主把工具描述塞进模型上下文

拿到工具清单后，宿主（host）要做一件事：把这些工具的描述文本放进模型的上下文里。

这里藏着最容易被低估的细节——模型对工具的全部认知，就是那段描述文字。它不知道工具背后是GitHub API还是本地脚本，不知道执行逻辑是否安全，它只知道「描述说了什么」。描述写得含糊，模型就会选错工具或填错参数。

输入参数 schema 通常采用 JSON Schema 格式描述，它规定了工具接受哪些参数、每个参数的类型（字符串、数字、枚举等）、是否必填以及取值范围。模型在生成调用请求时，会依据 schema 约束来构造参数对象。schema 越精确，模型填错参数的概率越低；反之，若 schema 过于宽松（例如全部用 string 类型且无枚举限制），模型就可能传入服务器无法解析的值。在 MCP 中，工具清单里的 schema 会随描述文本一同注入上下文，因此它不仅是服务器端的校验依据，更是模型“填写表单”时的唯一说明书。工具开发者应把 schema 视为面向模型的接口文档来设计，而非仅用于后端校验。

第三步：模型选择工具并填写输入

模型读完你的问题，从上下文中挑选出search_issues工具，并填好参数：label为bug，query为login。

但关键限制再次出现：模型不能运行任何东西，它只是写出一个结构化的请求文本。模型输出的是「意图的表达」，而非「动作的执行」。这个区分是理解整个MCP架构的钥匙。

第四步：宿主请求授权，客户端发出调用

模型写出的请求先到宿主手里。宿主把它展示给你，并征求许可。你点了同意，客户端才把调用真正发给服务器。

这一步是安全阀。工具调用不是模型说了算，人类的批准是链路中的必经环节。对于敏感操作（写数据库、发消息、删文件），这个设计决定了Agent能否被信任。

宿主（host） 是运行 AI 应用的顶层程序，例如 IDE 插件、聊天客户端或 Agent 框架。它负责管理模型会话、连接一个或多个 MCP 客户端，并充当用户与工具调用之间的中介。在授权环节，宿主决定以何种方式向用户呈现调用请求——可以是弹窗确认、命令行提示，也可以根据策略自动批准只读操作。宿主还承担着聚合多个服务器工具列表、维护上下文窗口、记录审计日志等职责。换句话说，宿主是“模型能力”与“真实世界”之间的编排层：模型看不到服务器，服务器也不认识模型，所有连接、授权与上下文拼装都由宿主完成。这也解释了为什么宿主的安全策略直接决定了 Agent 的可信边界。

第五步：服务器执行并回传，模型作答

服务器收到调用后，去查询GitHub的真实API，把结果返回。结果重新进入模型上下文，模型据此写出最终答案：「三个未修复的bug，附链接。」

为什么这五步值得开发者记住

把这条链路压缩成五个动词：列表、选择、批准、调用、回答。视频在结尾强调，每一次工具调用都遵循这个模式。

这个抽象的实用价值在于：调试Agent时，任何异常都能定位到具体环节。模型选错工具？问题在第二步的描述质量。参数填错？检查schema是否清晰。调用被拒？那是第四步的授权策略。结果没被正确使用？回看第五步的上下文注入。

另一个值得注意的推论是安全边界。既然模型只能「写文本」，那么所有真实世界的影响都发生在服务器端和宿主端。这意味着权限控制、审计日志、人工确认这些机制，才是Agent系统的真正防线——而不是模型本身的「自律」。

一个容易被忽略的设计哲学

MCP把「模型的能力」和「工具的执行」彻底解耦。模型永远停留在文本层，工具调用通过标准化的协议在外部完成。这种分离带来两个好处：模型可以对接任意实现了协议的服务器，而服务器不需要关心里面跑的是哪个模型。

代价则是描述文本成了单点瓶颈。工具描述写得不好，再强的模型也选不对工具；schema定义不严，参数就会出错。对工具开发者来说，写一份好的工具描述，其重要性不亚于写对执行逻辑。

下次你的Agent调错工具时，不妨沿着这五步倒查一遍——问题往往不在模型，而在链路中某个被人忽略的环节。