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

With no annotations, the description carries the full burden, and it only discloses the numerical methods used. It says nothing about accuracy/precision limits, how step or intervals affect results, failure modes for invalid expressions, or return format.

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?

A single dense sentence that front-loads the domain and enumerates the two operations with their algorithms. No waste, though it is arguably too terse given the undocumented parameters.

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?

For a 7-parameter numerical tool with no annotations and no output schema, the description is too thin. It leaves the agent without guidance on required inputs beyond operation/expression or on interpreting results.

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 0% for 7 parameters, and the description only obliquely maps 'one-variable expressions' to x and names the two operations. Parameters step, lower, upper, and intervals are completely undocumented anywhere, which is a significant gap for a numerical method whose accuracy depends on them.

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?

Names the resource (one-variable calculus) and the specific operations (five-point numerical derivative, Simpson definite integral), which is more precise than the generic siblings like calculate_expression. It does not explicitly differentiate itself from calculate_expression or solve_root, so it stops short of a 5.

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?

No guidance on when to use this tool versus calculate_expression, solve_root, or calculate_matrix. The choice between derivative and integral is left entirely to the operation enum in the schema rather than being framed in prose.

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

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

With no annotations, the description carries the full behavioral burden, yet it says nothing about which operations require the optional b operand, what happens when b is omitted for a binary operation, error/domain behavior (e.g. divide by zero, sqrt of a negative), or precision. It merely lists operation names.

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?

A single, front-loaded sentence with no filler; the resource and operation set are stated immediately and nothing is wasted.

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?

For a 3-parameter tool with nested objects, 0% schema description coverage, no annotations, and no output schema, the description leaves too much unspecified — notably the role of b and the behavior/return of each operation — so an agent cannot call it confidently in all cases.

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 0% and there are nested objects, so the description must compensate. It does partly help by mapping human operation names to the enum values (magnitude=abs, argument=arg, power=pow, square root=sqrt) and by showing the {re, im} shape, but it never explains the b parameter or which operations need it.

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 (arithmetic) and resource (complex numbers) with the {re, im} representation, and enumerates the supported operations. It distinguishes itself from generic siblings like calculate_expression or calculate_decimal, though it does not explicitly name a sibling to route against.

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?

There is no guidance on when to use this tool versus calculate_expression, calculate_matrix, or the other math siblings, and no exclusions or prerequisites are given. The operation list implies capability but not selection criteria.

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

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

The description discloses useful behavioral traits: determinism, UTC timezone, and business-day logic. With no annotations, the description carries the full burden, but it omits key behaviors such as output format, edge cases (invalid dates, negative amounts), and whether 'business_days' observes holidays.

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?

Single sentence, front-loaded with the core capability ('Deterministic ISO calendar math in UTC'), followed by an operation list. No wasted words, though the operation list is dense and could be formatted for clarity.

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?

For a 5-parameter tool with 0% schema coverage, no annotations, and no output schema, the description is inadequate: it fails to explain parameter usage, return values, or error behavior. It provides a high-level overview but leaves significant gaps an agent needs to call the tool correctly.

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%, so the description must compensate, yet it only loosely maps to parameters ('add days/weeks/months/years' hints at unit/amount, 'difference' hints at otherDate, 'weekday'/'business_days' map to operation). It does not explain how unit, amount, or otherDate interact, nor their defaults or constraints (e.g., amount limits, date format). Five parameters remain largely undocumented.

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 clear resource (ISO calendar math in UTC) and enumerates the specific operations: add days/weeks/months/years, date difference, weekday, business-day count. This lets an agent distinguish it from siblings like calculate_expression or convert_units. It's specific, though it doesn't explicitly name a sibling it should be preferred over.

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 enumerated operations imply when to use the tool (date arithmetic instead of general math), but there is no explicit when-to-use vs. alternatives guidance. With 12 sibling calculation tools, an agent could benefit from knowing this is date-only and cannot handle expressions.

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

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

With no annotations, the description carries the full burden. It usefully clarifies that inputs are decimal strings and that precision means significant digits (1-200), but says nothing about error behavior (divide by zero, sqrt of negatives), whether the result is rounded/truncated, or the return format.

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 tightly written sentences with the core capability front-loaded and the input/precision contract immediately after. No filler or repetition of the tool name.

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?

Four parameters at 0% schema coverage, no annotations, and no output schema, yet the description is only two sentences. It omits operand requirements per operation, failure modes, and result format — significant gaps for an arithmetic tool whose behavior differs by enum value.

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%, so the description has to compensate. It explains the type of 'a'/'b' (decimal strings) and the meaning and range of 'precision' as significant digits, which is real added value, but it never explains that 'b' is required for binary operations while 'sqrt' needs only 'a'.

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 gives a specific verb ('Perform') and a precise resource ('high-precision decimal arithmetic'), and the IEEE-754 clause narrows the scope well. It does not, however, differentiate itself from siblings like calculate_expression or calculate_percentage, which an agent could easily confuse it with.

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?

