模块 06 — 考试题型（Exam Style）

题干中文、考试术语保持英文。答案与逐项解析在文件末尾「答案与解析」独立小节。 场景题 S1–S3 均为 MCP vs 直接 API 集成 (direct API integration) 决策题。

单选题

1. 在 MCP 架构中，与恰好一个 server 通信、并维持 server 间隔离边界的角色是：

A. Host B. Client C. Server D. Authorization Server

1. 三大 server 原语中，被设计为 model-controlled（由模型自主发现并调用）的是：

A. Resources B. Prompts C. Tools D. Elicitation

1. 关于 Prompts 原语，正确的说法是：

A. prompt 的内容由用户编写，server 只负责透传 B. user-controlled 指由用户决定何时使用，内容由 server 定义 C. prompts 只能由模型在推理中自动触发 D. prompts/get 的渲染结果直接发给 server 执行

1. 截至 2026-08-30，MCP 规范（revision 2026-07-28）定义的两种标准 Transport 是：

A. WebSocket 与 gRPC B. stdio 与 Streamable HTTP C. HTTP+SSE 与 stdio D. AMQP 与 Streamable HTTP

1. Streamable HTTP 传输中，客户端发送每条 JSON-RPC 消息的方式是：

A. 建立长连接后在双向流里多路复用 B. 每条消息一个 HTTP POST，服务端以单个 JSON 或请求级 SSE 流应答 C. 每条消息一个 HTTP GET，通过 query 参数编码 D. WebSocket 帧推送

1. Modern 规范（2026-07-28+）中，协议版本与客户端能力如何传递？

A. 连接建立时通过一次 initialize 握手锁定 B. 每个请求的 _meta 字段携带，server 逐请求独立接受或拒绝 C. 由 Authorization Server 在 token 里签发 D. 写死在 TLS 会话票据里

1. 官方 Client Best Practices 中，何时应从全量注入工具定义切换到 progressive discovery？

A. 只要连接了超过 1 个 MCP server B. 工具定义占到上下文窗口的显著部分，建议阈值约为 1%–5% C. 工具总数超过 5 个 D. 出现第一次 tool 调用失败

1. Anthropic 的 tool search tool（tool_search_tool_regex_20251119 / tool_search_tool_bm25_20251119）的正确用法是：

A. 把所有工具定义移出 tools 数组，只传一个搜索工具 B. 全部定义照常放 tools，对不需预载的工具标 defer_loading: true，由 Claude 按需检索加载 C. 在 MCP server 端实现 BM25 索引 D. 用第二个小模型在客户端做工具路由

1. tools/call 返回结果中 isError: true 表示：

A. 传输层断开，需要重建连接 B. JSON-RPC 协议错误，请求未被受理 C. 工具执行的业务错误：错误文本在 content 里，模型可读并可据此修正重试 D. server 不支持该工具所属的 capability

1. 关于 MCP 的 Authorization，符合规范的做法是：

A. 所有传输统一走 OAuth 2.1 授权码流程 B. HTTP 传输实现 OAuth 2.1（server 作为 resource server）；stdio 传输从环境取凭证、不应走该流程 C. stdio 子进程用 token passthrough 复用 host 的凭证 D. Authorization 对所有实现是强制项

1. 下列哪项是规范明文禁止或点名的反模式？

A. server 按确定性顺序返回 tools/list 结果以提升 prompt cache 命中 B. Token passthrough：server 把 client 的上游 token 原样转发给下游 API C. host 只注入任务相关的工具定义 D. 本地 HTTP server 校验 Origin 头

1. Anthropic MCP connector（beta header mcp-client-2025-11-20）的能力边界是：

A. 完整 MCP client：支持远程与 stdio server 的 tools/resources/prompts B. 仅支持公网 HTTP server 的工具调用（不支持 stdio、resources、prompts），无需自建 MCP client C. 需要自己实现 SSE 解析与 OAuth 流程 D. 只能连接 modelcontextprotocol.io 官方示例 server

场景决策题（MCP vs 直接 API 集成）

S1. 创业公司客服助手

Scenario：5 人创业公司给客服团队做 Claude 助手，需要查订单（自家 REST API，2 个工具）、查物流（第三方物流商 REST API，1 个工具）。调用模式固定：用户问「我的订单到哪了」→ 查订单 → 查物流。公司没有其他 AI 应用计划，延迟要求普通（秒级可接受）。 Constraints：工程人力极少；工具总数 3 个；单应用消费；无复用计划。 Options： A. 为订单和物流各建一个 MCP server，走标准发现 B. 直接 API 集成：在应用内定义 3 个 Claude API tools（模块 04 模式），后端直调 REST C. 用 Anthropic MCP connector 连自建公网 MCP server

