Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses detailed behavioral traits: it runs a binary search over server counts up to maxServers (default 50), invokes the simulator for each candidate, and returns null with achieved wait if even maxServers can't meet the target. It also includes anti-fabrication instructions to quote results verbatim and not propose a different number. These go well beyond the annotations, which only state readOnlyHint and destructiveHint, and do not contradict them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than the minimal examples but each sentence serves a clear purpose: purpose, usage guidance, algorithm, infeasibility handling, and anti-fabrication caution. It is structured logically and front-loaded with the core purpose, though the anti-fabrication paragraph adds some length while still being valuable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's algorithm (binary search), its behavior at the maxServers boundary (null with achieved wait), and offers clear guidance on alternative tools. Since an output schema exists, it does not need to describe return values in detail. For a complex inverse simulation tool, this description is remarkably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning to the parameters by explaining that targetAvgWaitMinutes is the maximum acceptable wait and that the tool finds the smallest server count meeting it. It also explains maxServers as the search ceiling. However, schema description coverage is 63%, and the description does not compensate for undocumented parameters like serviceCoV or the distribution enums. It provides moderate added value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'given an arrival rate, service rate, and a target average wait time, returns the SMALLEST number of servers needed to meet the target.' It uses a specific verb ('returns') and resource ('SMALLEST number of servers'), and explicitly distinguishes it from the sibling tool 'simulate_mmc' by labeling it 'INVERSE of simulate_mmc'. This makes the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage conditions: 'Use this when the user asks "how many servers do I need?" / "what staffing keeps wait under N minutes?"' It also states when not to use it: 'If the user asks "what if c=N?" for a specific N, call simulate_mmc with that c.' This is clear when-to-use and when-not-to-use guidance with a named alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.