Interview Bank

MCP in 7 Days: Wire Tools Into Any Agent

D1 Why a Protocol: the Host/Client/Server Triangle, JSON-RPC Messages, and Three Primitives

• How is MCP actually different from a model's built-in function calling, and when should you not use MCP?MCP 和模型自带的函数调用到底差在哪？什么情况下你不该用 MCP？

  Common in ChinaCommon overseasBasic#mcp-basics#architecture

  How to reason about it · think before answering

  1. The screen is whether you have actually wired tools yourself. Calling MCP an upgraded function call fails, because the two sit at different layers.
  2. Separate the layers first: function calling is a model API feature — you pass tool definitions in the request and the model replies with which one to invoke. MCP governs where that definition and its executor live and how they are exchanged.
  3. They compose rather than compete: an MCP client still translates tools/list output into the model API's tool parameters, so the final hop is ordinary function calling.
  4. Conclusion: MCP turns an M-applications-by-N-tools wiring problem into M plus N, at the cost of an extra process, an extra serialization boundary, and an extra place to debug.
  5. Skip MCP when the tool has exactly one consumer, when calls are hot and latency-sensitive (a remote round trip is tens to hundreds of milliseconds, five per turn is noticeable), or when the decision does not need a model at all.
  6. Likely follow-up: local stdio is cheap, so why not use it everywhere? Because the cost is not only transport — it is one more process to deploy, monitor, and authorize.

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

  1. 这题在筛「有没有真正接过工具」。把 MCP 说成「函数调用的升级版」就露馅了，因为两者根本不在同一层，答对的人第一句就会先把层次拆开。
  2. 拆法：问自己「这一步是模型 API 的事，还是工具从哪来的事」。函数调用是模型 API 的能力——你把工具定义放进请求，模型回一个要调谁；MCP 管的是那份定义和执行体住在哪个进程里、用什么语言交换。
  3. 接着点出两者是叠加而非替代：MCP 客户端拿到 tools/list 之后，还要把它翻译成模型 API 的工具参数，最终仍然走函数调用那条路。
  4. 结论：MCP 解决的是 M 个应用乘 N 个工具的重复接线，把乘法变成加法；它换来的代价是多一层进程、一层序列化、一层要排查的地方。
  5. 不该用的三种情况：工具只有自己这一个程序用；调用极频繁且对延迟敏感（远程一次往返几十到几百毫秒，一轮连调五次用户就有感）；这件事根本不需要模型决定，产品逻辑本来就是确定的。
  6. 可预期的追问：那本机 stdio 的开销很小，是不是就可以随便用？答案是开销不只在传输，还在多一个要部署、要监控、要授权的进程上。

  Key points

  • Function calling is a model API capability; MCP is a distribution protocol for tool definitions and executors — they stack, not compete
  • MCP converts M-by-N adapters into M plus N, paying with an extra process and serialization hop
  • Skip it for single-consumer tools, latency-sensitive hot paths, and flows that are deterministic by design
  • The test is whether a second program will ever need this capability; if yes, the protocol cost amortizes

  答题要点

  • 函数调用是模型 API 的能力，MCP 是工具定义与执行体的分发协议，两者叠加而不是替代
  • MCP 的价值是把 M 乘 N 的适配器数量变成 M 加 N，代价是多一层进程与序列化
  • 单一消费者、延迟敏感的热路径、以及本来就确定的产品流程，这三种情况不该用 MCP
  • 判据是「这个能力要不要给第二个程序用」，只要答案是要，协议的成本就摊得开

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，总描述保持短而准

D3 Resources and Prompts: URI Templates, Change Notifications, Progress and Logging, Pagination, and Client Capabilities

• For the same data, what is the difference between exposing it as an MCP resource versus a tool, and how do you choose?同一份数据，做成 MCP 资源和做成工具有什么区别？你按什么标准选？

  Common in ChinaCommon overseasBasic#primitives#server-design

  How to reason about it · think before answering

  1. This screens for real server design experience. Saying resources are read-only and tools mutate scores a pass at best, because read-only search still belongs in a tool.
  2. Reframe it: do not ask what the data is, ask who decides to use it this time. The spec makes resources application-driven, picked by the host or the user, while tools are model-controlled. Fixing the controller also fixes who is accountable when it goes wrong.
  3. Add the practical test: enumerability. A resource has to appear in a paginated list a human can pick from, so a code search with an unbounded input space must be a tool even though it never writes anything.
  4. Conclusion: read-only, enumerable, user-selectable becomes a resource; side-effecting, model-timed, or non-enumerable becomes a tool.
  5. Bring up cost unprompted: tool definitions ship on every turn whether used or not, while an unselected resource costs zero tokens. Three thousand documents as three thousand tools blows up the context window; as resources they are pay-per-use.
  6. Likely follow-up: where do prompts fit? They are the third primitive, user-selected and usually surfaced as slash commands — the three differ only by who controls them.

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

  1. 这题在筛「有没有真的设计过服务端」。答成「资源是只读的、工具会改数据」只能算及格，因为只读的检索照样该做成工具，区分度全在这一步。
  2. 拆法：不要问「它是什么」，问「这一次由谁决定用不用它」。规范把资源定成应用驱动——由宿主应用或用户挑；工具是模型控制——模型看着描述自己调。控制方定了，出错时该找谁负责也就定了。
  3. 再补一条更实用的判据：能不能被枚举。资源要出现在一张可翻页的清单里让人挑，所以「搜索代码」这种输入空间无限的能力，哪怕完全只读也必须做成工具。
  4. 结论：只读、可枚举、希望用户在界面上挑的做成资源；有副作用、或需要模型自己判断时机、或无法枚举的做成工具。
  5. 生产视角要主动加一句成本：工具定义不管用不用，每轮都要塞进请求；资源不被选中就一个 token 都不占。三千篇文档做成三千个工具会直接撑爆上下文，做成资源则按需付费。
  6. 可预期的追问：那提示模板算第几种？答案是第三种，由用户显式选中，典型形态是斜杠命令——三种原语的差别只在控制方，不在能力。

  Key points

  • Resources are application-driven and picked by host or user; tools are model-controlled and chosen from their descriptions
  • Enumerability is the practical dividing line: unbounded-input capabilities like search stay tools even when read-only
  • Cost-wise tool definitions occupy context every turn while unselected resources cost nothing, so large corpora must be resources
  • The controller determines accountability: bad tool choice means bad descriptions, bad prompt choice means bad naming, bad resource injection is a product problem

  答题要点

  • 资源是应用驱动的，由宿主或用户挑；工具是模型控制的，由模型看描述自己调
  • 能不能枚举是最实用的分界线：搜索这类输入空间无限的能力即使只读也做成工具
  • 成本上工具定义每轮都占上下文，资源不被选中就不花钱，大规模知识库必须走资源
  • 控制方决定了出错时找谁负责：模型选错是描述问题，用户选错是命名问题，应用塞错是产品问题