讲讲https://pypi.org/project/mcptoon/0.8.15/#files#1这个

回复 群友 3892 mcptoon 的核心主张和我们刚聊的延迟加载是同一件事，但它解决这个问题的层次更靠下、也更激进：把“工具定义”整个搬出上下文，只留名字索引。它给出的数字是用 255 个工具做合成样本测出来的：把所有工具定义（schema）全量换成 JSON 约 token，换成它的 compact 视图后只剩 581 token，降幅 99.2%；实际调用具体工具时，才用 mcptoon inspect 取回完整 schema；skill 同理，371 个 SKILL.md（工具说明文件）共 92.6 万 token，平时常驻的指针只占 39 token，一次查找 501 token。 还有几个关键设计，看 README 比看宣传语有用： 一是它把自己做成 CLI，而不是常驻代理进程。任何能跑 shell 的 agent 直接执行 mcptoon call 就行，零配置；不能跑 shell 的 GUI 客户端，就挂一条 mcptoon serve 的 MCP 入口。它自己引用的 Firecrawl 和 Scalekit 的 benchmark 也在说同一件事：同一个任务，用 CLI 访问大约比用 MCP 便宜 10～32 倍。这个结论在你们讨论的 api/mcp、cli、gui、cu 层级里，清楚地属于最上层。 二是工具不发包、不带 catalog。搜索时实时查 Smithery（1.7 万多条）和官方 MCP Registry，不预置任何第三方源，原因是想减少供应链层，并且让内置列表不依赖发版更新。这个取舍我觉得是对的。 三是它默认接管你现有的 MCP 配置：quickstart 会把已经配置的 server 路由到网关下，并删掉它们的直连条目。这一步是它最需要警惕的地方，会改动你机器上的 agent 配置；不过它也提供了 mcptoon restore 回滚、mcptoon --dry 预览和 mcptoon uninstall --dry。我建议你先用 dry run 看一遍它到底会改哪些文件。 我的判断分两层： 技术上它是正确的方向，但“99.2%”这个数字要作限定：那是名字索引相对全量 schema 的比值，省下的主要是“静态占位”，不是“每个任务实际用到的量”。真正长期只用到 3～5 个工具的 agent，本来就不会把全部工具定义全量注入上下文；而工具很多（上百个）的场景才是它真正省得厉害的地方。它的失败模式和我们上次聊的一样，是召回准确率：索引里只有名字，模型挑工具全靠 description 和参数类型，这一点 compact 模式下已经不提供了。名字起得含糊，或者两个工具名长得像，模型就会挑错，或者干脆不调用工具。README 里没有给出“召回率”的证据，只测了 token 数，这是它目前最薄弱的地方。 更值得想的是产品定位：它其实是在做 MCP 生态的“包管理器加 context 压缩层”。这个位置有个天然矛盾：只要上游 agent 官方开始支持延迟加载（Anthropic 的服务端 tool search、pi 的 codemode 就是范例），这类夹在工具与 agent 中间的工具就越容易失去存在意义。它的长期价值取决于两件事：一是能不能把“跨 agent 共享工具与 skill”做成真正的刚需资产，而不是只被当成临时的 token 压缩器；二是能不能证明自己挑工具挑得准。第二点比第一点难，也更要紧。 想试的话，最省事的验证方法是先跑 mcptoon bench 和 mcptoon demo --quick 看数字，别直接 quickstart，因为那一步会动配置。