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

With no annotations, the description carries the full burden and does well: it discloses that the input is a string representation, the valid base range 2-36, and that the output is a string. It does not cover error behavior for invalid digits or out-of-range bases, which is a minor gap for a pure 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?

Front-loads the purpose in one sentence, then gives the input/output contract and a concrete example. No wasted text.

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 small pure conversion function with an output schema present, the description supplies everything needed: parameter kinds, valid ranges, and a worked example. Nothing material is left for the agent to guess.

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 does: it explains all three parameters — number is a string interpreted in from_base, and the result is expressed in to_base, both bounded to 2-36. The worked example further anchors the argument kinds and order.

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 (convert) and resource (an integer from one base to another), and the input/output contract is unambiguous. No sibling tool does base conversion, so an agent can select this without ambiguity among the math utilities.

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?

It defines the valid domain (bases 2-36) but gives no explicit guidance on when to prefer this over sibling tools or any preconditions/alternatives. Usage is implied by the clear purpose rather than stated.

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 adds one useful behavioral trait: bounds accept symbolic expressions like `oo`, `-oo`, and `pi`. However, it omits other behavioral details such as error handling, required permissions, or the role of the `variable` parameter.

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 two short sentences, front-loaded with the core operation and followed by a useful note. Every sentence earns its place with no 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?

An output schema exists, so return values need not be explained. However, with 0% schema description coverage and no annotations, the description leaves critical gaps: the `variable` parameter is unmentioned, and there is no usage guidance or error behavior. For a tool with four parameters, this is insufficient.

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 the description must compensate. It names expression, lower, and upper, and explains that bounds are expressions, but it completely ignores the `variable` parameter. It also provides no syntax guidance for the `expression` parameter itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation ('Definite integral') and the resources (expression, lower, upper), distinguishing it from the indefinite sibling 'integrate' by name. However, it does not explicitly mention that sibling or contrast the tools, so it falls 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 when-to-use guidance is provided. The description does not indicate when to choose this tool over alternatives like `integrate`, nor does it mention any prerequisites or conditions. Usage is only implied by 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?

With no annotations present, the description carries the full burden and does disclose meaningful edge-case behavior: at least one value is required, and sample stdev/variance require two values and are ``null`` otherwise. This is exactly the kind of behavioral detail an agent needs to avoid misinterpreting output, though it says nothing about error behavior if the constraint is violated.

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?

Three short sentences, front-loaded with the purpose, then the output inventory, then the edge-case constraint. No filler and no repetition of the schema.

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 single-parameter pure function with an output schema already defining the return shape, the description covers purpose, returned fields, and the input edge cases completely. Nothing an agent needs to invoke or interpret it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but there is only one parameter (``numbers``) whose name and type make its meaning self-evident, and the description adds a genuine constraint beyond the schema: a minimum length of one, and two for the sample-based statistics. That is real added meaning over a bare array-of-numbers 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 ("Return summary statistics for a list of numbers") and enumerates the exact statistics produced (count, sum, min, max, mean, median, population/sample stdev, variance). This clearly distinguishes it from every sibling, which are symbolic/algebraic tools (differentiate, integrate, matrix_multiply) rather than summary-statistics tools.

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 — the description makes clear it is the tool to reach for when you have a raw list of numbers and want aggregate statistics — but it never states when to use it versus alternatives or any preconditions beyond the input cardinality. No explicit when-not guidance 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?

No annotations are provided, so the description carries the burden, and it does disclose that differentiation can be taken to a higher order. It does not state that this is a pure side-effect-free computation or how the result is returned, though an output schema exists to cover the return value.

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 sentence with no filler, front-loading the operation and its operands. Nothing is redundant.

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?

Because an output schema exists, return values need not be described. Still, for a symbolic-computation tool with undocumented parameter defaults and no guidance on relations to sibling tools, the definition is minimally adequate rather than complete.

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 does identify all three parameters conceptually (expression, variable, order). However, it omits the defaults (variable='x', order=1) and any format expectations for the expression string, leaving part of the parameter meaning unresolved.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (differentiate) and its operands (expression w.r.t. variable, to a given order), so the operation is unmistakable. It does not, however, distinguish itself from the obvious sibling 'integrate' or other calculus tools, leaving the agent to infer the boundary.

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 alternatives such as integrate or simplify_expression even though they occupy adjacent territory. The agent must infer context entirely 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?

