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 important behaviors: results are returned in order, failures in individual items do not abort the batch, each failure slot holds an error envelope, and there is a maximum of 100 items. This goes beyond basic expectations and adds meaningful 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 moderately sized and front-loads the purpose. Each section (item format, error behavior, batchable tools) earns its place. It could be slightly more compact, but the structure is clear and logical.

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

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

Given that an output schema exists, return value details need not be described. The description covers the core semantics: batch behavior, tool whitelist, ordering, partial failure handling, and item structure. It is complete enough for an agent to invoke the tool correctly.

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

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

The schema only defines 'calls' as an array of objects with no property details. The description compensates by specifying the exact item structure ({tool, arguments}) and the maximum length (100), which is essential for correct invocation. However, it does not explicitly state that the tool names must be from the provided list, though that is implied.

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 uses a specific verb ('Run many calculations') and specifies the resource (calculations) and the batch context. It clearly distinguishes this tool from siblings by positioning it as a batch wrapper over the listed individual 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?

It explicitly states the goal ('to cut agent round-trips') and lists alternative individual tools that can be batched, giving clear context for when to use this tool versus calling a single tool directly. It does not explicitly state when not to use it, but the implication is strong.

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 excels in specifying key behaviors: count_business_days is inclusive, add_business_days accepts negative days, built-in regions work offline, and custom holidays are additive. It does not document error handling or return types, but the output schema is present to cover the return format.

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

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

The description is extremely well-organized: it starts with a one-sentence purpose, then a compact list of operations, followed by region details and a structured argument list. Every sentence adds necessary information without redundancy, and the formatting makes it 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?

Given the tool's moderate complexity (6 parameters, 4 operations, multiple region modes), the description covers all essential aspects: operation semantics, parameter formats, region behavior, and custom holidays. An output schema is present, so the absence of return-type details is acceptable. The only minor omission is behavior when an unsupported region is used without the holidays package, but this is implicitly handled by the 'optional package' note.

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 provides only names and types, leaving all meaning to the description. The description explains each parameter in detail: operation options, ISO date format, negative day support, end_date necessity for counting, valid region values, and custom_holidays format. This fully compensates for the 0% schema coverage.

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 clear purpose: 'Business-day arithmetic honoring weekends and regional public holidays.' It then enumerates four specific operations, making the tool's function unambiguous. This distinguishes it from sibling tools like currency conversion or financial metrics, which are clearly different domains.

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 strong contextual guidance: it lists supported regions, mentions the optional holidays package for broader country coverage, and specifies which parameters apply to which operation. However, it does not explicitly state when to use this tool over alternatives or when it would be inappropriate, falling short of a full usage-guide.

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 transparency burden. It discloses exact decimal precision, that rates/margins are decimals (0.05 = 5%), optional defaults like [gross_margin=1], and that currency only formats monetary results. It does not discuss error handling or edge cases, but the provided behavior is substantial.

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 long but every line earns its place. The intro is front-loaded, the metric-to-params list is well-structured with code blocks and bullets, and the Args section mirrors the schema. There is no redundancy or 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 tool's complexity (14 metrics, varying params), the description is thorough: it explains precision, param mappings, defaults, and formatting, and points to list_metrics for full schemas. Since an output schema exists, omitting return-value details is acceptable. This description is fully adequate for a complex compute 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 coverage is 0%, but the description compensates fully by mapping each metric to its required parameter keys, showing optional defaults in brackets, and explaining the decimal convention. It also clarifies that currency is for formatting. This gives the agent complete parameter semantics beyond the generic 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 clear verb+resource: 'Compute a business / SaaS / finance metric with exact decimal precision.' It then lists 14 supported metric names, giving a precise scope that differentiates it from sibling calculators like currency_convert or business_days.

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 implicitly defines usage by listing the metrics it supports and directs users to call list_metrics for full schemas, but it never explicitly states when to choose this tool over alternatives like compound_growth, net_present_value, or currency_convert. There are no exclusions or trade-off notes.

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 transparency burden. It discloses the annual decimal rate format, the allowed compounding frequencies, and which parameters are needed for each operation. It does not mention edge cases (e.g., negative years) or the exact return format, but for a pure calculation tool, this level of detail is adequate and useful.

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 well-structured: it opens with the overall purpose, then lists operations and parameters in a clear format. The use of backticks and pipes makes it scannable. Every sentence adds value, and there is no repetition of schema defaults or obvious 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 tool's complexity (9 parameters, 3 operations), the description covers the necessary operating contexts: what each operation computes, the inputs it needs, and the rate/compounding semantics. Since an output schema exists, return-value details are not required. The description is sufficient for an agent to select and invoke the tool correctly for typical use cases.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of 'rate' (annual decimal), 'compounding' (allowed values), and enumerates which parameters are required for each operation. It does not explicitly describe 'currency' or 'begin_value'/'end_value' beyond their role in operations, but the operation context makes their purpose clear. This meaningfully supplements the bare 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 clearly identifies the tool as compound-interest/growth math with specific operations (future value, present value, CAGR). It distinguishes itself from siblings like net_present_value and loan_amortization by focusing on single-sum growth calculations. The verb 'compound-interest / growth math' is specific and the listed operations clarify the resource.

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 when to use the tool by listing the three operations and the required parameters for each. It implicitly differentiates from siblings (e.g., using this instead of net_present_value for simple growth). However, it does not explicitly state alternatives or exclusion scenarios, so it stops short of a full 'when-not-to-use' guideline.

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 burden and discloses important behavior: Decimal precision, fallback to static rates on network failure with a warning, the meaning of the live parameter, and the return fields (converted amount, cross-rate, provider, timestamps).

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 structured into a clear summary, supported currencies, rate behavior, and an Args section. Each sentence adds useful information, and the document is front-loaded with the core purpose.

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

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

