Deferred Tool Loading, Explained: Treat Tool Schemas as a Context Budget

An agent connected to hundreds of tools does not need hundreds of tool schemas in every model call. Deferred loading makes the catalog available without making the catalog permanently present.

1. Tool availability and tool presence are different

Connecting an agent to a tool server answers one question: what capabilities may the runtime reach? Loading every tool definition into the model context answers another: what descriptions and schemas must the model consider on this step?

Those questions are often collapsed. In a small demo, one server exposes a handful of tools and preloading them is harmless. In an enterprise catalog, an agent may connect to many MCP servers, each with dozens of operations. Every definition brings a name, description, input schema, and potentially an output schema. The model pays that context cost before it knows whether the user needs any of them.

TrueForge’s deferred tool loading separates reachability from immediate visibility. The documented default is preload disabled. At startup, the model sees the MCP server’s name and description. Individual tool schemas are discovered when the task requires them.

2. Why schemas are not free metadata

A tool definition is executable vocabulary. It tells the model what action exists, how to call it, and what structure to expect. That information can be essential. It can also be redundant across thousands of requests that never use the tool.

The recurring cost has four dimensions:

• Tokens. Definitions occupy the same finite input window as instructions, history, retrieved evidence, and tool results.
• Attention. More candidates make selection harder, especially when descriptions overlap.
• Latency and spend. Larger recurring inputs can increase processing time and billed input volume, depending on the model and cache behavior.
• Change surface. A catalog update can alter what appears in context even when the task uses none of the changed tools.

This does not mean “fewer tools is always better.” The goal is the right information at the right time. Preloading is useful when a small set of tools is called on nearly every turn and their schemas help the model plan correctly from the first step.

3. The documented discovery loop

When preload is disabled, TrueForge exposes four meta tools in place of every individual definition:

The first use therefore requires a short planning loop. The model recognizes the relevant server, lists its tools, inspects a candidate, and calls it. TrueForge documentation notes that these discovery round-trips happen the first time a tool is needed and are cheaper than carrying all schemas on every model call.

That is a workload claim, not a mathematical law. A poor server description can send the model to the wrong catalog. Ambiguous tool names can require multiple inspections. A frequently used tool may cost more to rediscover than to preload. Measure real trajectories.

4. Selective preload is usually the interesting setting

TrueForge does not force an all-or-nothing choice. The documented configuration supports keeping a server deferred while preloading named tools. This is the practical middle path for a server with a long tail and a small hot set.

{
  "mcp_servers": [
    {
      "name": "github",
      "preload": false,
      "preload_tools": ["search_pull_requests"]
    }
  ]
}

Now the high-frequency search schema is available immediately, while dozens of administrative or rarely used operations remain discoverable. The configuration turns observed usage into a context policy.

5. A preload decision framework

Avoid choosing solely from the number of tools. A 100-tool server used once a month should usually remain deferred. A 30-tool server whose two read operations appear in every run may benefit from selective preload. The relevant unit is recurring context cost multiplied by actual use—not catalog prestige or theoretical capability.

6. Deferred loading is not a security boundary

Hiding a schema from the initial prompt does not revoke the tool. If the agent can discover and call it, the capability remains reachable. TrueForge’s preload setting controls context composition. Tool enablement, MCP server collaboration, identity, authorization, guardrails, and approvals belong to other control surfaces.

This distinction matters in incident reviews. “The schema was not preloaded” is not evidence that the agent could not invoke the tool. Audit the effective tool catalog, access policy, requester identity, approval configuration, and actual gateway/runtime events.

7. Descriptions become routing infrastructure

When the full catalog is deferred, server names and descriptions carry more responsibility. They should identify the domain, the major task families, and meaningful exclusions. “Internal tools” is weak. “Read deployment status and service metrics; production mutations require a separate operations server” gives the model a usable routing boundary.

Tool descriptions should also be discriminative. Two operations named “search” and “find” with nearly identical prose create avoidable exploration. Good descriptions state the object, scope, side effects, and important constraints without becoming miniature manuals.

8. Versioning and cache assumptions

A discovered schema can change. Do not assume that a schema inspected on one turn remains valid forever or that every runtime caches discovery identically. Preserve effective server and tool versions when reproducibility matters, and handle schema mismatch as an ordinary runtime failure.

Prompt caching can reduce the billed or computational impact of repeated static schemas on some model providers, but it does not make irrelevant definitions semantically free. They still shape the model’s input and can compete with task evidence. Evaluate token, latency, and task-quality effects separately.

Catalog governance should also account for description changes. When a server description is the first routing clue the model sees, editing that description can alter which catalog the agent explores even if no tool schema changed. Treat descriptions as versioned runtime inputs: review them, record the effective version, and include representative routing tasks in regression tests.

9. How the mechanisms compose

Deferred tool loading controls definitions. Large-response handling controls results. Code Mode controls intermediate computation. Subagents isolate work streams. Compaction summarizes older history. Each acts on a different source of context growth.

10. What to measure

• Input tokens before the first tool call.
• Number of discovery steps per successful task.
• Wrong-server and wrong-tool selection rate.
• Time from user request to first useful tool call.
• Fraction of preloaded tools actually used.
• Task success and retry rate after catalog changes.

Run comparisons on representative tasks. A lower token count is not a win if tool selection degrades. A faster first call is not a win if every subsequent model step carries ninety unused schemas.

A useful rollout starts in shadow analysis. Capture which preloaded definitions were present, which tools were actually invoked, and which deferred discovery calls would have been needed. Then enable deferral for a bounded agent and compare trajectory quality. This avoids turning a context optimization into a fleet-wide behavioral change without evidence.

Track failures by stage as well. “Could not complete the task” is too coarse: the agent may have selected the wrong server, failed to find the tool, loaded the right schema but formed invalid arguments, or called the correct tool and misread its result. Stage-level evidence shows whether the preload policy is responsible or merely adjacent to the failure.

11. Production checklist

• Write discriminative server and tool descriptions.
• Start deferred for large or occasional catalogs.
• Preload only measured high-frequency tools.
• Track schema size, discovery steps, latency, and task success together.
• Version tool contracts and handle mismatch explicitly.
• Keep authorization, guardrails, and approvals at the governed tool boundary.
• Retest preload policy when the catalog or workload changes.

Frequently asked questions

What is the TrueForge default?

Current documentation says preload is false by default: server name and description are loaded first, and tool definitions are discovered on demand.

Can I preload only one tool?

Yes. The documented preload-tools list can eagerly load selected tools while leaving the rest of the server deferred.

Does deferred loading reduce permissions?

No. It changes context composition. Disable tools or enforce access policy when a capability should not be callable.

Is discovery always cheaper?

No. It is usually attractive for large, sparse catalogs. Frequently used tools may be better preloaded. Measure the full workload.

How does this relate to Code Mode?

The agent can fetch an output schema before writing a script, allowing Code Mode to process a tool response without guessing its structure.

References

1. TrueForge: Deferred Tool Loading
2. TrueForge harness capabilities and context engineering
3. TrueForge agent specification
4. TrueForge: Code Mode
5. TrueFoundry MCP Gateway overview

Editorial disclosure: Product behavior is described from public TrueForge and TrueFoundry documentation available on September 10, 2026. Examples are illustrative and should be adapted to each application’s authorization, privacy, reliability, and compliance requirements.

‍

‍