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

With no annotations provided, the description carries the behavioral burden. It discloses that the result is non-negative, that a dict with result or error is returned, and that the operation and result are logged. It does not discuss edge cases like NaN or infinity, but for a simple math function this is acceptable 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?

The description starts with the core purpose and then uses Args, Returns, and Notes sections that are compact and scannable. There is only mild redundancy between the first sentence and the first note, but no unnecessary 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?

Given the low complexity of the operation and the presence of an output schema, the description covers the input wrapper, the actual numeric parameter, the return shape, and the logging behavior. It is nearly complete, though it omits explicit error-condition details such as invalid number handling.

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 so by explaining that `data` is a SingleNumberOperation object containing the input number `a`. This is sufficient to know how to invoke the tool correctly, even though no example is 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 opens with a specific verb and resource: 'Calculate the absolute value of a given number.' This clearly distinguishes it from the sibling arithmetic/math tools and leaves no ambiguity about the tool's purpose.

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 usage context is implied by the description: use this when you need the non-negative magnitude of a number. However, it does not explicitly compare itself with sibling tools or state when not to use it, so the guidance remains implicit 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?

No annotations are provided, so the description carries the behavioral burden. It discloses the return format (operation name and result, or error message on exception) and the logging behavior. This is helpful transparency for a tool that otherwise has no side effects.

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 docstring is well-structured with Args, Returns, and Logs sections. Every section adds useful information, and the description is appropriately sized for a simple tool. Minor redundancy exists with the operation name and the Args section, but it does not detract.

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 description is complete enough for a simple arithmetic operation: it covers inputs, return behavior, error handling, and logging. The presence of an output schema reduces the need to explain return values. The only missing element is explicit guidance about when not to use this tool, 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 reported as 0%, so the description must compensate. It explains that the `data` parameter is an object containing two numbers `a` and `b` to be added, adding meaning beyond the bare schema. This is sufficient for an agent to construct a valid call.

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: 'Perform addition of two numbers provided in the data object.' This clearly distinguishes it from the sibling tools like subtract, multiply, and divide. The operation and expected input shape are unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when addition is needed, but it does not explicitly discuss when to prefer this tool over alternatives or provide any exclusions. For a simple arithmetic tool, the intended usage is fairly obvious, but no guidance about edge cases or alternative selection 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 full burden. It discloses that the operation always rounds up, handles negatives as ceiling, logs the operation and result, and returns either a result or an error message. It does not mention edge cases like NaN or infinity, but the behavior is otherwise well covered.

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 compact and clearly organized with Description, Args, Returns, and Notes sections. Every sentence earns its place and the key behavior is front-loaded.

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 math operation, the description is complete: it defines the behavior, gives the required input shape, states the return shape, and notes logging behavior. The presence of an output schema reduces the need to detail return values further.

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 clarifies that `data` is a wrapper object containing the input number `a`. This helps an agent navigate the nested structure, but it adds little beyond what the schema already shows and provides no constraints, ranges, or examples for the parameter value.

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 clear verb and resource: it rounds a number up to the nearest integer. The examples, especially -3.1 -> -3, effectively distinguish ceiling from floor and other arithmetic siblings.

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 intended use is implied by the name and the operation description, but there is no explicit guidance about when to choose this tool over alternatives such as floor or round. No exclusions or sibling routing 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?

With no annotations, the description carries the burden and discloses important behavior: input in degrees, result range [-1, 1], logging of operation and result, and a Dict return containing either result or error. It doesn't detail error cases or side effects beyond logging, but those are secondary for a pure math 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?

Purpose is front-loaded in the first sentence, and the remaining Args/Returns/Notes lines each add a non-redundant constraint: units, result range, return shape, and logging behavior. No filler or excessive detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter math tool, the description covers invocation (what object to pass), units, expected output range, return format, and side effect (logging). The output schema also exists, so the missing detailed return shape is not a 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%, so the description compensates by explaining the data parameter as 'an object containing the angle in degrees' and by clarifying angle units. It does not spell out the exact JSON shape (data.angle), but the schema's AngleOperation definition fills that 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?