'Without IEEE-754 surprises' implies the use case — reach for this when exact decimal results matter — which is genuine implied guidance. But it names no alternative and gives no explicit when/when-not rules against the twelve sibling calculators.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Safely' is a meaningful signal that evaluation is sandboxed rather than arbitrary code execution, but the description says nothing about error behavior, return type, precision, or limits beyond the schema's 2000-char cap.

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 tight sentences: the core action first, capability scope second. Zero redundancy and nothing buried.

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 say what a call returns (number? string?) and how failures surface. It adequately scopes supported operations but leaves the return contract and error semantics 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%, so the description must compensate. It clarifies that 'variables' are optional and numeric and are meant to be substituted into the expression, which adds real meaning for the nested object parameter, but it adds nothing about the 'expression' string's syntax, alternates, or length constraint.

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 ('Safely evaluate a mathematical expression') and enumerates the supported function families, so the agent knows this is a general-purpose math evaluator. It does not name any sibling (e.g. calculate_decimal, solve_root, calculate_matrix) to draw the boundary explicitly, so it stops short of a 5.

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?

Usage is implied by the capability list (trig, logs, sqrt, min/max, constants) rather than stated as when-to-use versus alternatives such as calculate_decimal or solve_root. No exclusions or prerequisites are given, leaving routing to be inferred from the sibling names.

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

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

No annotations are provided, so the description carries the full burden: it does not state that this is a pure, side-effect-free calculation, nor what conventions it assumes (nominal vs effective rate, end-of-period payments, rounding). For a numerics tool these assumptions materially change results and none are disclosed.

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?

One short, front-loaded sentence with no wasted words. It is arguably too terse for a five-parameter financial tool, but nothing in it is filler.

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 0% schema description coverage, no annotations, and no output schema, the description would need to explain rate units, compounding periods, and payment timing to be callable correctly. It supplies none of that, leaving significant ambiguity for a required-parameter tool.

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% across five parameters, and the description names none of them. It never clarifies that annualRatePercent is in percent (not decimal 0.05), that periodsPerYear defaults to 12, or that the operation selects which of the three formulas runs — all of which an agent must infer.

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?

Specific verb (Calculate) plus the three distinct results it can produce (compound future value, present value, periodic loan payment), which map cleanly onto the operation enum. It is distinguishable from siblings like calculate_percentage or calculate_matrix, though it never explicitly contrasts itself with them.

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?

No statement of when to use this tool versus calculate_expression, calculate_percentage, or any other sibling. The only implied guidance is the operation names themselves inside the schema enum, which the description merely echoes.

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

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

No annotations are provided, so the description carries the full behavioral burden. It names the operations but omits constraints such as required square matrices for determinant/inverse, error behavior, return format, or numerical precision.

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?

A single front-loaded sentence with no wasted words; the colon and list are efficient.

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?

Given no annotations, no output schema, and 0% schema description coverage, the description is too thin for a 7-operation matrix tool. It should specify which parameters each operation needs and key constraints.

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%, so the description must compensate. It repeats the operation enum values and clarifies 'solve Ax=b' to link a and b for that operation, but it does not explain parameter roles for the other operations, required/optional status, or shapes.

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 resource (matrix) and enumerates the operations, so an agent can tell it is the matrix-arithmetic tool rather than a general expression evaluator. It does not explicitly name or differentiate from any sibling, so it stops short of a 5.

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?

No guidance on when to choose this tool over calculate_expression or other calculators; the operations are listed but no scenarios, prerequisites, or exclusions are given. Implied usage only.

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

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

With no annotations, the description carries the full burden but discloses almost nothing about behavior: it doesn't state whether the tool is pure, deterministic, how it handles errors or edge cases, or what the return format is. It merely enumerates operation names.

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 a single, front-loaded sentence with no redundant or filler content. It is appropriately sized for a simple calculator tool.

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?

Given 3 required parameters, no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It should clarify parameter roles and provide at least minimal usage context to ensure correct invocation.

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%, so the description must compensate. It lists operation types that map to the enum, but it does not explain the roles of x and y for each operation (e.g., which is the percentage and which is the base for percent_of). This leaves parameter semantics largely ambiguous.

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 states a specific verb (calculate) and resource (percentage) and lists several operation modes, which helps distinguish it from generic math tools like calculate_expression. However, it does not explicitly differentiate itself from siblings or clarify its scope relative to them.

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?

No guidance is provided on when to use this tool versus alternatives such as calculate_expression or calculate_finance. There are no prerequisites, exclusions, or context for selecting among the listed operations.

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

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

No annotations are provided, so the description must carry the full burden. It does not state whether params accept defaults, what happens on invalid inputs, or how results are returned. The only behavioral hint is the enumeration of supported distributions/operations, which is thin for a computational tool.

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?

A single, dense sentence that front-loads the operation and lists the supported configurations. No filler.

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?