With no annotations, the description carries the full burden and does substantial work: it discloses sandboxed evaluation, that no Python eval is used, and that only whitelisted names are allowed — real safety-relevant behavior. It stops short of stating error behavior for malformed expressions, unsupported names, or long computations.

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 purpose sentence is front-loaded, followed by capabilities, then the sandbox guarantee, then a concrete example. Every sentence adds information an agent would otherwise have to guess.

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 description still sketches the numeric result. Supported syntax and the sandbox model are covered; error/edge-case behavior for invalid input is the only notable omission for this one-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% and the single 'expression' parameter has only a type, so the description must compensate — and it does, enumerating accepted operators, constants (pi, e, tau), supported functions, and giving a worked example with an expected result. Minor gap: no statement about what forms are rejected.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('evaluate') and resource ('a mathematical expression') and states the output type ('numeric value'), which distinguishes it from the symbolic siblings like simplify_expression, expand_expression, and differentiate. An agent can tell it apart from the manipulation tools without opening any 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?

The numeric-result framing implicitly separates it from symbolic tools, but there is no explicit when-to-use statement, no named alternative, and no exclusions. The agent must infer that this is the numeric path while the symbolic siblings are the rewrite paths.

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 burden. It is a pure, side-effect-free symbolic transform, and the example conveys that output shape, but the description never states that it performs no mutation, nor how it handles non-polynomial or unparseable input.

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 an embedded example; nothing wasted and the purpose is immediately clear.

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 single-parameter pure-math tool with an output schema present, the description covers the essentials; return semantics need not be restated. It is only slightly thin on input-format edge 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?

One parameter with 0% schema description coverage, so the description must compensate. The inline example '(x + 1)**2' does illustrate the expected string syntax of the expression argument, which is genuinely useful, but it stops short of stating syntax rules or error conditions.

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 (expand) and resource (symbolic expression), with a concrete input→output example that makes the operation unambiguous. It does not, however, differentiate itself from close siblings like simplify_expression or factor_expression, leaving the agent to infer the boundary.

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 example: use it when you want a product/power form rewritten as a sum of terms. There is no explicit when-to-use statement, no mention of when to prefer simplify_expression or factor_expression, and no prerequisites noted.

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 demonstrates an input-output transformation but does not disclose whether the operation is pure/deterministic, what happens for unfactorable expressions, or any error or assumption 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 description is a single front-loaded sentence plus an example, with no wasted words. It communicates the core action immediately and uses the example efficiently.

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 required string parameter, and the presence of an output schema, the description plus example is nearly complete for correct invocation. The main gap is lack of sibling routing, which is partly a usage-guideline concern rather than invocation completeness.

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 add parameter meaning. It does so with a concrete example (``x**2 - 1`` -> ``(x - 1)*(x + 1)``), showing the expected expression syntax, though it does not formally document allowed variables or operators.

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 ('Factor') and resource ('symbolic expression'), and the example clarifies the exact transformation. It is readily distinguishable from sibling tools such as simplify_expression or expand_expression because factorization is a distinct symbolic operation.

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?

It gives no guidance on when to use this tool versus alternatives like simplify_expression, expand_expression, or solve_symbolic_equation. The example implies that the tool is for factoring, but there is no explicit when/when-not condition or sibling routing.

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, and it discloses almost nothing beyond domain validity: behavior with a single-element array, zeros, or negative numbers is unstated, as is determinism or purity. The only behavioral disclosure is the minimum-arity requirement, which is a minor piece of context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the return values, followed by the input format and a compact inline example. Every sentence earns its place with zero 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 narrow, pure math function with an output schema present, the description covers the essentials: what is computed and what input shape is acceptable, so return-value details need not be repeated. The remaining gap is domain-edge behavior (zero/negative/single input), which 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?

With 0% schema description coverage, the description must compensate, and it does: it clarifies the parameter is a list of integers and adds the cardinality rule ('two or more') that the schema does not enforce, plus a concrete example '[12, 18, 24]'. It stops short of edge-case semantics (empty array, single value, negatives), so not a full 5.

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 the specific verb ('Return') and the exact resources computed ('greatest common divisor and least common multiple'), and it also names the second return value. No sibling tool (is_prime, prime_factorization, evaluate, etc.) overlaps with this operation, so the purpose is unambiguous from the name-plus-description 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?

