主题
JavaGuide 与小林都讲透了 MCP（二哥无对应专题），对比 JavaGuide《MCP》 与小林《什么是 MCP》《MCP vs FC》《推理模型为什么不支持 MCP》《MCP 通信方式》《SSE vs WebSocket》。
两版对比
定位，两边一致：MCP 是开放协议不是框架，解决的是工具接入的 M×N 碎片化——小林的账最直观：5 个应用 × 8 个工具 = 40 份对接代码，GitHub API 一改字段要 5 处同步改；有了 MCP，Server 写一次、所有 Host 复用。JavaGuide 给的是协议细节：JSON-RPC 2.0、Host/Client/Server 三层角色、Tools/Resources/Prompts 三类能力（工具改变世界、资源观察世界、提示结构化表达）。
MCP 和 Function Calling 什么关系（易错点）：小林的表述最准——MCP 底层靠 FC 驱动：Client 把拉来的工具定义翻译成 FC 格式喂给模型，模型完全感知不到 MCP 的存在；所以「模型不支持 FC，MCP 翻译层就失效」。类比是 FC 像请求格式、MCP 像 REST 规范加服务注册发现。JavaGuide 同向：FC 产意图，MCP 管工具的发现与连接标准化。
传输，小林有独家纠偏：本地 stdio（子进程管道）、远程 Streamable HTTP；关键澄清是 2025-03 的规范弃的是「HTTP+SSE 双端点架构」，不是 SSE 本身——双端点合并成单 /mcp 端点，长请求才升级为 SSE 流，很多资料把这点说反了。
生产化，两边互补：JavaGuide 给了落地检查清单（鉴权、审计、Server 质量参差不能直接信任）；小林给了一个深度问题——推理模型为什么不支持 MCP：思考链要一次性连续生成，工具调用要中途暂停等结果，暂停还想保住 KV Cache 会让显存翻倍、吞吐腰斩，训练目标也冲突（RLHF 奖励「想到底」，FC 要学会打断自己），解法是把工具调用挪到思考结束后。
最优题解
MCP 是一个开放协议，解决工具接入的碎片化：以前 M 个应用接 N 个工具要写 M×N 份胶水代码，MCP 把它变成「Server 写一次，所有 Host 都能用」。结构上三层——Host 是宿主应用，Client 是 Host 里的通信模块（一个 Client 对一个 Server），Server 对外暴露三类能力：Tools 能执行、Resources 能读、Prompts 是模板；协议层是 JSON-RPC 2.0，本地走 stdio、远程走 Streamable HTTP。
它和 Function Calling 不是竞争关系：MCP 底层就是靠 FC 驱动的——Client 把工具定义翻译成 FC 格式喂给模型，模型根本感知不到 MCP，所以不支持 FC 的模型 MCP 就用不了。这也是为什么推理模型长期不支持工具调用：思考链要一口气生成，工具调用要中途暂停等结果，暂停还想保住 KV Cache 显存就翻倍，训练目标也是冲突的；现在的解法是把工具调用挪到思考结束之后。
上生产还要注意：协议统一不等于 Server 可信，工具的鉴权、审计、失败回滚仍然在业务侧，跟 FC 时代一样。
追问链
追问：MCP 的 Tools、Resources、Prompts 为什么分开？ 参考答：三类能力控制权不同——Tools 有副作用要走审批，Resources 是只读可缓存，Prompts 是给用户的模板；分开才能分别做权限和审计。
追问：本地 stdio 和远程 HTTP 怎么选？ 参考答：stdio 延迟低、免认证，适合本机个人工具；远程要考虑鉴权和代理穿透，SSE 在 HTTP/1.1 下有同域连接数上限，长请求走 Streamable HTTP 的单端点按需升级成流。
我的理解
这题的送命回答是把 MCP 说成「模型的新功能」。核心锚点：模型看不见 MCP——它是 Host 和 Server 之间的基础设施层，FC 才是模型那一侧的接口。小林的「40 份对接代码」账和「推理模型范式冲突」是两个能主动展开的加分点；「弃双端点不弃 SSE」这个纠偏能证明读过规范而不是二手转述。