Best choice：B Why：工具少（3 个）、单消费方、调用模式固定——MCP 的三大收益（标准化发现、多 host 复用、生态 server）一项都用不上；直接 API 集成零协议层、零额外部署，是官方 Client Best Practices 也承认的「少量工具全量注入完全合理」场景。 Why others are weaker：A 为 3 个工具引入 server 开发、进程运维与协议调试，纯开销；C 还要求把内部 API 暴露成公网 server（connector 不支持 stdio），反而扩大攻击面。 Tradeoffs：B 的代价是若未来出现第二个消费方（如内部运营用 Claude Code 查订单），要重做集成；A 的代价是当下每一步都更慢更复杂。 What would change the answer：公司宣布要做平台化（多个 agent/工具复用同一批集成）、或工具数涨到几十个、或直接采用生态现成 MCP server（如 Stripe 官方 server）——转向 A/C。

S2. 集团级 AI 平台

Scenario：大型集团的 AI 平台团队要为全集团 40+ 个内部应用提供「AI 能力接入网关」。首批接入：Jira、Confluence（两者官方/生态有现成 MCP server）、集团 CRM（老旧 SOAP 接口，需封装）、数据仓库（只读查询）。预计最终工具总量 300+，各应用的权限范围不同（财务可见薪酬数据域、普通业务不可见）。 Constraints：多消费方（40+ 应用，含 Claude Code / 自研 agent）；工具规模大；per-app 权限；平台团队有 server 运维能力；合规要求全链路审计。 Options： A. 每个应用自己直连各系统 API，平台只发凭证 B. 平台统一建设 MCP server 群（封装 SOAP CRM 等），配 tool search / progressive discovery 与基于授权的工具过滤 C. 全部走 Anthropic MCP connector，各应用在请求里带 mcp_servers 直连

Best choice：B Why：MCP 的全部适用条件齐备——多 host 复用（一次封装 40 处消费）、工具 300+（必须 progressive discovery 治理上下文）、per-app 权限（规范明确允许工具集随请求授权不同：只返回调用者 scope 允许的工具）、审计可在 server 层集中落地。 Why others are weaker：A 是 40×N 的重复集成，且权限与审计无法集中治理；C 让每个应用自己管理 server 连接与授权，权限边界散落各处，且 connector 仅支持工具调用，SOAP 封装等复杂治理仍无处安放。 Tradeoffs：B 是重基建路线：平台团队长期维护 server 群、要做 Origin/OAuth 治理、防 token passthrough 与 confused deputy；上线周期长。C 的优点（零 client 编排）可以在平台统一暴露 HTTP server 后，由轻量应用叠加使用——两者可组合。 What would change the answer：若集团收缩到 2–3 个消费应用且工具 <20，A（直连）重新成立；若安全团队禁止任何 server 端集中凭证，则退回 A 并接受重复建设。

S3. 实时风控辅助

Scenario：支付公司的 Claude 风控辅助应用：模型在分析可疑交易时需要调用内部风控引擎 API（单工具、P99 < 80ms、已有熔断/限流/重试基建），以及查询历史案例库（只读、慢、结果大，适合摘要后进上下文）。 Constraints：风控调用延迟预算极紧；案例库调用低频；两者都只被这个应用消费；风控团队明确拒绝把引擎暴露成公网 HTTP 服务。 Options： A. 两个能力都 MCP 化（风控引擎、案例库各一个 server） B. 风控引擎直接 API 集成（应用内 tool + 既有可靠性基建），案例库也直接集成但结果走摘要管线 C. 风控引擎直连，案例库做成 MCP server 供未来复用

Best choice：B Why：单消费方 + 固定调用模式 + 延迟关键 + 禁止公网暴露——风控引擎四条全部命中「直接 API 集成」判据，MCP 层只会加跳数与故障面；案例库同样单消费方，直连 + 摘要管线（控制进入上下文的大小）最省；工具总共 2 个，无任何发现/复用诉求。 Why others are weaker：A 给 80ms 预算的路径加协议封装，且公网暴露被风控团队否决（stdio 本地子进程形态在生产服务里也引入部署复杂度）；C 为「未来复用」这个尚未兑现的诉求提前付出 server 建设，属投机性架构（YAGNI）。 Tradeoffs：B 放弃了标准化与未来复用的可能性——如果案例库后来要给合规团队用，需重做集成；但这个代价比现在过度设计低得多。 What would change the answer：出现第二个消费方（如反洗钱团队要查案例库）→ 案例库值得 MCP 化（C）；风控引擎若开始提供探索式多工具查询（模型需要动态发现参数组合）→ 重新评估 A。

答案与解析

每题给出：正确答案 · 逐项解析（为什么对/为什么错）· 考什么。

单选题答案

1. B

• A 错：Host 是宿主应用，创建并管理多个 client，不亲自与 server 通信
• B 对：Client 由 host 创建，与恰好一个 server 通信（1:1），并维持 server 间隔离边界
• C 错：Server 是被连接方，暴露原语
• D 错：Authorization Server 是 OAuth 2.1 概念，不属于 MCP 三方架构
• 考什么：三方架构角色划分（Architecture 页）

2. C

