Interview Bank

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.

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

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. 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.

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

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 most common question in this course. The classic mistake is framing the three as competitors and saying skills are lighter than MCP, when they do not solve the same problem.
2. Lead with the one-line division: MCP handles wiring, Skills handle experience, and function calling is the shortest wire of all.
3. Then name the gaps. Function calling and MCP supply capability: the model cannot reach your database or file a ticket until you give it a tool. Skills supply experience: the model can already write a commit message, it just does not know your format.
4. Give the two most informative contrasts. Context cost: tool definitions are resent every turn, while a skill costs only its name and description per turn with the body loaded on demand. Degradation: tools and protocols are binary, but a skill that fails to install is still readable Markdown, which is exactly why the format spread across dozens of clients. It requires the host to read files, not to implement a protocol.
5. For selection give a runnable decision path. First separate missing capability from missing method. For capability, choose by reuse surface: one application means function calling, several agents justify an MCP server. For method, choose by determinism: instructions go in the skill body, byte-identical results go in a bundled script.
6. Close on composition. The normal case stacks them: an MCP server exposes the ticket system as a tool, and a skill body says to pull this week's tickets with that tool and then group them by a template. Tools give hands, skills give procedure.
7. Expected follow-up: when should you not use MCP? When only one application needs it and there are just two or three actions. Standing up a server is over-engineering.

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

1. 这是本课最高频的一题。答错的典型是把三者摆成竞争关系，说「Skills 比 MCP 更轻量所以更好」——它们解决的根本不是同一个问题。
2. 先给一句能背下来的分工：**MCP 管接线，Skills 管经验**，而函数调用是接线之前那根最短的线。
3. 再落到缺口上。函数调用与 MCP 补的是**能力**：模型本来读不到你的数据库、发不出工单，给它工具它就能了。Skills 补的是**经验**：模型本来就会写提交信息，只是不知道你们这儿的格式。能力的缺口用工具补，经验的缺口用技能补。
4. 然后给两条对比里最有信息量的差异。第一，上下文成本：工具定义每一轮都要重发，而 skill 每轮只有名字与描述，正文按需加载。第二，装不上时的降级：工具与协议是二值的，接不上就没有；**一个 skill 装不上仍然是一份人能读的 Markdown**，这正是它能在几十家客户端铺开的原因——它不要求宿主实现协议，只要求宿主会读文件。
5. 选型给一条能当场走的流程：先分缺能力还是缺做法。缺能力时按复用面选，只有这一个应用要用就写函数调用，多个 Agent 都要用才值得做成 MCP 服务端。缺做法时按确定性选，靠指令说清楚就写进 skill 正文，结果必须逐字一致就配脚本。
6. 最后一定要说配合。三者常态是叠着用：MCP 服务端把工单系统接进来成为工具，skill 的正文里写「先用工单查询工具拉出本周工单，再按这份模板归类」。**工具给它手，skill 给它章法。**
7. 可预期的追问是「那什么时候不该用 MCP」。答案是只有一个应用要用、动作又只有两三个的时候——为它起一个服务端是过度设计，直接写函数调用更短。