面试题库

7 天 MCP：把工具接进任何 Agent

D1 为什么需要一个协议：host / client / server 三角、JSON-RPC 消息与三种原语

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

  国内高频海外高频基础#mcp-basics#architecture

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

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

  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.

  答题要点

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

  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
• MCP 规范为什么规定一个客户端只连一个服务端？多路复用不是更省资源吗？Why does the MCP spec require one client per server instead of multiplexing many servers over one connection?

  国内高频海外高频进阶#architecture#security

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

  1. 这题看着在问性能，其实在问安全边界。只从连接数和资源占用切入的回答会被判为没读过设计原则那一节。
  2. 拆法：先问「共享一条通道之后，谁能看见谁」。规范写死了两条原则——服务端不应该读到整段对话，也不应该看得见别的服务端；一对一是实现这两条最直接的手段。
  3. 举一个具体后果：接一个第三方天气服务端时，一对一隔离让它只能看到你传的城市名；共享通道则可能让它读到你和内部数据库服务端之间的往来，那就是一次数据泄露。
  4. 结论：完整对话历史留在宿主，服务端只拿到这次真正需要的参数；宿主是唯一的安全边界执行者，也是唯一做跨服务端编排的地方。
  5. 代价要主动说：接 N 个服务端就有 N 条连接、N 套生命周期要管，客户端实现的复杂度大头正是在这里，而不是在发报文上。
  6. 可预期的追问：那多个服务端的工具重名怎么办？答案是聚合与消歧是宿主侧的职责，规范建议加服务端标识前缀，并且明确说不要依赖服务端自报的名字，因为它不保证唯一也未经验证。

  How to reason about it · think before answering

  1. It reads like a performance question but is really about security boundaries. Answering only in terms of connection count signals you never read the design principles.
  2. Ask who can see whom once a channel is shared. The spec fixes two principles: servers should not read the whole conversation, and should not see into other servers. One-to-one is the most direct way to enforce both.
  3. Concrete consequence: with isolation, a third-party weather server sees only the city you passed. On a shared channel it could observe traffic between you and an internal database server — a data leak.
  4. Conclusion: full history stays with the host, each server receives only the arguments this call needs, and the host is the single place where boundaries are enforced and cross-server orchestration happens.
  5. State the cost yourself: N servers means N connections and N lifecycles, and that is where most client complexity lives, not in sending messages.
  6. Likely follow-up: how do you handle tool name collisions across servers? Aggregation and disambiguation belong to the host; the spec suggests prefixing with a server identifier and explicitly warns against relying on the server's self-reported name, which is neither unique nor verified.

  答题要点

  • 一对一是安全设计而非性能设计：服务端读不到整段对话，也看不见别的服务端
  • 完整历史留在宿主，服务端只收到本次调用真正需要的参数
  • 跨服务端的聚合、消歧、授权都由宿主统一做，边界只有一处需要加固
  • 代价是连接与生命周期管理，这是客户端实现复杂度的主要来源

  Key points

  • One-to-one is a security decision, not a performance one: servers cannot read the conversation or see peers
  • Full history stays in the host; a server receives only the arguments for the current call
  • Aggregation, disambiguation, and authorization all happen in the host, so there is a single boundary to harden
  • The cost is connection and lifecycle management, which dominates client implementation complexity