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
  • 判据是「这个能力要不要给第二个程序用」，只要答案是要，协议的成本就摊得开