Opens with a specific verb and object: 'Calculate the cosine of an angle in degrees.' This distinguishes it from sibling math/trig tools (sine, tangent) and states the unit, so an agent knows this is the cosine operation and not a generic angle calculator.

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 first line and Notes give clear context for when to use it: whenever the cosine of an angle expressed in degrees is needed, with a reminder that radians are not accepted. It does not explicitly contrast with sine/tangent siblings, but the wording is unambiguous enough 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 discloses the ZeroDivisionError condition, logging behavior, and that responses are either success or error dictionaries. This gives the agent a complete picture of runtime 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 well-structured with Args, Returns, Raises, and Notes sections, and the core action is front-loaded. It contains slight redundancy between the Returns line and the Notes about success/error responses, but overall every section 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?

For a simple one-parameter arithmetic tool, the description is complete: it defines the input object, explains the roles of both fields, specifies the error condition, and describes the return behavior. An output schema exists, so the missing formal return schema is not a 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 coverage is 0%, and the description fully compensates by explaining that `a` is the numerator, `b` is the denominator, and that a zero `b` causes an error. It provides meaningful semantic meaning beyond the raw schema property names.

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: 'Perform division of two numbers provided in the TwoNumberOperation object.' The verb 'divide' plus explicit numerator/denominator roles distinguishes it from all sibling math 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?

The description implies the tool should be used whenever division is required, but it does not explicitly discuss when to choose this tool over alternatives like modulus or power. Usage context is clear from the operation name and description, but no exclusion or alternative 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?

There are no annotations, so the description carries the behavioral disclosure burden. It discloses error behavior (ValueError on negative/non-integer), valid input domain, that it 'Logs the operation and result,' and that it returns a dictionary with result or error. It does not describe output key names, but the presence of an output schema reduces the need for that detail.

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 core purpose is front-loaded in the first sentence, and the rest is a compact docstring organized into Args, Returns, Raises, and Notes. There is minor redundancy between the Raises section and the first Note, but every section adds useful information and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter mathematical tool, the description provides everything needed: purpose, parameter structure, valid input domain, error conditions, side effects, and return container. Since an output schema exists, return-value details are already covered. An agent can confidently select and invoke this tool without additional 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 description coverage is 0%, so the description needs to compensate. It explains that `data` is a `SingleNumberOperation` object containing the input number `a`, and clarifies the valid domain as non-negative integers. This is sufficient for constructing the argument, though the exact nested JSON shape is left to the schema.

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

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

The description states a specific verb and resource: 'Calculate the factorial of a given number.' This unambiguously identifies the operation and distinguishes it from sibling math tools like add, power, sqrt, and logarithm. There is no vague or misleading language.

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 clear usage constraints: 'Only works with non-negative integers' and raises ValueError for negative or non-integer input. This tells the agent when the tool can be used and what inputs are invalid. It does not explicitly name alternatives for non-factorial operations, but the operation itself is unique among the 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?

With no annotations provided, the description carries the full disclosure burden. It states that rounding always goes down (including negative values), that results are returned as a dictionary with either a result or an error message, and that the operation logs the call. This is solid but does not detail 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 front-loaded with the core behavior and uses compact Args/Returns/Notes sections. Minor redundancy exists between 'Round a number down' and 'Always rounds down,' but the second clause earns its place through clarifying negative examples.

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 operation this is complete: it defines the input wrapper, the operation, the return shape, edge-case behavior, and logging. The only missing detail is when an error message is produced, but the output schema presumably covers the exact return keys.

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 explain the parameter. It does explain that data is a SingleNumberOperation object containing the input number a, which compensates for the schema's opaque top-level reference. It could add the exact type constraint, but 'input number' plus schema is sufficient.

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 opens with a specific verb and resource: 'Round a number down to the nearest integer.' The explicit examples, including the negative case -3.1 -> -4, distinguish this from a rounding/truncation or ceiling operation, which is the direct sibling.

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 operation's use is implied clearly by the verb and examples, but the description never says when to choose floor over the sibling ceiling (or vice versa). There is no explicit exclusion or conditional 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the operation logs activity, returns a dictionary with either a result or an error message, and raises ValueError for non-integer inputs. These are meaningful behavioral traits beyond the bare operation, though it does not specify whether the operation has side effects beyond logging.

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 well-structured with Args, Returns, Raises, and Notes sections, making it scannable. The main purpose is front-loaded, and each section adds useful information. There is minor redundancy between the Raises section and the Notes bullet about integers, but overall the length is justified.

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 mathematical operation, the description is complete: it covers the operation, input constraints, error behavior, return format, and side-effect logging. An output schema exists, so return-value details need no further explanation. An agent has everything needed to invoke the tool correctly and interpret its outcome.

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 reported as 0%, so the description must compensate. It explains that `data` is a TwoNumberOperation object containing `a` and `b`, and adds the critical constraint that both must be integers. It also clarifies that the operation produces the largest dividing number, giving semantic meaning to the parameters beyond the schema's minimal 'First number' and 'Second number' labels.

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 opens with a specific verb and resource: 'Calculate the Greatest Common Divisor (GCD) of two numbers.' It later defines the result as 'the largest number that divides both inputs,' which precisely distinguishes it from sibling tools like lcm, since LCM is the least common multiple. This leaves no ambiguity about what the tool does.

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 clear context for use: it is for computing the GCD of two integers. It states the prerequisite that both numbers must be integers, and it notes that a ValueError is raised if they are not, which guides the agent on input preparation. However, it does not explicitly mention alternatives like lcm or when to prefer one over the other, so it stops short of a 5.

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 present, so the description carries the full burden. It explicitly discloses the integer requirement, the return dictionary shape with either a result or an error, the ValueError condition, and the side effect of logging the operation and result. This is strong 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?

