大模型 function call 和 MCP 怎么分工，第一次上手最容易卡在选型上

搜「大模型 function call mcp」的人多半卡在同一处：手里有一批 HTTP 接口，想让模型自己调，结果不知道该把功夫花在写 tools 定义上，还是去搭一个 MCP server。这篇不铺概念，先把两者的边界摆正，再给一套能照着走的判断顺序和落地动作。

搜「大模型 function call mcp」的人，卡点大多不在概念，而在动手那一刻：手里攒了一堆 HTTP 接口，想让模型自己挑着调，结果站在岔路口不知道该往哪边走——是把功夫花在写 tools 定义上，还是先去搭一个 MCP server。这事儿看着像选型，其实是想清楚了就能少走半年弯路。

这篇不铺概念，先把两者的边界摆正，再给一套能照着走的判断顺序和落地动作。结尾会点几个真正让人返工的细节，都是实际写代码时容易踩的，不是文档里抄来的。至于哪家模型工具调用稳不稳，这种要看数字的，去站内榜单核对当时的结论，本文不给死结论。

先分清谁在干活：一个是协议位，一个是消息位

function call 解决的是「模型怎么把话说成一次调用」。说白了就是请求体里多一段工具声明，模型回你一段结构化参数。它不管工具从哪来，也不管谁维护，只负责把自然语言翻成「调哪个、带什么参数」。

MCP 解决的是另一件事：工具从哪来、怎么被别人复用。它是一个进程间约定，把工具、资源、提示词按统一方式暴露给客户端。所以两者压根不是替代关系，MCP server 最终还是得靠模型侧的 function call 能力把参数吐出来，缺哪边都跑不通。

一句话对照：function call 是嘴，MCP 是插座。嘴决定能不能把话说清楚，插座决定电从哪儿来。

function call

请求里声明工具，响应里拿到结构化参数，负责「怎么调」

MCP

把工具和资源按统一约定暴露出去，负责「工具从哪来、给谁用」

两者关系

MCP server 的工具最终仍由模型侧 function call 触发，属于上下游而非二选一

判断顺序：先问工具有几个，再问谁来用

选型别一上来就问技术先进性，先问两个很土的问题：手上到底有几个工具？这些工具将来给谁用？答案不同，路就完全不同。

这里有个不适用的情况得说清楚：如果工具需要强事务、多步确认、对返回结果做后处理，别指望模型侧直接串起来。中间得自己加编排层，把状态管住。模型负责选工具和填参数，事务边界和回滚这类事它兜不住。

• 工具有几个，先数清楚，别边写边加
• 只自己用还是给别人用，这个答案决定要不要封装
• 有没有写操作，写操作多的先把编排层想明白
• 需不需要多步确认，需要的话别让模型一条链跑到底

真正让人返工的几个细节

第一坑在工具描述。描述写得太简，模型挑错工具的概率立刻上来。别只写参数含义，要写清什么时候该用、什么时候别用。我见过一个团队三个工具描述几乎一样，模型每次都挑第一个，排查了半天以为是模型能力问题。

第二坑在参数 schema。偷懒全用自由字符串，模型就会给你塞一句自然语言回来。枚举、必填、格式约束该写死就写死，校验放在模型之外再兜一层。

第三坑在 MCP 的接入。server 跑在本地就以为万事大吉，传输方式和启动命令配错是最常见的接不上原因。先怀疑路径和权限，再怀疑协议本身，这个顺序能省不少时间。

1. 先把工具描述补齐每个工具写清适用和不适用的场景，再写参数；写完后让别人读一遍，看他能不能分清每个工具
2. 参数 schema 收紧枚举、必填、格式都落到 schema 里，别指望模型自觉
3. 单独启动 server 验证外部客户端接入前，先用最笨的方式把 server 单独跑起来，确认能连上再往下走
4. 打印工具返回调试阶段先看原始返回，别直接看模型的最终回答，否则分不清是调用没成还是模型没读懂结果

落地节奏：小步验证，再谈复用

第一个工具只接只读查询，跑通一轮再扩。写操作往后放，出问题也容易兜。这不是保守，是给自己留排查余地——只读跑不通，问题一定在接线或描述上，不会牵扯数据被改。

每次调用记下四列就够定位大部分问题：工具名、参数、耗时、返回状态。多了没必要，少了就抓瞎。日志先攒着，等真出问题再回头翻，比事后加打点快得多。

要评估哪家模型对工具调用稳，别凭感觉。到站内榜单和实测页对着看当时的数字，再结合自己的工具描述跑一轮小样本，两边对上了再定。榜单是参考，自己那套 tools 定义才是最终考场。