面试题库

30 天从前端工程师到 Agent 工程师

D23 MCP 与 Skills：协议、server/client、与 function calling 区别；Claude Agent SDK 一览

• MCP 里 server 和 client 分别承担什么角色？server 能暴露哪几类东西，传输方式有哪些？What roles do the MCP server and client play, what can a server expose, and which transports exist?

  国内高频海外高频进阶#mcp#protocol#transport

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

  1. 这题看着是背概念，实际区分度在两个小地方：一是能不能把宿主和 client 分开说，二是知不知道 tools 之外还有别的原语。只答「server 提供工具、client 调用工具」是及格线以下。
  2. 先把三个角色摆清楚：server 是能力提供方，一个独立进程；client 是宿主里负责跟某一个 server 说话的那一小块，一个 client 只连一个 server；宿主是你的 Agent 应用，它同时持有多个 client。很多人把宿主和 client 当成一个东西，一问「连三个 server 怎么办」就露馅。
  3. server 侧三种原语要一起说，并且要说清谁来选：tools 是可执行的动作，由模型来挑；resources 是按 URI 读的只读数据；prompts 是可复用的提示词模板，后两者通常由用户或宿主来挑。这句「谁来选」比原语名字本身更能体现你真读过协议——把一份大文档做成 resource 而不是 tool，等于把花不花这笔 token 的决定权从模型手里收回给人。
  4. client 侧也能声明能力让 server 反过来请求宿主：sampling 是让宿主跑一次模型补全，roots 是告诉 server 哪些目录可见，elicitation 是请宿主向用户要一条输入。知道有这三样、不展开，分寸刚好。
  5. 传输两种：stdio 用于本地子进程，Streamable HTTP 用于远程。这里有个时间戳式的加分点——旧的 HTTP 加 SSE 双端点传输已经被标为 legacy，只为兼容老客户端保留；把它当现行方案讲，等于告诉对方你看的是去年的文章。
  6. 可以预期的追问：stdio server 有什么特别要注意的？答 stdout 被 JSON-RPC 独占，所有日志必须走 stderr，否则 client 会收到解析不了的消息；另外子进程的生命周期归宿主管，退出时要杀掉，不然留一堆孤儿进程。

  How to reason about it · think before answering

  1. This looks like recall, but it discriminates on two small things: whether you separate host from client, and whether you know there are primitives beyond tools. 'Server provides tools, client calls them' is below the bar.
  2. Lay out three roles: the server is the capability provider and its own process; the client is the piece inside the host that talks to exactly one server; the host is your agent application, holding several clients at once. People who conflate host and client fall apart the moment you ask how they would connect to three servers.
  3. Cover all three server-side primitives and say who chooses each: tools are executable actions chosen by the model; resources are read-only data addressed by URI; prompts are reusable templates — the latter two are normally chosen by the user or host. That 'who chooses' framing shows you actually read the spec: modelling a large document as a resource rather than a tool moves the decision to spend those tokens from the model back to a human.
  4. The client side declares capabilities too, letting the server call back into the host: sampling asks the host to run a model completion, roots tells the server which directories are visible, elicitation asks the host to collect user input. Naming them without elaborating is the right level of detail.
  5. Two transports: stdio for a local subprocess, Streamable HTTP for remote. The dated detail worth knowing is that the older two-endpoint HTTP+SSE transport is now legacy, kept only for backwards compatibility — presenting it as current signals you read last year's blog posts.
  6. Expect the follow-up: anything special about stdio servers? Stdout is reserved for JSON-RPC, so every log line must go to stderr or the client receives unparseable messages; and the host owns the subprocess lifecycle, so it must reap the child on exit or leave orphans behind.

  答题要点

  • server 是能力提供方（独立进程），client 是宿主里连接单个 server 的那一块，宿主可以同时持有多个 client
  • server 侧三种原语：tools 由模型挑，resources 是按 URI 读的只读数据，prompts 是可复用模板，后两者通常由人来挑
  • client 侧还能声明 sampling、roots、elicitation，让 server 反过来请求宿主做事
  • 传输两种：stdio（本地子进程）与 Streamable HTTP（远程）；旧的 HTTP 加 SSE 已是 legacy，不要当现行方案讲
  • stdio server 的 stdout 被 JSON-RPC 独占，日志必须走 stderr；子进程生命周期由宿主负责回收

  Key points

  • The server is the capability provider in its own process; a client connects to exactly one server; the host holds many clients
  • Three server-side primitives: tools chosen by the model, resources as URI-addressed read-only data, prompts as reusable templates — the latter two usually chosen by a human
  • Clients can declare sampling, roots and elicitation so the server can call back into the host
  • Two transports: stdio for local subprocesses and Streamable HTTP for remote; the old HTTP+SSE transport is legacy
  • On stdio, stdout belongs to JSON-RPC so logs must go to stderr, and the host must reap the child process
