When an AI has too many tools, the actual work barely fits

A strategy-development agent needs data, a backtest, a chart, trades, and dozens of other actions. If every prompt carries the full catalog, tool descriptions fill the context window before the model even looks at the code.

That is why we are adding Progressive Tool Discovery to XTester.McpHost and plan to use it in XTester Studio. The host keeps the full list. The model first sees a small finder and loads only the tool for the current step.

What happens if you hand the agent the whole catalog

MCP (Model Context Protocol) lets an AI call environment functions: load history, run a test, open a chart. Each function arrives with a name, a description, and an argument schema. One schema easily costs hundreds of tokens. Dozens of tools cost thousands, before the user has asked a question.

Space is not the only thing that breaks. The model also picks the wrong call more often when similar actions sit side by side: several ways to read trades, several ways to start a test. In a trading IDE that shows up quickly. There are many domain operations, and the task is often narrow: inspect one entry on one stretch of history.

How Progressive Tool Discovery works

The host still knows the whole catalog. It does not dump every schema into the model.

A typical loop looks like this:

1. The model gets a small search tool.
2. It describes what it needs now: run a backtest, or open trades for a period.
3. The host returns a few matching names with short descriptions.
4. The full schema is loaded only for the chosen call.

This is the client pattern described in the MCP docs: tools/list stays with the host; the model sees search_tools and on-demand loading. It does not shrink what the environment can do. It changes when a description enters the window.

Why this matters when you develop a strategy

Take the step “why did the strategy enter here.” The agent needs a chart, a trade list, and maybe the run parameters. It does not need export tools, a cloud queue, every exchange connector, and the full help surface at the same time.

XTester Studio is built around that loop: write, compile, test on history, then inspect the result. Progressive Tool Discovery matches the loop. Debugging an entry loads a narrow set. Comparing runs loads a different set.

XTester.McpHost is already a separate process through which an agent talks to the engine and the project. On-demand tool discovery will live in that host, then in Studio. That is the implementation plan, not a claim that the feature is already in a public Studio build.

When a full list is still fine

If there are few tools and the descriptions are short, handing over the whole set is simpler. Search adds a step and a little latency.

A full list is reasonable when the set is fixed and narrow: three read-only calls for one scenario. Progressive discovery is for a catalog that grows with the environment: data, tests, charts, a journal, orders, run comparison.

Approach	What the model sees first	When to use it
Full catalog	Every name and schema	Few tools, stable set
Explicit short set	Only preselected calls	A known scenario, no search
Progressive Tool Discovery	A finder, then one or a few schemas	A large, growing trading-IDE catalog

We do not copy token-savings percentages from other products. Each catalog has its own description length. The point is the same: context should go to the work, not to the menu.

Limits

This article explains a mechanism. It is not trading advice. Loading a tool on demand does not make a backtest more honest by itself: fees, slippage, period choice, and overfitting remain. The exact MCP calls and the moment the feature appears in Studio depend on the McpHost implementation. What we describe here is the principle we are putting in.

If you write strategies and attach an agent to them, watch how many tools sit in the current prompt, not how many exist in the system. The next step usually needs one call, not the whole workbench.

Related: XTester Studio on Code - OSS, walk-forward and out-of-sample checks.