[rgbrenner]

The article has no date on it, but says deferred tool loading is a recent update that occurred after the article was written. Deferred tool loading was added in Nov 2025: https://www.anthropic.com/engineering/advanced-tool-use

So these numbers are at least 7 months out of date. Why is this being posted now?

[red_hare]

+1

Its crazy that people are still discussing this. It's ancient history. Deferred tool loading, large contexts, and prompt caching have made 2026 completely different from 2025.

Also, the "CLI saves token" debate really falls apart when step one of using the CLI is running "--help". The problem remains: if knowing how to call the thing isn't in parametric memory, it has to be in context.

[fooster]

Build a more specific skill the for the exact workflow you want?

[didibus]

Skill still needs to be loaded in context, what would it change?

[usrusr]

I think that what they mean is that instead of ten perfectly orthogonal "unix philosophy" tools (skills) for the agent to compose when solving a problem, each with an API surface (description text) the size of Texas, you'd want to can each composition in a shell script (or a bespoke rust binary, if you enjoy watching your bot perform some heavy lifting) that only solves one problem but solves it so focused that the accompanying skill description barely consumes more context than the tool's self descriptive name.

[didibus]

I still didn't follow, you mean to pipe things between tool calls? Like if you want to query something and then update another without the intermediate getting brought in context?

[usrusr]

Instead of requiring each session to understand the n tools used to solve a particular problem, you bundle up the solution in a conventional script (that's what I meant by "can", as in canning) that the agent can use with very little documentation in the context. When the model is smart enough to figure out the composition of underlying tools during regular execution, it will also be able to do the canning up as a script and write the lightweight documentation that turns the script into a skill. Subsequent use will only require that lightweight documentation in context.

[mkl]

Older than that, as it implies GPT-4o is current.

[wild_egg]

Deferred tool loading is not part of MCP. It's a Claude API special parameter that most other LLM APIs do not support.

[red_hare]

OpenAI API also supports defer_loading https://developers.openai.com/api/docs/guides/tools-tool-sea...

And it's not actually necessary for it to exist at the API level. It's a pattern. Making it API-side is just an optimization.

To do it client-side: 1. Define a single tool, tool_search 2. List the names of your deferred tools in context (or tool_search's description) 3. When tool_search is called, match the query against the tool names (or names + descriptions) 4. Append the matched tool def to the context in a new <system>-esque tag

Claude Code (as of the leak) does this client side. You can even see the custom matching function and A/B tests about whether to include the descriptions.

Whether or not that tool definition comes from MCP or a local definition is kind of beside the point.

[BeetleB]

On the flip side, Claude is at fault in not letting you choose which tools on which MCP servers to keep in context. When I first starting using MCP about a year ago (not on Claude Code), my tools actually let me selectively turn on/off individual tools.

Crazy that the company that invented MCP is not putting basic features like this in the product.

[didibus]

I think if you deny a tool, it won't be loaded in context at all ever, even it's name and description won't be loaded.

[didibus]

Deferred cli/skill loading is also not part of CLIs or skills, it's all about how the coding agent/harness is implemented.

[MallocVoidstar]

The article is from May 29 2026, they're lying about that update being 'recent' and coming after the article to make themselves look better.