Interview Bank

MCP in 7 Days: Wire Tools Into Any Agent

D7 Productionizing and Retrospective: Writing Evals for Tools, Versioning, Publishing to npm and a Registry, Observability, and a Capstone Project

• How do you evaluate whether an MCP tool is any good, and what categories of test cases would you design?怎么评估一个 MCP 工具做得好不好？你会设计哪几类测试用例？

  Common in ChinaCommon overseasIntermediate#eval#tooling

  How to reason about it · think before answering

  1. The screen is whether you have shipped tools. 'Write unit tests' answers the wrong question: unit tests check that given arguments produce the right output, while the first thing to break on an MCP tool is the model not selecting it at all, so the arguments never reach your function.
  2. Define the target: an eval measures selection accuracy, meaning given a user utterance and a tool list, does the model pick the right tool. Correctness of the tool itself belongs to unit tests, and the two layers should not be blurred.
  3. Then the three categories, which is the direct answer. Happy path: unambiguous intent, such as 'find me the release process doc'. Edge: intent carried by semantics rather than keywords, such as 'what does release-process say', which has no verb cue and only a slug-shaped token, and is most often misread as a search. Traps: cases where nothing should be called, such as 'thanks, no need to look it up', 'how do you say document in English', and 'what can you do'. I usually weight them four, three, three.
  4. Stress that the third category is the dividing line: an eval set of only happy paths reports a comfortable hundred percent while measuring nothing about over-triggering, which is what most production complaints actually are, and over-triggering has side effects.
  5. Then the assertion, where the classic bug lives: treating an expected value of null as 'anything goes', which makes negatives permanently green. The correct assertion judges both directions. I also rerun the whole set with a deliberately wrong selector that always picks the same tool and require every negative to fail, which validates the assertion rather than the selector.
  6. Finally the engineering constraints: one command, under a minute, on a cheap small model, because a slow eval is no eval, since whoever edits a description will not wait. And report per category rather than one number: happy-path drops mean a vague description, edge drops mean the sentence distinguishing two similar tools is missing, trap drops mean the description over-claims.
  7. Likely follow-ups: when do you run it? On any change to descriptions, schemas, or the tool set, wired into CI. And what if the model changes? The eval set is a cross-model asset, so you rebaseline on a model switch, which is part of why it pays for itself.

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

  1. 这题在筛「有没有真的上线过工具」。答「写单元测试」是答错了赛道——单元测试测的是给定参数输出对不对，而 MCP 工具最先出问题的地方是模型压根没选它，参数根本到不了你的函数。
  2. 先把要评估的对象说清：评估评的是**选中率**，也就是给一句用户的话和一张工具表，模型会不会选中该选的那个。工具本身的正确性归单元测试，两层不要混。
  3. 然后给三类用例，这是本题的正面回答。正例：意图明确时选得中，比如「帮我搜一下发布流程文档」。边界：意图靠语义而不是关键词，比如「release-process 这篇讲了什么」——没有任何动词提示，只有一个像 slug 的词，最容易被误判成搜索。诱导误选（负例）：不该调的时候一个都不调，比如「谢谢，不用查文档了」「文档这个词英文怎么说」「你都能干什么」。占比我一般给四三三。
  4. 第三类是分水岭，要主动强调：只有正例的评估集会给你一个 100% 的假象，它测不出过度触发，而线上大多数投诉恰恰是过度触发——用户随口一句否定，助手转头就去干了，还带副作用。
  5. 接着讲断言，这里有个最常见的写法错误：expected 为 null 的用例被当成「随便都行」，于是负例永远绿。正确的断言两个方向都判：期待某个工具时选中它才算过，期待不调用时什么都不选才算过。我会额外拿一个「总是选同一个工具」的假选择器再跑一遍，要求负例全部失败——这验的不是选择器，是我的断言真的在起作用。
  6. 最后是工程约束：评估集要能一条命令跑完，一分钟以内，用便宜的小模型跑。跑得慢的评估集等于没有，因为改描述的人不会等。结果也不要只看总分，按三类分开看才有行动价值：正例掉了说明描述写糊了，边界掉了说明缺了区分相似工具的那句话，负例掉了说明描述写得太热情。
  7. 可预期的追问：什么时候跑？描述、schema、工具增删这三类改动都必须跑，把它挂进 CI。再追问会问到「模型换了怎么办」，答案是评估集是跨模型的资产，换模型时先跑一遍拿到基线，这也是它值得投入的原因之一。

  Key points

  • Evals measure selection accuracy, not tool correctness; the latter is unit-tested and the layers must not blur
  • Three categories are mandatory: happy path, edge, and traps, weighted roughly four three three
  • Assert both directions: an expected null must mean nothing was called, and validate the assertion with a deliberately wrong selector
  • One command, under a minute, scored per category, and triggered by any description or schema change

  答题要点

  • 评估评的是选中率，不是工具正确性；后者归单元测试，两层不能混
  • 三类用例缺一不可：正例、边界、诱导误选，建议四三三
  • 断言两个方向都判：期待 null 时必须什么都不选；再用故意选错的选择器验证断言本身
  • 一条命令一分钟内跑完，按类别分开看分数，描述与 schema 改动必须触发