Usage is implied by the operation itself, and the description adds the one real usage constraint ('two or more integers'), which tells the agent this is not a single-argument call. However, it never states when to prefer this over a general evaluator or prime_factorization, and there are no exclusions or prerequisites.

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 discloses one meaningful trait – the result is an indefinite integral (no bounds, no constant term implied) – but says nothing about behavior for non-integrable expressions, error reporting, or supported syntax, and there is no safety/mutation context at all.

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; the operation and its scope are 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 not be explained, and the single sentence covers the core operation. However, for a symbolic-computation tool with two undocumented parameters, the absence of any input-format or failure-mode guidance leaves gaps an agent would want filled.

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 does clarify that `variable` is the variable of integration (with `expression` as the integrand), but adds no syntax, format, or naming conventions for the expression string beyond what the parameter titles already imply.

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 (integrate) and resource (expression w.r.t. a variable) and the qualifier "indefinite" usefully separates it from a definite-integral tool. It is not explicitly differentiated from the sibling differentiate, but the operation is unambiguous from the name and sentence.

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 gives no when-to-use guidance, no prerequisites, and never names an alternative such as differentiate or evaluate. Usage is only inferable from the tool name and the word "integral."

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 and does disclose meaningful behavioral traits: the algorithm ('trial division up to sqrt(n)') and the boundary rule ('values below 2 are not prime'). It implies a pure, side-effect-free computation. It could go further on complexity or negative-number handling, but the added context is solid.

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?

Three short lines, no filler, and the core purpose is front-loaded ahead of algorithm and edge-case details. Every sentence earns its place.

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. For a simple pure predicate the description covers purpose, algorithm, and edge cases adequately; only minor details like complexity or large-input behavior are 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?

One parameter exists with 0% schema description coverage, so the schema types it as an integer named 'N' with no further meaning. The description reiterates that it is an integer and adds the domain rule that values below 2 are not prime, which gives partial semantic value beyond 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 ('Return whether the integer n is a prime number'), which is unambiguous and immediately actionable. It does not explicitly differentiate itself from the sibling prime_factorization, though the boolean-vs-factorization distinction is inferable from the wording.

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 alternatives such as prime_factorization or gcd_lcm. For a primality predicate the use case is intuitive, but the description provides no explicit routing guidance or exclusions.

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 notes that infinity ('oo') is allowed as a point and defines direction semantics, but it omits whether computation is symbolic or numeric, how divergent limits are handled, or any error conditions.

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 two compact sentences that front-load the operation and then explain the direction parameter. Every phrase carries information, and there is no redundant or filler text.

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 described. The description covers the purpose and parameter meanings adequately, but with no annotations and 0% schema coverage it lacks usage guidance and behavioral edge-case information that an agent might need to invoke it correctly in context.

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?

With 0% schema description coverage, the description must explain all four parameters. It clarifies the roles of expression, variable, point, and direction, including the allowed direction values and the acceptance of infinity for the point.

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 precise mathematical verb and resource: computing the limit of an expression as a variable approaches a point. It is immediately distinguishable from siblings such as differentiate, integrate, or evaluate, which perform different operations.

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 explains the direction argument but offers no guidance on when to use this tool versus alternatives like evaluate or solve_symbolic_equation. It also does not specify prerequisites or contexts where a limit is preferable.

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 notes the input must be a square matrix but does not mention error handling for non-square inputs, numerical limits, or any other behavioral traits.

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 wasted words. It is appropriately sized for a simple mathematical 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?

While the tool is simple and an output schema exists, the description lacks details about the input format and error behavior for non-square matrices. Given the absence of annotations and 0% schema coverage, it is minimally adequate but leaves clear gaps.

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, and the description only implies the parameter is a square matrix without specifying the expected nested-array format or numeric constraints. It adds minimal meaning beyond the schema's type information.

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 (Return) and resource (determinant of a square matrix), clearly distinguishing it from siblings like matrix_inverse or matrix_multiply. An agent can immediately tell what operation is performed.

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 matrix_inverse or solve_linear_system. The description merely states the operation without any usage 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 does not meet it. It implies what happens with non-square or singular input but never states the failure mode, numeric precision, or whether results are exact or floating point—real concerns for a numeric inverse.

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 front-loaded sentence with no filler; the operation and its input constraints 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?

An output schema exists, so return values need no explanation, and the tool is simple with one parameter. However, with zero annotation coverage and an undocumented parameter, the description should still say more about error behavior for singular matrices to be fully sufficient.

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 'matrix' parameter, so the description is the only source of constraint. It adds the square/non-singular requirement, which is genuinely useful semantics, but says nothing about the expected nesting (list of row lists) or orientation.

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 ('Return the inverse of ... matrix') and constrains the domain to square, non-singular inputs, which cleanly separates it from matrix_transpose, matrix_multiply, and matrix_determinant. It does not explicitly name or contrast those siblings, 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?