The description is efficiently structured with Args, Returns, Raises, and Notes sections. Every sentence adds relevant operational information, with no filler 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?

For a single-parameter math tool with an output schema, the description covers input structure, constraints, return behavior, error handling, and logging. Nothing essential for an agent to invoke 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%, but the description compensates by explaining that data is a TwoNumberOperation containing a and b and adding the critical integer constraint that the schema's 'number' type does not convey. It does not repeat parametric details already in the schema.

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

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

The description opens with a specific verb and target: 'Calculate the Least Common Multiple (LCM) of two numbers.' It then reinforces the meaning by stating the result is the smallest number divisible by both inputs, which clearly distinguishes it from the sibling gcd and other arithmetic 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?

The description clearly states the integer precondition and general operation, but it does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives such as gcd. Usage is mostly implied by the mathematical operation named in the purpose.

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 provided, the description carries the full behavioral burden and does reasonably well. It discloses that invalid inputs raise ValueError, that the operation is logged, and that the result is returned in a dictionary, providing useful behavior beyond the schema.

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 well-structured with Args, Returns, Raises, and Notes sections, and the core purpose is front-loaded in the first sentence. Each section adds useful detail without significant redundancy, though some repetition with the schema is present.

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 description covers the expected inputs, error behavior, default configuration, natural logarithm alternative, return shape, and logging side effect. It is complete enough for a simple mathematical operation, though it could be improved by defining what makes a base 'invalid' and by referencing the natural_log 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 reported as 0%, so the description must compensate. It explains that value must be positive, that base defaults to 10, that base 'e' performs natural logarithm, and that invalid bases raise an error. This adds meaningful semantic information beyond the raw schema 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?

The description states a specific operation: 'Calculate the logarithm of a value with a specified base,' with the tool name and resource clearly aligned. It does not explicitly distinguish itself from the sibling natural_log tool, though the natural logarithm handling is mentioned indirectly via base 'e'.

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 explicit guidance is given about when to choose logarithm over natural_log or other math siblings. The note about base 'e' implies how to do natural logs, but it does not tell an agent when to use this tool versus the dedicated natural_log sibling.

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 provided, the description carries the full burden. It discloses key behaviors: returns a dict with result or error, raises ValueError on an empty list, and logs the operation. These are genuinely useful behavioral details beyond the schema.

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 well-structured with clear sections for Args, Returns, Raises, and Notes. It is compact and front-loaded with the purpose. The only minor redundancy is the Args line, which repeats schema information, but overall it is concise and readable.

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 with one parameter and an output schema, so the description does not need to explain return values in depth. It covers the main error condition, the return shape, and the logging side-effect, making it complete enough for an agent to invoke the tool correctly. It lacks deeper statistical caveats, but they are not essential 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%, so the description should compensate, but the Args section merely restates what the schema already shows: data is an object containing a list of numbers. It does not add parameter-level meaning such as supported numeric types, formatting constraints, or edge-case handling beyond the empty-list note.

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: 'Calculate the mean (average) of a list of numbers.' This clearly distinguishes it from statistical siblings like median and standard_deviation, and the formula note reinforces the exact meaning.

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 implies when to use the tool by defining mean and the operation, but it does not explicitly contrast it with alternatives like median or standard_deviation. For a simple arithmetic/statistical tool, the intended usage is reasonably clear, yet no direct guidance or exclusion is 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 burden of behavioral disclosure. It explains the empty-list ValueError, the even-length averaging rule, and that the operation and result are logged, which gives the agent useful behavioral expectations beyond the raw schema.

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 well-structured docstring with clear Args, Returns, Raises, and Notes sections. Every sentence provides relevant information and no filler is present.

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 single-parameter calculator tool, the description covers the operation, input contract, return shape, error condition, edge-case behavior, and logging. The presence of an output schema further reduces the need to describe return details.

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

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

