1. 先把两个概念摆到桌面上MCP Server 和 Function Calling 到底谁管什么刚接触大模型开发的人几乎都会在同一个地方卡住Function Calling 和 MCP Server 听起来都是“让模型去调用外部东西”那它们是不是一回事我一开始也这么想过后来在本地把两个流程都跑了一遍才发现它们根本不在一个层面上。Function Calling 是模型自身的一种能力。你给它一份函数清单它根据用户的话判断该不该调用、调用哪个、参数填什么然后吐出一段结构化的 JSON。注意模型只负责“决定调用”真正执行函数的还是你自己的代码。它像是一个翻译官把你的自然语言需求翻译成程序能看懂的调用指令。MCP Server 则是一套标准化的协议实现。它解决的是另一个问题当你有几十个工具、多个数据源、好几个客户端都要接的时候每个工具都单独写一套适配代码太累了。MCP 把工具的暴露方式、参数描述、调用通道统一成一套规范任何支持 MCP 的客户端都能按同一套规则去发现和调用工具。它更像是一个统一的工具插座插头形状固定了谁都能插。所以职责边界很清楚Function Calling 是模型侧的“决策能力”MCP Server 是工程侧的“接入标准”。两者不是替代关系而是可以协作的。你可以只用 Function Calling 跑通一个天气查询也可以在 MCP Server 里把工具注册好让模型通过标准协议去调用。下面我会先讲清楚怎么用 TaoToken 拿到可用的模型接口再分别给出可复制的配置和验证步骤。适合读这篇的人刚学大模型 API 调用、分不清工具调用和协议标准、想在本机跑通一次完整链路的开发者。你不需要有很深的后端经验只要能跑 Python 和改 JSON 就行。2. 前置准备用 TaoToken 拿到模型接口和 Key不管你是走 Function Calling 还是 MCP Server最终都要有一个能响应请求的模型服务。TaoToken 在这里的角色是提供统一的模型接入入口你不需要分别去对接多家模型拿一个 Key 就能在同一个接口下切换使用。第一步打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录。登录后进入控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。在控制台里找到 API Keys 页面新建一个 Key 并复制保存。这个 Key 只显示一次丢了就得重建。第二步确认你要用的模型。如果你只是想验证 Function Calling 的请求结构用模型对话页面就能快速试 https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果你打算长期做编码类或 Agent 类项目可以了解 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。第三步记下 API 基地址 https://taotoken.net/api 。注意这个地址后面不加任何 UTM 参数直接作为 base_url 使用。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面写了不同语言下的调用示例遇到参数不确定的时候翻一下比猜要快。注意Key 不要写死在代码里提交到仓库用环境变量读取。我习惯用TAOTOKEN_API_KEY这个变量名后面所有示例都按这个来。到这里前置就完成了。你手里应该有一个可用的 Key、一个 base_url、以及至少一个模型名称。接下来进入实操。3. 可复制配置Function Calling 请求骨架与 MCP Server 的 settings.json这一节给两份可以直接抄的配置。先看 Function Calling 的请求骨架再看 MCP Server 的 settings.json 示例。两份配置解决的是不同层面的问题不要混在一起理解。3.1 Function Calling 的最小请求结构Function Calling 的核心是你在请求里带上tools字段模型返回时可能给出tool_calls。下面是一个 Python 示例用 OpenAI 兼容的调用方式base_url 指向 TaoToken。import os import json from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlhttps://taotoken.net/api ) # 定义工具清单模型只能从这里选 tools [ { type: function, function: { name: get_weather, description: 查询指定城市某天的天气, parameters: { type: object, properties: { location: {type: string, description: 城市名如北京}, date: {type: string, description: 日期如明天} }, required: [location, date] } } } ] response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 明天北京的天气怎么样}], toolstools, tool_choiceauto ) print(json.dumps(response.choices[0].message, ensure_asciiFalse, indent2))这段代码里模型不会真的去查天气它只会返回一个类似{name: get_weather, arguments: {\location\:\北京\,\date\:\明天\}}的结构。执行权在你手里你需要解析这个结构调用真实函数再把结果作为role: tool的消息回传模型才会生成最终自然语言回复。3.2 MCP Server 的 settings.json 配置骨架MCP Server 的配置通常放在客户端的 settings.json 里不同客户端路径不同但结构类似。下面是一个通用骨架你可以按自己用的客户端调整字段名。{ mcpServers: { weather-server: { command: python, args: [-m, mcp_server_weather], env: { WEATHER_API_KEY: your_weather_key, TAOTOKEN_API_KEY: your_taotoken_key } }, file-reader: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /Users/yourname/data], env: {} } } }这份配置里mcpServers下每个键是一个 Server 的名字command和args决定怎么启动它env传环境变量。客户端启动时会按这份配置拉起各个 Server然后通过 MCP 协议去发现这些 Server 暴露了哪些工具。模型侧看到的工具列表就是这些 Server 注册上来的。对比一下就能看出差异Function Calling 的 tools 是你在每次请求里手写传进去的MCP Server 的工具是通过协议动态发现的。前者是请求级配置后者是会话级注册。提示settings.json 里不要出现明文的生产密钥。本地测试可以用测试 Key正式环境走密钥管理服务注入。4. 验证请求跑一次 Function Calling 并确认 MCP 工具被发现配置写好了不代表能跑通这一节给两个验证动作。先验证 Function Calling 的返回结构再验证 MCP Server 是否被客户端正确加载。4.1 验证 Function Calling 返回了 tool_calls把 3.1 的代码保存为test_fc.py设置好环境变量后运行export TAOTOKEN_API_KEY你的Key python test_fc.py如果一切正常你会看到类似这样的输出{ role: assistant, content: null, tool_calls: [ { id: call_abc123, type: function, function: { name: get_weather, arguments: {\location\: \北京\, \date\: \明天\} } } ] }看到tool_calls就说明模型正确识别了工具并生成了调用参数。注意content是 null因为模型把话都放进了 tool_calls 里。这时候你需要在代码里补上执行逻辑解析 arguments调用真实函数然后把结果拼成下面这条消息再发一次请求。# 假设你已经执行了函数并拿到 result messages [ {role: user, content: 明天北京的天气怎么样}, response.choices[0].message, { role: tool, tool_call_id: response.choices[0].message.tool_calls[0].id, content: json.dumps({weather: 晴, temp: 18-26℃}, ensure_asciiFalse) } ] final client.chat.completions.create( modelgpt-4o-mini, messagesmessages ) print(final.choices[0].message.content)第二次请求后模型会基于工具返回的数据生成自然语言回答比如“明天北京晴气温 18 到 26 摄氏度”。到这里 Function Calling 的完整闭环就跑通了。4.2 验证 MCP Server 是否被加载MCP Server 的验证方式取决于你用的客户端。以支持 MCP 的桌面客户端为例配置好 settings.json 后重启客户端然后在对话里问一句“你有哪些可用工具”。如果 Server 加载成功客户端会把注册的工具列表展示出来或者模型会直接告诉你它能调用哪些工具。如果客户端有日志面板打开看启动日志。正常情况会看到类似Connected to MCP server: weather-server的记录。如果看到Failed to start或command not found说明 command 或 args 写错了回去检查路径和依赖是否安装。一个容易忽略的点MCP Server 本身也是一个进程它需要能独立启动。你可以先在终端手动跑一下python -m mcp_server_weather确认它不报错再放进 settings.json。这样能把“Server 本身有问题”和“客户端配置有问题”分开排查。5. 本篇常见错排查从报错信息反推是 FC 还是 MCP 的问题跑不通的时候先看报错出现在哪一层能省很多时间。下面列几个我实际遇到过的坑。第一个坑Function Calling 请求返回 400提示tools is not supported。这通常是你选的模型不支持工具调用。换一个支持 Function Calling 的模型再试模型对话页面里可以快速切换验证。第二个坑模型返回了 tool_calls但 arguments 解析失败。原因是模型可能返回了非标准 JSON或者你直接拿字符串当字典用了。正确做法是用json.loads解析并加 try 捕获异常。如果模型经常返回坏 JSON可以在 system 消息里强调“arguments 必须是合法 JSON”。第三个坑MCP Server 在 settings.json 里配置了但客户端没反应。先确认 command 指向的可执行文件在 PATH 里npx 类的要确认网络能拉到包。其次确认 args 里的路径是绝对路径相对路径在不同工作目录下会失效。最后看客户端是否支持你配置的传输方式有些客户端只支持 stdio有些还支持 SSE。第四个坑把 MCP Server 当成 Function Calling 的替代品结果发现模型根本不认识工具。这是因为 MCP 工具需要客户端先做协议层的发现和注册模型才能看到。如果你直接在请求里手写 tools那走的就是 Function Calling跟 MCP 无关。两者可以同时存在但不要指望配了 MCP 就自动有了 Function Calling 的效果。第五个坑Key 权限或额度问题导致请求被拒。确认 Key 是在 TaoToken 控制台新建的并且账户有可用额度。如果报 401检查TAOTOKEN_API_KEY环境变量是否真的被读到了可以打印前几位确认。注意排查时把请求体和响应体都打出来看比只看报错信息快得多。尤其是 tool_calls 的 id回传时必须原样带上否则第二次请求会报 tool_call_id 不匹配。6. 接下来怎么走按你的目标选对应入口如果你现在的目标是先把 Function Calling 跑通建议直接用模型对话页面做快速验证改一改 tools 定义和用户提问观察返回结构的变化 https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。等你确认请求结构没问题了再回到代码里补执行逻辑。如果你打算长期做编码类或 Agent 类项目需要更稳定的调用额度和更顺手的接入方式可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。它适合那种每天都要反复调模型、不想每次手动配环境的场景。如果你在接入过程中遇到 Key 或权限相关的问题先去 API Keys 页面确认 Key 状态 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。参数和返回格式的细节接入文档里写得更全 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。最后说一个我自己的习惯每次改完 tools 定义或 settings.json先跑最小请求验证不要一上来就接完整业务逻辑。最小请求能过再往上叠功能出问题时排查范围小很多。Function Calling 和 MCP Server 的差异跑通一次之后自然就清楚了光看概念容易绕进去。