MCP 成本审计改为逐轮计算工具定义

两位读者在评论区质疑了我的计费模型，他们说得对。因此，mcp-tax 0.3 重新构建了这个模型。

修正：schema 每一轮都会重新进入上下文窗口

旧版 audit 把每台 server 的 tool schema 按每个 session 只计费一次。这是错的——每次 API 调用，整个上下文都会重新发送给模型，其中包括所有 tool schema。一个包含 20 轮交互的 session，如果 schema 占用 30k token，带来的就不是 30k 的额外开销，而是 600k；而且这份 schema 在这 20 轮中，每一轮都必须能装进上下文窗口。

新的计费账本按轮计算。mcp-tax audit --turns 20 会按轮数计算 session 的总开销，同时在 JSON 输出中保留旧版按每个 session 只计算一次的数值，字段名为 old_model_session_tokens，让你清楚看到旧模型少算了多少：它算出的数值，其实是真实值除以交互轮数。感谢 MCPulse 对这个问题的追问——schema 的成本并不是在 tools/list 时支付的，而是在每次调用模型时支付的。（另外，prompt caching 只会降低价格，不会减少上下文窗口占用。因此，账本将 billable_tokens 和 cumulative_window_tokens 分成两列记录。）

按 server 拆分 preamble

现在，每台 server 都有独立的计费条目：各自的 preamble（每一轮重新注入的 token）、累计上下文窗口 token 数，以及计费 token 数。preamble 才是你实际做取舍的单位——禁用成本最高的那一项，就能看到总开销随之变化。

按页统计传输字节数

tools/list 分页现在会报告每一页的传输字节数，这是另一个独立的衡量维度。传输字节数代表发现工具时的传输成本，每个 session 只支付一次；它不属于上下文额外开销，也不会重新进入上下文窗口。一台 server 可能在传输上很啰嗦（分成许多小页面），但 schema 成本很低；也可能反过来。audit 会同时展示这两个维度，避免你再把它们混为一谈。感谢 Rudratosh Shastri，和他的讨论促成了这次拆分。

pip install mcp-tax
mcp-tax audit --turns 20

34 项测试全部通过（25 项 unittest + 9 项 smoke），仅依赖 stdlib，采用 MIT 许可证。

GitHub：hahahahahahahahah6/mcp-tax

PyPI：mcp-tax/0.3.0/

如果需要进一步采取行动，你可以考虑屏蔽此人和／或举报滥用行为。