Interview Bank

MCP in 7 Days: Wire Tools Into Any Agent

D2 Writing Your First MCP Server: stdio Transport, the Official SDK, Parameter Schemas, Tool Annotations, and Debugging With Inspector

• Who is a tool's description actually written for, and what concretely goes wrong in production when it is too vague?工具的 description 到底写给谁看？写得太泛，在生产里会造成什么具体后果？

  Common in ChinaCommon overseasBasic#tool-design#prompt-surface

  How to reason about it · think before answering

  1. The screen is whether you have ever debugged a tool the model refuses to call. Answering 'write it clearly so colleagues understand' reveals doc-thinking; the point is that the description is the model's only evidence.
  2. Ask what the model has when it makes the decision: the tool name, this one description, and the parameter schema. It cannot see your wiki, comments, or spec. The description is a decision input, not documentation.
  3. Split vagueness into two failure directions. Under-calling: the model never realizes the tool solves the current problem, so the task silently fails with no error. Over-calling: fuzzy boundaries make the model invoke it when it should not, which is a real incident if the tool has side effects.
  4. Conclusion: a usable description answers three things — what it does, what the parameters look like with an example, and when it should be used. The third is the one people omit, and it is the gate that prevents over-calling.
  5. Add the engineering view: a description is an external contract, so changing it changes behavior, and the same wording performs differently across models. It belongs in version control with an eval set, not in post-launch eyeballing.
  6. Likely follow-up: is longer always better? No. Descriptions consume context budget and crowd out the actual conversation once you have many tools. Keep the summary short and push detail into each parameter's own description.

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

  1. 这题在筛「有没有真的排查过模型不调工具」。答成「写清楚一点，方便别人理解」就落到文档思维了；面试官想听的是描述是模型唯一的判断依据这件事。
  2. 拆法：先问自己「模型做这个决定时手上有什么」。它看不到你的 wiki、代码注释、需求文档，只有工具名加这一句描述加参数 schema。所以描述不是文档，是决策依据。
  3. 把「太泛」拆成两个方向的后果：一是**漏调**，模型不知道这个工具能解决当前问题，任务默默做不成，而且不会报错；二是**误调**，描述边界不清，模型在不该调的时候调它——如果这个工具有副作用，那就是一次真实的线上事故。
  4. 结论：一句合格的描述要回答三件事——做什么、参数长什么样（给例子）、什么情况下才该用。第三条最常被漏掉，也最要命，因为它才是防误调的那道闸。
  5. 补一条工程视角：描述是对外契约，改它等于改行为。同一段描述在不同模型上表现还不一样，所以描述要进版本管理、要有评估集，不能靠上线后人肉观察。
  6. 可预期的追问：那把描述写得越长越好吗？不是。描述会占上下文预算，工具一多就挤掉真正的对话内容；正确做法是短而准，把细节放进每个参数各自的 description 里。

  Key points

  • The description is read by the model and is its only basis for deciding whether to call the tool
  • Vagueness causes silent under-calling or dangerous over-calling of side-effecting tools
  • A good description states what it does, what the parameters look like with an example, and when it applies
  • Treat it as an external contract with version control and evals; push detail into per-parameter descriptions to save context

  答题要点

  • 描述是给模型看的，是它决定调不调这个工具的唯一依据，不是给同事看的文档
  • 写得太泛有两类后果：漏调导致任务静默失败，误调则可能触发有副作用的操作
  • 合格描述回答三件事：做什么、参数长什么样并给例子、什么情况下才该用
  • 描述是对外契约，要进版本管理并配评估集；细节放进每个参数的 description，总描述保持短而准