undefined

points

[-]

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.

by fooster13 hours ago|

parent|

[-]

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

by didibus13 hours ago|

parent|

[-]

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

by usrusr11 hours ago|

parent|

[-]

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.

by didibus11 hours ago|

parent|

[-]

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?

by usrusr8 hours ago|

parent|

[-]

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.

by mkl12 hours ago|

prev|

[-]

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

by MallocVoidstar20 minutes ago|

prev|

[-]

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.

by wild_egg18 hours ago|

prev|

[-]

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

by red_hare14 hours ago|

parent|

[-]

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.

by BeetleB14 hours ago|

parent|

prev|

[-]

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.

by didibus13 hours ago|

parent|

[-]

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.

by didibus13 hours ago|

parent|

prev|

[-]

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