MCP 和 function calling 的差别：从 settings.json 配置骨架看两条集成路径

1. 从 settings.json 里那行配置说起MCP 和 function calling 到底差在哪如果你最近在 Cline、CC Switch 或者 Claude Code 里配过工具大概率见过两种完全不同的配置写法一种是在settings.json里塞一段mcpServers另一种是在代码里定义tools数组然后传给模型。这两种写法看起来都在做「让 AI 能调外部能力」这件事但它们在配置层面的骨架完全不一样。MCP 和 function calling 的差别本质上不是「谁更新」而是「能力从哪里来、由谁组织、怎么被复用」。这篇不聊抽象概念直接从两份可复制的配置骨架入手让你亲手跑通两条路径看清差别到底出现在哪一层。适合谁看已经在用 Cline、CC Switch 这类 AI 工具见过mcpServers配置项但没搞清它和 function calling 关系的开发者或者正在做集成选型纠结当前项目该用哪种方式接外部能力的人。读完你应该能判断我现在的场景是 function calling 就够还是值得上 MCP。先说结论方便你带着判断往下看function calling 解决的是「模型这一轮要不要调工具、参数怎么填」它靠近模型交互MCP 解决的是「AI 应用如何统一连接、发现和复用外部能力」它靠近应用与外部能力之间的连接层。很多系统里两者不是二选一而是一起工作。下面用配置骨架把这两层拆开。2. 前置准备TaoToken 接入信息与两条路径的配置位置不管走哪条路径你都需要一个能发起模型请求的入口。这里用 TaoToken 作为统一接入点它的 API 地址是https://taotoken.net/api兼容常见的 OpenAI 风格请求格式所以 function calling 和 MCP 两条路径都能接。你需要先拿到一个 API Key。打开https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite创建一个 Key复制出来备用。注意 Key 只在创建时完整显示一次先存到本地环境变量里别直接写进会提交到 Git 的配置文件。两条路径的配置位置不一样这是第一个能直观感受到的差别function calling 的配置通常写在你的应用代码里或者写在调用模型时传的tools参数里。它跟着「这一次请求」走请求结束工具定义的生命周期也就结束了。MCP 的配置写在 AI 客户端的配置文件里比如 Cline 的settings.json、CC Switch 的config.toml。它跟着「这个客户端」走配一次之后这个客户端里所有对话都能用上这组能力。换句话说function calling 的配置是「请求级」的MCP 的配置是「客户端级」的。这个位置差异后面会反复出现。提示先把 API Key 写进环境变量比如export TAOTOKEN_API_KEY你的key后面两份配置骨架都会引用它避免明文散落。3. 路径一function calling 的配置骨架与逐步验证3.1 function calling 的 settings 骨架function calling 没有独立的「配置文件」它的骨架体现在请求体里。下面是一段可以直接跑的 Python 示例用requests发起一次带工具的对话请求。工具定义写在tools数组里模型会根据用户问题决定要不要调、调哪个。import os import json import requests API_KEY os.environ[TAOTOKEN_API_KEY] BASE_URL https://taotoken.net/api/v1/chat/completions # 工具定义这就是 function calling 的「配置骨架」 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如 杭州 } }, required: [city] } } } ] payload { model: gpt-4o-mini, messages: [ {role: user, content: 杭州现在天气怎么样} ], tools: tools, tool_choice: auto } resp requests.post( BASE_URL, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json }, jsonpayload, timeout60 ) print(json.dumps(resp.json(), ensure_asciiFalse, indent2))这段骨架的关键点tools数组里每个工具都有name、description、parameters。模型看到这些描述后自己判断要不要发起调用。你不需要告诉它「先调天气再回答」它根据description决定。3.2 跑通并观察返回结构把上面代码存成fc_demo.py设置好环境变量后运行export TAOTOKEN_API_KEY你的key python fc_demo.py如果模型决定调用工具你会在返回的choices[0].message里看到tool_calls字段类似{ role: assistant, tool_calls: [ { id: call_abc123, type: function, function: { name: get_weather, arguments: {\city\:\杭州\} } } ] }注意模型只负责「决定调什么、参数填什么」它不会真的去查天气。真正执行get_weather的是你的应用代码。你需要拿到tool_calls后自己执行函数再把结果作为一条role: tool的消息塞回对话发起第二次请求模型才会基于结果生成最终回答。这就是 function calling 的本质它是「模型侧的一次调用决策」执行权在你手里工具定义跟着这次请求走。3.3 补上执行环节形成完整闭环为了让你看到完整流程补一段执行和回传的代码# 假设模型返回了 tool_calls tool_call resp.json()[choices][0][message][tool_calls][0] func_name tool_call[function][name] args json.loads(tool_call[function][arguments]) # 本地执行这里用假数据模拟 def get_weather(city): return f{city}当前晴气温 22 摄氏度 result get_weather(args[city]) # 把结果回传给模型 messages payload[messages] [ resp.json()[choices][0][message], { role: tool, tool_call_id: tool_call[id], content: result } ] final requests.post( BASE_URL, headers{Authorization: fBearer {API_KEY}}, json{model: gpt-4o-mini, messages: messages}, timeout60 ) print(final.json()[choices][0][message][content])跑完你会看到模型基于天气结果生成的回答。整个链路里工具定义、执行逻辑、结果回传都在你的应用内部模型只参与「决策」这一环。4. 路径二MCP 的 settings.json / config.toml 配置骨架与验证4.1 MCP 的配置骨架长什么样MCP 的配置不在请求里而在客户端的配置文件里。以 Cline 的settings.json为例骨架大概是这样{ mcpServers: { weather-server: { command: npx, args: [-y, your-scope/weather-mcp-server], env: { TAOTOKEN_API_KEY: 你的key } }, docs-server: { command: node, args: [/path/to/your/docs-server/index.js], env: { DOCS_ROOT: /path/to/docs } } } }如果你用的是 CC Switch配置写在config.toml里骨架类似[[mcp_servers]] name weather-server command npx args [-y, your-scope/weather-mcp-server] [mcp_servers.env] TAOTOKEN_API_KEY 你的key [[mcp_servers]] name docs-server command node args [/path/to/your/docs-server/index.js]对比一下就能看出差别function calling 的骨架是「工具描述」MCP 的骨架是「Server 启动方式」。MCP 配置里没有parameters、没有description它只告诉客户端「怎么把这个 Server 跑起来」。至于这个 Server 暴露了哪些工具、哪些资源是 Server 启动后通过协议自己声明的。4.2 启动并验证 MCP Server 是否接入成功配好之后重启你的 AI 客户端。以 Cline 为例它会在启动时按command和args拉起每个 MCP Server然后通过标准输入输出跟 Server 握手获取能力列表。验证动作在 Cline 里打开 MCP 面板你应该能看到weather-server和docs-server两个条目展开后能看到它们各自暴露的 Tools 和 Resources。如果某个 Server 显示红色或报错说明启动失败去客户端日志里看具体原因。一个常见的验证方式是直接在对话里问「用 weather-server 查一下杭州天气」。如果接入成功客户端会把这句话路由到对应 Server 的工具上你会在对话里看到工具调用记录。注意这里的调用记录是客户端展示的跟 function calling 里你手动解析tool_calls不一样——MCP 客户端帮你把「发现能力、路由调用、回传结果」这一整套都接管了。4.3 MCP Server 侧的最小实现骨架如果你想自己写一个 MCP Server最小骨架大概是这样Node.js 示例用官方 SDKimport { Server } from modelcontextprotocol/sdk/server/index.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new Server( { name: weather-server, version: 1.0.0 }, { capabilities: { tools: {} } } ); // 声明这个 Server 暴露哪些工具 server.setRequestHandler(tools/list, async () ({ tools: [ { name: get_weather, description: 查询指定城市的当前天气, inputSchema: { type: object, properties: { city: { type: string, description: 城市名称 } }, required: [city] } } ] })); // 处理工具调用 server.setRequestHandler(tools/call, async (request) { if (request.params.name get_weather) { const city request.params.arguments.city; return { content: [{ type: text, text: ${city}当前晴气温 22 摄氏度 }] }; } throw new Error(Unknown tool); }); const transport new StdioServerTransport(); await server.connect(transport);看到没MCP Server 里的tools/list返回的结构跟 function calling 里的tools数组非常像——都有name、description、inputSchema。这不是巧合MCP 客户端拿到这些工具后最终还是要转成模型能理解的工具接口模型侧走的仍然是类似 function calling 的机制。这就是为什么说两者是协同关系不是替代关系。5. 两条路径的配置层对比与常见错排查5.1 配置层差异对照维度function callingMCP配置位置应用代码 / 请求体客户端 settings.json / config.toml配置生命周期请求级每次请求都要带客户端级配一次长期生效能力声明方式手写 tools 数组Server 启动后通过协议声明执行方你的应用代码MCP Server 自己执行复用范围绑定在单个应用内跨客户端复用同一套 Server你最先感知到的地方请求返回里的 tool_calls客户端 MCP 面板里的 Server 列表5.2 常见错排查报错一tools传了但模型不调用。先检查tool_choice是不是设成了none或者模型本身不支持 function calling。另外description写得太模糊也会导致模型判断不出该不该调把用途写具体比如「查询指定城市的当前天气」比「天气工具」好得多。报错二MCP Server 在客户端里显示启动失败。九成是command或args路径不对。npx方式要确认本地能联网拉包node方式要确认路径是绝对路径。环境变量env里的 Key 如果没传进去Server 启动时读不到会直接退出去客户端日志里搜stderr能看到具体报错。报错三MCP 接入了但对话里不触发工具。检查客户端是否真的把 Server 的工具注册进了当前对话。有些客户端需要手动在对话里启用某个 Server或者 Server 的tools/list返回为空。用客户端的「查看能力」功能确认工具列表非空。报错四function calling 回传结果后模型答非所问。大概率是tool_call_id对不上。回传的role: tool消息里tool_call_id必须跟模型返回的id完全一致否则模型会把这条结果当成无关上下文。报错五API 请求 401。检查Authorization头是不是Bearer加 Key中间有空格。Key 如果是从环境变量读的确认export在当前 shell 生效或者用python-dotenv加载.env文件。6. 选型建议与后续接入入口回到选型。如果你只有一个应用、几个固定工具function calling 通常已经够用配置简单、链路清晰、调试直观。如果你开始出现「同一套能力要在 Cline 和另一个客户端里都用」「不只是调工具还要暴露可读资源和可复用提示」「想把内部系统做成独立能力模块」这些信号MCP 的价值才会明显起来。两条路径的接入入口不一样按你的场景选想先把模型调用跑通、验证 function calling 链路去模型对话页试一下https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite。准备长期做编码或 Agent 集成需要稳定的 Key 和额度管理看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite。配置过程中卡在 Key 或接入参数上直接翻接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite。如果你用的是 Claude Code 这类 Anthropic 风格客户端接入说明在这里https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude_code_anthropicutm_campaignrewrite。最后留一个我自己的判断习惯每次纠结用哪个先问一句——我现在的痛点是「模型还不会调工具」还是「工具接入和复用已经开始变乱」。前者优先 function calling后者才轮到 MCP。把这两层分清了再看 Cursor、Claude Code 这些产品的配置项就不会被名词带着跑。