Schema description coverage is 0% for the top-level parameter, so the description must compensate. The Args section explains that data is an object containing a list of numbers, but this mostly restates the schema's intent without adding deeper semantics such as required format or constraints beyond the empty-list error.

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 of a list of numbers." This makes the tool's purpose immediately clear and naturally distinguishes it from sibling arithmetic and statistical tools like mean or standard_deviation.

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 clearly indicates when to use the tool: whenever a median of a numeric list is required. It does not explicitly mention alternatives or exclusions, but the verb and resource are specific enough that an agent would not confuse it with other 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?

With no annotations, the description carries the full behavioral burden. It documents the return dictionary, the ZeroDivisionError condition, and the log format, which is strong. There is a small ambiguity: the Returns section suggests error messages are returned while the Raises section says ZeroDivisionError is raised, but overall behavior is much clearer than typical definitions.

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 docstring-style structure front-loads the core action and each section (Args, Returns, Raises, Logs, Example) adds non-redundant operational detail. Every section contributes something an agent needs to invoke or interpret the call correctly.

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-argument function with nested numeric fields, the description covers what the tool does, how parameters are packaged, what a successful result looks like, how errors are handled, and what gets logged. No critical operational information is missing for an agent to call 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?

The schema coverage is 0%, so the description must compensate for parameter meaning. It names the `data` object, says it holds two numbers `a` and `b`, and the log format 'a % b = result' plus the example clarifies their roles and ordering. It does not provide deep per-field semantics, but is sufficient for a simple two-number operation.

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 first sentence states a specific operation — 'Calculate the modulus (remainder) of two numbers' — on a clear resource (the `data` object). The operation is semantically distinct from sibling math tools like divide or gcd, so an agent can tell when this tool applies.

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 clear context: it computes `a % b`, requires two numeric fields, and explicitly notes that `b` cannot be zero. It does not explicitly compare this tool to sibling alternatives, but the modulus/remainder semantics are unambiguous enough for tool 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?

With no annotations provided, the description carries full behavioral disclosure. It explicitly states the return format (dictionary with result or error message), the exact logging format ('MUL | {data.a} * {data.b} = {result}'), and that exceptions are caught and converted into an error response. This is thorough for a pure computation 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?

The description is well-structured with Args, Returns, Logs, and Exceptions sections, and the core purpose is front-loaded. It is slightly more verbose than a simple multiply tool strictly requires, but each section contributes meaningful behavioral information rather than padding.

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 two-number multiplication operation, the description covers inputs, output contract, error behavior, and logging. Even though an output schema is marked as present, the description independently explains what the return value will be. Nothing essential for correct invocation 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?

The top-level data parameter has no schema description (0% coverage), but the description compensates by explaining that data is a TwoNumberOperation object containing a and b to be multiplied. This adds semantic clarity beyond the bare schema. It does not provide examples or edge-case notes, so it stops short of a 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?

