probability.gamma_ppf

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

Annotations already declare this a safe, idempotent, closed-world read, so the description is not burdened with safety disclosure. It goes beyond them by stating the computation is done in scipy float64 and that the result string is rounded to 10 significant digits, and it flags that scale is the reciprocal of rate — a concrete behavioral/error-prevention detail the annotations cannot convey.

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?

Three sentences, each doing work: purpose first, then parameter constraints plus return format, then the scale/rate misuse warning. Nothing is repeated from structured fields and there is no filler, though the second sentence is densely packed.

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?

An output schema exists, so return values need not be explained, yet the description still tells the agent the result is a rounded string. Domain constraints, the default value, and the primary failure mode (rate vs scale) are all covered; only error behavior for out-of-range q or malformed decimals is left unspecified.

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?

Schema description coverage is 0% — properties carry only titles and everything is typed as a plain string — so the description must carry the semantics, and it does: q must be strictly between 0 and 1, shape must be positive, scale is a positive decimal string defaulting to 1. It also warns that passing rate instead of scale yields a wrong answer, which is exactly the kind of meaning the schema lacks; only the exact string syntax remains unspecified.

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 names a specific operation on a specific distribution: computing the quantile (분위수) of the gamma distribution, which unambiguously implies the inverse-CDF direction. It does not explicitly route the agent away from gamma_cdf/gamma_pdf, but the verb+resource combination is precise enough to select the tool without opening the schema.

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?

Use is implied by the operation itself, but there is no explicit statement of when to prefer gamma_ppf over siblings such as gamma_cdf or the other *_ppf tools, and no prerequisites are described. The scale-vs-rate warning is a parameter correction rather than usage routing, so guidance remains implicit.

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