The square/non-singular precondition implicitly tells the agent which inputs are valid, but there is no statement of when to reach for this tool versus matrix_determinant, solve_linear_system, or matrix_transpose. Usage must be inferred 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 behavioral burden. It discloses the input shape convention ('Matrices are lists of rows') and the dimension-compatibility contract, which is useful, but says nothing about error behavior when dimensions mismatch or about output formatting. For a pure computation tool 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?

Two short sentences, front-loaded with the operation and followed by the key constraint. No padding or redundancy.

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 and the tool is a pure function, so return values and side effects need little explanation. The main omission is what happens on mismatched dimensions, but for this simple operation the definition is essentially complete.

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 both parameters named only 'A' and 'B'. The description partially compensates by tying the A@B notation to the two inputs and clarifying that matrices are nested lists of rows, but it does not add per-parameter detail beyond the trivially simple types.

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 ('Return the matrix product A @ B'), which is unambiguous and clearly distinct from the sibling math operations. It does not explicitly name any sibling alternative, but the operation is 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 explicit when-to-use/when-not guidance or routing to alternatives like matrix_inverse or solve_linear_system. However, the stated precondition ('Columns of A must match rows of B') functions as an implied validity condition for invoking it correctly.

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 not state that this is a pure, non-mutating operation, nor does it disclose error behavior for ragged/empty inputs or invalid dimensions, leaving the agent to infer everything.

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 stating the operation, with the verb front-loaded and no filler or repetition. 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 a simple pure function. The only meaningful gap is the absence of error/edge-case behavior (e.g., non-rectangular input), which is minor at this complexity level.

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 there is only one parameter and its type (array of arrays of numbers) is self-evident from the schema. The description adds no extra semantics such as rectangularity requirements or accepted shapes, but the compensation burden is low for a single obvious parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific, unambiguous mathematical operation (transpose) on a specific resource (matrix), which an agent can read without opening the schema. The operation itself is naturally distinct from siblings like matrix_multiply or matrix_inverse, though the description never explicitly contrasts 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?

There is no guidance on when to use this tool versus related siblings such as matrix_multiply, matrix_determinant, or matrix_inverse, nor any stated prerequisites or exclusions. Usage is only implied by the well-known semantics of 'transpose'.

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, so the description carries the burden. It discloses the return format ('list of {"prime": p, "exponent": k} entries, ordered by prime') and provides a concrete example (prime_factorization(360) -> 2^3 * 3^2 * 5^1). This is good behavioral context. It doesn't mention error handling for non-positive n, but the domain restriction is stated.

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 sentences plus an example. Front-loaded: what it does, then the return format, then a concrete example. Zero waste.

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, well-understood math operation with one parameter, the description is nearly complete. It covers purpose, input, output format, and example. An output schema exists, but the description's return format detail is still helpful. The only minor gap is explicit error behavior for invalid inputs.

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 adds meaning: it specifies the parameter must be a positive integer and names it n. Baseline for 0 params is 4, but here there is 1 param; the description compensates for the schema's lack of description by clarifying the 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?

Specific verb+resource: 'Return the prime factorization of a positive integer n.' This is precise and distinguishes itself from siblings like is_prime (primality test) and factor_expression (symbolic factoring). An agent can select this unambiguously.

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?

Implied usage: prime factorization is a well-known operation, and the description specifies input domain ('positive integer'), which implicitly excludes non-positive integers. However, it offers no explicit guidance on when to use this vs. siblings like is_prime or factor_expression.

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. The input-to-output example does disclose the core behavior (a pure, deterministic symbolic rewrite returning a simplified form), but it says nothing about assumptions, domain restrictions, or whether simplification is canonical for a given input.

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 an inline example; nothing redundant and the essential information 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?

An output schema exists, so return values need no explanation, and for a one-parameter pure math function the description is nearly sufficient. It only falls short on routing guidance relative to the many sibling symbolic tools.

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 required parameter 'expression' is undocumented in the schema. The example ('sin(x)**2 + cos(x)**2') does demonstrate the expected string syntax, including the ** operator, which partially compensates, but format details such as variable names or accepted functions are left implicit.

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 ('simplify') and resource ('symbolic expression'), with a concrete before/after example making the transformation unambiguous. It does not, however, distinguish itself from its close siblings expand_expression and factor_expression, which are also symbolic rewrites.

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 over expand_expression, factor_expression, or the other symbolic siblings. The example implies it is a canonicalizing rewrite, but there is no explicit when/when-not statement or named alternative.

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 full behavioral burden. It discloses the key domain constraint (A square and non-singular), which tells the agent the tool is invalid for singular or non-square matrices. It does not describe error behavior, numerical method, or precision, leaving some behavioral 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?

