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

• 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 特有的：改工具描述，因为描述是模型选工具的唯一依据
  • 它更危险是因为不报错：测试全绿、日志干净，只有选中率悄悄下滑，几周后才浮上来
  • 闸门是评估集；加字段要可选，改语义要换新工具名并给旧的一段弃用期