The description opens with a specific verb and resource: 'Perform multiplication of two numbers provided in the data object.' It clearly distinguishes itself from the sibling arithmetic tools by naming the operation and the two inputs. No ambiguity about what the tool does.

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 name and description: call this when you need the product of two numbers. However, it does not explicitly discuss when to use this tool versus alternatives like add, subtract, or power, nor provide any exclusion or preference guidance beyond the basic semantic.

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 behavioral disclosure burden and does it reasonably well: it documents the non-positive input domain via `ValueError` and notes that the operation is logged. It also states that the return is a dictionary with either a result or an error message, giving the agent a clear expectation.

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 uses a clear Args/Returns/Raises/Notes structure and front-loads the core purpose in the first sentence. It is appropriately sized, though the note about base e slightly repeats what the opening sentence already states.

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 pure numeric operation, the description covers the input wrapper, error behavior, return shape, and logging side effect. Combined with the available output schema, the agent has enough information to invoke and interpret the tool correctly; the only real gap is sibling differentiation, which is already scored under usage guidelines.

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 description coverage is 0%, so the description must compensate; it identifies `data` as a `SingleNumberOperation` object containing the field `a` and states that `a` is the input number. However, the positive-number requirement is only mentioned in the raises clause rather than attached to the parameter, and the description adds little depth beyond the schema's minimal 'Input number' text.

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 opens with a specific verb and object, 'Calculate the natural logarithm (base e) of a given number,' which unambiguously identifies the operation and distinguishes it from the generic `logarithm` sibling. It also names the single data argument, so purpose is clear.

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 about when to prefer this tool over related siblings such as `logarithm`, nor any exclusionary guidance. The only implied signal is the tool name and opening sentence, which is insufficient when a closely related `logarithm` tool exists.

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 openly discloses the log format ('POW | base ^ exponent = result'), the return shape (result or error message), and exception handling. This is useful, though it stops short of describing edge cases like non-finite inputs or exact response keys.

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 front-loaded with the core purpose and then uses short sections for input, return, logging, and errors. Each section earns its place, though the Args line partially restates what the input schema already expresses. Overall it is compact, structured, and easy to scan.

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 math tool, the description covers invocation, return behavior, logging side effects, and error handling. The output schema exists and can carry return-value details, so the return description is sufficient. It is complete enough for an agent to call the tool correctly, with no major missing prerequisites.

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 description identifies the only parameter, data, as a PowerOperation object containing base and exponent values. It adds the semantic relationship that the base is raised to the exponent, which goes slightly beyond the raw schema. It does not elaborate on constraints such as negative or fractional exponents, leaving the schema's number type to carry that weight.

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 first sentence states a specific operation—calculate power—with clear roles for base and exponent, leaving no ambiguity about the mathematical operation. The phrase 'given exponent' also differentiates it from fixed-exponent siblings like square. This is a precise, non-tautological description.

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 implies the use case: whenever exponentiation with a base and exponent is needed. However, it does not explicitly state when not to use this tool or mention alternatives among the arithmetic sibling tools. The agent must infer selection from the operation semantics rather than being guided.

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 disclosure burden. It adds useful details: input must be degrees rather than radians, output is bounded between -1 and 1, and the operation is logged. It also notes that the result may be an error message, giving an agent awareness of failure modes.

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 well-organized with Args, Returns, and Notes sections. It is concise, front-loaded with the core purpose, and every line contributes useful information without 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?

For a simple one-parameter math tool with an output schema available, the description covers input semantics, unit expectations, output behavior, and logging side effects. Nothing essential is missing for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is reported as 0%, so the description must compensate. It states that 'data' is an AngleOperation object containing the angle in degrees, which clarifies the single parameter's purpose and units. However, it mostly restates what the schema shows and does not add detail about accepted ranges, rounding, 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?

The description opens with a specific verb and resource: 'Calculate the sine of an angle in degrees.' It clearly identifies the mathematical operation, the input unit, and is immediately distinguishable from sibling tools like cosine, tangent, and logarithm. The scope 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?

