先这样答
两者的本质区别是内嵌和独立。Function Calling 的工具内嵌在应用代码里，schema 和调用逻辑跟项目绑死，应用换了就要重写；MCP 的工具是独立进程，对外暴露标准接口，任何支持 MCP 的客户端都能连，工具生命周期和应用解耦，一次实现到处复用。
选型判断就一个问题：这个工具会不会在本应用之外被用到。不会——做 Demo、临时接一两个内部工具、场景一次性，Function Calling 直接写，快且没有额外进程和配置负担。会——跨项目或跨团队复用、工具数量多到散落在各处难管理、或者社区已经有现成的 MCP Server（GitHub、数据库、浏览器这类），直接配置接入比自己手写对接划算得多，这时候 MCP 的标准化投入是值的。
做 Agent 系统的倾向更明确：工具来源多、数量大，手写 Function Calling 的维护成本会随工具数线性涨，MCP 的统一接入和管理是长期更省的路线。反过来，只看「项目规模大」就上 MCP 也不对——大项目工具只在内部用、不复用，硬引入 MCP 只是徒增部署复杂度。
面试官会怎么追问
- 「工具数量多为什么倾向 MCP？」 统一注册和发现机制，工具的增删不用改应用代码；Function Calling 的 schema 散在各处，几十个工具之后版本管理就乱了。
- 「两者能混用吗？」 能且常见：核心私有工具用 Function Calling 内嵌，通用能力（搜索、代码执行）接 MCP Server，一个系统里并存。
- 「MCP 的额外成本是什么？」 独立进程的部署运维、连接管理、以及团队对协议的理解成本；工具少且不复用时这些成本收不回来。
回答的坑
用「项目大小」或「工具多少」单维度判断。规模只是一个因素，复用需求、现成生态、部署环境都要进判断。
把两者说成二选一的竞争关系。实际系统里混用是常态，关键说清各自的适用边界。
同系列的题
—— 本题完 ——