The important distinction
MCP lists tools. The host decides how the model sees them.
MCP supports listing and calling tools. It does not require a host to place every definition into the model’s prompt, nor does the stable protocol define one semantic tool-search system. Progressive exposure is primarily a host, model-provider, or framework capability.
What “progressive” means
Instead of handing the AI the instruction manual for every connected action on every turn, the host starts with a small catalog—often server or namespace names and descriptions. When the request requires a capability, the model searches the catalog and loads the full definitions for a few relevant tools.
Vendors use several names: tool search, deferred tool loading, dynamic tool discovery, dynamic tool selection, and progressive tool disclosure. The mechanisms vary, but the goal is similar.
Up-front loading
EVERY TURNSimple for a small catalog. Increasingly expensive and distracting as servers and tools accumulate.
Progressive discovery
AS NEEDEDMore room for the actual task, more stable caching, and fewer irrelevant choices—with an extra discovery step.
When it is worth using
Loading everything remains reasonable for a small, stable set of tools. Progressive discovery becomes useful when definitions occupy a meaningful part of the model’s context, when users may connect many servers, or when permissions produce large tenant-specific catalogs.
Measure instead of guessing. Track tool-definition tokens, time to first response, search recall, selection accuracy, cache behavior, and end-to-end task success. The right threshold depends on the model, catalog, and user job.
Verified support as of July 28, 2026
| Product | Vendor term / approach | Automatic? | MCP-aware? |
|---|---|---|---|
| OpenAI Responses API | Native tool_search with defer_loading on functions, namespaces, or MCP servers; supported on GPT-5.4 and later. | Explicit API configuration | Yes |
| OpenAI Codex CLI | MCP tools use tool search by default when the selected model/provider supports it, with fallback behavior for older support. | Yes, when supported | Yes |
| Anthropic Claude API | Native regex or BM25 Tool Search with deferred tools; also supports custom search implementations. | Explicit API configuration | Yes, including MCP connector toolsets |
| Claude Code | MCP Tool Search; tools are deferred and discovered on demand by default, with configurable thresholds and eager exceptions. | Yes by default, with documented fallbacks | Yes |
| GitHub Copilot in VS Code | Client-side semantic tool_search, keeping core tools loaded and deferring the rest in current VS Code releases. | Yes | Yes |
| Cursor Agent | On-demand MCP discovery and loading from project definitions. | Yes | Yes; search algorithm not publicly specified |
| Microsoft 365 Copilot | Dynamic tool discovery lets agents discover tools at runtime for MCP server-based plugins. | Default for current MCP plugins | Yes |
| Gemini CLI | Discovers tools from configured MCP servers during startup or connection. Official documentation does not describe deferred semantic loading. | No documented progressive mode | Yes, but eager discovery |
| Cloudflare MCP Server Portals | Code Mode search-and-execute facade: a small search/execution surface discovers upstream tools and processes results in a sandbox. | Architectural choice | Yes, through a gateway pattern |
Support can differ by product surface, model, version, proxy, and configuration. For example, verified behavior in GitHub Copilot for VS Code should not be generalized to every Copilot product. We have not found official evidence that the ChatGPT consumer interface progressively loads every custom MCP app in the same way as the Responses API.
What an MCP server author should do
- Give the server a short, discriminative description that explains its domain and when its tools are useful.
- Use focused, distinctive tool names and descriptions; put the selection-critical detail first.
- Group related capabilities by user intent or domain, and remove duplicative tools.
- Keep a small number of frequent or foundational tools eager only when the host supports that choice and the token cost is justified.
- Apply authorization before a tool can become visible in search results. Discovery must not leak capability or record names across roles or tenants.
- Re-index when the server legitimately signals a changed tool list.
- Test whether the right tool can be found separately from whether it can be called correctly.
Avoid a fragile workaround
Do not mutate one connection’s tool list as a hidden side effect of a “load domain” call.
Use host/provider tool search, an explicit search-and-execute facade, or request-time permission filtering. Current protocol work allows lists to change over time or by authorization, but not as arbitrary connection-specific hidden state.
The tradeoff
Discovery adds a step, and a search system can fail to retrieve a relevant tool. Keep evaluation coverage for synonyms, indirect requests, similar tool names, permission-filtered catalogs, and rare but critical operations. For very small catalogs, up-front loading may still be more reliable and simpler.
A good default posture
Keep the frequent core visible. Make the long tail searchable.
The model retains a useful map of available domains without paying the full schema cost until the user’s request actually needs it.
Primary references: official MCP client best practices, OpenAI Tool Search, Claude Code MCP Tool Search, VS Code/GitHub Copilot implementation notes, Cursor 2.4 release notes, Microsoft dynamic tool discovery, and Gemini CLI MCP documentation.