/context counts tool schemas as "Messages" — needs separate "System tools" and "MCP tools" rows

Related

This is not a duplicate of the closed feature requests #16414 and #19891 (both asked for more granular /context output and were closed by the inactivity bot without maintainer response). This issue is narrower and is a bug, not an enhancement: the tools field is misattributed to the "Messages" category, not merely coarse.

What's wrong

/context reports tool-definition tokens (the API tools field — both built-in tools and MCP tool schemas) under the "Messages" category. "Messages" should be the conversation. On a clean session where I typed one word (hello), /context showed 93.7k tokens under "Messages" while the actual on-screen conversation was ~130 tokens. The tokens aren't just coarsely grouped — they're filed under the wrong heading, so a brand-new session looks like it already has a huge conversation history. There is no "Tools" or "MCP tools" category at all.

Measured across three clean sessions, varying only how many tools were loaded (conversation was ~130 tokens each time):

| tools on the wire | /context "Messages" | real request cost (response usage) |
|---:|---:|---:|
| 11 | 26.4k | 37,008 |
| 25 | 39.1k | 49,657 |
| 133 | 93.7k | 104,227 |

"Messages" tracks the tool count, not what I typed. The "real request cost" is cache_creation_input_tokens from each request's own streamed response usage, which matches the /context total — so the total is right, only the per-category attribution is wrong.

What should happen

"Messages" should count only the on-screen conversation (user/assistant turns, commands and their output) — ~130 tokens in the runs above. Tool schemas should get their own row(s), ideally split into:

• System tools — built-in tool schemas. Fold in the tool-related first-turn reminders (the ToolSearch/deferred-tools notice and the agent-types list) since they describe the tool machinery rather than the conversation.
• MCP tools — MCP tool schemas, ideally broken down per server.

Skills and Memory files are already broken out into their own rows correctly (single-counted; the category sum equals the total) and should stay as-is.

Steps to reproduce

1. Start Claude Code in a session with several MCP servers configured.
2. Run /clear.
3. Type a single word (e.g. hello) and send.
4. Run /context.
5. Observe "Messages" showing tens of thousands of tokens despite the conversation being one word. The figure rises as more tools/MCP servers are loaded, confirming it is counting the tools field rather than the conversation.

Environment

• Claude Code CLI 2.1.185 (data captured) / 2.1.217 (installed)
• Model: Claude Opus 4.8
• Reproduced with tool-search (deferred MCP tools) both on and off

Secondary observation (possibly a separate issue, unconfirmed on public API)

POST /v1/messages/count_tokens appears to ignore the tools field: a request carrying a ~232 KB tools array returned input_tokens: 8. If reproducible on api.anthropic.com, count_tokens is undercounting real prompt cost by the entire tool-schema size. Observed through a proxy, so a proxy-side cause can't be fully ruled out.