MCP 协议：从 M×N 到 M+N
MCP 把「每个应用 × 每个工具」的适配矩阵变成「应用接协议 + 工具接协议」，解决的是 Function Calling 的工具发现与分发问题，不改变模型调用工具的机制。2026-07-28 的无状态改版让 Server 能扛住负载均衡：会话状态从连接里挪到了请求头。
也叫：MCP · Model Context Protocol · MCP Server · 工具发现 · 无状态改版
核心概念：先打比方，再给定义出自 T3-4
比喻：MCP 之于 AI 应用，像 USB-C 之于外设。
这个比喻广为流传，但只对一半，面试里最好补上另一半：USB-C 统一的是物理接口和供电协商，你插上去之后设备能不能用、驱动对不对、有没有恶意固件，接口标准并不负责。MCP 同理——它统一了"工具怎么被发现、怎么被描述、怎么鉴权、怎么传输"，但它不保证工具好不好用，也不天然保证安全。把这层补充说出来，比单纯背比喻高一个层级。
定义：MCP（Model Context Protocol，模型上下文协议） 是一个开放协议，规定 AI 应用如何与外部工具、数据源交互。它由 Anthropic 于 2024 年 11 月提出并开源，现由 Linux Foundation 旗下的项目治理（截至 2026-08）。
它解决的核心问题是集成的组合爆炸：
没有 MCP：M 个客户端 × N 个系统 = M×N 个私有适配器
Claude Desktop ─┬─→ 自研适配器 → Jira
Cursor ─────────┼─→ 自研适配器 → Jira ← 同一个 Jira 集成，写了 M 遍
自研 Agent ─────┴─→ 自研适配器 → Jira
有 MCP：M + N
Claude Desktop ─┐
Cursor ─────────┼─→ [MCP] ─→ Jira MCP Server（只写一次，谁都能接）
自研 Agent ─────┘ GitHub MCP Server
内部 CRM MCP Server和 Function Calling 的关系——这是必考题，一句话说清：
FC 是模型层的能力，MCP 是应用层的协议。两者不是替代关系，是上下游关系。
FC 解决的是"模型怎么表达它想调用什么"（输出结构化调用意向，见 T3-2）；MCP 解决的是"这些工具从哪来、怎么被发现、怎么鉴权、怎么跨进程传输、版本怎么演进"。一次 MCP 工具调用的实际链路是：MCP Server 提供工具清单 → 客户端把清单翻译成模型的 tools 参数 → 模型用 FC 输出调用意向 → 客户端通过 MCP 把调用转发给 Server 执行。FC 依然在链路中央，MCP 换掉的是它两端的管道。
口型、供电协商一次谈妥，插上就通
一根线换掉一堆专用接头 —— 组合爆炸消在这一层
工具怎么被发现、描述、鉴权、传输
开放协议，Anthropic 于 2024 年 11 月提出并开源，现由 Linux Foundation 旗下的项目治理
驱动对不对、固件有没有毒，它不问
外设是别人做的，风险跟着这根线一起进来
工具好不好用、安不安全，都不保证
接第三方 Server = 在你的 Agent 里执行别人写的代码，并让别人写的文字进入模型上下文
以上节选自T3-4 MCP 协议与 2026 无状态改版——从 M×N 到 M+N，再到能扛住负载均衡，读全文能看到前后语境。