HN讨论 · 身份未知
近 100 个工具的 MCP 工具发现 token 成本：视频编辑器场景
一位开发者在构建可访问近 100 个工具的视频编辑器，工具发现阶段需要不断向模型呈现这些工具，导致 token 开销高。该开发者在 Mcptoon（宣称把发现 tokens 削减 97% 的 MCP CLI 客户端）的评论区询问实现技巧，希望在自己应用里复用。这个具体场景把“大规模工具发现成本”落到真实开发任务上。
查看原始信号hn:49253721
目标用户
构建带大量 MCP 工具（如视频编辑器）的 AI 应用的独立开发者
潜在需求
掌握更高效的工具发现实现方式：在不牺牲工具可用性的前提下，减少工具列表送进模型的 token 成本，并能在自己的编辑器内落地。
发生场景
其在建的视频编辑器 AI 助手可访问近 100 个工具，每次工具发现都可能把这近 100 个工具全量送入上下文，token 开销明显，希望降低这一开销。
来源证据
开发者称其视频编辑器可访问近 100 个工具，并希望了解 Mcptoon 的工具发现优化技术，以让工具发现更高效。
How does it work? Im building a video editor and right now it has access to nearly 100 tools. Would be good to learn the techniques you used to make tool discovery more efficient.https://news.ycombinator.com/item?id=49253721
为什么值得留意
单一评论不代表整体情况，但该评论给出了真实用户规模和真实任务：近 100 个工具的视频编辑场景，正对应 Mcptoon 宣称解决的 97% token 削减问题；即使这个解决方案不成立，也说明大型工具集的发现成本是一个值得观察的实际痛点。
已有方案
- Mcptoon – MCP CLI 客户端，宣称将工具发现 tokens 削减 97%
未满足部分
- 评论者希望获得的工具发现实现细节尚未在讨论中给出，无法直接移植到视频编辑器
可能延伸 · 模型推测
- 将工具发现削减技术抽成通用中间件，供各种 MCP 客户端使用
- 在视频编辑器等应用内实现按需或分层工具加载
- 构建衡量工具发现 token 开销并验证优化效果的测试基准
目前未知
- Mcptoon 的 97% 削减未经独立验证
- 评论者询问技巧，不代表其已尝试并失败于现有方案
- 除该评论者外，是否还有其他同场景用户存在同类需求未见数据
- 评论者的痛点可能不仅是 token 数量，也可能涉及延迟或工具选择准确度
继续核实
- 面向几十到上百个工具的 MCP 应用，工具发现阶段的 token 开销是否还有其他用户报告或量化数据？
- 按需或分层工具发现方案对工具调用准确率有何影响？
- MCP 生态中是否有通用测度工具发现 token 开销的基准？
主题词
llm tool discoverymcp tool listingtoken usagetool selectionlarge tool set