For a 3-param computational tool with no annotations, no output schema, and only 33% schema coverage, the description is too terse. It doesn't explain parameter defaults, output format, or edge cases. An agent would likely need to inspect the schema and guess at behavior.

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 33%, and the description repeats the distribution list but adds nothing about the params object beyond what the schema's description already says. The schema's params description is actually richer than the tool description. Baseline is 4 when zero params; with 3 params and low coverage, the description fails to compensate, so a 3 is appropriate.

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 ('Evaluate') and resource (probability distributions, listing normal/binomial/Poisson and the PDF/CDF/PMF forms). Clearly distinguishable from siblings like calculate_matrix or calculate_calculus. It stops short of a 5 because it doesn't say why one would pick this over summarize_statistics.

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?

No guidance on when to use this tool versus the many calculate_* siblings, nor any exclusions. The name and description imply a domain (probability), but the agent receives no explicit routing cue.

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

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

No annotations exist, so the description carries the full behavioral burden. It says 'common' units but never states that from/to must belong to the selected category, how incompatible units are rejected, or whether precision/rounding is applied — all important for a conversion tool with no annotation coverage.

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?

One tight, front-loaded sentence with no filler. It is appropriately sized, though its brevity comes at the cost of the details the other dimensions lack.

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?

A four-required-parameter tool with no annotations, no output schema, and no schema descriptions. The description leaves unit-string format, cross-category validation, and result shape entirely 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% across four required parameters. The description restates the category enum values already present in the schema but adds nothing about the format of 'from'/'to' strings or the meaning of 'value' (base number to convert).

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 (convert) plus the resource (units) and enumerates the supported measurement categories. This clearly separates it from the calculate_* siblings, though it does not explicitly position itself against list_units or any other tool.

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?

No when-to-use guidance, no prerequisites, and no mention of the list_units sibling that would help an agent discover valid unit strings. The category list implies scope but not invocation context.

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

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 the shape of the result (all accepted symbols, grouped by category) and implies a read-only lookup. It says nothing about ordering within groups, case sensitivity, or whether aliases are included.

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?

A single front-loaded sentence with no filler; the resource and its grouping are stated in the first few words.

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?

For a trivial zero-param lister with no output schema, the description adequately conveys what comes back (symbols grouped by category). Minor gap: it doesn't characterize category names or whether the payload includes conversion factors.

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 tool takes zero parameters, so per the rubric the baseline is 4; there is no parameter surface for the description to clarify or contradict.

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 ('List every accepted unit symbol') plus the organizing principle ('grouped by category'), which distinguishes it from the calculate_*/convert_units siblings that perform computation. It does not name a sibling explicitly, so it stops short of 5.

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?

Usage is only implied: an agent can infer this is the reference/discovery counterpart to convert_units, useful for finding valid symbols before conversion. No explicit when-to-use statement or mention of alternatives is given.

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

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

With no annotations, the description carries the full behavioral burden. 'Robust bisection' meaningfully signals reliable convergence when the bracket contains a sign change, which is genuine behavioral information, but it omits preconditions (f(lower) and f(upper) must have opposite signs), failure behavior, and convergence/result reporting.

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?

A single front-loaded sentence with a clear verb, objective, and method—zero wasted words.

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?

For a numeric solver with no output schema and five undocumented parameters, one sentence is thin. It doesn't say how the expression is parsed, what the result looks like, or how tolerance/maxIterations affect outcomes, leaving real gaps for correct invocation.

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%, so the description must compensate and it largely does not. 'On a bracket' loosely maps to lower/upper, but expression, tolerance, and maxIterations receive no added meaning beyond their types and defaults in 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 states a specific verb and resource—'solve f(x)=0'—and adds the algorithmic method ('robust bisection') on a bracket. An agent can immediately tell this is a root-finding tool rather than a general evaluator, though it does not explicitly contrast with siblings like calculate_calculus.

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 phrase 'on a bracket' hints at the precondition of supplying two endpoints, but there is no explicit when-to-use guidance, no mention of when a bracket is required versus other root techniques, and no reference to any alternative sibling tool.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses what is computed (count, sum, mean, ...), which is the primary behavior for a stateless pure computation, but says nothing about the 100,000-element cap, behavior on empty/NaN input, or the shape/order of results.

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?

A single front-loaded sentence with the verb first and the enumeration of outputs following. Every element earns its place because there is no output schema to explain the return values.

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?

Given a very simple one-parameter tool with no output schema, the description lists the computed statistics, which is the key missing structured information. It is nearly complete, lacking only input-constraint and return-format details.

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?

One parameter ('values') exists with 0% schema description coverage, so the description ideally should clarify input expectations. It implies the input is a set of numbers being summarized but never names or constrains the parameter; the maxItems=100000 and minItems=1 limits are only in 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?

States a specific verb and resource ('Compute descriptive statistics') and enumerates the exact outputs, so the agent knows what it produces. It does not, however, differentiate itself from the numerous sibling calculators (calculate_probability, calculate_expression, etc.), which all involve numbers.

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?

There is no statement of when to use this tool versus the sibling calculators, nor any prerequisites or exclusions. The agent must infer that a numeric array should be summarized here rather than processed by calculate_expression.

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