tool-examples-can-narrow-rather-than-teachWorked examples in a tool description, long the standard way to teach tool use, can constrain a capable model to the exploration space the examples describe; Anthropic now advises designing expressive parameters instead — a status enumeration that implies its own usage rather than a demonstration of it.
Ingested from a paper but not yet reviewed by a human. It is deliberately inert: it does not move any technique’s standing, does not count toward the backtest, and is excluded anywhere a claim would carry weight. Read the source before relying on it.
Capability: Using the tools it is given · Agentic, Coding agent
Observed on
2026, Claude 5 generation.
Sources
- States the position directly, and names what it displaces: giving examples was "the number one rule for tool usage". No measurement is offered for this one — unlike the 80% prompt reduction it is asserted from experience, which is why the backing is mechanism-reasoning rather than single-paper.
Disagreeing is the most useful thing you can do here. Both sides of every contested claim in this catalog were assembled by the same person, which is its weakest point.
Related claims
- When an agent must work over a very large tool catalogue, wrapping each tool in a natural-language interface that resolves the API schema internally — so raw schemas are retrieved on demand rather than enumerated in the model's prompt — contributes more to multi-step tool- call success than the surrounding planner, router, or verifier stages.Using the tools it is given · unreviewed
- For locally deployed open-weight models driving a stateful, dependency-ordered MCP tool server, cutting tool descriptions from full specifications (purpose, parameter semantics, constraints, failure conditions) down to one sentence each raises the fraction of calls the server rejects for every model tested, while its effect on task coverage is less consistent.Using the tools it is given · unreviewed
- Giving a coding agent a repository context file — AGENTS.md, CLAUDE.md — does not raise its success rate on benchmark coding tasks and costs about 20% more inference: across 4 agents, 2 benchmarks and 3 conditions, LLM-generated files hurt slightly in 5 of 8 settings while developer-written ones gained 2.4% (p=0.21), and agents obey the files — which is why they spend more — so the files do not carry success-relevant information rather than being ignored.Following an unfamiliar procedure · contested · unreviewed
- For long-horizon tool-calling agents (tasks needing five or more calls), embedding state-transition cues — preconditions, invariants, completion states — into the descriptions of the tools on the intended chain is what actually steers the agent's trajectory; runtime corrective text appended to tool results only patches residual drift, and the plausible user prompt alone (persona, deadlines, format constraints) does not establish the trajectory at all.Following instructions hidden in data · unreviewed
Notes
The source supports this claim and contests a practice, and those are different things — the practice it displaces is not filed here, so there is nothing for the contest to attach to. That is the same gap Russ found on both review papers, appearing a third time. The incumbent worth filing would be "worked examples in a tool description are how you teach tool use", but the only evidence it was ever the rule is this source saying so, and one source cannot hold both stances on one claim. Worth watching rather than believing. The claim is plausible and comes from the party with the best view, but it is also the shape of advice that serves a vendor: fewer tokens per tool, less support surface. That is not an accusation, it is the interest structure the vendor-doc source kind exists to record. It would be settled by an ablation anyone could run — the same tool with and without examples, same tasks, measured — which nothing here provides.