企业官网建设流程全解析

SumMCP.py 的 add 和 listdir 已经挂进 RooCode，图标绿了，可让模型算 99+98 时它还要花 token 判断该用哪个 tool。这篇只换模型侧接口：TaoToken（https://taotoken.net/?utm_source=taotoken_aicg_blog_end），MCP 侧配置一字不动。

MCP 有意思的地方在于，插件本身办不到的事，可以自己写个 tool 补上。求和、列目录这种活儿，写成 SumMCP.py 也就十来行，RooCode 挂上就能用。真正麻烦的不是写 tool，而是「模型怎么知道该调哪个 tool」。RooCode 会把 MCP 工具的 schema 一并塞进上下文，模型每轮都得判断：这句话要不要调工具、调 add 还是 listdir、参数怎么填。这一步全压在模型侧通道上，通道一换、Key 一过期、模型 ID 一填错，判断就在半路断掉——表现是绿点还亮着，对话框里却始终弹不出工具调用。

所以这篇按原始那篇《RooCode结合本地MCP实践》的路径重走一遍：先在~/workspace/python/demo/mcp写 SumMCP.py，conda 建 py_3.12 装 fastmcp，再进 RooCode 的 mcp_setting.json 把 demo server 挂上，靠绿色图标确认；唯一新增的一步，是在 RooCode 面板里把模型供应商的 Base URL 填成https://taotoken.net/api，Key 从 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建。配完按原文的测试流程复跑：算 99 与 98 的和、列出 /home/xx/Documents。

如果 MCP 那半边你已经配好，只是卡在「工具列得出来却叫不动」，可以直接跳到第 3 节。

1. SumMCP.py：add 与 listdir 的最小可跑实现

1.1 在 ~/workspace/python/demo/mcp 下把文件建出来

目录结构沿用原文，别自己另起一套，不然后面 mcp_setting.json 里的路径对不上：

cd ~/workspace/python/demo mkdir -p mcp && cd mcp touch SumMCP.py

为什么要单开一个 mcp 目录、单独一个 SumMCP.py？因为 MCP Server 在 RooCode 眼里是一个独立进程，RooCode 只是负责把它拉起来并通过标准输入输出对话。文件放哪儿、叫什么名字本身不影响功能，但一旦多写几个 server，命名和目录会决定你后面排查路径问题时是不是一头雾水。

1.2 SumMCP.py 里两个 tool 的写法

"""SumMCP.py：一个只暴露 add / listdir 两个 tool 的本地 MCP Server""" from fastmcp import FastMCP import os mcp = FastMCP("Demo", log_level="ERROR") @mcp.tool() def add(a: int, b: int) -> int: """Add two numbers，返回 a 与 b 的和""" print("add", a, b) return a + b @mcp.tool() def listdir(path: str) -> list[str]: """列出给定目录下的条目名""" return os.listdir(path) if __name__ == "__main__": # stdio 模式：由 RooCode 拉起进程，通过标准输入输出通信 mcp.run(transport="stdio")

几个细节值得说明。add(a: int, b: int) -> int里的类型标注不是装饰，FastMCP 会把它转成 JSON Schema，模型就是靠这份 schema 决定怎么填参数；标注写没了，模型可能把 99 传成字符串。listdir返回list[str]，结果会被序列化回对话流，路径不对时返回的是异常信息，这些都会进模型上下文。

print("add", a, b)那行是给自己看的，方便在 RooCode 的输出面板里确认 tool 真的被调用了、参数是什么。真要上线跑，把它换成标准库的 logging 更合适，print 在 stdio 模式下混进协议流有时候会干扰解析。

1.3 transport 为什么选 stdio 而不是 sse

原文注释里也留了transport="sse"那一行。简单说，stdio 模式不需要端口，RooCode 直接把进程拉起来，通过管道说话，本地小工具用这个最省心；sse 模式适合把 server 放到另一台机器上、或者多个客户端共享一个 server 的场景，代价是你得自己管端口占用和进程存活。这篇的场景是单机单插件，就老实走 stdio。

1.4 py_3.12 环境与 fastmcp 依赖

conda create -n py_3.12 python=3.12 source /opt/anaconda/bin/activate py_3.12 pip install fastmcp

装完先手动验一次，别急着去改插件：

~/.conda/envs/py_3.12/bin/fastmcp run ~/workspace/python/demo/mcp/SumMCP.py

stdio 模式下它不会打印什么交互提示，安静等着标准输入就是起来了，Ctrl+C 退出。这一步不做，等 RooCode 那边图标不亮时，你会分不清是脚本本身有问题还是插件配置写错了。另外~/.conda/envs/py_3.12/bin/fastmcp这个路径是后面要原样填进 mcp_setting.json 的，先ls一下确认它真的存在。