• 什么场景下应该考虑用 MCP，而不是直接写 function calling？不该用的时候硬上会付出什么代价？When should you reach for MCP instead of plain function calling, and what does it cost when you shouldn't?

  国内高频海外高频进阶#mcp#architecture#trade-offs

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

  1. 题眼在后半句。只会说「MCP 更标准更解耦」的人，等于说「微服务更解耦」——听起来对，但没有判据，面试官会立刻追问「那你们所有工具都做成 MCP server 了吗」。
  2. 先给判据，而且要是可执行的三条：能力要被多个宿主复用、能力由另一个团队或第三方维护、需要不改宿主代码就能增删能力。命中任意一条才考虑，**一条都不命中就直接写本地函数**——把默认答案摆成「不上」，这条比三条判据本身更能体现工程判断。
  3. 每条判据配一句为什么：多宿主复用把 N 乘 M 变成 N 加 M；别人维护时进程边界就是责任边界，他们改他们的、你不用发版；热插拔让加一个内部工具从一次发布降级成一次配置变更。
  4. 然后老实说代价，这是区分「用过」和「读过」的地方：多一个进程要保活、多一次握手要处理超时与重连、排障链路从一段变三段——工具没被调用，现在可能是模型没选、可能是 schema 翻译时丢了字段、也可能是 server 压根没起来。stdio 的子进程还要你自己回收，否则留孤儿进程。
  5. 还有一条容易被忽略但很加分：MCP 不改变你的成本结构。工具描述照样每轮都进上下文，工具多了照样会让模型选错——D5 那条「工具超过一定数量就该合并描述」在接了 MCP 之后一字不变，甚至更需要，因为现在别人可以往你的工具列表里塞东西。
  6. 可以预期的追问：那内部工具一律不上 MCP 吗？不是。有一类值得例外——你希望它能被 IDE 里的助手和运维机器人一起用，那第一条判据就命中了，即使它是你自己维护的。

  How to reason about it · think before answering

  1. The hinge is the second half. Answering only 'MCP is more standard and decoupled' is like saying 'microservices are more decoupled' — true-sounding but with no criterion, and the interviewer will immediately ask whether you turned every tool into an MCP server.
  2. Give three actionable criteria: the capability must be reused by more than one host, owned by another team or a third party, or added and removed without changing host code. Any one of them justifies MCP; none of them means write a local function. Making 'no' the default answer shows more engineering judgment than the criteria themselves.
  3. Attach a reason to each: multi-host reuse turns N times M into N plus M; external ownership makes the process boundary the responsibility boundary, so their change is not your release; hot-swapping demotes adding an internal tool from a deployment to a config change.
  4. Then state the costs honestly, which is where shipped experience shows: another process to keep alive, another handshake with its own timeouts and reconnects, and a debugging path that went from one hop to three — a tool that never got called might mean the model did not pick it, the schema lost fields in translation, or the server never started. On stdio you also own reaping the child process.
  5. One more point that is easy to miss and scores well: MCP does not change your cost structure. Tool descriptions still enter the context every turn, and more tools still degrade tool selection. The rule that you should consolidate tools past a certain count survives MCP unchanged — arguably it matters more, because now other people can add entries to your tool list.
  6. Expect the follow-up: so internal tools never go through MCP? Not quite. If you want the same capability available to an IDE assistant and an ops bot as well, the first criterion is met even though you own the code.

  答题要点

  • 三条判据，命中任意一条才考虑 MCP：多宿主复用、由他人维护、需要不改代码增删能力
  • 默认答案是不上：三条都不命中就直接写本地函数，这是更好的工程决策
  • 代价是多一个进程要保活、多一次握手要处理超时、排障从一段链路变成三段
  • MCP 不改变成本结构：工具描述照样每轮进上下文，工具过多照样会让模型选错，该合并还是要合并
  • 第三方能力接进来之后，工具列表不再完全由你掌控，这本身就是需要设计的一件事

  Key points

  • Three criteria, any one justifies MCP: reuse across hosts, ownership by another team, or add/remove without touching host code
  • The default is no — if none of the three apply, a local function is the better engineering decision
  • Costs: another process to supervise, another handshake with timeouts, and a debug path that grows from one hop to three
  • MCP does not change your cost structure: descriptions still enter context every turn and too many tools still hurt selection
  • Once third-party capabilities are attached, your tool list is no longer fully under your control, which is itself a design problem