考察点
这道题出自京东和小红书的大模型岗三面，是典型的工程选型题。面试官不关心概念定义（那是初面的事），关心的是你权衡过真实成本：MCP 底层既然还是 Function Calling 驱动，那中间这层协议到底多花了什么、买来什么，以及那个灵魂拷问——工具很少时上 MCP 是不是过度设计。能给出明确的选型分界线和量化视角，就是资深答案。追问常往 gateway 模式、性能优化、迁移路径走。
参考答案
先摆正两者关系：不同层，不是竞品
Function Calling 是模型能力：模型按 schema 输出结构化调用请求，由应用执行。MCP 是接入协议：标准化工具的描述、发现、传输，让任何工具方写一次 server 就能被任何 Agent 应用使用。两者的真实关系是——MCP 的调用链路底层仍然靠 FC 驱动：Host 从 MCP server 拉到工具列表后，把工具 schema 转成模型 API 的 tools 参数，模型用 FC 能力决定调用，Host 再把调用请求翻译成 MCP 消息转发给 server 执行。所以「MCP 还是 FC」不是二选一，是「要不要在 FC 之上加一层标准化协议」。
类比：FC 是函数调用约定，MCP 是 USB 接口标准。没有 USB 你也能焊线连外设，只是每接一个都要手工适配。
MCP 多付出了什么
既然底层都是 FC，上 MCP 的额外成本要说清楚：
- 运行时开销。每个 server 是独立进程（stdio）或远程服务（HTTP），调用多一次进程间或网络往返，延迟增加几毫秒到几十毫秒；server 进程的启动、保活、崩溃恢复都要管。
- 抽象层折损。工具描述从 server 定义经 MCP 传输再转 FC schema，链路长了一截，调试时一个问题要查三段：模型侧、协议侧、server 侧。
- 运维面扩大。server 的版本管理、鉴权配置、监控告警，一个都不能少；server 升级改了工具 schema，宿主侧可能静默劣化。
- 上下文成本。MCP 默认把工具列表全量给 Host，接的 server 多了，光 schema 就吃掉几千上万 token。
买来什么，以及选型分界线
换来的是解耦与复用：工具方独立迭代不用改 Agent 代码；同一批 server 被多个 Agent 应用共享；直接吃生态——GitHub、数据库、浏览器自动化都有现成 server，不用自己写；工具可以动态发现，不用硬编码。
我的选型分界线很直接：
- 工具少于 5 个、全部自研、只服务一个应用——直接写 FC。schema 就在代码里，调用零额外跳数，调试一条链到底。只有 1 个工具时上 MCP 是典型的过度设计：你为一个永远不会换的实现引入了进程管理、协议调试和运维成本，买来的「标准化」没有任何消费者。
- 要接第三方现成 server、工具方是独立团队、同一组工具要喂给多个 Agent 应用——MCP 的价值开始兑现，工具数量越多、团队边界越多，收益越大。
- 中间态（工具不少但都自研）：先把工具执行层抽成独立服务，接口保持简单；等出现第二个消费者或要接外部生态时再包 MCP，迁移成本很低。
团队规模上来后还有一个演进形态值得提：MCP gateway。几十个 server 直连 Host 会变成连接和鉴权地狱，挂一层网关统一做鉴权、限流、工具检索（按需下发 schema 而不是全量注入），Host 只对接网关——这是生产级 MCP 部署的主流答案。
可能的追问
- 已经在用 FC 的系统怎么迁到 MCP？ 答：把现有函数执行层包成 MCP server（schema 原样映射），Host 侧换成 MCP client 拉工具，模型侧完全无感；建议先迁只读工具验证链路，写操作最后迁。
- MCP server 的性能怎么优化？ 答：stdio 模式复用进程别每次拉起；HTTP 模式上连接池和本地缓存；热路径工具可以考虑绕开协议直连，但要接受失去标准化。
- 什么场景就算工具多也不该上 MCP？ 答：延迟极度敏感的在线链路（协议开销不可接受）、工具和应用生命周期强绑定（拆出去反而增加分布式复杂度）、安全合规要求全链路可审计且协议层审计能力还没建起来的时候。