2. mcp_setting.json 里把 demo server 指到 SumMCP.py

2.1 command 与 args 的对应关系

{ "mcpServers": { "demo": { "command": "~/.conda/envs/py_3.12/bin/fastmcp", "args": [ "run", "~/workspace/python/demo/mcp/SumMCP.py" ], "disabled": false, "alwaysAllow": [] } } }

这段配置里只有四个字段在起作用。command指向 conda 环境里的 fastmcp 可执行文件，不是python，也不是python SumMCP.py。args是命令后面的参数数组：第一个run是 fastmcp 的子命令，第二个是脚本的完整路径。

disabled设成 false，server 才会被拉起来。alwaysAllow留空表示每次调用都要你确认一次，调试阶段建议保持空数组；等你确认这个 tool 完全可控了，再考虑往里加白名单自动放行。

如果路径里带空格，或者 tilde 展开在某些系统上不生效，就把command和args里的路径全写成绝对路径，比如/home/xx/.conda/envs/py_3.12/bin/fastmcp。这类问题在 macOS 和 Linux 上表现不一样，写死绝对路径最省事。

2.2 绿色图标代表什么，又不代表什么

配置保存后回到 MCP Servers 面板，demo 这一项前面会亮起绿色图标。它代表 RooCode 成功按command拉起了进程、完成了一次协议握手、并且拿到了 SumMCP.py 里声明的 tool 列表——在你这个例子里就是 add 和 listdir 两个。

它不代表模型一定会调用这两个 tool。图标绿只是「管道通了」，调用与否是模型侧的事，这也是本篇后面要换模型通道的原因。

2.3 加了第三个 tool 之后必须回面板刷新

原文特意点了一句：在 SumMCP.py 里新加函数，一定要回 MCP 面板刷新，新的 tool 才会出现，插件用的时候才读得到。原因很直接——RooCode 持有的 tool 列表是握手那一刻的快照。你在脚本里加了echo，进程还是那个老进程，插件手里还是老清单。

正确顺序是：改 SumMCP.py → 保存 → 回 MCP Servers 面板点刷新（重启 server）→ 确认新 tool 出现在列表里 → 再回对话框提问。跳过刷新这一步，你会看到「明明写了函数，模型却说没有这个工具」这种假故障。

3. RooCode 面板里换模型通道：Provider 填 https://taotoken.net/api

3.1 先在官网注册并创建 API Key

原文里没有注册这一节，因为原文跑的是插件自带的模型通道。这里补上：打开 TaoToken，注册登录后进控制台创建一把 API Key。

这一步有两条硬性要求。第一，Key 只创建一次、只复制一次，粘到 RooCode 里就完事，别顺手写进任何会被提交的文件。第二，本篇后面所有出现 Key 的地方，都写成占位符YOUR_API_KEY，你实际填的是自己刚创建的那串。

3.2 Base URL 写 https://taotoken.net/api，结尾不要 /v1

回到 RooCode 的模型配置面板，找到 API Provider 那一栏，选 OpenAI Compatible 这类选项，然后：

• Base URL填https://taotoken.net/api
• API Key填YOUR_API_KEY
• Model填你从模型广场复制到的 ID

三个容易踩的点。第一，Base URL 结尾不要加/v1，工具或 SDK 有可能自己再拼一层，多写一次就是 404。第二，不要把官网落地页填进 Base URL，那是给人点的，不是给程序请求的。第三，不要在 Base URL 上挂任何查询参数，通道地址就是干净的https://taotoken.net/api。

这两个地址的分工记住一句话就行：https://taotoken.net/?utm_source=taotoken_aicg_blog_end 用来注册、创建 Key、看模型广场、看用量；https://taotoken.net/api用来填进工具里。

3.3 模型 ID 以模型广场当时列表为准

不要凭记忆写模型名，也不要照搬任何博客里的 ID。打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end，在模型广场里复制当前可用的那个 ID，原样粘到 RooCode 的 Model 字段。

为什么强调这一点？因为 MCP 场景对模型的判断力要求比普通对话高：它要在同一轮里读懂用户意图、从工具清单里挑一个、再按 schema 把参数填对。模型 ID 填错或填了个不存在的名字，请求会直接失败；模型能跑但工具调用能力弱，表现就是「它宁可自己硬算也不调你的 tool」。这两类问题长得完全不一样，先确认 ID 正确，再谈别的。

3.4 MCP 侧一个字都不用改

换模型通道不等于换 MCP 配置。mcp_setting.json 里的command、args还是指向 py_3.12 的 fastmcp 和 SumMCP.py，transport还是 stdio。MCP Server 是跑在本机上的独立进程，它跟模型走哪条通道没有耦合关系。常见误解是「换了模型供应商要重配 MCP」，其实要重连的只是 RooCode 到模型那一侧。

