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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds examples of return values but does not disclose edge-case behaviors like handling of empty lists, sample vs. population standard deviation, or mode ties. It does not contradict annotations but adds limited behavioral context.

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 concise and front-loaded: a one-sentence purpose, an operations list, a usage note, and two examples. No fluff or redundant detail.

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 tool is simple, has an output schema, and the description covers when to use it and alternatives. The examples are helpful. Minor gaps: the example call uses 'statistics' instead of the actual tool name 'calc_statistics', and it refers to 'calculate tool' rather than the exact sibling name 'calc_expression', which could cause slight confusion but not ambiguity about intent.

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 input schema already fully documents both parameters (numbers and operation) with descriptions and examples. The description repeats the allowed operations and provides example calls, but adds little beyond the schema, so the baseline of 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?

The description clearly states the tool's function: 'Perform statistical calculations on a list of numbers' and enumerates the supported operations. It also distinguishes itself from siblings by explicitly pointing to the 'calculate tool' for single mathematical expressions, aligning with the sibling calc_expression.

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?

Explicit usage guidance is provided: 'Use this tool to compute descriptive statistics over a list of numbers. To evaluate a single mathematical expression, use the calculate tool instead.' This tells the agent when to use this tool and which alternative to pick.

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