25 款 MCP Server 上下文税实测：Notion 占用 1.9 万 token，差距达 544 倍

你接入的每一个 MCP Server 都附带一组工具定义 Schema。这些 Schema 会在整个会话期间注入到每一次模型请求中——甚至在你向 Agent 提问之前就注入了。这是一笔固定的上下文窗口税和账单税，而且没有任何 MCP 目录会列出这个数字。

所以我动手测量了。我拉取了 25 个流行的 Model Context Protocol Server，在本地启动每一个，运行真实的 tools/list 握手，然后用 chars/4 计算它们每个请求的 Schema 消耗的 token 数（这是 tokenscope 使用的启发式方法，标注为估算值）。25 个中有 16 个不需要真实凭证即可注册工具，因此这些得到了测量；其余的需要 OAuth/远程传输或真实密钥，标注为未测量，也不做估算。

上下文税，测量结果

这是一个 544 倍的跨度——从 35 tokens 到略超过 19,000，在整个会话的每个请求中都要支付。把 notion-mcp 和 github 同时连上，你就接近 ~23k tokens 的纯 Schema 开销，而这还没有开始处理任何一个用户轮次。对于一个长期运行的 Agent 任务，这不是可以四舍五入的误差；它吃掉了你大部分的上下文预算，也是账单上一笔真实的支出。

教训不是"不要用大的 Server"。而是这笔成本在连接时是不可见的，那些按星标/安装量对 Server 排名的目录也不会告诉你。你只能在账单上看到它。

趁着我打开这些包的时候，我也扫描了它们的行为

同样是这 25 个 Server，静态源码扫描（不执行任何代码）：网络出口、secret-env 读取、exec/shell 暴露面。有几点值得关注：

25 个中有 16 个读取了 secret env 变量；25 个中有 8 个有 exec/shell 暴露面。upstash-context7-mcp 读取了 OPENAI_APPS_CHALLENGE_TOKEN + CLIENT_IP_ENCRYPTION_KEY，并向外发往 login.microsoftonline.com。

25 个中有 4 个附带了打包/压缩后的 dist（exa 有 293k 字符的行；notion 有 582k）。你无法静态地将一个压缩后的 blob 分离出调用站点的主机 vs 嵌入的字符串，所以我把它们标注为打包——出口无法静态解析，而不是渲染一个误导性的"干净"标签。exa 的包中除了 api.exa.ai 还引用了未披露的 api.agnost.ai。

对这 25 个 Server 做到诚实的出口扫描是主要工作量——naive 扫描会把注释/jsdoc 中的 URL 也算作出口（有一个 Server"打电话回家"到了 wikipedia.org 和 rfc-editor.org……来自文档字符串）。一个主机只有在它的 URL 字面量处于实际网络调用站点或声明的 API base 中时才算出口。

上面的上下文税是 Server 端的、固定的开销。你自己 Agent 的每会话成本——哪个 Server 的 Schema 在消耗你的窗口、一次运行实际花了多少钱——你可以直接测量：

npx @wartzar-bee/tokenscope

如果你想在成本回归上线前就阻止它，wartzar-bee/ci-guardrail 会在 CI 中以你拦截失败测试相同的方式拦截 token 成本。

这里所有内容都来自已发布的 npm 包——npm pack 这些 Server，运行扫描器，为每个启动 live tools/list。发现有单元格错了？方法是开放的；去纠正它。

这是 wartzar-bee 的一部分——用于构建和运营成本高效自主 Agent 的工具。Apache-2.0。