最近在用Claude Code做项目，发现上下文窗口莫名其妙消耗很快，有时候对话才刚开始，可用token就已经去了一大半。排查了一圈，才发现元凶是我安装的MCP server。
问题根源：tool description的隐性开销
MCP（Model Context Protocol）允许Claude调用外部工具。每个MCP server在初始化时，会把所有tool的名称、描述、参数schema一起注入到上下文里。这些描述如果写得冗长，积少成多，消耗非常可观。
举个实际案例：我有一个MCP server注册了23个工具，每个工具的description平均350个token，光这一个server就占掉了8000+token——还没开始干任何事。
问题在于这个消耗是不透明的。你不知道哪个server最"重"，不知道哪个tool的描述写得最啰嗦，也没有工具帮你可视化这个开销。
解决思路：先诊断，再优化
我做了一个命令行工具 mcp-checkup，专门用来扫描和分析MCP工具的token消耗情况。
核心功能：
- 读取本地Claude的MCP配置文件
- 枚举所有已安装server及其注册的tools
- 计算每个tool description的token数量
- 按消耗排序，标记"膨胀"的tool
- 输出优化建议（哪些description值得缩减）
使用方式：
npx mcp-checkup
不需要任何配置，直接读取现有的MCP配置，输出报告。
输出示例（简化版）：
MCP Token Audit Report
======================
Server: filesystem
read_file 142 tokens
write_file 189 tokens
list_directory 97 tokens
...
Server total: 1,847 tokens
Server: github
create_pull_request 412 tokens ⚠️ HIGH
list_issues 388 tokens ⚠️ HIGH
...
Server total: 6,203 tokens 🔴 BLOATED
Total across all servers: 11,429 tokens
优化方向
找到膨胀的tool之后，有几种处理方式：
- 联系server维护者：有些冗长描述是开发者没有意识到，提issue往往有效
- 自行fork修改：如果是开源server，trim掉冗余的parameter descriptions
- 选择性加载：很多MCP server支持只暴露部分工具，不需要的工具不注册
- 换替代品：同类功能的server，选description更简洁的
背景：为什么这个问题值得关注
随着MCP生态快速扩张，越来越多的开发者会同时安装5-10个甚至更多MCP server。每个server的开发者都在自己的工具描述里努力写清楚功能，结果集合起来就是一场token灾难。
这个问题会随着MCP采用率上升变得越来越普遍。mcp-checkup的定位不是"修复"，而是让这个隐性成本变得可见——可见才能优化。
GitHub: github.com/yifanyifan8…
如果你在用Claude + MCP，欢迎跑一下看看你的实际情况。有问题或者建议欢迎开issue。
