面试题库

7 天 MCP：把工具接进任何 Agent

D5 写一个 MCP client：在自己的 Agent 循环里发现并调用工具、多 server 聚合与命名冲突

• 把 MCP 的工具定义翻译成模型 API 的工具参数时，最容易丢掉的是什么？丢了会怎样？When translating an MCP tool definition into a model API's tool parameters, what is most easily lost, and what goes wrong when it is?

  国内高频海外高频深入#client#tool-schema

  分析过程 · 先想清楚再作答

  1. 这题在考「你知不知道这一步是有损的」。答「字段名对一下就行」的人多半没写过客户端，因为 MCP 的工具定义里有好几样东西在模型 API 那边根本没有对应位置。
  2. 先列清单再讲后果。丢的主要是三样：annotations（readOnlyHint、destructiveHint、idempotentHint 这类行为提示）、outputSchema（结构化返回的形状）、title（给人看的名字）。另外还有一样常被忽略的是分页——只取 tools/list 第一页等于把后面的工具整批丢掉。
  3. 逐条讲后果。annotations 丢了，模型不知道哪个工具是破坏性的，客户端也就没法自动决定要不要弹确认框——所以确认逻辑必须由客户端按注解自己做，不能指望模型自觉。outputSchema 丢了，下游只能靠解析自然语言拿数据，而且做代码模式（让模型写代码调工具）时生成不出准确的返回类型。title 丢了，界面上只能显示一串带前缀的机器名。
  4. 这里必须主动补一句最重要的：**注解本身是不可信输入**。规范要求客户端把工具注解当成不可信的，除非来自可信服务端。readOnlyHint 为真不是「这个工具安全」的证明，它只是服务端的自我声明。所以注解可以用来决定 UI 上要不要多问一句，但不能拿它当权限判据。
  5. 结论：翻译这一步的正确心态是「知道自己丢了什么，并在客户端补回来」。补法是——确认与拦截由客户端按注解做、结构化返回自己校验、界面用 title 而给模型用 description、分页翻到 nextCursor 消失为止。
  6. 可预期的追问：description 要不要改写？可以适度加工，比如在前面缀一句来源说明帮助模型在重名时选对，但不要重写语义——描述是服务端作者调过的，也是他们唯一能影响模型选择的地方。再追问可能是「outputSchema 缺失怎么办」，官方建议先用泛型接住往下游传，真需要类型时用一个小模型做一次抽取并校验，别在循环里做。

  How to reason about it · think before answering

  1. This checks whether you know the step is lossy. Anyone answering 'just map the field names' has probably not written a client, because several parts of an MCP tool definition have no home on the model-API side.
  2. List first, then consequences. Three things go missing: annotations (readOnlyHint, destructiveHint, idempotentHint), outputSchema, and title. A fourth, often overlooked, is pagination — taking only the first page of tools/list silently drops whole batches of tools.
  3. Consequences one by one. Without annotations the model cannot tell which tool is destructive and the client has nothing to base a confirmation prompt on, so confirmation logic must live in the client and read the annotations directly. Without outputSchema, downstream code parses natural language, and code-mode generation cannot produce accurate return types. Without title, the UI can only show a prefixed machine name.
  4. Volunteer the most important caveat: annotations are untrusted input. The spec requires clients to treat tool annotations as untrusted unless they come from trusted servers. readOnlyHint being true is not proof of safety, only the server's own claim, so annotations may drive whether you ask the user, never whether the caller is authorized.
  5. Conclusion: the right posture is to know exactly what you dropped and compensate in the client — confirmation driven by annotations, structured results validated by you, title for the UI and description for the model, and pagination followed until nextCursor disappears.
  6. Likely follow-ups: may you rewrite the description? Light augmentation is fine, such as prefixing the source to help disambiguate collisions, but do not rewrite the meaning, since the description is what the server author tuned and their only lever on model choice. And what if outputSchema is absent? The official guidance is to accept a generic type and move on, or extract a typed result with a fast model outside loops and validate it.

  答题要点

  • 丢的是 annotations、outputSchema、title，外加只取第一页时整批丢掉的工具
  • annotations 丢了就没法决定要不要弹确认框，确认逻辑必须由客户端按注解自己做
  • 注解是不可信输入，只能驱动 UI 提示，不能当权限判据
  • outputSchema 丢了下游只能解析自然语言；description 可以缀来源但不要重写语义

  Key points

  • Annotations, outputSchema and title are lost, plus every tool past the first page if pagination is ignored
  • Without annotations there is nothing to drive a confirmation prompt, so that logic must live in the client
  • Annotations are untrusted input: they may drive UI prompts, never authorization decisions
  • Losing outputSchema forces downstream natural-language parsing; you may prefix the description but must not rewrite its meaning