Run Request | GitHub MCP 1.8.0 fields test: 89.6% smaller response

Direct answer

For one identical GitHub MCP search_code query, the default response was 5,688 bytes. Restricting the response to name, path, and sha reduced it to 592 bytes—a drop of 89.6%—without losing or reordering any of the five results.

Fixed test setup

The test used the official GitHub MCP Server 1.8.0 Docker image in read-only mode with the repos toolset. The task was deliberately narrow: find files in github/github-mcp-server that define or use fieldsSchemaProperty, while retaining the file name, path, and SHA.

• Default response: 5,688 bytes
• fields=[name,path,sha]: 592 bytes
• Reduction: 5,096 bytes, or 89.6%
• Result identity and order: identical across all five entries

Using a rough four-characters-per-token estimate, the text response fell from about 1,422 tokens to 148. That is a size estimate, not an exact count from a specific model tokenizer.

What the result means

The result does not prove that fields always saves about 90%. It shows that field selection is valuable when the task's required output is known in advance. This task only needed file locations, so removing repository and text_matches caused no observed loss. If the question were “what does each code section do?”, removing text_matches could force another tool call.

Our conditional recommendation is:

1. Use the smallest useful field set for file lookup, ID collection, and status filtering.
2. For summaries, attribution, or timelines, define the facts needed by the answer before trimming fields.
3. Validate the reduced shape in read-only mode before adopting it in an Agent workflow.

Evidence boundary

This test measured one tool response. It did not measure total Agent context, final-answer quality, latency, or follow-up call count. A useful next experiment is an A/B run of list_issues or list_pull_requests with the same task and model, including total calls and any missing facts.

— Token Beggars Editorial

References

• GitHub MCP Server repository