• A 错：Resources 是 application-driven（host 决定取用）
• B 错：Prompts 是 user-controlled（用户显式选择）
• C 对：Tools 是 model-controlled，模型自主发现与调用
• D 错：Elicitation 是客户端提供给 server 的能力，不是 server 原语
• 考什么：三大原语的控制方——MCP 最高频考点

3. B

• A 错：prompt 内容由 server 定义，不是用户编写
• B 对：官方原文「user-controlled 指谁决定何时使用，不指谁编写内容」
• C 错：prompts 设想为用户触发的斜杠命令，不是模型自动触发
• D 错：渲染结果并入对话，由 host 处理，不「发给 server 执行」
• 考什么：user-controlled 的精确含义（规范 Prompts 页）

4. B

• A 错：WebSocket/gRPC 不是标准传输（自定义传输可以自建，但非标准）
• B 对：stdio 与 Streamable HTTP 是 2026-07-28 规范的两种标准绑定
• C 错：HTTP+SSE 是 2024-11-05 的旧传输，已被 Streamable HTTP 取代
• D 错：AMQP 不存在于此规范
• 考什么：标准传输清单 + 旧传输淘汰史

5. B

• A 错：没有长连接多路复用；2026-07-28 版还删除了协议级会话
• B 对：每条消息一个 POST；响应是单个 JSON 或该请求作用域的 SSE 流
• C 错：GET 不用于发消息
• D 错：不是 WebSocket
• 考什么：Streamable HTTP 消息机制（Transport 页）

6. B

• A 错：initialize 握手是 Legacy（≤2025-11-25）时代机制
• B 对：Modern 规范无握手，每请求 _meta 携带版本与 clientCapabilities，server 逐请求接受或以 UnsupportedProtocolVersionError 拒绝
• C 错：与 Authorization Server 无关
• D 错：与 TLS 无关
• 考什么：Modern vs Legacy 版本差异（Versioning 页）

7. B

• A 错：server 数量不是判据，工具定义占窗口比例才是
• B 对：官方建议实现「窗口百分比阈值」切换，示例给 1%–5%
• C 错：官方明确「少量工具全量注入完全合理」
• D 错：与调用成败无关
• 考什么：progressive discovery 的切换阈值（Client Best Practices）

8. B

• A 错：定义仍需全部提交给 API，只是不预载
• B 对：全部放 tools + defer_loading: true，Claude 用 tool search 按需加载（regex/BM25 两变体）
• C 错：那是 host 自建 progressive discovery 的做法，不是原生 tool search
• D 错：subagent 选工具是自建 discovery 的策略之一，与原生 tool search 无关
• 考什么：原生 tool search 与自建方案的区别（Tool search tool 文档）

9. C

• A 错：传输未断，isError 是正常返回的结果
• B 错：JSON-RPC 协议错误走 error 对象；isError 是 result 内的业务错误标志
• C 对：业务错误进 content，模型可读、可据修复线索自我修正（对应示例 02 的 ToolError 回路）
• D 错：capability 不匹配是协议层错误
• 考什么：工具错误语义 vs 协议错误（Tools 页 + 模块 04 回路）

10. B

• A 错：规范按传输区分，不是一刀切
• B 对：HTTP 传输应实现 OAuth 2.1 子集（server=resource server）；stdio 应从环境取凭证、不应走该流程
• C 错：token passthrough 是被禁止的反模式
• D 错：Authorization 是 OPTIONAL
• 考什么：按传输区分的授权模型（Authorization 页）

11. B

• A 对的但非反模式——确定性顺序是官方 SHOULD 建议（利于缓存），故本项不是答案
• B 是答案：token passthrough 被授权规范明文禁止（绕过 audience 控制与审计）
• C 错：只注入相关定义正是 progressive discovery 的精神
• D 错：Origin 校验是 Streamable HTTP 的 MUST，是正解不是反模式
• 考什么：安全正反模式的区分（Security Best Practices）

12. B

• A 错：不支持 stdio、resources、prompts
• B 对：connector = Messages API 内置 MCP client；仅远程 HTTP server 的工具调用
• C 错：connector 的意义恰是免自建 client
• D 错：任何公网 MCP server 都可连
• 考什么：MCP connector 能力边界（platform.claude.com 文档）

场景题要点回顾

• S1（5 人创业，3 工具，单消费）：选直接 API。MCP 三大收益（标准化发现/复用/生态）全用不上；答案改变的触发器是「第二个消费方或工具规模增长」
• S2（集团平台，300+ 工具，40+ 应用）：选统一 MCP server 群。多 host 复用 + 规模治理（tool search）+ per-app scope（规范允许工具集随请求授权不同）+ 集中审计；connector 可作为轻量应用的叠加消费方式
• S3（延迟关键风控 + 单消费）：选直接 API（含案例库）。延迟预算、既有可靠性基建、禁止公网暴露、无复用诉求四条全命中直连判据；案例库「未来复用」属投机性架构（YAGNI）
• 三题共同的答题框架：消费方数量 → 工具规模 → 延迟/控制要求 → 复用与生态 → 安全/合规边界，逐项过决策表（README §7）