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，总描述保持短而准
• When should a tool return a JSON-RPC error versus a result with isError set to true? Give me a decision rule.什么时候该返回 JSON-RPC 的 error，什么时候该返回 isError 为真的工具结果？给我一个判据。

  Common in ChinaCommon overseasIntermediate#error-handling#tool-design

  How to reason about it · think before answering

  1. This is close to a pass/fail line for MCP server work. Reciting 'two kinds of errors' is baseline; the discriminator is producing an actionable rule and knowing who the error text is written for.
  2. Ask who can fix it. If the request itself is invalid — unknown tool, arguments failing the call-tool schema, an internal server fault — no amount of parameter tweaking helps, so return a JSON-RPC error, typically -32602. If the tool ran but the business case failed — downstream API error, bad date format, amount out of range — a different argument might work, so return isError in the result.
  3. The rule in one line: could the model succeed by changing an argument? If yes use isError, if no use error. Note that isError is still a successful JSON-RPC response with resultType complete.
  4. Carry the text requirement into the conclusion: the spec says clients should hand execution errors to the model for self-correction, so the message is written for the model. List allowed values, the correct format, the boundary. 'Invalid parameter' just makes it guess.
  5. The production trap is not misclassifying but returning neither — skipping validation so an illegal input yields NaN or an empty result that is silently returned. The model then uses a wrong answer with no trace. Leaning on output-schema validation is not handling it either, since the model receives a schema stack trace.
  6. Likely follow-up: should clients feed protocol errors to the model too? The spec permits it but it rarely helps, because the model cannot fix them. Log and alert instead — that one is your bug.

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

  1. 这题几乎是 MCP 服务端的入门分水岭。能背出「两类错误」只算及格，区分度在于能不能给出一条可执行的判据，以及知不知道错误文案是写给谁的。
  2. 拆法：问「谁能修好这个错」。请求本身不合法——工具名不存在、参数不满足调用工具的 schema、服务端内部异常——模型再怎么改参数都没用，这类走 JSON-RPC 的 error，典型是 -32602。工具跑了但业务没成——下游 API 失败、日期格式不对、金额越界——模型换个参数就可能成功，这类走 result 里的 isError。
  3. 判据一句话：**模型换个参数有没有可能成功？有就用 isError，没有就用 error。** 注意 isError 仍然是一个成功的 JSON-RPC 响应，resultType 照样是 complete。
  4. 结论要带上文案要求：规范说客户端应当把执行错误交给模型自我纠正，所以文案是写给模型看的，要列出可选值、正确格式、边界条件。写「参数错误」等于让模型瞎猜。
  5. 生产视角的坑：最危险的不是分错类，而是**两类都不返回**——不做校验，让非法输入算出 NaN 或空结果静默返回。模型会把错误答案当正确答案用下去，且不留痕迹。靠输出 schema 校验去兜底也不算处理，因为模型拿到的是一段 schema 堆栈。
  6. 可预期的追问：客户端要不要把协议错误也喂给模型？规范说可以，但基本没用，因为模型改不了；更该做的是记日志报警，那是你的 bug 不是模型的。

  Key points

  • Protocol errors use the JSON-RPC error field: unknown tool, schema-invalid request, internal fault — unfixable by the model
  • Execution errors use isError true in the result and remain a successful JSON-RPC response
  • The rule: if a different argument could succeed, use isError; otherwise use error
  • Write execution-error text for the model with allowed values and formats; the worst case is neither, silently returning a wrong result

  答题要点

  • 协议错误走 JSON-RPC 的 error：未知工具、请求不满足 schema、服务端内部错，模型改参数也无济于事
  • 执行错误走结果里的 isError 为真：下游失败、业务校验不过，它仍是成功的 JSON-RPC 响应
  • 判据是模型换个参数有没有可能成功，有就 isError，没有就 error
  • 执行错误的文案写给模型看，要列出可选值与正确格式；最危险的是两类都不返回、静默给出错误结果