MCP 目录列 star 数、列 README、列安装命令。 没有一家告诉你：这个工具每次调用烧掉多少 token， 其中有多少返回内容模型根本没看。
chain.eco 是 agent / 工具 / MCP server 的编排层目录——以实测调用成本为索引，不是以流行度。
回答「你这笔 token 花得冤不冤」。上下文预算、缓存纪律、跨模型成本—— 先把浪费量出来。
回答「这些能力怎么串起来才不亏」。把度量结果落到具体工具上， 成为选型时真正有用的那一列数据。
度量在前，编排在后。没有前者的数据，后者就只是又一个 star 数排行榜—— 那种东西已经有很多了。
工具定义本身占多少上下文、一次典型调用的输入输出规模。 这是每轮对话都要付的固定开销，不是一次性的。
工具吐回来的内容，有多大比例从未被模型在后续回复里引用。 高浪费率的工具值得换一个，或者改调用方式。
工具定义是否稳定、会不会因为动态 schema 反复击穿 prompt cache。 这一项的影响常常比 token 数本身更大。
数据来自 token.best 的匿名聚合，不含任何用户内容、不含 prompt 原文。 条目发布前会标注样本量——样本不足的不发。
这个域名要求注册人签署可持续承诺。 对我们来说这不是一道需要应付的手续。
推理是真实的电力消耗。一次没必要的工具调用、一段每轮都重进上下文却从没被用到的 系统提示词、一个反复击穿缓存的 schema——这些都不只是账单上的数字， 它们对应着实际被烧掉的算力。
减少无效 token，就是减少算力浪费。 这恰好就是 token.best 和 chain.eco 在做的事。承诺与产品方向一致， 所以我们签得下去。
我们不会把这里做成环保主题站——那是另一回事。这只是说明为什么 .eco 对这个项目是合适的后缀，而不是随手挑的。