The tool has five parameters and no annotations, but the description covers all behaviors, fallbacks, and output fields, and even notes the return format despite an output schema being present. It is fully complete for agent invocation.

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

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

The input schema lacks descriptions, but the description provides thorough explanations for all five parameters, including constraints (amount >= 0), types (ISO 4217 codes), and options for date and live. This gives agents everything needed to invoke the tool correctly.

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: 'Convert an amount between major currencies with Decimal precision.' It lists supported currencies and return fields, clearly distinguishing this from sibling financial tools like calculate_metric or loan_amortization.

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 default static rate behavior and when to use live/historical rates via date or live=true, providing clear context. It does not explicitly compare to alternatives, but the tool's unique conversion purpose makes usage self-evident.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool returns Year-1 depreciation plus the full yearly schedule and that book value converges to salvage_value. It also lists the accepted methods, giving a good sense of 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-organized: a one-line summary, a methods list, a return behavior note, and a compact Args list. Every sentence provides necessary information without 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?

Given that the output schema exists, the description needn't detail return structure, but it already states the output shape. Combined with the parameter explanations, it is complete for this calculation 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?

The Args section adds meaning beyond the bare schema, explaining each parameter with constraints (cost, salvage_value <= cost, useful_life_years > 0) and the currency formatting. This fully compensates for the 0% schema description coverage.

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 'Asset depreciation schedule' and then enumerates the three supported methods. This clearly identifies the tool as a depreciation calculator and distinguishes it from sibling financial calculators like loan_amortization.

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 sets clear context: it is for computing depreciation schedules with specified methods. It doesn't explicitly compare to alternatives, but the purpose is distinct enough among siblings, so there's clear context without 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?

With no annotations, the description carries the full burden of safety disclosure. 'Return server health/status metadata' clearly indicates a read-only operation with no side effects, and listing the specific metadata fields provides a transparent expectation of the response. It does not describe potential caveats (e.g., network latency) but is sufficiently transparent for a health check.

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

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

The description is a single, concise sentence that fully captures the tool's purpose and output without extraneous words. It is properly front-loaded with the verb 'Return' and immediately specifies the resource.

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

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

Given that the tool has no parameters and an output schema is present, the description is complete for its simplicity. It fully explains what the tool returns, and there is no missing context for an agent to invoke 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 tool has zero parameters, and the schema coverage is trivially 100%. The description adds no parameter-specific detail because none is needed, which matches the baseline for parameter-free tools.

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 uses the verb 'Return' with a specific resource 'server health/status metadata' and explicitly lists the contents (name, version, tools, capabilities). This clearly distinguishes it from the sibling tools, which are all financial calculations, making 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?

The description implies usage via its role as a health check, and the tool is unique among siblings, so no alternatives are needed. However, it does not explicitly state when to use it (e.g., for monitoring connectivity) or any exclusions, but the context is clear from the name and description.

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

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