• When versioning an MCP server, what counts as a breaking change, and why is editing a tool description more dangerous than renaming a field?给一个 MCP 服务端做版本管理时，什么样的改动算破坏性变更？为什么说改一句工具描述比改一个字段名更危险？

  Common in ChinaCommon overseasIntermediate#versioning#tooling

  How to reason about it · think before answering

  1. The first half is common knowledge; the second half is the filter. Anyone who can explain that the description is part of the interface has actually operated tools in production.
  2. Give the four conventional categories, which the official guidance on extension evolution defines directly: removing or renaming fields, changing field types, altering the semantics of existing behavior, and adding new required fields. All four make existing implementations fail or behave incorrectly.
  3. Then add the MCP-specific fifth: editing a tool description. The description is the model's only basis for selecting a tool, so changing a sentence is a behavior change. Concretely, a server shortened 'search the internal doc library by keyword' to 'search documents', shipped no code changes, and two weeks later users reported the assistant had gotten dumber, because the model stopped choosing it.
  4. Now the crux, why it is more dangerous. Renaming a field makes callers fail loudly and someone finds you within five minutes. Editing a description raises nothing: unit tests pass, the server reports zero errors, logs are clean, and selection accuracy quietly drops a few points, surfacing weeks later as an undiagnosable 'it got worse'. Loud failures are far easier than silent degradation, so description changes need the stronger gate.
  5. Name the gate: an eval set with all three case categories, run on every description change, blocking the merge when selection accuracy drops. That is also why the eval must run fast from one command.
  6. Add the compatibility techniques: new fields must be optional, since old clients will not send them; to change semantics, introduce a new tool name rather than mutating in place, mark the old one deprecated with the replacement named in its description, and remove it only after a grace period, because you cannot know how many prompts hardcode that name.
  7. Likely follow-ups: how does the protocol version itself? MCP uses YYYY-MM-DD marking the last breaking change, backwards-compatible updates do not bump it, and deprecated features stay for at least twelve months before removal. And can you fix metadata after publishing to the registry? No: versions are unique and immutable once published, a typo costs a new version, and range-looking version strings are rejected outright.

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

  1. 这题的前半句是常识题，后半句才是筛子。能把「描述也是接口」说明白的人，基本都真的运维过工具。
  2. 先答常规的四类，官方在讲扩展演进时给过定义，直接可用：删除或重命名字段、改字段类型、改变现有行为的语义、新增必填字段。这四类的共同点是会让已有实现直接失败或者行为不正确。
  3. 然后补 MCP 特有的第五类：**改工具描述**。理由是描述是模型选工具的唯一依据，改一句描述就是一次行为变更。举个具体的：某个服务端把描述从「在内部文档库里按关键词搜索」精简成「搜索文档」，代码一行没动，两周后用户反馈助手变笨了——模型不再选它了。
  4. 接着讲为什么它**更**危险，这是题眼：改字段名会让调用方立刻报错，错误是响亮的，五分钟内就有人来找你；改描述不报任何错，单元测试全绿、服务端零错误、日志干净，它只会让选中率悄悄掉几个点，最后以「最近变笨了」这种没法定位的形式浮上来。响亮的错误比安静的退化好处理得多，所以描述改动反而更需要闸门。
  5. 闸门是什么要说出来：一份三类齐全的评估集，描述改了必须跑一遍，选中率掉了就别合。这也是评估集要能一条命令快速跑完的原因。
  6. 顺带把兼容技巧补上：加字段要加成可选的，因为老客户端不会传新参数；要改语义就换个工具名而不是原地改，旧的标弃用、描述里写明替代品、留一段时间再删，因为你不知道多少人的提示词里写死了那个名字。
  7. 可预期的追问一：协议自己怎么做版本？MCP 用 YYYY-MM-DD，标的是最后一次破坏性变更的日期，向后兼容的改动不递增版本；弃用的特性至少保留十二个月才可能移除。追问二：发到注册表之后怎么改？改不了——版本号唯一且发布后元数据不可变，打错字只能往上加一个版本，而且范围形式的版本号会被直接拒收。

  Key points

  • The four usual categories: removing or renaming fields, changing types, altering semantics, adding required fields
  • The MCP-specific fifth is editing a tool description, since the description is the model's only selection signal
  • It is more dangerous because nothing fails: tests pass and logs are clean while selection accuracy silently drops
  • The gate is the eval set; new fields must be optional, and semantic changes need a new tool name plus a deprecation window

  答题要点

  • 常规四类：删除或重命名字段、改字段类型、改变现有行为语义、新增必填字段
  • 第五类是 MCP 特有的：改工具描述，因为描述是模型选工具的唯一依据
  • 它更危险是因为不报错：测试全绿、日志干净，只有选中率悄悄下滑，几周后才浮上来
  • 闸门是评估集；加字段要可选，改语义要换新工具名并给旧的一段弃用期