考察点
小红书、京东三面都问过这道，属于选型题，面试官想看你能不能把两者放回正确的层次，而不是当成二选一的竞品。追问很尖锐：「既然 MCP 底层还是用 FC，那多付出了什么」「只有一个工具也值得上 MCP 吗」。
参考答案
两者不在同一层
Function Calling 是模型能力层的概念：模型按 schema 输出调用意图，解决的是「模型怎么表达想用工具」。MCP 是应用接入层的协议：规定工具能力怎么被发现、怎么被调用、连接和权限怎么管，解决的是「工具怎么标准化地接入任意 Agent 应用」。
关键事实是：MCP 链路里模型那一跳仍然走 FC。MCP Client 拿到 Server 上报的工具列表后，转成模型的 tools 参数发过去，模型输出的还是标准 tool_calls。所以「MCP 取代 FC」是个伪命题，它们是管道和阀门的关系，不是两个阀门。
区别对照
| 维度 | Function Calling | MCP |
|---|---|---|
| 层次 | 模型 API 能力 | 应用层开放协议 |
| 解决什么 | 模型输出结构化调用意图 | 工具发现、接入、生命周期标准化 |
| 工具定义在哪 | 你的应用代码里 | 独立的 Server 进程/服务 |
| 复用性 | 绑定当前应用 | 一次开发，任意 Host 接入 |
| 额外成本 | 几乎为零 | 多一层进程/网络开销和协议栈维护 |
MCP 多付出了什么
面试官追问的就是这张表的最后两行。代价有三：一是链路变长，本地 stdio 至少多一次进程间通信，远程 Server 多一次网络往返，延迟增加几十到几百毫秒；二是运维面扩大，每个 Server 是要部署、监控、升级的独立单元；三是协议栈依赖，SDK 和协议版本要跟进，能力协商、错误码这些概念都进了你的排障清单。
选型判断
我的判断框架：
- 工具少（1-3 个）、只服务单一应用：直接写 FC。一个查天气的工具也上 MCP，是把简单问题复杂化，协议开销换来的复用性你根本用不上。
- 工具多（5 个以上）或跨应用复用：上 MCP。给团队接 10 个外部工具这个经典场景，用 FC 意味着每个应用重复写 10 份 schema 和调用代码，工具方改了接口要改 N 处；用 MCP，工具方维护自己的 Server，应用侧零改动接入，这是 M×N 问题变 M+N 问题。
- 工具提供方和消费方是不同团队：强烈倾向 MCP，协议就是跨团队的契约，省掉大量对齐成本。
一句话收口：FC 是必选的地基，MCP 是可选的脚手架，工具规模和协作边界决定要不要搭。
可能的追问
- 接了 MCP 之后模型侧代码要改吗？ 基本不用，还是 tools 参数进、tool_calls 出。变化集中在工具发现和执行路由这一层，原来直接调本地函数，现在路由到对应 Client。
- MCP 有什么明显的坑？ 远程 Server 的鉴权和网络稳定性；Server 上报的工具数量太多会膨胀上下文；协议本身年轻，能力（如流式、状态管理）还在演进，版本兼容要留意。
- 未来 MCP 会内化进模型 API 吗？ 已经有厂商在 API 里直接支持传 MCP Server 地址，由平台代为连接和调用，这印证了 FC 是地基、MCP 在其上的分层判断。