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

No annotations are provided, so the description carries the burden, but this is a pure arithmetic operation whose behavior ('add two numbers together') is fully evident. It discloses nothing about output type, rounding, or numeric precision, which is a minor gap for a calculator 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, front-loaded sentence with zero wasted words. Nothing could be trimmed without losing meaning.

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, and the operation is trivial. The description is nearly sufficient for such a simple tool; the only missing piece is differentiation from the 'sum' sibling.

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%, with parameters named only 'a' and 'b'. The description says 'two numbers', which confirms operand type but adds no mapping to 'a'/'b' or information about order (irrelevant for addition, but not stated) or accepted numeric ranges.

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 (add) and its operands (two numbers), which is unambiguous on its own. It does not differentiate itself from siblings such as sum or mean, which also aggregate numbers, but the operation is clear enough that no agent would confuse 'add' with 'mod' or 'factorial'.

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 versus 'sum' (which likely adds a list) or how it differs from adding more than two values. The description gives no context, exclusions, or alternatives.

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, yet it says nothing about edge cases such as empty arrays, whether it counts elements or distinct values, or what the return type is. For a tool with zero structured behavioral coverage, one short sentence is insufficient.

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 short sentence that is front-loaded with the verb. It wastes no words, though the brevity borders on under-specification rather than true conciseness.

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, and the tool is simple with one parameter. Still, the description omits edge-case behavior (empty input, distinct vs total count) that matters for a counting 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% and the description only vaguely refers to 'values in a dataset'. It does not clarify that the lone required parameter is an array of numbers or what form the input takes, so the description fails to compensate for the undocumented 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 (count) and resource (values in a dataset), which is clearer than a bare name. However, it does not differentiate from nearby siblings like sum, mean, or mode, which also operate on a collection of values; the agent must infer the distinction from the name alone.

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 indication of when to use count versus the many aggregation siblings (sum, mean, median, variance). No context, prerequisites, or exclusions are provided.

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, yet it discloses nothing about edge cases such as division by zero or how errors are surfaced. For a pure arithmetic tool the risk is low, but the denominator-nonzero constraint is left entirely unstated.

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 zero waste that states the operation and operand order immediately.

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, and the operation is simple. However, the division-by-zero behavior and the a/b role assignment in the schema remain undocumented, leaving a small but real gap.

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% and the parameters are generically named 'a' and 'b', but the description meaningfully maps them ('first number by the second' → a is numerator, b is denominator). It still omits that b must be nonzero, so it partially compensates for the coverage gap.

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 (divide) and its operand relationship ('first number by the second'), which distinguishes it from siblings like multiply, subtract, and add. Sibling differentiation is implicit via the operation name rather than explicit, 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 versus alternatives such as mod, power, or the mean-family tools that also perform division internally. Usage is only implied by the mathematical operation name.

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. It does disclose one useful trait beyond the schema — 'with progress reporting' — which hints at a long-running/interactive operation. However, it omits critical behavior for factorial: domain constraints on n, overflow behavior, and what the progress reporting actually looks like.

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 efficient sentence with the action front-loaded and no wasted verbiage. Nothing redundant is included.

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, and one parameter is trivially discoverable. Still, for a numeric unary function the description should mention domain restrictions and any limits on n, which it does not.

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% and the description only restates the parameter name ('of n') without adding meaning. For factorial, the sign and range of n are semantically critical, and neither the schema nor the description address 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?

