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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds genuinely new operational context: ddof defaults to the sample form with always-population companion fields, percentile reproducibility is guaranteed via a named method, and each successful call costs $0.05 paid over x402 (USDC on Base). Disclosing billing and payment rail is material context an agent would not get from annotations.

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?

Purpose is front-loaded and the long output enumeration is justified for a statistics tool, since an agent must know whether mode, skewness, kurtosis and quartiles are included. The sentence is dense but every listed statistic earns its place; only the trailing pricing sentence is separable.

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?

With no output schema, the description fully compensates by enumerating every returned statistic (count, sum, mean, median, mode, variance/stdev, min, max, range, IQR, skewness, kurtosis, percentiles). Combined with the 100%-covered input schema, nothing needed to call or interpret the result is missing.

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 100%, so the ddof, method, values and percentiles semantics are already documented in the schema and the description largely restates them. It adds the rationale for the method parameter (reproducible rather than implementation-defined), which is marginal value beyond the enum listing, so baseline 3 applies.

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?

States a specific verb and resource ('Statistics calculator') plus the precise input shape ('numeric array in one call') and enumerates the outputs produced. No sibling tool in the list computes statistics, and the enumeration makes the scope unambiguous.

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 'in one call' framing signals this is the consolidated path for computing a batch of descriptive statistics rather than chaining narrower calls, which is useful routing context. However, it never states explicit when-to-use or when-not conditions, so guidance is contextual rather than prescriptive.

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