MCP工具描述导致token膨胀？我写了个诊断工具

最近在用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之后，有几种处理方式：

1. 联系server维护者：有些冗长描述是开发者没有意识到，提issue往往有效
2. 自行fork修改：如果是开源server，trim掉冗余的parameter descriptions
3. 选择性加载：很多MCP server支持只暴露部分工具，不需要的工具不注册
4. 换替代品：同类功能的server，选description更简洁的

背景：为什么这个问题值得关注

随着MCP生态快速扩张，越来越多的开发者会同时安装5-10个甚至更多MCP server。每个server的开发者都在自己的工具描述里努力写清楚功能，结果集合起来就是一场token灾难。

这个问题会随着MCP采用率上升变得越来越普遍。mcp-checkup的定位不是"修复"，而是让这个隐性成本变得可见——可见才能优化。

GitHub: github.com/yifanyifan8…

如果你在用Claude + MCP，欢迎跑一下看看你的实际情况。有问题或者建议欢迎开issue。