Your Agent Has Too Many Tools

Cloudflare recently published a preview of its new company-wide CLI. The scale is striking: more than 100 products and nearly 3,000 API operations, all moving toward one command-line interface.

Cloudflare already exposes its API through a Code Mode MCP server that uses fewer than 1,000 tokens. So the interesting part is not that a CLI can replace MCP.

It is that a CLI gives agents something MCP does not guarantee by itself:

Progressive disclosure.

Tool-context management is the practice of separating the capabilities an agent can access from the tool definitions loaded into its active prompt.

Tools Are Not Free

Every tool definition loaded into a model’s context has a cost before it is ever called.

Its name, description, and input schema consume context. A larger toolset also gives the model more candidates to distinguish between. Anthropic’s tool-search documentation gives a useful example: a typical collection of MCP servers can consume roughly 55,000 tokens in tool definitions before the agent starts working.

That is not necessarily a limitation of the MCP protocol. It is a limitation of loading a large capability surface eagerly.

A CLI avoids much of this by exposing a small entry point and a navigable command tree:

cf --help
cf dns --help
cf dns records --help

The agent learns only what it needs at each step. The rest of the interface stays outside the context window.

This is the same search-inspect-expand loop that makes coding agents effective at navigating code. The difference is that the agent is constructing a working set of capabilities instead of a working set of information.

Tool Search Brings the Pattern Back to MCP

The model-native alternative is dynamic tool search.

Instead of registering every function in the model’s initial context, the harness provides a small search tool and defers the rest. The model searches the catalog, loads a relevant subset, and then calls those tools normally.

Anthropic introduced its Tool Search Tool in beta on November 24, 2025. Claude Code followed by enabling automatic MCP tool search by default in version 2.1.7, released January 14, 2026, when MCP tool descriptions exceed 10% of the context window. OpenAI introduced tool search with GPT-5.4 on March 5, 2026.

The idea is shared. The implementations are not.

Anthropic’s API still receives the complete tool catalog, but tools marked defer_loading are left out of the model’s initial context. A regex or BM25 search returns tool_reference blocks, which the API appends inline at the point of discovery and expands into full definitions. At that moment the block is near the current tail; on later turns it remains at that point in the conversation history. Claude Code adds its own policy on top, automatically deferring MCP tools once their descriptions cross its configured threshold.

OpenAI’s implementation begins with a lightweight description of each searchable namespace or MCP server. Individual deferred functions still expose their name and description, while primarily deferring their parameter schemas. OpenAI supports both hosted search and client-executed search, and explicitly says all loaded definitions are injected at the end of the model’s context window to preserve the existing cache.

Both approaches preserve the useful property of MCP—typed, structured tools—without making the entire catalog resident from the first turn.

Mechanism	What the model initially sees	Cache behavior	Portability
Anthropic Tool Search	The search tool and non-deferred tools	Discovered definitions are inserted inline, preserving the stable prefix	Supported Claude models through the Anthropic API
OpenAI Tool Search	Namespace or MCP server descriptions and deferred tool names	Loaded definitions are appended at the end of the context	GPT-5.4+ through the OpenAI Responses API
CLI discovery	A command entry point; --help output appears only when requested	Does not change the registered tool prefix	Broad across agents that can run shell commands
Harness-managed discovery	A search step followed by a rebuilt tool list	Changing the tool list may force a cache miss	Varies by model and API; requires testing

But tool search is not a portable property of MCP. It needs support from the model, API, and agent harness. OpenAI limits its native tool search to GPT-5.4 and later, while Anthropic publishes its own Claude model compatibility list. An open model behind an OpenAI-compatible server may not offer the model-level tool-search capability built into supported Claude and OpenAI models. Its server may reject the extra fields, or the model may fail to understand the discovery protocol or select tools reliably after loading.

As of July 2026, the official API documentation for DeepSeek, Z.AI’s GLM models, and MiniMax documents ordinary function calling, but I could not find a provider-native equivalent to Anthropic or OpenAI’s deferred tool search in their current documentation or API schemas. That does not prevent a CLI or agent harness from implementing discovery as an ordinary tool; it means API compatibility alone is not evidence that the native protocol will work.

Loading a tool is only half the lifecycle problem. Unloading one can be harder. Some APIs or models may reject a later request when the conversation history contains a tool call whose definition is no longer registered. For those stacks, the safe assumption is that a loaded tool must remain in context until the relevant history is compacted or the session is restarted.

The behavior varies across providers and models. A multi-model harness may need its own rules for discovering, injecting, retaining, and retiring tool definitions, along with prompts that teach each model when to search before calling. Those rules need to be tested across normal turns, compaction, and resume so an optimization does not leave the session in an invalid state. A CLI and its --help tree remain the more portable progressive-disclosure mechanism because they expose capabilities as ordinary text without changing the model’s registered tool grammar.

The Cache Is Part of the Design

Progressive loading is not only about context length. It also affects prompt caching.

Anthropic and OpenAI both designed native tool search to preserve the existing prompt cache. Anthropic keeps its tools → system → messages prefix unchanged and inserts discovered definitions inline in the conversation. OpenAI appends loaded tools at the end of the context. In both cases, tool discovery can happen inside a session without rewriting its stable prefix.

The absence of this first-class support matters most when a harness needs to work across open-model providers. Without it, a harness may have to add a newly discovered definition to the tool list at the start of the next request. That typically forces a cache miss on that turn; if the expanded list then stays stable, later turns can reuse the new prefix. MiniMax’s documented cache order—tool list → system prompts → user messages—shows why changing the tool list can invalidate everything after it.

OpenAI’s cache remains mostly transparent on GPT-5.4: applications can influence routing and retention but cannot place explicit breakpoints. GPT-5.6 and later add explicit cache breakpoints and use prompt_cache_key. Either way, measure cached_tokens instead of assuming the cache behaved as intended.

There is still no free lunch. Once a tool has been loaded into the conversation, it becomes part of the agent’s working context. OpenAI lets applications remove a loaded tool from later turns, but changing that loaded set breaks the cache from that point forward. Keeping the tool spends context; removing it sacrifices cache locality.

That is a lifecycle decision, not just an API decision.

Tool Management Is Context Management

I initially assumed CLIs were simply better suited than MCP to large capability surfaces, and they remain a credible alternative today. Native tool search narrows that advantage by bringing progressive disclosure to MCP tools. The deeper lesson is that giving an agent access to a tool and placing that tool in its context are separate decisions.

Tool search and CLIs implement the same progressive-disclosure pattern: keep the catalog outside the working context, load only what the task needs, and treat loaded definitions as session state because changing them can affect both cache and history. Use native tool search when the model and API support it; use CLI discovery or carefully tested harness logic when they do not.

Keep the capability surface broad and the active tool context small.

As tool catalogs grow, the hard problem will not be connecting more tools. It will be deciding which ones belong in the context for this turn.