The description provides clear context for when the tool is appropriate: whenever the sine of an angle in degrees is needed. It does not explicitly state exclusions or direct the agent to an alternative sibling, but for a well-defined math operation the intended use is clear.

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 the ValueError for negative inputs, logging side effects, and the success/error response structure, going well beyond the tool's obvious 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 purpose is front-loaded in the first sentence, and the rest is organized into clear Args/Returns/Raises/Notes sections. It is slightly boilerplate-heavy in the Notes section, but every part is relevant and easy to scan.

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 calculator operation with an output schema, the description covers the operation, input shape, return dictionary, error behavior, and logging. Nothing essential to selecting and invoking this tool 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%, so the description must compensate. It clarifies that `data` is a SingleNumberOperation wrapper containing the input number `a`, but this largely mirrors the schema and adds little extra semantic detail beyond the negative-input constraint mentioned in Raises.

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 opens with a specific verb and resource: 'Calculate the square root of a given number.' This clearly distinguishes sqrt from the sibling arithmetic operations and leaves no ambiguity about what the tool does.

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 intended use is implied by the description and the Raises clause implies valid input must be non-negative, but there is no explicit guidance about when to prefer this tool over alternatives like power or square. The description gives clear context but not explicit when/when-not 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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly describes the return dictionary, the key fields ('operation name' and 'result'), the logging format, and error behavior. This goes well beyond the schema and gives the agent a concrete picture of side effects and outputs.

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 well-structured with clear Args/Returns/Logs/Raises sections and the core purpose is front-loaded. Each section is concise, though the Raises and error-return statements are slightly redundant with the Returns section.

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 pure-math operation, the description covers input, output, logging, and error handling. An output schema exists, so the return type is already structured. It lacks comparative guidance against sibling tools, but is otherwise complete for calling this tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It only restates that 'data' contains 'the number to be squared' and does not mention the actual field name 'a' or clarify the structure beyond what the schema already shows. This is minimal added value.

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 square of a given number.' This unambiguously identifies the operation and is clearly distinct from siblings like sqrt, power, or multiply.

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 prefer this tool over alternatives such as power, multiply, or sqrt. The only usage signal is the purpose statement itself; there are no exclusions, prerequisites, or comparisons to sibling tools.

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 provided, the description carries the full behavioral burden. It discloses the sample standard deviation formula, the ValueError for fewer than 2 numbers, the dictionary return type, and that the operation is logged. This is solid behavioral context for a simple 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?

The description is well-structured with a clear opening sentence followed by Args, Returns, Raises, and Notes sections. It is appropriately sized for the tool's complexity, front-loads the main purpose, and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter math operation, the description covers purpose, input shape, sample versus population behavior, error conditions, return type, and logging. Given the low complexity and the existence of an output schema, nothing critical 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%, so the description must compensate for the parameter. It explains that data is a ListOperation object containing a list of numbers and adds the key semantic constraint that fewer than 2 numbers raises ValueError, which the schema does not express.

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 begins with a specific verb and resource: 'Calculate the standard deviation of a list of numbers.' This clearly identifies the operation and distinguishes it from sibling statistics tools like mean and median, as well as arithmetic 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 usage context is implied rather than explicit: an agent can infer it is for measuring variation via standard deviation. The note about using sample standard deviation (n-1 denominator) provides some selection guidance, but it does not explicitly contrast with alternatives or state when not to use this tool.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the return dict structure, the success/error behavior, and the exact log format, which is useful and goes beyond a bare statement of 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 tightly structured into Args, Returns, and Logs sections, with every sentence contributing meaning. It is front-loaded with the core purpose and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple binary numeric operation, the description provides enough context: input shape, expected return format, error behavior, and logging side effect. It is slightly incomplete in not explicitly defining the subtraction order, but the parameter names and log format imply a - b.

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 only says the data object contains 'two numbers, a and b' and does not clarify operand order, numerical edge cases, or any constraints beyond what the schema already names.

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 opens with 'Perform subtraction of two numbers provided in the `data` object', which is a clear verb+resource statement. It does not explicitly contrast with sibling arithmetic tools, but the operation and result key ('subtract') make the purpose 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 about when to choose subtract over the many sibling arithmetic operations, nor any exclusions or prerequisites. The description simply states the operation without situating it among 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It meaningfully notes that input is in degrees, that tangent is undefined at 90°, 270°, etc., and that those cases return very large values rather than errors. It also discloses that the operation logs the operation and result, which is useful behavioral context.

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

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

The description is concise, clearly labeled with Args/Returns/Notes, and front-loads the core purpose in the first sentence. Every line adds useful information, and there is no redundant 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 single-parameter math utility with an output schema available, the description covers the critical operational details: degree input, undefined-angle behavior, error-return shape, and logging. No essential detail for correctly invoking the tool 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%, so the description must compensate for parameter meaning. It identifies the single parameter as an AngleOperation object containing the angle in degrees, which clarifies the input semantics beyond the raw schema. The schema already provides the property name and a brief angle description, but the description reinforces the degree unit.

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 opens with a specific verb and resource: 'Calculate the tangent of an angle in degrees.' It clearly identifies the operation and distinguishes it from sibling tools like sine and cosine through both the tool name and the explicit angle-unit 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?

The description implies when to use the tool—whenever a tangent calculation is needed—but does not explicitly compare it to alternatives such as sine or cosine. The notes about degrees and undefined angles provide useful context, but no direct when-to-use or when-not-to-use guidance is given.

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