Feature: hierarchical deferred tool discovery to reduce context usage from large MCP servers

Resolved 💬 3 comments Opened Feb 20, 2026 by DanielPBak Closed Feb 24, 2026

Problem

When an MCP server exposes a large number of tools (e.g., a gRPC proxy with hundreds of methods across multiple services), the deferred tool list alone consumes significant context. Even though the tools are deferred and their full schemas aren't loaded, every tool name is included in the system prompt so the model knows they exist for ToolSearch.

In our case, we have ~200 deferred tools across ~8 services from a single MCP server. The tool name list alone eats into the context window on every turn, even when production data queries aren't needed.

Proposed solution

Support hierarchical/nested deferred tool discovery. Instead of listing every tool name in the system prompt, allow grouping tools under namespaces or services. The model would only see the top-level groups, then expand into individual tools on demand:

  1. Level 0 (system prompt): Model sees 8 service groups (e.g., my_server/wallet, my_server/accounting, my_server/ledger)
  2. Level 1 (ToolSearch on a group): Model sees the individual tool names within that service (e.g., GetPlanAccount, ListPlanAccounts, ...)
  3. Level 2 (ToolSearch on a specific tool): Model loads the full JSON schema for that tool

This would reduce the context footprint from ~200 tool entries to ~8 group entries, with no loss of capability since the model can drill down when needed.

Context

This likely affects anyone connecting Claude Code to large MCP servers (enterprise gRPC services, large API gateways, etc.) where the number of available operations is high but only a few are needed per session.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