States a specific verb+resource ('Calculate factorial of n'), which is unambiguous and clearly distinct from the arithmetic siblings like multiply or power. It lacks any explicit sibling differentiation, but the operation is inherently self-identifying.

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 prefer this over alternatives (e.g. multiply loops) and no stated preconditions, such as n needing to be a non-negative integer or practical size limits. The agent is left to infer usage entirely.

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 does add one genuinely useful constraint not present in the schema — that values must be positive — since the schema accepts any number including negatives and zero. However, it says nothing about what happens on invalid input (error vs. NaN), empty arrays, or how the result is returned.

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. Every word earns its place and the key constraint appears immediately.

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 one-parameter math utility with an output schema (so return format needn't be explained) and no annotations, purpose plus input-domain constraint is close to sufficient. The main missing piece is error behavior for zero/negative or empty input.

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 the single parameter is just an untyped-by-description array of numbers. The phrase 'of positive values' does add a real semantic constraint on the input domain that the schema does not express. It still leaves open whether the array may be empty, whether duplicates or ordering matter.

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 (Calculate) and resource (geometric mean) plus a scope qualifier (positive values). This is clearly distinct from the sibling harmonic_mean or mean, but the description never names the alternatives, so it relies on the agent's own domain knowledge to differentiate.

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 mention of when geometric mean is preferred over the arithmetic mean or harmonic_mean siblings, and no exclusions. Usage is only implicitly inferable from the mathematical name.

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 the domain constraint that inputs must be positive, but says nothing about behavior on empty arrays, zero/negative inputs, or errors. Partial but not full behavioral disclosure.

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; every word earns its place and the key domain constraint is included.

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 simple one-parameter statistical tool with an output schema (so return values needn't be described), the description covers the core purpose and a key domain constraint. It falls short only on error/edge-case behavior, which is minor here.

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% and the single 'numbers' array param is undocumented in the schema. The description adds the meaningful constraint that values must be positive, but does not clarify that input is an array of numbers or how invalid input is handled.

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 ('Calculate') and resource ('harmonic mean'), which distinguishes it from the sibling 'geometric_mean' and 'mean' by name. However, it does not explicitly contrast itself with those siblings, so an agent must infer the difference.

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 harmonic mean versus the sibling 'geometric_mean' or 'mean', and no prerequisites or exclusions stated. The 'positive values' phrase hints at the domain but is not framed as usage guidance.

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 discloses the core computation (Q3 - Q1), which is useful, but does not specify quartile interpolation method, handling of edge cases, or explicit purity/no-side-effect behavior.

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 definition is a single, front-loaded sentence with zero waste. It is appropriately sized for a simple mathematical function.

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 and an output schema exists, so return values need not be explained. However, the description leaves the quartile computation method ambiguous and provides no parameter guidance, making it only minimally complete 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 single numbers parameter has no structured documentation. The description says 'of a dataset' but adds no meaningful detail about the expected numeric array, requiredness, or constraints beyond what the schema name implies.

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), resource (interquartile range), and formula (Q3 - Q1) of a dataset. It clearly identifies what the tool computes, though it does not explicitly distinguish itself from siblings like quartiles, range_stat, or percentile.

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 description provides no when-to-use guidance, prerequisites, or alternatives. With related tools such as quartiles, percentile, and range_stat available, an agent receives no help in choosing iqr over them.

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 bears the full burden. It conveys that this is a pure computation over a numeric array (no side effects implied by 'find'), but does not disclose behavior for edge cases such as empty arrays, ties, or non-numeric input. For a trivial pure function this is adequate but thin.

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 short sentence with no wasted words, and the core purpose is front-loaded. It is appropriately sized, though slightly under-specified rather than maximally informative.

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, and this is a simple single-parameter pure function. The description is complete enough for an agent to invoke it correctly, with only edge-case behavior left implicit.

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 schema gives only the parameter name 'numbers' and type. The phrase 'in a dataset' loosely maps to that array input but adds no real format, constraint, or ordering semantics beyond what the schema shows.

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 ('find') and resource ('maximum value') with scope ('in a dataset'), which is clear on its own. It does not, however, explicitly differentiate from the closely related sibling min_value, though the name and wording make the distinction inferable.

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 alternatives like min_value, mean, or median, all of which are siblings. No prerequisites, edge-case handling, or exclusions are mentioned.

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 of behavioral disclosure. It says nothing about edge cases: what happens with an empty dataset, whether non-numeric values are rejected, whether the result is rounded, or how it handles extreme values. The only behavioral inference available is that it's a pure read/compute operation, which is implicit in the name, not in the description.

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 filler or redundancy. It is appropriately sized for the simplicity of the tool, though its brevity comes at the cost of completeness.

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 has an output schema, so the description needn't explain return values. However, with no annotations, zero schema description coverage, and no behavioral or usage context, the description is too thin for a tool sitting among many similar statistical and arithmetic siblings. It lacks the information an agent would need to confidently select and invoke it correctly in ambiguous scenarios.

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 schema does not document the single 'numbers' parameter beyond its type and title. The description says 'a dataset' but does not clarify that the parameter is a flat array of numbers, whether it must be non-empty, or any constraints. With the schema providing no semantic description and the tool description also silent, the parameter is effectively 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 states a specific verb ('Calculate') and resource ('arithmetic mean of a dataset'), which is clear on its own. However, with siblings like geometric_mean, harmonic_mean, median, and mode, the description does nothing to distinguish arithmetic mean from those alternatives beyond the word 'mean' itself. It's a vague but functional purpose statement.

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 when-to-use guidance, no mention of alternatives like geometric_mean or harmonic_mean, and no conditions under which this tool should be selected over its siblings. With 23 sibling tools in the same numeric-calculation domain, the lack of routing guidance is a significant gap.

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 discloses nothing about edge cases (even-length datasets averaging the two middle values, empty input handling, ordering requirements), though the operation itself is a deterministic pure computation with low risk.

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 zero filler. It is appropriately sized for a simple unary math function.

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-value explanation is unnecessary, and the tool is a simple pure computation. The description is nearly complete for its complexity, with only edge-case behavior (empty/even-length input) left implicit.

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% for the single 'numbers' parameter, so the description should compensate. 'dataset' hints at an array of values, which aligns with the schema, but it does not state the expected element type, non-emptiness, or numeric-only 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 ('Calculate the median') and, by naming 'median', implicitly distinguishes itself from the many sibling statistics tools (mean, mode, variance, etc.). It is clear but offers no explicit sibling-differentiation guidance.

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 and no alternatives named. With siblings like mean, mode, and percentile, a note on when median is preferred (e.g., robust to outliers) would add real value; the description provides none.

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?

Without annotations, the description must carry the behavioral burden. It implies a read-only computation, which is likely correct, but does not specify behaviors such as handling of empty arrays, NaN values, or return type. The presence of an output schema mitigates some concern about return format, but the description adds no behavioral detail beyond the basic operation.

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 that directly states the tool's purpose with no wasted words. It is appropriately sized for a simple operation, though it could benefit from brief usage or edge-case notes.

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 the tool's simplicity, one parameter, and an output schema, the description covers the core function but leaves gaps in usage context, edge-case behavior, and parameter details. It is adequate but incomplete for full contextual understanding.

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 schema has 0% description coverage and only one parameter ('numbers') whose type is clear from the schema. The description does not add any semantics about the parameter, such as format or constraints, but given the simple parameter and output schema, this is minimally acceptable.

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 ('Find') and resource ('minimum value in a dataset'), and is clearly distinguishable from siblings like max_value, mean, and median. An agent can identify its function immediately.

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?

Provides no guidance on when to use this tool versus alternatives such as max_value or median, or how to handle edge cases like empty datasets. The absence of any usage context forces the agent to infer from the name alone.

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 defines the operation deterministically, but omits edge-case behavior such as division by zero or sign handling for negatives, which matter for a modulo 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 front-loaded sentence with zero waste. It is appropriately sized for a trivial two-argument math operation.

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-value explanation is not needed. For a simple pure-computation tool the description is essentially complete, with only b=0 behavior left unstated.

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 both parameters are named only 'a' and 'b'. The description usefully disambiguates that a is the dividend and b the divisor, but adds nothing about integer constraints or edge cases.

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+resource: computing the remainder of a divided by b. The operation is unambiguous and distinct from the arithmetic siblings (add, divide, power, etc.), though it does not explicitly call out how it differs from 'divide'.

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 mention of alternatives, no prerequisites. Given the operand parameters are untyped semantics-wise, an agent gets no help on context beyond the bare operation.

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 bears full behavioral burden. The parenthetical '(s)' hints that multiple modes may be returned, which is useful, but there's no disclosure of edge cases like empty input, all-equal values, or how ties are reported.

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 filler. Appropriate size for a simple statistical tool, though it could afford one more sentence of detail without becoming bloated.

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 and has an output schema, so return values needn't be explained. However, for a statistical function with a 0%-documented parameter and no annotations, the description is barely adequate.

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 the single parameter 'numbers' is only documented by its property title. The description doesn't clarify the expected array form, numeric constraints, or handling of floats, so it does not compensate for the low coverage. Baseline 3 reflects that one parameter is at least obvious from the name.

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 ('find') and the statistical concept ('mode(s) of a dataset'), which is enough to distinguish it from siblings like mean, median, and sum. It doesn't explicitly name a sibling but the resource is 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?

There is no guidance on when to prefer mode over mean or median, nor any note about what happens with multimodal datasets despite the parenthetical '(s)'. Usage is entirely inferred from the name.

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 discloses nothing beyond the operation, but multiplication is an inherently pure, side-effect-free function, so the behavioral profile is self-evident to an agent. No edge-case context (overflow, float precision, operand order) is added.

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 zero filler. Every word earns its place and the operation is stated immediately.

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 no explanation, and the tool is a trivial two-operand primitive. The definition is adequate for correct invocation, though it could note operand semantics or precision 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 0% — parameters 'a' and 'b' carry only bare titles. The description's phrase 'two numbers' partially compensates by fixing the operand type and count, but adds no meaning about order, range, or behavior beyond that.

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 (multiply) and its operand resource (two numbers). Within a family of arithmetic siblings (add, subtract, power), the operation itself is fully unambiguous and needs no further differentiation.

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 explicit when-to-use or when-not-to-use guidance, but for a primitive binary arithmetic operation the correct usage is implied by the description and the sibling operation names. No alternative routing is offered.

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 disclose the interpolation/quantile convention (e.g., linear interpolation vs nearest-rank), which materially affects the returned value, nor anything about handling of unsorted input, empty arrays, or out-of-range p. For a pure-computation tool this is thin behavioral 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?

A single, front-loaded sentence with zero wasted words. Structure is optimal for a simple math utility.

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-value explanation is unnecessary. However, for a percentile tool the unresolved ambiguity in the p scale and interpolation method is a real completeness gap that the description does not close, leaving an agent to guess semantics that change the result.

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 two required parameters, so the description must compensate. It partially does: 'pth percentile' connects to the p parameter and 'dataset' to numbers, but it says nothing about valid p ranges (0-100 vs 0-1), and the schema gives only bare titles like 'P' and '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?

States a specific verb+resource: 'Calculate the pth percentile of a dataset.' An agent knows exactly what operation this performs. It does not, however, differentiate itself from nearby siblings such as quartiles, median, or iqr, which compute related order 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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to alternative tools like median or quartiles for related summary statistics. The agent must infer that this is the tool for arbitrary percentile queries versus the fixed-percentile siblings.

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, but this is a pure, deterministic arithmetic function with no side effects, so the disclosure burden is low. The description does not mention edge cases (negative base with fractional exponent, overflow, complex results), which is the main behavioral gap.

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 that states the operation precisely, with a brief parenthetical gloss; nothing is wasted and the core action comes first.

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 two-parameter pure function with a sibling set of simple arithmetic tools and an output schema already present, the description covers what an agent needs to select and call it. Only edge-case behavior is left implicit.

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%, but the schema titles ('Base', 'Exponent') and the description together make the two parameters' roles clear, and the description adds the mathematical relationship between them. Still, no format, range, or edge-case semantics are provided.

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 ('Calculate') and an unambiguous mathematical relation ('base raised to the power of exponent'), which an agent can distinguish from siblings like root, multiply, or factorial 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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative (e.g. 'use root for nth roots'). Usage is only implied by the operation itself, which for a math primitive is reasonably self-evident.

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 of behavioral disclosure. It states the operation and its outputs, which implies a pure, read-only calculation, but it does not mention edge-case handling (e.g., empty arrays, interpolation method) or confirm the absence of side effects. The presence of an output schema covers the return format, so the gap is moderate.

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. It states the operation and outputs immediately, which is appropriate for a simple calculation 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?

For a simple one-parameter statistical tool with an output schema, the description is minimally adequate. However, it omits usage guidance relative to siblings and does not address edge cases or input expectations, leaving some gaps for an agent to navigate.

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 single parameter has 0% schema description coverage, so the description must compensate. It refers to 'a dataset' but adds no details about the expected input format, whether the array can be empty, or how the numbers should be structured. The schema name and type are self-explanatory, but the description adds little beyond that.

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 ('Calculate') and resource ('quartiles') and even names the three outputs (Q1, Q2, Q3), so the operation is clear. However, it does not differentiate this tool from overlapping siblings such as percentile, median, or iqr, which could also produce some of these values.

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 alternatives like percentile, median, or iqr. The description simply states what it calculates, leaving the agent to infer the appropriate 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?

No annotations are supplied, so the description carries the full behavioral burden, but for a deterministic pure-function statistic the bar is inherently low. It does not disclose edge-case behavior (empty array, single element, NaN handling) or confirm the operation is stateless and side-effect free, leaving modest gaps.

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 tight sentence with zero waste, front-loading the operation and its exact formula. Nothing could be trimmed without losing meaning.

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 one-parameter, deterministic arithmetic tool with an output schema present, the definition supplies everything needed to call it correctly. Return-value explanation is unnecessary given the output schema, and the remaining edge-case silence is minor for this tool class.

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; 'of a dataset' loosely signals that the numbers parameter is the input set. Combined with the schema's array-of-number typing, this is minimally adequate, though it adds no format, ordering, or constraint detail beyond 'max - min' semantics.

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 (Calculate), the resource (range of a dataset), and even spells out the formula (max - min), which lets an agent distinguish it from adjacent statistics siblings like iqr or variance. It stops short of naming an alternative explicitly, so it is clear but not sibling-routing.

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 prefer range over siblings such as iqr, stddev, or min_value/max_value, and no stated preconditions. The agent must infer usage entirely from the tool name and formula.

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 says nothing about edge cases (e.g., even roots of negative numbers), whether n must be a positive integer, or the default n=2 behavior — all things an agent would want to know before invoking a root function.

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 short sentence that front-loads the core operation with no filler. The parenthetical Chinese gloss (开方) is mildly redundant but harmless.

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. For a simple two-parameter math tool the description is minimally adequate, but it leaves domain/error behavior unstated, which is the main thing missing given the total absence of annotations.

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 implicitly defines both parameters (the number and the root degree n via 'nth root'), which is better than nothing, but it does not mention the default n=2, the integer constraint on n, or the sign domain.

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 (nth root of a number), so an agent immediately knows the operation. However, it does not distinguish itself from closely related siblings like power (the inverse operation) or divide, so the agent must infer the boundary itself.

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 root instead of power, divide, or any other arithmetic sibling. For a pure math helper in a large arithmetic family, the absence of routing guidance is a real gap.

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 fully disclose behavior. It does not mention whether it computes population or sample standard deviation, nor does it describe any assumptions about the input (e.g., handling of empty arrays or non-numeric values).

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, concise sentence that is front-loaded with the action and result. It contains no unnecessary 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?

Given that this is a statistical function with a required array parameter and no annotations, the description is incomplete. It omits critical details such as the type of standard deviation (population vs. sample), the required input format, and the return value characteristics (though an output schema exists, it likely describes the return type but not the statistical method).

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 is only 1 parameter. The description says 'of a dataset' but does not clarify that the parameter is an array of numbers. Baseline for 1 param is not explicitly defined; however, with low schema coverage, the description should compensate but does not add meaning beyond the schema's property name.

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 (Calculate) and resource (standard deviation of a dataset), which clearly distinguishes it from siblings like variance or mean. However, it does not explicitly differentiate from the closest sibling 'variance', which is a related but distinct statistic.

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 standard deviation vs. variance or other spread measures. The description merely states what the tool does without any context for selection.

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 does disclose the operand ordering ('second number from the first'), which is the key behavioral detail for subtraction, but it does not mention result type, error behavior, or any other runtime characteristics.

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. It communicates the core operation directly and is appropriately sized for a simple arithmetic 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?

An output schema exists, so return values need not be explained. For a two-parameter arithmetic tool this is minimally adequate, but the description could explicitly map 'first'/'second' to 'a'/'b' to remove the only real ambiguity in calling it 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 coverage is 0%, so parameter semantics must come from the description. It maps 'first' and 'second' to the two operands, implying a minus b, but does not explicitly bind those terms to the parameter names 'a' and 'b', leaving a slight ambiguity.

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 mathematical operation (subtraction) with explicit operand order (second from first), which is clearer than a bare name. It lacks any sibling differentiation, though the sibling names (add, divide, multiply) make the distinction obvious without extra text.

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 given about when to use this tool versus alternatives like add or divide. The description only states the operation, not the context or conditions for selecting it.

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 supplied, so the description carries the full behavioral burden and does not meet it. It says nothing about determinism, behavior on an empty array, non-numeric handling, or overflow, all of which matter for an aggregation over arbitrary input values.

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 compact sentence with no filler, and the verb is front-loaded. It is efficient, though it is arguably under-specified rather than optimally trimmed.

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-value explanation is not needed, and the tool takes one required parameter. Still, the absence of any disambiguation from 'add' or guidance on edge-case input leaves the definition only minimally viable for a math primitive in a dense sibling set.

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 for the single 'numbers' parameter. Saying 'all values in a dataset' does clarify that the input is a whole collection to be collapsed rather than two operands, which is more than the bare parameter name conveys, but it adds no format, type, or ordering detail.

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 ('sum of all values in a dataset'), which is clearer than a tautology. However, it does not distinguish this from siblings that are semantically adjacent, most notably 'add' (binary addition) versus 'sum' (aggregate over a collection), nor does it clarify its relationship to aggregate siblings like 'mean', 'count', or 'max_value'.

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 instead of 'add' or the other aggregate siblings. An agent must infer from the word 'dataset' that this collapses an entire collection rather than adding two operands, which is a meaningful ambiguity in a 23-tool arithmetic family.

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 of behavioral disclosure. It does not specify whether it computes sample or population variance, how it handles edge cases (e.g., empty or single-element datasets), or any error behavior, which are critical for a statistical operation.

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, efficient sentence that is front-loaded with the core action. There is no wasted wording.

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?

Although an output schema exists and covers return values, the description omits essential context for correct invocation: the distinction between sample and population variance and any input constraints. For a mathematical tool with zero annotation and schema coverage, this is a significant gap.

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% for the single parameter. The description only says 'of a dataset,' adding no detail about the expected format (e.g., a non-empty array of numbers) or constraints, so it fails to compensate for the missing schema documentation.

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: 'Calculate the variance of a dataset.' It is clear what the tool computes, but it does not distinguish itself from siblings like stddev, mean, or median beyond the self-evident name.

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 alternatives such as stddev or mean, nor any mention of prerequisites or context. The description offers no usage conditions at all.

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