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

With no annotations, the description carries the full behavioral burden, and it does disclose a genuinely useful operational detail the schema cannot: the cost of 1 credit per call. It also implicitly reveals the tool is a pure computation with no side effects by listing only math functions. But it says nothing about the return shape for the statistics mode (mean, median, count?), numeric precision, or how invalid expressions are reported, which are the details an agent most needs.

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?

Two compact clauses front-load the capability and the parenthetical function list is dense but each item earns its place by defining the accepted grammar. The cost note is appended efficiently rather than buried. Minor deduction because the parenthetical enumeration slightly crowds the opening sentence.

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 and no annotations, the description should close the loop on what a statistics call actually returns, and it does not — the word "summary statistics" is left undefined. For a simple two-parameter computation tool the coverage is close to adequate, but the missing return-value detail is the one gap that could force a trial call.

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 coverage is 100%, so the baseline would be 3, but the description earns above that by supplying the expression grammar — the allowed operators and functions (sqrt, ln, log, round, min, max, pi) — which the schema only labels as an untyped "string". It also clarifies that "values" is a number collection, consistent with the schema's "array or comma list of numbers".

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 verb ("Evaluate") and two concrete resource modes (an expression, or summary statistics of a number list), and it enumerates the supported operators and functions, which tells an agent exactly what the tool can compute. It does not differentiate against near-neighbours like text_stats or convert_units, but the sibling list is largely unrelated utilities, so the purpose is still 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 two operating modes are stated, and by implication "expression" drives the expression mode while "values" drives the statistics mode, so an agent can infer which parameter to populate. However, there is no explicit when-to-use framing, no statement of what happens if both parameters are supplied, and no note on which statistics are produced.

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