The description discloses the numerical method (Newton's method + bisection fallback) and the prerequisite sign pattern, which is useful. However, it does not cover failure modes like multiple IRRs or non-convergence, and there are no annotations to provide additional safety/permission 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 and well-structured: definition, algorithm note, requirement, and argument list. Every sentence serves a purpose, with no 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?

Given that an output schema exists, return values need no explanation. The description covers the mathematical definition, algorithm, prerequisite, and parameter details. It lacks discussion of edge cases (e.g., multiple IRRs), but is otherwise adequate for a straightforward calculator.

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 compensates thoroughly. It explains cashflows with a concrete example and defines guess as a decimal starting rate for Newton's method, giving both format and purpose.

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 explicitly defines 'the per-period rate where NPV == 0', which is a clear and specific statement of the tool's purpose. This distinguishes it from sibling tools like net_present_value, which calculates NPV rather than the rate.

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 is for calculating IRR but does not explicitly state when to use it over alternatives. It mentions a constraint (at least one negative and one positive cashflow) but lacks scenario-based 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 burden. It states the tool lists every supported metric, implying a read-only operation, but does not disclose any additional behavioral traits such as response size, pagination, or authentication requirements. This is adequate for a simple list operation, but not rich.

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 sentence that leads with the verb and clearly states the scope. Every word earns its place; there is 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?

Given the tool's simplicity (no input parameters) and the presence of an output schema, the description sufficiently covers what the tool does. It explains the content of the listing (description, required/optional params), making it complete for its context. The output schema can handle return value 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?

The tool has zero parameters, and the input schema is empty, so the baseline is 4. The description does not need to add parameter semantics. It does clarify that the output includes parameter information for each metric, which is helpful context 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?

The description uses a specific verb ('List') and resource ('every supported metric'), and specifies what is included (description, required and optional params). This clearly distinguishes it from sibling tools like calculate_metric which perform calculations rather than listing metadata.

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 usage: to discover available metrics and their parameters. However, it does not explicitly state when to use this tool versus alternatives, nor mention any prerequisites or exclusions. For a simple listing tool, the context is fairly clear, but no formal guidance 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?

With no annotations, the description provides useful behavioral details: the exact payment formula, the conversion of annual_rate to monthly, the effect of extra_payment ('shortens the term'), and the conditional return of the schedule via include_schedule. It does not cover edge cases or rounding, but the core calculation behavior is transparent.

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: a one-line summary, the formula (useful for transparency), and a clean Args list. Every sentence adds value, and there is no fluff or redundancy. The front-loaded summary gives immediate clarity.

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

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

Given the six parameters, no annotations, and 0% schema coverage, the description covers the calculation logic and parameter semantics well. An output schema exists, so return values need not be described. However, it omits explicit usage exclusions and error-handling behavior, leaving a minor 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?

The schema has 0% description coverage, so the description fully compensates by explaining all six parameters: principal (>0), annual_rate (decimal, with example), term_months (>0), extra_payment (optional, shortens term), currency (ISO formatting), and include_schedule (conditional schedule return). This is highly valuable beyond the raw 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 'Level-payment loan: monthly payment, total interest, payoff, and schedule,' which clearly specifies the tool's function and outputs. The verb is implicit but unambiguous, and the resource (loan amortization) is distinct from sibling tools like compound_growth and depreciation.

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 usage for level-payment, fixed-rate loans through the formula and parameter details, but it does not explicitly state when to use this tool versus alternatives (e.g., compound_growth, NPV). No exclusions or alternative tool names are mentioned, so guidance is only implied.

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 disclosing behavior. It explains that period 0 is the initial investment, the rate is a decimal, and the currency is used for formatting. This adds valuable detail about input interpretation and output formatting, though it stops short of describing error handling or edge cases.

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: a concise summary, the formula, and a clear args list. Every sentence adds necessary detail without redundancy. The structure is easy to scan and front-loads the core purpose.

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 moderate complexity and the presence of an output schema (so return values need not be described), the description is complete. It specifies the formula, period indexing, minimum cashflow length, and parameter formats, leaving no critical behavioral 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?

The input schema provides no descriptions (coverage 0%), so the description's parameter explanations are essential. It fully clarifies rate (decimal per period), cashflows (list of >=2 numbers with an example), and currency (ISO code for formatting), adding meaning far beyond the schema's bare type definitions.

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 identifies the tool as computing Net Present Value (discounted cash flow) of a periodic cashflow series. It provides the formula and explains the timing convention, which distinguishes it from sibling financial tools like internal_rate_of_return and compound_growth.

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 when to use the tool: to compute NPV for a series of periodic cash flows. It does not explicitly name alternatives or state exclusions, but the mathematical definition precisely scopes its application, making the usage unambiguous.

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