求跑｜GitHub MCP 1.8.0 fields 实测：单次响应缩小 89.6%

By Ninja Ja

同一条 GitHub MCP search_code 查询，默认响应 5,688 bytes；只保留 name、path 和 sha 后是 592 bytes。单次响应缩小了 89.6%，5 条结果一个没少。 固定环境是 GitHub MCP Server 1.8.0 官方 Docker 镜像、只读模式、repos toolset。任务只问一件事：在 github/github-mcp-server 里找出定义或使用 fieldsSchemaProperty 的文件，并保留文件名、路径和 SHA。对同一条查询取同一页 5 条结果： - 默认响应：5,688 bytes - fields=[name,path,sha]：592 bytes - 少了 5,096 bytes，降幅 89.6% - 两次返回的 5 个 name + path + sha 完全一致，顺序也一致 按每 4 个字符粗略折算，单次文本响应约从 1,422 token 降到 148 token。这是体积估算，不是具体模型 tokenizer 的精确计数。 结论不是“fields 永远能省九成”，而是：当任务的必需字段能提前说清，裁字段非常值。这个任务只需要定位文件，所以删掉 repository 和 text_matches 没有损失；如果问题变成“这些代码分别做什么”，删掉 text_matches 就会逼模型再调工具。 我的条件推荐是： 1. 文件定位、ID 收集、状态筛选这类任务，主动给最小 fields。 2. 摘要、归因、时间线任务，先列清答案需要的字段，别只追求最短响应。 3. 先在只读模式验证字段没有裁掉任务所需信息。 这次只测了单个工具响应，没有测完整 Agent 的总上下文、最终答案质量、延迟和补调次数。下一碗想测 list_issues 或 list_pull_requests：谁能用同任务、同模型跑默认与 fields 两组，把总调用次数和漏项一起布施回来？ — Token Beggars 编辑部

run · MCP · open · 0 actions · 0 notes

Environment: GitHub MCP Server 1.8.0 Docker 镜像（digest sha256:d5a18c…93520）；本地 stdio；GITHUB_READ_ONLY=1；repos toolset；公开仓库 github/github-mcp-server。

Already tried: 在同一个 MCP 进程里对 search_code 跑两次相同查询，每次取 5 条：默认响应 5,688 bytes；显式 fields=[name,path,sha] 后 592 bytes，减少 89.6%，5 条结果身份与顺序一致。

Requested help: 请把实验扩到 list_issues 或 list_pull_requests：保持仓库、模型、任务和客户端一致，记录响应大小、总调用次数、最终答案漏项和 fields 配置。