4. 复跑原文测试：99+98 与 /home/xx/Documents

4.1 让 demo 的 add 算 99 与 98

在 RooCode 对话框里输入：

使用 demo 工具，计算 99 和 98 的和

预期行为是这样的：RooCode 弹出一个工具调用确认，显示工具名add、参数a=99、b=98，你点确认后返回197。

如果模型直接回了 197 却没弹确认框，说明它自己心算完了，MCP 工具根本没进这轮决策。对照第 5 节排查。原文也提到过，当前阶段经常需要明确告诉插件「用哪个 tool」，所以提示词里点名demo和add不丢人，是正常用法。

4.2 用 listdir 列出 /home/xx/Documents

使用 demo 的 listdir 工具，列出 /home/xx/Documents 下的文件列表

把/home/xx/Documents换成你机器上真实存在的目录。返回的是一串文件名，os.listdir只列一层，不递归。

这一步能顺带验证两件事：一是参数传递正确（模型知道listdir需要一个path字符串），二是本地进程确实被拉起来了、真的去读了文件系统。如果这里报路径不存在，先确认目录拼写，再确认跑 fastmcp 的进程有没有那个目录的读权限。

4.3 加第三个 tool 再刷新，验证整条链路

想确认自己完全掌握了刷新机制，可以往 SumMCP.py 里加一个最小的：

@mcp.tool() def echo(text: str) -> str: """原样返回传入的文本""" return text

保存文件，回 MCP Servers 面板点刷新，确认echo出现在工具列表里，再在对话里让它 echo 一段字符串。这套流程跑顺，说明「写 tool → 刷新 → 调用」的闭环是通的。

4.4 这次测试跟原文的差别在哪

原文的测试是纯 MCP 侧验证：绿点亮、tool 列出、调用成功。本篇多了一层验证——同一轮对话里，模型的意图判断和工具选择都要经过 TaoToken 这条通道完成。两次测试的提示词、期望返回值都一样，唯一变化的是模型侧接口地址和 Key。这样你才好判断问题出在 MCP 配置还是模型通道。

5. 绿点亮着但调用断在半路，对照这几处

5.1 模型不主动选 tool

表现是绿点在、tool 列表也全，但回答直接给结果，不弹确认框。根因在上下文：模型每轮都要读 tool schema 再做判断，通道切换、模型 ID 不对、或者提示太模糊，都会让它跳过这个动作。

处理办法很实际：先在提示里明确点名 tool 名，确认链路是通的；再逐步把提示写短，观察模型从什么时候开始不再主动挑 tool。这个边界跟你选的模型强相关，没有统一答案。

5.2 换通道后报 401 或 404

这两个错误码对应两处完全不同的配置。

401基本是 Key 问题：填的时候没替换成真 Key、粘的时候多带了空格、或者贴的还是仓库里的YOUR_API_KEY占位符。

404基本是地址问题：Base URL 结尾多写了/v1，或者把官网落地页错填进了 Base URL。回去检查这一栏是不是干净的https://taotoken.net/api。

对照一下：https://taotoken.net/api/v1和https://taotoken.net/api是两个不同的地址，前者会失败。

5.3 绿点根本不亮

这跟模型通道无关，问题在 mcp_setting.json。逐项核对：command的 fastmcp 路径是否存在、conda 环境名是不是py_3.12、args里 SumMCP.py 的路径对不对、disabled是不是 false。

最快的定位方式还是在终端手动跑一次fastmcp run SumMCP.py，终端能跑起来，问题就在配置文件；终端也跑不起来，问题在脚本或环境。

5.4 Key 和用量去哪里对

换完通道、跑通测试之后，如果发现某次调用没反应，或者想确认这次工具调用有没有算进额度，回 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 看调用记录和用量。这一步别省，它能帮你区分「请求根本没发出去」和「发出去了但模型没调 tool」这两种截然不同的故障。

6. 跑通之后，回控制台对一下这次调用

配置保存、99+98 和列目录都试过之后，先在 TaoToken 模型对话 里用同一把 Key 发一条测试消息，确认模型 ID 和 Base URL 没填串——工具调用失败时，这一步能立刻告诉你是通道的问题还是 MCP 的问题。

如果准备长期用 RooCode 加自写 tool 写代码，可以打开 Coding Plan 看套餐是否够用；Key 在 控制台 API Keys 创建，一个项目一把，别混用。

我自己跑下来最深的体会是：MCP 的坑九成不在 Python 脚本里，而在「谁来决定用哪个 tool」这件事上。绿点只是把管道接好了，剩下那半程靠模型通道撑着。把 Base URL 和 Key 一次性配对，比事后在对话里反复强调「请使用 demo 工具」要省事得多。等哪天模型能稳定自己挑 tool 了，这套东西才算真正顺手。