「我们该用 Function Calling 还是 MCP？」——这是过去一年开发者社区被问得最多的问题之一，而它其实是个有陷阱的问题：两者不在同一层，不构成二选一。Function Calling 是模型的能力（模型学会了输出结构化的调用请求），MCP 是工具的分发协议（工具怎么被发现、被描述、被任何应用接入）。真正的问题应该是：「我的工具，要不要按 MCP 的方式封装和分发？」
这篇文章先把两个概念放回各自的位置，再按三种典型场景给出明确建议。
Function Calling 解决「模型怎么表达调用意图」，MCP 解决「工具怎么被发现和接入」。
Function Calling：模型输出结构化调用请求
Function Calling / Tool Use 是 2023 年以来各家模型陆续具备的能力：你在 API 请求里声明工具（名称、描述、JSON Schema 参数），模型判断需要时返回一个结构化的调用请求，由你的代码实际执行，再把结果传回模型继续生成。
你声明: search_files(query: string, dir: string)
模型回: { "name": "search_files",
"arguments": { "query": "报销", "dir": "/docs" } }
你执行 → 把结果传回 → 模型基于结果作答关键点：模型从头到尾没有执行任何东西，它只是「填表」。工具的注册、执行、鉴权、错误处理，全部在你的应用代码里。这就带来了它的局限——每个工具都要为每个应用写一遍集成。你给自家应用写的天气查询工具，别人的应用用不了；你想让自己的助手接上 GitHub、Slack、数据库，就要自己写三份集成代码。M 个应用 × N 个工具 = M×N 份胶水代码。
MCP：把工具集成从 M×N 变成 M+N
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月发布的开放协议，随后被 OpenAI、Google 等主要玩家陆续采纳，成为事实上的行业标准。它规定了一套基于 JSON-RPC 的客户端-服务器协议：
- MCP Server：工具的提供方。把「搜索文件」「查数据库」「操作 GitHub」封装成标准接口，声明自己有哪些工具（tools）、资源（resources）、提示模板（prompts）；
- MCP Client / Host：工具的使用方，如 Claude Code、Cursor、各类桌面助手。连接任意 Server，动态发现它的工具列表，注入给模型使用。
于是集成关系从 M×N 变成 M+N：GitHub 官方写一个 MCP Server，所有支持 MCP 的应用直接接入；你的应用支持 MCP Client，就立刻获得整个 Server 生态。这就是「AI 的 USB-C 接口」比喻的含义。
但要看清一层关系：MCP 底层仍然依赖 Function Calling。 Client 从 Server 拿到工具列表后，还是以工具声明的形式交给模型，模型还是通过 Function Calling 表达调用意图，Client 再把请求转发给 Server 执行。MCP 没有取代 Function Calling，而是站在它上面，解决分发和互操作问题。
| 维度 | Function Calling | MCP |
|---|---|---|
| 是什么 | 模型能力 + API 格式 | 工具集成的开放协议 |
| 工具注册 | 写死在应用代码里 | 运行时从 Server 动态发现 |
| 复用性 | 单应用私有 | 一次封装，所有 MCP 应用可用 |
| 依赖关系 | 独立存在 | 底层依赖 Function Calling |
| 额外成本 | 无 | Server 进程/服务、协议层、鉴权配置 |
三种场景，三个答案
场景一：自研应用内部的私有工具 → 直接 Function Calling
你在做一个客服机器人，工具是「查订单」「查物流」，只有这个应用用。直接在代码里声明工具、处理调用就好——引入 MCP 意味着多维护一个 Server 进程和一层协议，换不来任何收益。应用内私有工具，Function Calling 是最短路径。
场景二：想让 Claude Code、Cursor 等现成 AI 应用连上你的系统 → MCP
你没有自己的 Agent，但想让团队在 Claude Code / Cursor 里直接查公司数据库、搜内部文档、操作内部平台。这些应用不会为你的系统写集成，但它们都是 MCP Client——你写一个 MCP Server，它们全都能接。这是目前 MCP 价值最实的场景，具体做法见《从零写一个 MCP Server：文件搜索工具实战》。
场景三：工具要对外分发、或多个内部应用共用 → MCP
你是 SaaS 厂商想让 AI 生态接入你的产品，或者公司内部有五个 AI 应用都要用同一批工具。按 MCP 封装一次，处处可用，还能集中做鉴权、审计和版本管理。反过来，如果你在自研 Agent 平台，让它支持 MCP Client，就能白嫖日益庞大的 Server 生态，而不是自己重写每个集成。
判断标准就一条：这个工具会被多少个应用使用？一个，写死；多个或对外，MCP。
选 MCP 之前要知道的代价
- 运维面扩大：每个 Server 是一个进程（本地 stdio）或一个服务（远程 HTTP），要管部署、版本、可用性；
- 安全面扩大：第三方 Server 相当于给模型装插件，工具描述可能携带提示注入，权限过宽的 Server 会成为事故源——只接可信来源，高风险操作保留人工确认，详见《AI Agent 为什么容易失控》；
- 上下文成本：接入的 Server 多了，几十上百个工具描述会占据大量上下文并干扰模型选择。按任务只挂需要的 Server，或对工具做检索式按需注入；
- 协议在演进：MCP 的鉴权（OAuth）、远程传输（Streamable HTTP）等部分近两年迭代较快，接入时以官方最新规范为准。
MCP 扩大了能力面，也扩大了攻击面：第三方 Server 的信任评估不能省。
适用人群与替代方案
适合正在做工具集成选型的 Agent 开发者和平台团队。还有两条路线值得知道：一是 OpenAPI 描述导入——部分平台支持直接把现有 REST API 的 OpenAPI 文档转成工具声明，已有成熟 API 且只在单平台用时，比写 MCP Server 更快；二是代码执行型 Agent——让模型直接写代码调 SDK/API（如在沙箱里跑 Python），灵活性最高，适合数据分析类场景，但安全边界要求也最高。
常见问题
Q：用了 MCP，模型调用工具会更准吗？ A：不会。调用准确率取决于模型能力和工具描述质量，与分发协议无关。MCP 解决的是「接得上」，不是「调得准」。
Q：MCP Server 必须用 Node/Python 写吗？ A：不。MCP 是语言无关的协议，官方和社区 SDK 覆盖 TypeScript、Python、Java、Go、C# 等主流语言，任何能说 JSON-RPC 的程序都能实现。
Q：先写了 Function Calling 工具，以后迁 MCP 亏吗？ A：不亏。工具的核心逻辑（参数校验、业务执行）完全复用，迁移只是换一层「注册和通信」的壳。合理的做法就是先用 Function Calling 跑通业务，确有复用需求再包成 MCP Server。
小结
一句话结论：Function Calling 是能力，MCP 是接口标准，后者建立在前者之上。私有工具直接 Function Calling；想被现成 AI 应用接入、或工具要跨应用复用，就封装成 MCP Server。别为了赶标准而 MCP 化一切，也别在需要生态互通时还在手写胶水代码。