The description is a single, front-loaded sentence with no wasted words. It states the operation and the key precondition immediately, making it easy to parse.

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 mathematical solver, the description covers the core operation and its main validity constraint. It could be more complete by noting behavior on singular matrices or parameter shape expectations, but is largely sufficient.

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. The equation 'A x = b' implicitly defines the roles of both parameters: A as the coefficient matrix and b as the right-hand side vector. However, it does not specify expected shapes (e.g., n×n for A, length n for b) or ordering, beyond the square constraint on 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 states a specific mathematical operation (solving A x = b for x) and adds a validity constraint (A square and non-singular). This clearly distinguishes it from sibling matrix operations like matrix_multiply or matrix_inverse. However, it does not explicitly name or contrast with the closest alternative, solve_symbolic_equation.

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 gives a prerequisite (A must be square and non-singular), which implies when the tool is applicable. It does not explain when to choose this over using matrix_inverse and multiplication, nor when to prefer a symbolic solver. Guidance is implied rather than explicit.

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 burden and does well: it discloses the domain precondition (a != 0), the outputs (discriminant plus real or complex roots), and implicitly the complex-result behavior. It does not describe error/exception behavior or numeric precision limits, but covers the essentials.

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 short sentences, front-loaded with the core purpose and the equation, followed by behavior. No filler sentences.

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 (3 scalar params, single math operation) and an output schema exists, so return formatting need not be explained. Precondition, domain, and result shape are all covered; nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the parameters are bare 'A/B/C' titles, so the description must compensate. The equation form ``a*x^2 + b*x + c = 0`` maps each parameter to its role as a coefficient, which is meaningful, though it never spells out the mapping in prose or notes that all three are required.

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 (solve) and the exact resource (``a*x^2 + b*x + c = 0``), plus what it returns (discriminant and roots). This clearly separates it from siblings like solve_linear_system and solve_symbolic_equation.

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?

Explicitly states the precondition ``a != 0`` and redirects to a linear solve otherwise, which is real when-not guidance. It does not name the exact sibling (solve_linear_system) it is pointing to, so routing requires a small inference.

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, and it does disclose two useful behavioral details: bare expressions are assumed equal to zero, and output is a list of solution strings (shown via example). It is silent on the solution domain (real vs. complex), multiple/no solutions, and error behavior, which is a meaningful gap for an unannotated math 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?

Two short sentences with the core purpose and a worked example front-loaded, and the accepted-input-forms note following. No filler; every clause adds information.

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 re-explained, and the example conveniently previews them. However, with zero schema description coverage, no annotations, and an undescribed variable parameter, the description leaves gaps an agent would want filled before calling 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. It adds real meaning for the required equation parameter (bare expression vs. explicit '=' form) plus a worked example, but says nothing about the variable parameter, including that it defaults to 'x' and how it selects the solved-for variable.

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 ("Solve an equation for a variable") and reinforces it with a concrete example mapping an input equation to its solution set. It clearly differs from computation siblings like evaluate, but it never distinguishes itself from solve_quadratic or solve_linear_system, which plausibly overlap.

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 guidance and no mention of alternatives such as solve_quadratic or solve_linear_system, which are the natural siblings an agent would confuse this with. The note about bare expressions describes input format, not when this tool should be selected over others.

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 for a pure mathematical computation this is minor. It does disclose one useful behavioral trait – the O-term is dropped from the result – which tells the agent the exact output form. It does not state defaults, precision, or failure behavior (e.g., non-analytic points).

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 names the operation and its three operative inputs, with the parenthetical output note appended compactly. No filler sentences.

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 the description need not explain return values, and the (O-term dropped) note covers format. However, with 0% parameter descriptions and no usage guidance, an agent lacks format details for point/variable and any when-to-use context.

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 the description must compensate, and it only partially does. It references expression, point, and order in prose, but says nothing about the variable parameter (default 'x') or the expected format of point (string, default '0'). Key semantics for 4 undocumented parameters are left to inference.

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 operation (Taylor series expansion) on a named resource (expression) with clear scope (about a point, to a given order). It is readily distinguishable from siblings like expand_expression or differentiate. It stops short of explicitly naming alternatives, but the operation itself 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 use this tool versus related siblings such as expand_expression or differentiate, nor any stated prerequisites or context. The usage is only implied by the operation name itself.

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