FDE W2D4 学习手册 · MCP 核心
W2 Day4 · B 级（必须掌握，面试高频）· 4h · 学完能讲透"MCP 的 Host/Client/Server 模型、初始化握手、三种原语与安全边界"
本日定位：W2 前三天铺垫了 Function Calling（Day1）、采样与结构化（Day2）、Agent 编排（Day3）。今天进入 MCP（Model Context Protocol）——它是"把工具/数据接给 LLM 的标准协议"，也是 FDE 面试必考。重点在"协议模型 + 初始化握手 + 三种原语 + 安全边界"。
学完能回答：① MCP 的 Host/Client/Server 三层模型、初始化时怎么协商协议版本和能力；② MCP 和 Function Calling 的区别、Tool Annotation 为什么不能当鉴权；③ stdio 与 Streamable HTTP 两种 Transport 的适用场景。
使用方法：通读原理 → 重点看「工程含义」「面试话术」「易错点」→ 做自测清单 → 配合《W2D4 评测题.md》。选中不熟的词可标注（左下★重要 / 右下📌待查）。
一、为什么需要 MCP：从 Function Calling 的痛点说起
Function Calling 解决了"模型能调一个函数"，但它是各家私有的、点对点的：每接一个数据源（保单库、OCR 服务、规则引擎）都要为每个模型写一套适配，N 个模型 × M 个工具 = N×M 集成。MCP 的价值是把"工具/数据提供方"和"模型/应用方"用统一协议解耦：工具按 MCP Server 标准实现一次，任何兼容 MCP 的 Client 都能用。
一句话定位：MCP = "LLM 世界的 USB-C 接口"。Server 暴露能力，Client 消费能力，Host 承载二者。候选人背景是 Java+大数据+医保，可以把 MCP 类比成"给保险系统接数据源做了一套标准 SPI/接口规范"。
工程含义很清楚：MCP 把"工具集成"从 N×M 降到 N+M。对医保场景，保单查询、OCR、特药规则校验各做一个 MCP Server，前端 Agent（Host）按标准协议发现并调用，无需为每个模型重写适配。
MCP 解决的是"工具/数据接入的标准化"问题——Function Calling 是"模型怎么调函数"，MCP 是"工具怎么按统一协议被任何模型调用"。它是 LLM 生态的"USB-C"：Server 实现一次，所有兼容 Client 通用。
① 别把 MCP 当成"比 Function Calling 更强的能力"——它管的是传输与发现的标准，能力本身还是 Tool/Resource/Prompt。② MCP 不是替代模型能力，而是给模型"插上标准化的外接设备"。③ 固定验证版本 2025-11-25，面试被问"最新版本"要能答出来，别随口说 latest。
二、Host / Client / Server 三层模型
2.1 角色定义
| 角色 | 是谁 | 职责 | 医保场景例子 |
|---|
| Host | 承载 LLM 交互的"宿主应用" | 管理会话、UI、把多个 Client 连到模型；负责用户授权与信任决策 | 理赔审核 Agent 应用（如自研 Web 后台） |
| Client | Host 内每个 Server 连接对应的"连接器" | 与单个 Server 维护 1:1 连接、转发请求、处理协议 | 理赔应用里"连接保单 MCP Server"的那个客户端实例 |
| Server | 暴露能力的"服务端" | 实现 Tools/Resources/Prompts，响应 Client 请求 | 保单查询 MCP Server、OCR MCP Server |
2.2 关系
Host（1 个应用） ⇄ 多个 Client（每 Server 一个） ⇄ 多个 Server（每个能力一个）
关键约束：一个 Client 只连一个 Server（1:1）；一个 Host 可有多个 Client；Server 不直接认识 Host，只跟 Client 通信。Host 是"总指挥"，Client 是"翻译官+传声筒"。
Host 是跑模型的应用（如理赔 Agent），Client 是 Host 里连接某一个 Server 的 1:1 通道，Server 是暴露能力的服务。一个 Host 有多个 Client，每个 Client 只连一个 Server。记住"Host 管总、Client 管连、Server 管能力"。
① 别混淆 Host 和 Client：Host 是应用本身（含 UI、会话、权限），Client 是 Host 内部为某个 Server 开的连接对象，不是独立进程。② Server 不直接对 Host 负责，它只跟 Client 说话——所以"信任/授权"问题多在 Host 这一层决策。③ 面试常考"Client 为什么 1:1"：因为连接、会话、能力协商都是按 Server 维度建立的，多路复用会破坏生命周期管理。
三、初始化握手：协议版本协商 + 能力发现
3.1 握手流程
Client 连上 Server 后，第一步必须做 initialize 请求，双方交换元数据，再发 initialized 通知完成握手：
Client → initialize{ protocolVersion, capabilities, clientInfo } → Server
Server → result{ protocolVersion, capabilities, serverInfo }
Client → notifications/initialized
- protocolVersion：双方协商出的协议版本（取 Client 支持、Server 也支持的那一个，固定验证用
2025-11-25）。
- capabilities：各自声明支持的能力（如 Server 声明支持 tools、resources、prompts；Client 声明支持哪些采样/根）。
- clientInfo / serverInfo：名字、版本，用于排障与兼容性。
3.2 版本协商规则
Client 在 initialize 里带上自己支持的最新版本；Server 回自己能支持的最高且 ≤ 客户端请求的版本（按规范取双方交集的最大值）。这是"协商"不是"客户端说了算"——若 Server 太旧不支持该版本，握手失败。
工程上握手失败要快速失败（fail-fast）并给出清晰日志：明确是版本不匹配、能力不支持还是传输层断开。医保生产环境会把支持的协议版本写进配置并做启动自检，避免线上才暴露不兼容。
初始化握手 = "先对暗号再干活"。Client 发 initialize（带自己支持的最高版本+能力），Server 回它能支持的最高版本+能力，最后 Client 回 initialized 通知。协议版本是"协商"出来的交集最大值，不是客户端单方面指定。
① 握手必须先于任何工具调用——没 initialize 就直接 callTool 是协议错误。② 版本协商不是"取 Client 的版本"，是取双方都支持的最高版本；若 Server 版本过低会握手失败。③ 固定验证版本是 2025-11-25，面试要能答出具体版本号，体现你做过功课。
四、Transport：stdio（Local）与 Streamable HTTP（Remote）
4.1 两种标准 Transport
| Transport | 形态 | 适用 | 进程/网络 |
|---|
| stdio | 本地子进程，通过标准输入/输出传 JSON-RPC | Local（同机、同宿主进程内） | 无网络，走本地管道 |
| Streamable HTTP | 基于 HTTP，服务端可 SSE 流式推送 | Remote（跨网络、独立部署的 Server） | 走网络，需考虑认证/TLS |
4.2 关键差异
- stdio：Server 作为 Host 的子进程拉起，通信走 stdin/stdout，无独立网络端口，天然隔离、启动快，适合本地工具（如本地 OCR、本地文件读取）。
- Streamable HTTP：Server 是独立 HTTP 服务，支持普通 POST + 可选 SSE 流；Remote 场景用，能跨越机器，但引入网络、鉴权、会话（Mcp-Session-Id）等复杂度。
选 Transport 看部署：本地工具（保单库本地脚本、本地 OCR）用 stdio，省去网络与鉴权；跨团队/云上的能力（共享规则引擎、远程知识库）用 Streamable HTTP。医保场景里"本地病历解析"用 stdio，"中心化特药目录服务"用 HTTP。
Local 用 stdio（子进程+stdin/stdout，无端口，安全简单）；Remote 用 Streamable HTTP（HTTP+可选 SSE 流，支持跨网络）。选型原则：能本地就本地（stdio），必须跨网络才上 HTTP 并补鉴权。
① 旧版有 SSE Transport，但固定验证版本 2025-11-25 推荐/规范的是 Streamable HTTP，面试别把两者混为一谈。② stdio 不等于"不安全"——它只是没网络面，但 Server 进程本身的权限（能读哪些文件）仍要管控。③ HTTP Transport 必须配合鉴权（见 s11），裸奔上生产是事故。
五、固定验证版本：Protocol Version 2025-11-25
当前固定验证（面试/实现以之为准）的协议版本为 2025-11-25。该版本规范涵盖：初始化与能力协商、stdio 与 Streamable HTTP Transport、Tools/Resources/Prompts 原语、Tool Annotation 字段、Session 生命周期与 Mcp-Session-Id 头。
实现/选型时把协议版本钉死在配置里（如 protocolVersion: "2025-11-25"），并对 Server 返回的版本做校验，避免 Server 悄悄升级导致行为漂移。代码里建议用 SDK 常量而非硬编码字符串。
固定验证版本是 2025-11-25，覆盖 Transport、原语、Tool Annotation、Session 全部内容。面试被问"你按哪个版本实现"，要答具体版本号并知道它包含哪些能力，体现工程严谨。
① 别答"我用最新版"——面试官要的是你验证过的具体版本，2025-11-25 是当前固定验证版。② 不同版本的原语/字段可能不同（如 Tool Annotation 定义），实现时要对齐版本，别跨版本套用。
六、三种原语：Tools / Resources / Prompts
6.1 定义与区别
| 原语 | 谁触发 | 是什么 | 是否带副作用 | 医保例子 |
|---|
| Tools | 模型决定调用 | 可执行的函数（查、算、写） | 通常可写（有副作用） | 保单查询 Tool、OCR Tool、规则校验 Tool |
| Resources | 应用/用户注入上下文 | 可被读取的数据/文档（类似文件、记录） | 只读 | 保单 PDF 文档、特药目录表 |
| Prompts | 用户选择模板 | 预置的提示词模板（带参数） | 只读（生成提示） | "理赔审核"提示词模板 |
6.2 关键区别
- Tools 由模型在推理中自主决定调用（model-controlled），是"行动"。
- Resources 由应用把数据塞进上下文（application-controlled），是"知识/上下文"。
- Prompts 由用户从列表选一个模板（user-controlled），是"可被复用的提问范式"。
医保 Agent 里：Resources 提供"这份保单的原文"和"特药目录"，Tools 让模型"去查这张保单的状态/做 OCR/跑规则"，Prompts 提供"标准理赔审核话术模板"。三者分工明确——数据 vs 行动 vs 模板。
Tools = 模型控制的"动作"（可调、可有副作用）；Resources = 应用控制的"只读数据/上下文"（如保单文档）；Prompts = 用户选择的"提示词模板"。一句话：Tool 做、Resource 给、Prompt 套。
① 别把 Resource 当 Tool 用——Resource 是"读数据进上下文"，Tool 是"执行动作"，语义和权限不同。② 三者控制方不同（model/application/user），这决定了"谁能触发"和"要不要鉴权"。③ 面试常混淆 Tool 与 Resource，要能讲清"查询一个值"该做成 Tool 还是 Resource。
七、Tool Discovery（工具发现）
7.1 机制
握手完成后，Client 通过 tools/list 拉取 Server 暴露的全部工具（含 name、description、inputSchema）；模型据此决定调用哪个，再用 tools/call 执行。
握手完成 → tools/list（拿到全部 Tool 的 schema+描述） → 模型选 Tool → tools/call{ name, arguments }
7.2 输入 Schema
每个 Tool 的 inputSchema 是 JSON Schema，描述参数名、类型、必填、枚举。模型按它填参。发现机制让"Server 加了新工具、Client 无需改代码"成为可能——这是 MCP 解耦的核心红利。
医保场景：保单 Server 上线"历史理赔查询"新 Tool，只要它实现符合 schema，前端 Agent 下次 tools/list 自动发现，无需改 Host 代码。生产上会对 tools/list 结果做缓存+版本号，避免每次请求都拉。
工具发现 = 握手后 Client 调 tools/list 拿到所有 Tool 的 schema 和描述，模型按需选、用 tools/call 调用。好处是 Server 加工具、Client 零改造——这是 MCP"解耦 N×M"的关键。
① 发现的是"schema 和描述"，模型靠 description 判断该不该调——所以 Tool 的 description 写得好不好直接决定调用准确率。② tools/list 有成本，生产要缓存，别每次推理都拉全量。③ 别以为"模型总能选对 Tool"，描述含糊/相似 Tool 多会选错，要做评测。
八、Session 生命周期
8.1 生命周期阶段
- 建立连接：stdio 拉起子进程 / HTTP 建立连接。
- 初始化握手：initialize + initialized（见 s3）。
- 能力使用：tools/list、resources/read、tools/call 等正常交互。
- 会话维护：HTTP 场景下用
Mcp-Session-Id 关联请求（同一会话的状态）。
- 终止：Client 断开 / Server 关闭，释放资源。
8.2 HTTP 会话标识
Streamable HTTP 下，Server 在初始化响应里返回 Mcp-Session-Id，后续请求都要带这个头，否则 Server 不认。这保证了"有状态"交互（同一会话的上下文、已加载的资源）连贯。
工程上会话要设超时与回收：长时间空闲的 MCP 会话要能安全关闭，医保生产环境会对会话数做上限与监控，防止 Server 被大量悬挂会话拖垮。
Session 生命周期：连接 → 握手 → 使用 →（HTTP 下用 Mcp-Session-Id 关联）→ 终止。HTTP 传输靠 Session-Id 保持有状态；生产要做超时回收与连接数监控。
① stdio 没有 Mcp-Session-Id 概念（进程级会话），别把 HTTP 的会话机制套到 stdio。② 会话不释放会泄漏资源，Server 要能处理 Client 异常断开（如子进程被杀）。③ 面试可能问"HTTP 怎么知道同一会话"——答 Mcp-Session-Id 头。
九、Tool Annotation（工具注解）
9.1 是什么
Tool Annotation 是 Tool 定义上的一组元信息提示字段，用来给 Client/模型/UI 提供"这个工具大概是什么性质"的提示，例如：
title / readOnlyHint：是否只读（无副作用）。destructiveHint：是否破坏性（删/覆盖）。idempotentHint：是否幂等（重复调用结果一致）。openWorldHint：是否面向开放世界（如任意 URL）。
9.2 作用
Annotation 帮助UI 决定要不要弹确认框（如 destructive 工具先问用户）、帮助 Host 做展示与风险提示。注意规范明确：这些是提示（hints），不是强制约束。
医保场景：规则校验 Tool 标 readOnlyHint=true（只读、可放心调），而"提交理赔结论"Tool 标 destructiveHint=true（要弹确认）。Annotation 让前端按性质决定交互，提升安全 UX。
Tool Annotation 是工具上的"性质标签"（只读/破坏性/幂等/开放世界），作用是给 UI 和 Host 做提示——比如破坏性工具弹确认框。注意它只是 hint，不是强制约束。
① Annotation 是提示不是保证，Server 完全可以不遵守（比如标了 readOnly 实际去写了库）。② 字段是 hint 语义，名字带 Hint 后缀本身就说明"仅供参考"。③ 别把 Annotation 当成"工具分类的权威来源"，真正的分类要看实现。
十、Tool Annotation 不可作为真实鉴权依据
这是面试高频坑：有人以为"看 Tool 的 readOnlyHint 就能决定要不要鉴权/放不放心调"。错。Annotation 是 Server 自报的提示，客户端不能信任它来做安全决策。
安全决策（能否调用 / 要不要鉴权 / 是否允许写）必须基于 真实权限系统，而非 Tool Annotation
- Annotation 可由 Server 随意填写或遗漏，恶意/有缺陷的 Server 会谎报（标 readOnly 实际删数据）。
- 鉴权（谁能调、能调什么）应落在 Host/Client 的权限策略 + Server 自身的访问控制上，而不是读 Annotation。
- Annotation 只配合作"UX 提示"（是否弹确认），不配合作"安全边界"。
医保生产：是否允许 Agent 调用"提交理赔"工具，由 Host 的权限配置（如当前用户角色、该保单状态）决定，绝不看 Tool 自己填的 hint。即便 Server 标成 readOnly，敏感写操作也要独立鉴权。
Tool Annotation 不能当鉴权依据——它是 Server 自报的提示，可被谎报或漏填。是否允许调用、要不要鉴权，必须靠 Host/Client 的权限策略 + Server 真实访问控制，Annotation 只配合作 UX 提示（弹确认框）。
① 这是核心易错点：把 hint 当安全边界 = 安全漏洞。② 面试若说"看 readOnlyHint 就知道这工具安全"，直接判错。③ 权限决策要"默认拒绝 + 显式授权"，不能"默认信 Annotation"。
十一、OAuth 在 HTTP Transport 中的适用边界
11.1 适用场景
当 MCP 走 Streamable HTTP（Remote Server）时，传输层是标准 HTTP，因此可以套用标准 Web 授权（如 OAuth 2.0 / OIDC）来保护端点：Client 持 token 访问 Server，Server 校验 scope。
11.2 边界与注意
- OAuth 保护的是传输/端点访问，不是"每个 Tool 的细粒度业务授权"。
- stdio（Local）通常不需要 OAuth——它没网络面，靠进程/文件系统权限隔离即可。
- MCP 授权规范把授权放在传输层（HTTP 时用标准 OAuth），但具体 scope 与策略由实现定义。
MCP 授权规范（modelcontextprotocol.io 的 Authorization 章节）明确：Remote Server 应使用标准 Web 授权框架；授权是"谁来连 Server"，细粒度"能否调某 Tool"仍由 Host/Server 策略决定。
医保跨网络场景：中心化"特药目录 MCP 服务"用 HTTP + OAuth，只有持有效 token 的理赔系统能连；但"能否查某客户保单"这种细粒度权限，仍由 Server 内部按用户身份判定，OAuth 只管"门禁"。
OAuth 适用于 Remote/HTTP 的 MCP Server，保护"谁能连端点"（门禁级）。它不替代细粒度业务授权（谁能调某 Tool/查某数据）；Local/stdio 一般无需 OAuth。OAuth 是传输层授权，Tool 级授权另算。
① 别以为"上了 OAuth 就 Tool 级安全了"——OAuth 管端点准入，Tool 级权限是另一层。② 混淆"传输授权"与"业务授权"是常见错误。③ stdio 硬套 OAuth 是过度设计。
十二、MCP Server 来源信任
12.1 信任问题
MCP Server 能执行动作、读数据，所以"这个 Server 从哪来、可不可信"是核心安全议题。Host 在连接前必须评估 Server 来源：官方维护 vs 第三方社区 vs 自建。
12.2 工程做法
- 来源白名单：只允许连接预核准的 Server（域名/包签名）。
- 最小权限：Server 进程只给必要文件系统/网络/数据库权限。
- 人工确认：首次连接陌生 Server 弹确认，展示它将暴露的能力。
- 沙箱：对不可信 Server 放进沙箱/容器，限制它能触达的资源。
- 能力审查：连接后审查 tools/list 暴露的能力，拦截高危工具。
医保场景：连接一个第三方"医保政策爬虫 MCP Server"前，先在 Host 配置里加白名单 + 沙箱运行，限制它只能访问公开政策站点、不能碰内网保单库。不可信 Server 默认不连。
MCP Server 来源信任 = "这个 Server 能不能连"。做法：来源白名单、最小权限、首次确认、沙箱隔离、连接后能力审查。不可信 Server 默认拒绝，别让模型自动连陌生 Server。
① "模型发现一个新 Server 就自动连"是危险设计，必须由 Host 做信任决策。② 别只看 Server 名/描述就信——要验证来源与签名。③ 即使 Server 可信，它暴露的高危 Tool 也要二次审查。
十三、面试达标线①：Host/Client/Server 模型 + 初始化握手
| 考点 | 必须能讲清 |
|---|
| 三层模型 | Host 管总（应用+权限）、Client 是 1:1 连接通道、Server 暴露能力；一个 Host 多 Client，一个 Client 一 Server |
| 初始化握手 | initialize 交换版本+能力 → Server 回版本+能力 → initialized 通知；先握手后调用 |
| 版本协商 | 取双方都支持的最高版本（固定验证 2025-11-25），非客户端单方面指定 |
| 能力发现 | 握手后 tools/list 拉 schema，模型据此调用；加工具 Client 零改造 |
达标线①核心：能画出 Host⇄Client⇄Server 关系，讲清 initialize 握手三步（版本协商+能力发现），并能答出固定验证版本 2025-11-25。这是 MCP 的"地基"，必须滚瓜烂熟。
十四、面试达标线②：MCP vs Function Calling + Annotation 为何不鉴权
14.1 MCP 与 Function Calling 的区别
| 维度 | Function Calling | MCP |
|---|
| 定位 | 模型调函数的能力（单点） | 工具/数据接入的标准协议（生态） |
| 集成 | 每家模型私有，N×M 适配 | 统一协议，Server 一次实现多 Client 通用 |
| 能力 | 通常只有"函数调用" | Tools + Resources + Prompts 三类原语 |
| 发现/传输 | 由应用硬编码 | tools/list 动态发现 + 标准 Transport（stdio/HTTP） |
14.2 Tool Annotation 不能当鉴权
Annotation = Server 自报的提示(hint) → 可被谎报/遗漏 → 不能用于安全边界决策
鉴权必须落在 Host/Client 权限策略 + Server 真实访问控制，Annotation 仅作 UX 提示（如弹确认框）。
达标线②核心：MCP 是"标准协议/生态"（解耦 N×M、三类原语、动态发现），Function Calling 是"模型调函数的能力"。Tool Annotation 只是 hint，恶意 Server 会谎报，所以安全决策绝不能看 Annotation，要靠真实权限系统。
十五、W2D4 自测清单
- 能讲清 MCP 解决什么问题（N×M 集成→N+M），并类比成"LLM 的 USB-C"。
- 能画出 Host / Client / Server 关系，说清各自职责与 1:1 约束。
- 能复述初始化握手三步：initialize → Server 回版本+能力 → initialized。
- 能说出固定验证版本号 2025-11-25，并解释版本协商取"双方支持的最高版本"。
- 能区分 stdio（Local）与 Streamable HTTP（Remote）的适用场景与差异。
- 能讲清 Tools / Resources / Prompts 三类原语及各自控制方（model/application/user）。
- 能解释 Tool Discovery：tools/list 拿 schema，模型用 tools/call 调用，加工具零改造。
- 能说清 Session 生命周期，以及 HTTP 下 Mcp-Session-Id 的作用。
- 能列出 Tool Annotation 的常见字段（readOnly/destructive/idempotent/openWorld）并说明它是 hint。
- 能论证"Tool Annotation 不能作为真实鉴权依据"，并给出正确做法。
- 能讲清 OAuth 在 HTTP Transport 的适用边界（门禁级，非 Tool 级），stdio 一般无需。
- 能说出 MCP Server 来源信任的工程做法（白名单/最小权限/沙箱/能力审查）。
十六、高频面试题速记卡
Q：MCP 和 Function Calling 什么关系？
Function Calling 是"模型调函数的能力"（单点）；MCP 是"工具/数据接入的标准协议"（生态），管传输、发现、三类原语，把 N×M 集成降到 N+M。
Q：Host、Client、Server 分别是什么？
Host=跑模型的应用（管权限/会话）；Client=Host 内连某个 Server 的 1:1 通道；Server=暴露 Tools/Resources/Prompts 的服务。一个 Host 多 Client，一 Client 一 Server。
Q：初始化握手做什么？
Client 发 initialize（带支持的最高版本+能力），Server 回能支持的最高版本+能力，Client 再发 initialized 通知。先握手后调用。
Q：固定验证的协议版本是多少？
2025-11-25，覆盖 Transport、原语、Tool Annotation、Session。面试要报具体版本号。
Q：stdio 和 Streamable HTTP 怎么选？
Local 用 stdio（子进程+stdin/stdout，无端口）；Remote 跨网络用 Streamable HTTP（HTTP+可选 SSE，需鉴权）。
Q：Tools、Resources、Prompts 区别？
Tool=模型控制的动作（可有副作用）；Resource=应用控制的只读数据/上下文；Prompt=用户选的提示词模板。做/给/套。
Q：Tool Annotation 能当鉴权依据吗？
不能。它是 Server 自报的 hint，可被谎报/遗漏。鉴权必须靠 Host/Client 权限策略+Server 真实访问控制。
Q：OAuth 在 MCP 里管什么？
仅管 Remote/HTTP 的端点准入（门禁级）。Tool 级/数据级细粒度授权是另一层，stdio 一般无需 OAuth。
Q：MCP Server 来源不信任会怎样？
恶意/缺陷 Server 可执行危险动作或谎报能力。做法：白名单、最小权限、首次确认、沙箱、连接后能力审查。
Q：HTTP 下怎么保持同一会话？
靠 Mcp-Session-Id 头，Server 初始化时下发，后续请求都带，保证有状态交互连贯。
FDE W2D4 学习手册 · MCP 核心（面试级）· 配合《W2D4 评测题.md》自测
📌 待查★ 重要