Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D23 MCP and Skills: the Protocol, Server/Client, How It Differs From Function Calling; a Tour of the Claude Agent SDK

• You are about to attach a third-party MCP server in production. What worries you, and what do you check?你要把一个第三方维护的 MCP server 接进生产环境，会担心什么、做哪些检查？

  Common in ChinaCommon overseasDeep dive#mcp#security#operations

  How to reason about it · think before answering

  1. This stacks yesterday's security topic onto today's openness topic, and it discriminates hard: every benefit of MCP rests on the capability being maintained by someone else, and that is also its biggest risk.
  2. First name the new trust assumptions: you put someone else's code into your own process tree, you feed its returned text straight into the model, and you let it add entries to your tool list. Each maps to a class of risk.
  3. Then go through the checks. Execution: the server is a process that runs, so constrain which files it can read, whether it has network access, its timeout and the identity it runs as — the least-privilege and sandbox story from yesterday. Data: treat everything it returns as untrusted input, which is exactly the indirect-injection scenario where instructions hide in a field of a tool result. Tool output is never instructions, and the permission gate must live in your process and fire before the call.
  4. Third, governance, the part most people miss: the tool list can change at runtime — one listChanged notification and a new tool appears. So pin your allowlist by tool name, keep newly appearing tools out of the model's list until a human approves, and pin the server version instead of tracking upstream latest.
  5. Fourth, availability and cost: this is a new external dependency. If it is down your agent silently loses a set of capabilities, so you need timeouts, graceful degradation (tell the model the capability is temporarily unavailable rather than failing the whole turn), and its calls on your observability dashboard.
  6. Expect the follow-up: how do you decide it is worth attaching at all? Back to the three criteria — if only one host uses it and you could implement it yourself, you are taking third-party risk with no matching benefit.

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

  1. 这题是把昨天的安全和今天的开放性叠在一起考，区分度极高：接 MCP 的全部好处，都建立在「能力由别人维护」这一点上，而这一点同时就是它最大的风险。
  2. 第一层想清楚新增了什么信任假设：你把一段别人写的代码放进了自己的进程树，把它返回的文本直接喂给了模型，还允许它往你的工具列表里加条目。这三件事各自对应一类风险。
  3. 第二层逐条给检查项。执行侧：server 是一个会跑起来的进程，要限制它能读哪些文件、能不能联网、超时多久、以什么身份运行，也就是昨天讲的最小权限和沙箱那一套。数据侧：**它的返回结果一律当不可信输入**，这正是昨天间接注入的固定现场——工具返回的备注字段里可以藏指令；所以工具结果不能当指令执行，权限闸门必须在你自己的进程里、在调用之前判。
  4. 第三层是治理，最容易被漏掉：工具列表可以在运行中变化，server 发一条 listChanged 通知就能加一个新工具。所以你的白名单要按工具名固定，新出现的工具默认不进模型的工具列表，要有人点头；server 的版本要锁定，不能跟着上游 latest 漂。
  5. 第四层是可用性与成本：这是一个新的外部依赖，它挂了你的 Agent 就少一批能力，所以要有超时、要有降级（工具不可用时告诉模型「这个能力暂时不可用」而不是整轮失败），要把它的调用计入你的可观测面板。这三条正好复用前面几周讲过的东西。
  6. 可以预期的追问：怎么判断它值不值得接？答案回到那三条判据——如果这个能力只有你一个宿主用，而且你完全可以自己实现，那接一个第三方 server 承担的风险没有对应的收益。

  Key points

  • Three new trust assumptions: their code in your process tree, their text in your model context, their entries in your tool list
  • Execution: least privilege — restrict filesystem and network, set timeouts, run as a low-privilege identity, sandbox where warranted
  • Data: treat every result as untrusted input; tool output is never instructions, and the permission gate must fire in your process before the call
  • Governance: allowlist by tool name so newly appearing tools stay out until approved, and pin the server version rather than tracking latest
  • Availability: treat it as an external dependency with timeouts, graceful degradation and dashboard coverage

  答题要点

  • 三个新增信任假设：别人的代码进了你的进程树、它的返回文本进了模型上下文、它能往你的工具列表里加条目
  • 执行侧按最小权限收紧：限制文件访问与网络、设超时、以低权限身份运行，必要时进沙箱
  • 数据侧一律当不可信输入：工具返回结果不能当指令执行，权限闸门必须在自己的进程里、在调用之前判
  • 治理侧锁死变化面：按工具名做白名单，新出现的工具默认不进模型的工具列表；锁定 server 版本，不跟 latest
  • 可用性侧当外部依赖对待：超时、降级、把它的调用与失败计入可观测面板