1. Cherry Studio 里 MCP 天气服务卡在对话与工具调用之间先看现象1.1 卡住的时候界面和日志分别长什么样原文 Step5 完成后的正常流程是在 Cherry Studio 里配置好模型 api进入对话输入「北京今天天气」模型先决定调用 query_weatherCherry Studio 把 city 参数传给本地 MCP 服务天气文本返回后再由模型整理成自然语言。整个过程应该在几秒内结束。卡住时的表现通常有三种。第一种对话区出现一个「工具调用」的占位卡片后面一直转圈既不结束也不报错第二种模型像没看到工具一样把问题复述一遍或者答非所问第三种等待十几秒后提示「模型服务连接失败」但没有任何细节说明失败在哪个环节。从日志上看weather.py 对应的终端窗口什么都没有打印。这个细节很关键说明请求根本没到 MCP 服务端。如果 query_weather 真的被调用了weather.py 至少会打印出城市查询接口的返回结果。所以问题不在服务端而在模型通道——Cherry Studio 没有从模型响应里拿到 tool_call 结构自然不知道下一步该调用哪个工具。1.2 为什么「模型通道不认」会让 MCP 直接断掉MCP 的调用链路分两段第一段是模型根据对话内容决定「要不要用工具」第二段才是把参数发给 MCP 服务端执行。Cherry Studio 里配置的 Base URL决定的是第一段能不能完成。原文 Step5 填的是 https://api.baystoneai.com/如果这个地址在当前环境下返回了鉴权失败、路径不存在或者响应格式完全不被 Cherry Studio 识别模型就不会产生工具调用意图。没有 tool_callquery_weather 就永远轮不到执行。这也解释了为什么很多人盯着 weather.py 查半天查不出结果。服务端本身是好的Step1–Step4 的 uv 环境、FastMCP 初始化、SSE 路由都能跑通问题只是 Step5 把模型指向了一个不被识别的通道。排查方向必须从「天气服务」转到「模型通道」核心就两个变量Base URL 和 API Key。2. 从 https://api.baystoneai.com/ 到 TaoToken模型通道的 Base URL 决定 MCP 能不能被触发2.1 原文 Step5 填的那个地址在 MCP 流程里管什么Cherry Studio 里有两个地址很多人会搞混。一个是模型供应商的 Base URL负责对话和工具决策另一个是 MCP 服务地址负责实际执行天气查询。原文 Step5 填的 https://api.baystoneai.com/ 属于前者它决定了 Cherry Studio 能不能正常调用大模型。MCP 服务地址是在「工具管理」里单独配置的本地开发时长这样http://127.0.0.1:8081/sse。两个地址分工完全不同配置项职责原文示例排查时的关注点模型通道 Base URL让模型决定是否调用工具https://api.baystoneai.com/是否被 Cherry Studio 识别鉴权是否通过MCP 服务地址执行 query_weather 并返回天气文本http://127.0.0.1:8081/sse服务是否启动SSE 路由是否可访问当模型通道的 Base URL 不认时相当于大脑断联工具调用指令永远不会产生。很多人反复检查 MCP 服务地址其实那个地址只要能在浏览器里打开 http://127.0.0.1:8081/sse 看到连接建立就已经是好的。2.2 为什么用 TaoToken 替换模型通道的 Base URLTaoToken 的定位是统一 API 兼容通道它给开发工具提供的是一个对外表现稳定的接口地址。Cherry Studio、Codex、Claude Code 这类工具对 Base URL 的路径拼接很敏感有的要求带 /v1有的要求不带。TaoToken 的接入地址是 https://taotoken.net/api末尾不需要再加 /v1也不需要把模型服务地址换掉。Cherry Studio 填上之后请求会走到一个能正常完成鉴权和模型响应的通道模型才有机会输出 tool_callMCP 天气服务才能被触发。这一步只动 Cherry Studio 的模型供应商配置不动 weather.py不动 SSE 服务也不动和风天气的 Key。排障范围被压到最小是这条路径最省事的地方。3. 在 TaoToken 官网创建 Key再回 Cherry Studio 改模型通道3.1 注册并创建 API Key然后去模型广场复制模型 ID准备材料只有三样Cherry Studio 已安装、本地 weather.py 的 SSE 服务还在运行、一把能被模型通道识别的 Key。前两样原文已经带你做好了第三样现在补上。打开 TaoToken 官网注册登录后进入控制台的 API Keys 页面创建一把 Key。创建完成后只显示一次先复制保存到一个临时文件里下文统一用 YOUR_API_KEY 占位。Key 有了之后回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场找到你准备在 Cherry Studio 里使用的模型 ID。注意模型 ID 不要凭记忆填不同供应商的 ID 命名规则不一样以模型广场当时列表为准直接复制过去最稳。3.2 在 Cherry Studio 添加供应商并填写 Base URL进入 Cherry Studio 的设置 → 模型服务 → 添加供应商。供应商类型选择「OpenAI 兼容」或者「自定义」都可以名称随意关键是下面三个字段Base URLhttps://taotoken.net/apiAPI KeyYOUR_API_KEY模型 ID从模型广场复制的那串 ID填完保存后回到对话页把当前对话模型切换成刚添加的模型再发一句「北京今天天气」。如果模型列表里没有出现新模型重启一次 Cherry Studio 再切。这里最容易踩的坑是手滑把 Base URL 填成 https://taotoken.net/api/v1。TaoToken 的接口路径就是 https://taotoken.net/api末尾的 v1 不要自己加。4. 用 Codex 对照 /api 与 /v1 差异收敛 query_weather 的报错面4.1 让 Codex 做静态对照而不是直接动本地服务如果你已经改了 Base URLquery_weather 还是没反应下一步别急着反复开关 Cherry Studio 里的开关。把问题丢给 Codex让它做一次静态对照。你可以在 Codex CLI 或聊天界面里粘贴一段上下文Cherry Studio 的模型通道 Base URL 是 https://taotoken.net/apiMCP 服务地址是 http://127.0.0.1:8081/sse天气服务用 FastMCP 实现工具名是 query_weather。要求它列出模型通道与 MCP 通道各自负责哪一步/api 结尾与 /v1 结尾在常见工具里是怎么被拼接的。Codex 不会直接连到你的本地服务它只负责生成核查清单。真正执行的动作由你在本地做Codex 根据你贴回去的结果做二次判断。4.2 用 curl 在本地验证 Base URL 是否被模型通道识别让 Codex 生成一条探测命令人工照着执行也可以。在本地终端跑下面这条curl https://taotoken.net/api/models \ -H Authorization: Bearer YOUR_API_KEY能列出模型列表说明地址和 Key 都被识别。如果返回 404把完整输出贴回给 Codex让它判断是路径拼接问题还是模型 ID 问题。如果返回 401说明 Key 没配对回控制台重新创建。注意这条请求是发到 https://taotoken.net/api 的不要在 URL 后面加 /v1也不要把官网落地页的带参地址当成接口地址填进来。4.3 重试 query_weather观察天气文本是否正常返回curl 通了之后回 Cherry Studio 再说一次「上海现在什么天气」。正常情况是query_weather 收到 city 参数weather.py 打印出城市 ID然后返回带温度、湿度、风速的文本。对话里如果还是停在工具调用把 Cherry Studio 的日志级别调到 debug重点看请求里有没有带 Authorization 头响应里有没有 tool_calls 字段。这一步能直接区分是「MCP 服务没启动」还是「模型根本没打算调用工具」两个方向不再互相混淆。5. 对照原文 Step1–Step4 检查服务端weather.py 与 SSE 路由别被误伤5.1 uv 环境与 weather.py 的常见检查点排障时最怕模型通道改好了服务端反而因为之前的反复测试留下隐患。建议按原文 Step1–Step4 的顺序快速过一遍。Step1 的 uv 环境确认终端里执行过 source .venv/bin/activate并且 uv add mcp[cli] httpx requests 已经把依赖装齐。很多人卡住是因为开了新终端但虚拟环境没有激活导致 python 命令跑的是全局环境。Step2 的 weather.py重点看两处一是和风天气的 Key 是否真的填了值二是 get_city_id 里的 geoapi 地址能不能通。可以用一条最简单的命令单独验证python -c from weather import get_weather; print(get_weather(北京))如果这条能返回天气文本服务端逻辑就是通的问题一定在 Cherry Studio 的通道配置上。5.2 Step4 的 SSE 服务与 Cherry Studio 工具地址对应关系Step4 把 MCP 服务改造成了 SSE 模式启动后监听 127.0.0.1:8081。在 Cherry Studio 的工具管理里添加 MCP 服务时地址要填 http://127.0.0.1:8081/sse注意带上 /sse 路径。很多人把地址填成 http://127.0.0.1:8081少了 /sse 一段服务就连不上。连接成功后工具列表里应该能看到 query_weather 以及它的描述信息。如果这里是空的说明 MCP 服务注册失败模型通道再正常也调不到天气工具。服务端检查完再回到对话测试。此时模型通道用了 TaoToken 的 https://taotoken.net/apiMCP 服务地址指向本地 SSE两者都通了query_weather 才会从「工具列表里存在」变成「对话里真的被调用」。6. 跑通之后去控制台对一下这一次调用天气文本正常返回后事情还没完。你可以在 TaoToken 模型对话 里用同一把 Key 发一条测试消息确认模型 ID 和 Base URL 没填错。如果准备长期在 Cherry Studio 里跑 MCP 天气查询可以打开 Coding Plan 看套餐够不够用Key 不够了随时去 控制台 API Keys 重新创建。之后想在 Claude Code 里也做类似的 MCP 调试可以对照 Claude Code 接入文档 把环境变量一次性配齐。回看整个排查过程最值得记住的一点是MCP 服务在 Cherry Studio 里不工作十有八九不是工具本身写坏了而是模型通道没有把「调用工具」的指令传下来。Base URL 填 https://taotoken.net/apiKey 用自己在官网创建的那把模型 ID 从模型广场复制三个字段都对了query_weather 自然就正常返回天气文本。下次再遇到类似卡顿先 curl 一下通道再回头看服务端能省掉一大半无效检查。