The short version: Microsoft's agent framework just made a change that quietly fixes one of the most expensive habits in agent engineering. As of the Python package python-1.11.0 (July 10, 2026), an agent no longer has to load every MCP tool's schema into its context up front. Instead it gets a handful of loader tools and discovers, loads, and unloads tool schemas on demand — while the allowed_tools allow-list still bounds everything it can touch. If your agent talks to several MCP servers, this is the flag that stops you paying for tool definitions the model never uses.

The problem, stated plainly#

Every MCP tool ships a schema: its name, its parameters, their types, a description. That schema is text, and it lives in the model's context so the model knows the tool exists. One server with a dozen tools is fine. But connect a filesystem server, a database server, a browser server, and a couple of SaaS integrations, and you can front-load tens of thousands of tokens of pure schema before the agent has read a single line of the actual task. The framework's own pull request says it directly: a large MCP server "expose[s] many tools, which frontloads a lot of schema into the model context even when only a small subset is needed" (PR #6850).

That costs money on every turn, and — less obviously — it costs accuracy. A model choosing among 80 tools it can barely see is worse at picking the right one than a model choosing among the five that matter. This is the same failure we mapped in Too Many Tools: tool search vs code execution, and it's the reason "how many tools can I attach?" is the wrong question.

What progressive disclosure actually does#

Instead of dumping all schemas in at session start, the framework hands the model a small set of loader tools plus anything you explicitly name in always_load. The loader tools do three things, and their names tell the whole story:

So the model works the way a developer reads API docs: skim the index, open the one page you need, close it, move on. The verbatim release note describes it as letting agents "discover, load, and unload MCP tool schemas on demand while keeping the allowed_tools boundary intact" (python-1.11.0). You turn it on with a flag (use_progressive_disclosure), pre-load the handful of tools that are used on nearly every turn with always_load, and leave the long tail to be fetched lazily.

The model works the way a developer reads API docs: skim the index, open the one page you need, close it, move on.

The security question answers itself. Progressive disclosure changes when a tool's schema enters context — not whether the tool is allowed. Your allowed_tools allow-list is the same hard boundary it always was; nothing outside it can be discovered or loaded. That matters, because the last thing you want from a token optimization is a new way for an agent to reach a tool you never sanctioned — the kind of boundary erosion we've tracked in MCP tool poisoning.

The two shapes of the fix — and which one this is#

There are two known ways to stop tools from eating your context, and it's worth being precise about which one Microsoft shipped.

Tool search / progressive disclosure keeps tools as tools and loads their schemas lazily. That's this feature. Anthropic productized the same idea for Claude as a Tool Search Tool, reporting roughly an 85% token reduction while keeping the full library reachable.

Code execution with MCP goes further: it turns your tools into a code API the model calls inside a sandbox, so a tool that returns a 10,000-row result can be filtered in code before any of it touches the context window. Anthropic's write-up on that approach reports token savings large enough to change the economics of long agent runs (Code execution with MCP).

Progressive disclosure fixes schema bloat; code execution fixes result bloat too, at the cost of running model-written code in a sandbox. Most teams should reach for progressive disclosure first — it's a flag, not an architecture — and add code execution only when tool outputs, not tool definitions, are what's blowing the budget. If you're not sure which is hurting you, measure the tool context cost before you change anything.

Why this is a convergence, not just a release note#

The interesting part isn't that one framework added one flag. It's that with Microsoft shipping this, the big agent stacks have now landed on the same answer independently. Anthropic did it for Claude. The pattern is trivial to build against any MCP client yourself. And Microsoft — whose framework already leans on progressive disclosure for skills — has now made it a first-class option for MCP tools in Microsoft Agent Framework.

A year ago the field's answer to "too many tools" was "attach fewer tools." That was a real constraint on what agents could do. The new answer is: attach all of them, load none of them until you need one. The tool library stops being a context tax and goes back to being what it should have been — a menu the agent orders from, not a wall it has to read first.