1. 为什么自建 MCP Server 之后模型通道还得单独配MCP Server 是这两年本地工具接入大模型最顺手的一套方案。它本质上是一套标准化的 JSON-RPC 通信协议用来让大模型程序安全调用外部本地工具、本地数据、本地软件。注意它既不是大模型也不是工具本身只是一套对话规则规定双方消息怎么发、参数怎么传、结果怎么返回。整个体系分 Host、MCP-Client、MCP-Server 三个角色Host 是完整的上层 AI 应用比如 WorkBuddy、Claude Desktop负责跑大模型、管会话、做权限校验、处理上下文窗口MCP-Client 藏在 Host 里负责和 Server 握手MCP-Server 就是我们自己写的那个本地进程。很多人跟着教程走完一遍uv init . -p 3.11建工程、uv add mcp[cli]装 python-sdk、在 vscode 里写好server.py和main.py、让服务通过 stdio 等 WorkBuddy 父进程发指令再到 WorkBuddy 连接器的「自定义 MCP 服务管理」贴 JSON、看到绿灯、在对话里验证工具被调用最后打包成wb_add_mcp_demo发到 PyPI。流程很完整但有个坑几乎没人提那份 JSON 配置只解决了 Host 怎么拉起本地 MCP ServerHost 里真正消耗 Token 的模型对话走哪条通道原文压根没交代。这就导致一个尴尬局面——绿灯亮了工具也能被调用可你一旦把 WorkBuddy 的模型通道指向别处或者想统一管理 Key 和用量就会发现 MCP 这层和模型这层是两套东西。这篇就把这缺失的一步补上本地 MCP Server 继续用 stdio 被拉起协议代码一行不改只把 WorkBuddy 的模型认证通道换成 TaoToken看它到底行不行、怎么验证、哪里容易翻车。2. 先把 TaoToken 的 Key 和 Base URL 准备好在动 WorkBuddy 的模型设置之前得先有一把能用的 Key。去https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end注册账号进控制台创建一把 API Key。这一步和 MCP Server 本身没关系纯粹是给 Host 里的模型对话准备通道。创建完 Key 之后重点记两个东西一是这串 Key 本身二是 Base URL。Base URL 填https://taotoken.net/api注意这里不带/v1也不加任何 UTM 参数。很多人习惯性在后面补/v1结果请求 404还以为是 Key 的问题其实是路径拼错了。注意TaoToken 这把 Key 是给模型对话通道用的和后面发布 PyPI 用的 token 完全是两码事千万别混用也别把 PyPI token 填到模型设置里。如果你后面要长期跑编码类 Agent或者想让 WorkBuddy 里的工具调用链路更稳定可以顺手看下 Coding Plan 的入口它和单次 API 调用是两种用法按自己的使用频率选就行。Key 建好之后先别急着关页面等会儿验证请求成功与否还要回来看这把 Key 的调用记录。3. 本地 MCP Server 保持 stdio一行协议代码都不改这一步是整篇的关键认知MCP Server 和模型通道是解耦的。你的server.py里那些server.tool()装饰器、stdio_server()的启动逻辑全都不用动。MCP 协议负责的是 Host 和本地进程之间怎么传 JSON-RPC 消息模型走哪条通道是 Host 内部的事。先确认工程结构还是老样子。进入MCP_Server文件夹初始化工程uv init . -p 3.11 uv add mcp[cli]python-sdk这层封装了底层 JSON-RPC、stdio 通信、握手、工具 schema你只写业务逻辑就行。main.py里保证直接运行脚本时能启动 MCP 服务通过 stdio 管道等待 WorkBuddy 父进程发送调用指令大致是这样import asyncio from mcp.server import Server from mcp.server.stdio import stdio_server server Server(wb_add_mcp_demo) server.tool() async def add(a: int, b: int) - int: 两数相加 return a b async def main(): async with stdio_server() as (read, write): await server.run(read, write, server.create_initialization_options()) if __name__ __main__: asyncio.run(main())这段代码和模型通道没有任何耦合。stdio 只是传输层SSE、streamable-http 也能实现 MCP 服务和客户端之间的通信但本地场景 stdio 最省事。WorkBuddy 作为 Host负责把本地进程拉起来然后通过管道收发消息。真正要改的是 WorkBuddy 那边的模型设置。打开 WorkBuddy 的自定义模型通道设置把 Base URL 填成https://taotoken.net/apiAPI Key 填刚才创建的那把。保存之后Host 里所有消耗 Token 的模型对话就走 TaoToken 这条通道了而 MCP Server 依旧按原样被 stdio 拉起。4. 配置 JSON、看绿灯、验证工具被调用WorkBuddy 连接器里的「自定义 MCP 服务管理」还是照旧配。点配置 MCP贴入类似这样的 JSON{ mcpServers: { wb_add_mcp_demo: { command: uv, args: [run, python, main.py], cwd: /你的路径/MCP_Server } } }这里command和args按你本地实际启动方式填cwd指向工程目录。保存后如果出现绿灯说明 MCP 配置成功了Host 已经能拉起本地 Server 并完成握手。绿灯只是第一步它证明的是 MCP 这层通了不代表模型通道也通了。接下来在对话里触发工具调用比如直接问「帮我算一下 3 加 5」看 WorkBuddy 是否调用了add工具并返回结果。工具被成功调用说明 stdio 链路没问题。同时回到 TaoToken 侧确认这把 Key 的请求是否成功。如果对话有正常回复、工具也触发了但 TaoToken 后台看不到请求记录那大概率是模型通道没切过去或者 Base URL 填错了。这一步是很多人忽略的交叉验证绿灯管 MCP请求记录管模型通道两个都亮才算真正跑通。5. 打包发布到 PyPItoken 分开放功能验证完最后把 MCP Server 发布到公网供别人使用。新建一个名为wb_add_mcp_demo的文件夹在终端里执行uv init . --package -p 3.11 uv add mcp[cli]这会在当前目录初始化 uv 项目生成pyproject.toml等工程文件并指定 Python 版本为 3.11。打开src下的__init__.py把工具逻辑整理进去保证包被导入时能正确暴露 MCP 服务入口。然后打包uv build打包产物在dist/目录下。接着去 PyPI 添加 API token拿到 token 后执行uv publish --token XXXX这里的XXXX是你的 PyPI token和 TaoToken 那把 Key 分开放、别混用。发布成功后回到 PyPI 项目页能看到wb_add_mcp_demo已经上线别人就能通过uv add wb_add_mcp_demo安装使用了。6. 常见报错排查绿灯不亮MCP 连不上。先看cwd路径对不对再看command能不能在终端里手动跑通。uv run python main.py如果本地直接报错WorkBuddy 那边肯定也拉不起来。常见的是虚拟环境没激活或者依赖没装全重新uv sync一次。工具调用没反应。绿灯亮但对话里触发不了工具多半是工具 schema 没注册成功。检查server.tool()装饰器是否写对函数签名和类型注解是否完整MCP 靠这些生成 schema。模型对话报 401 或 404。401 一般是 Key 填错或没生效404 大概率是 Base URL 多写了/v1。记住填https://taotoken.net/api不带/v1也不加 UTM。TaoToken 后台看不到请求。说明模型通道根本没走 TaoToken检查 WorkBuddy 的自定义模型设置是否保存成功有没有被其他通道覆盖。发布时 token 报错。PyPI token 和 TaoToken Key 是两套体系别把https://taotoken.net/api相关的 Key 填到uv publish里。PyPI token 只在 PyPI 后台生成权限范围也只在发布。stdio 启动超时。有些环境里uv不在 PATHWorkBuddy 拉起时找不到命令。把command换成uv的绝对路径或者用python直接指向虚拟环境里的解释器。整套流程跑下来核心就一句话MCP 管工具怎么被调用TaoToken 管模型对话走哪条通道两者互不干扰。本地 Server 的协议代码一行不用改改的只是 Host 里的模型认证配置。绿灯亮、工具触发、TaoToken 后台有请求记录这三件事同时成立才算真正把自建 MCP Server 和模型通道都跑通了。