3814个参数描述全是同一句话，137.5KB白烧了

一个MCP服务器的 tools/list 响应，是它对外发布的最常被读取的文档。每个客户端在连接时都会拉取它，模型读它来决定调用哪个工具、传什么参数。多数人盯着的是"你暴露了多少个工具"，几乎没人关心工具与工具之间的那些字节到底在干什么。

minia2a 团队量了一遍自己的。结果是一句合成出来的话，在每次会话的工具清单里占掉 137.5 KB，什么信息都没说。

删掉这一句生成出来的话之后，每个工具清单少掉 137.5 KB——占整个载荷的 28.3%。

测出来的东西

一次不带鉴权、不带支付头的调用就能复现：向 https://minia2a.uk/mcp 发一个 JSON-RPC 请求，method 为 tools/list，返回状态码 200，下载体积 357167 字节。

修复之前，3815 个参数槽位里有 3814 个带着描述。每一个都长这样：

"description": " to process"

不是相似，是逐字相同，只有字段名不同。board 被描述成"board to process"，state 被描述成"state to process"。

这句话不是人写的，是服务时生成的

这一点值得在自己的服务器上查一遍，因为它决定了补救方式。磁盘上的 schema 文件根本不是一份 JSON Schema 文档，而是一个从服务 id 到参数名列表的映射：

{"x402-2048-move": ["board", "state"], "x402-abbreviation": ["text"], ...}

一共 1624 条，文件里没有任何 description 字段。网关把每个参数名转成参数 schema，而 schema 的形状需要一个 description 槽位，于是它用"参数名 + to process"填了进去。没人写过那句话。是一条代码路径写了 3814 次，而且没有任何评审者见过它——因为评审者会打开的那份文档，不是客户端收到的那份文档。

如果你的描述是从字段名生成的，那你没有描述。你有一笔成本。

把价格还原出来

修复前的载荷没有存档，所以团队精确重建了被删掉的那段碎片——每个参数槽位一个 ,"description":" to process"，按 JSON 编码后的样子：

• 140842 字节 = 137.5 KB，分布在 3815 个槽位上
• 357167 + 140842 = 498009 字节 = 486.3 KB，这是反事实体积

修复前另有一次独立测量，读数是 482 KB。重建值比它高 0.9%——足够接近，说明"每个参数槽位一个 description 键、追加在末尾"这个模型就是全部真相，差距来自格式，不是漏了某一项。

为什么值得写下来

参数描述是工具目录承载语义的地方。名字叫 board，模型从中看不出期望格式、取值范围，也看不出它是一串整数还是一个走法字符串。真正的描述，是读者无法从名字推导出来的文本——这就是全部的检验标准。按这个标准，这里有 3815 个字段没有语义，137.5 KB 的噪声在承载它们，而这份文档在每次会话开始时都会被拉取。

有两个属性让这类缺陷容易上线、难以察觉：

• 它对规范不可见。description 在 JSON Schema 属性里是可选的，用填充文本填满它完全合法，没有任何东西会拒绝。
• 它对测试不可见。一个 schema 形状测试断言这个键存在、且是字符串。两条都成立。断言这个字符串不可从名字推导，才是缺失的那项检查，而形状测试表达不了它。

它对评审同样不可见，因为被评审的产物（schema 文件）里并不包含客户端收到的那句话。

查一遍自己的目录

这段脚本能跑在任何支持 streamable HTTP 的 MCP 服务器上。它拉取 tools/list，然后报告两半：你的参数文本里有多少是在复述字段名，以及这种复述花掉了多少字节。

在修复前的目录上，它报告 3814 / 3815 属于复述——100%——以及 137.5 KB。在当前目录上，它报告 0 和 0.0 KB，因为字段现在只带一个名字和一个类型，别的什么都没有——从信息量上说，它们本来也就只带了这些。区别在于，客户端为被告知这件事付了多少钱。

修复是删除，不是重写

最容易上钩的反应是"生成更好的描述"。忍住。一个产出过坏句子的生成器，会换一种风格继续产出坏句子：让它变坏的性质是它的输入只有字段名，而一个只以字段名为输入的生成器，产不出读者无法推导的文本。要么把描述写在人能看见、或者手里握着参数含义的模型能看见的地方，要么干脆不输出描述。两种都行。填充文本不行，因为它和内容一样贵，在 grep 眼里也和内容长得一样。

方法说明：上述响应体积、工具数、参数数、描述数，都来自 2026-10-16 一次实时的 tools/list 调用，可用第一条命令复现。137.5 KB 这个数字是对被删碎片的还原，不是存档的修复前读数；482 KB 的修复前读数是独立测量，两者 0.9% 的吻合度一并给出，供你自行权衡。