01

60 秒回答模板

MCP 客户端调用服务端工具一般不是让模型直接访问服务端，而是由客户端作为中间控制面完成。流程上，客户端先和 MCP Server 建立连接并完成能力协商，拉取可用工具列表、参数 schema 和说明；随后客户端把这些工具能力放进模型上下文，让模型根据用户意图决定是否发起 tool call；客户端收到结构化 tool call 后做参数校验、权限检查、超时预算和幂等控制，再把请求转发给对应 MCP Server；服务端执行真实工具，比如查库、读文件或调外部 API，并返回结构化结果或错误；客户端再把结果喂回模型，让模型生成最终回答。工程上要强调三点：模型只做决策和生成，不直接执行工具；客户端负责安全、调度、状态和错误处理；服务端工具要有清晰 schema、权限边界、可观测性和失败语义。

考点 画成用户、LLM、MCP Client、MC
难度 真实面经题
回答目标 讲清 MCP tool-call 控制链路
02

深入解析

01

连接与能力协商

第一步是客户端和 MCP Server 建立连接，明确双方支持的协议版本、能力范围和通信方式。客户端不能假设服务端有哪些工具，而应通过协议发现工具、资源或 prompt 能力。这个阶段的重点是把服务端能力变成客户端可管理的能力清单，而不是把服务端实现细节暴露给模型。

02

工具发现与 schema 暴露

客户端从服务端获取工具名称、描述、输入参数 schema、返回结构和可能的错误。随后客户端把适合当前任务的工具说明注入模型上下文。好的工具描述要让模型知道什么时候用、参数怎么填、结果代表什么；schema 要让客户端能做结构化校验，避免模型生成的参数直接进入执行层。

03

模型生成 tool call

用户问题进入模型后，模型会判断是否需要调用工具。如果需要，它输出结构化 tool call，包括工具名和参数。这里模型只是提出调用意图，不能被视为可信执行方。客户端要检查工具是否存在、参数是否符合 schema、用户是否有权限、调用是否会产生副作用。

04

客户端调度与安全控制

客户端是关键控制点，负责把模型的调用意图转换成真实请求。它需要设置超时时间、重试策略、取消信号、并发限制和审计日志；对读写类工具还要区分只读、写入、删除等风险等级。对于敏感工具，客户端可以要求用户确认，或者只允许在沙箱中执行。

05

服务端执行与结果回传

MCP Server 执行具体工具逻辑，并返回结构化结果。返回值应尽量表达事实状态，而不是让服务端直接拼最终自然语言答案。客户端收到结果后，把结果作为 tool result 再交给模型，模型结合上下文生成面向用户的最终回答。如果服务端返回错误，也应保留错误类型、可重试性和用户可见解释。

06

状态、错误和可观测性

完整回答还要补充状态和异常路径。比如多轮对话中工具结果如何进入上下文，长结果如何摘要，调用失败如何降级，超时如何取消，调用链如何打 trace。面试中不要只答成功链路，要说明客户端如何限制权限、记录审计、处理失败和避免模型绕过工具边界。

03

易错点

  • 只说“模型调用工具，工具返回结果”，没有讲客户端的调度和安全职责。
  • 把 MCP Server 当成业务后端网关，忽略工具发现、schema 和协议协商。
  • 认为模型输出的工具参数可以直接执行，漏掉参数校验和权限检查。
  • 只描述成功流程，没有说明超时、失败、取消、重试和错误回传。
  • 把工具返回结果当最终答案，忽略还需要交回模型生成用户可读回答。
  • 没有区分只读工具和有副作用工具，导致安全边界回答很弱。
04

面试官追问

为什么不能让模型直接调用服务端工具？

模型输出不可完全信任，必须由客户端做 schema 校验、权限判断、调用审计和副作用控制，否则容易出现越权、误调用或参数注入。

工具 schema 设计不好会有什么问题？

模型会误选工具、乱填参数，客户端也难以校验。结果是调用成功率低、错误不可解释，还可能把业务约束泄露到 prompt 里靠模型猜。

MCP 调用失败后怎么处理？

先按错误类型区分参数错误、权限错误、超时、服务端异常和外部依赖失败。可重试错误走有限重试或降级；不可重试错误要返回可理解的失败原因，并避免模型编造结果。

多轮对话中工具结果如何管理？

短结果可以直接进入上下文，长结果应摘要或结构化存储，并保留引用关系。对敏感结果要设置生命周期，避免无限期进入后续对话。

如何判断一个工具应该暴露给模型？

看它是否有明确输入输出、是否能被自然语言意图稳定触发、是否有可控权限和失败语义。高风险写操作要加确认或隔离。