agentstack-mcp

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

The description discloses a key behavioral trait: honoring weekends and regional holidays. However, with no annotations, it does not cover other important aspects such as return values, default region behavior, or how custom_holidays are applied, leaving some uncertainty for a tool without annotations.

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 (two sentences) and front-loaded with the purpose ('Business-day arithmetic'). It provides enumerations without unnecessary fluff, making every clause informative.

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

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

The tool has no annotations, no output schema, and 0% schema coverage. The description lists operations and regions but fails to clarify which parameters each operation requires or what the return format is, leaving significant gaps 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?

Schema description coverage is 0%, so the description must compensate. It does add meaning by enumerating allowed values for operation and region, but it leaves the other four parameters (days, start_date, end_date, custom_holidays) completely unexplained, which is insufficient for a six-parameter tool.

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 states 'Business-day arithmetic honoring weekends + regional holidays' and enumerates the four operations, clearly distinguishing this tool from sibling financial calculators like calc_currency_convert or calc_metric.

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 provides clear context by describing the domain (business-day arithmetic) and listing available operations/regions, so an agent can infer when to use it. However, it does not explicitly mention alternatives or exclusions, stopping 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?

With no annotations present, the description adds useful behavioral context by specifying that rate is an annual decimal and by enumerating valid compounding frequencies. However, it does not disclose parameter relationships, defaults, edge cases, or return semantics, so significant behavioral ambiguity remains.

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 brief, front-loaded, and includes key value domains without wasted words. It is appropriately compact, though the brevity also contributes to under-specification in other dimensions.

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 9 parameters, no output schema, and no annotations, the description is too sparse to support confident invocation. It covers operation types and compounding frequencies but omits required-parameter relationships, units for years/currency, and expected result shapes.

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 only clarifies rate's format and compounding values, leaving most of the 9 parameters unexplained. It does not map parameters to specific operations, so a user cannot determine which inputs are required for future_value versus cagr.

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 it computes compound-interest/growth math and enumerates the supported operations (future_value, present_value, cagr), which makes the purpose specific and generally distinguishable from sibling financial calculators like calc_irr and calc_npv. However, it does not explicitly contrast itself with any sibling tool.

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

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

The description implies the tool should be used for compound-interest or growth calculations and lists operation modes, but it gives no explicit when-to-use guidance or alternatives. Users are left to infer when to choose this over calc_irr, calc_npv, or calc_depreciation.

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 reveals Decimal precision, the static offline table default, and the use of ECB rates for live/historical data. This goes beyond a simple conversion statement, though it doesn't cover 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?

Two sentences, front-loaded with the action word 'COMPUTE.' and no redundant information. Every phrase contributes to the tool's purpose and behavior.

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

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

For a 5-parameter tool with no output schema and no annotations, the description covers the core functionality, supported currencies, precision, and rate modes. It omits output format and date format, but these are minor gaps given the tool's simplicity.

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 description adds context for the date and live parameters by linking them to live/historical ECB rates. It also lists supported currency codes, but doesn't explain amount, from_currency, or to_currency beyond their schema names. With 0% schema coverage, more parameter detail would be helpful.

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 tool converts between major currencies, listing specific currencies. The verb 'convert' and resource 'currencies' are specific, and it is distinct from sibling calc tools like calc_business_days or calc_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 provides clear context for when to use the tool (currency conversion) and explains the two modes (static offline vs live/historical via date/live=true). It doesn't explicitly name alternatives or exclusions, but the sibling set makes it obvious this is the currency 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?

With no annotations, the description must disclose behavioral traits but only adds a list of methods. It does not mention return structure, limitations (e.g., salvage value must be less than cost), or how currency is handled, leaving significant gaps.

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

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

The description is extremely brief (one line), but this brevity is under-specification rather than conciseness. It omits critical information about parameters and expected outputs, so it is not appropriately sized.

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 5 parameters, no annotations, and no output schema, the description is completely inadequate. It provides no context on return values, assumptions, or calculation details, making it nearly unusable for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate. It defines the 'method' possible values but provides no semantics for 'cost', 'salvage_value', 'useful_life_years', or 'currency', leaving most parameters unexplained.

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 tool computes an asset depreciation schedule and lists three depreciation methods. This distinguishes it from sibling calculation tools like compound growth or IRR, though it could be more explicit about output format.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions for choosing a depreciation method. The description simply states the function without context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the numerical method (Newton + bisection) and the sign-change requirement, which gives some insight into behavior. However, it does not describe what happens when the sign-change condition is not met, how multiple IRRs are handled, or how the guess parameter affects convergence.

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

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

The description is a single, front-loaded sentence that conveys the core purpose and a key constraint without any fluff. Every word contributes meaning, making it highly concise and easy to parse.

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

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

The tool has two parameters and no output schema, so the description must explain parameters and return values. It covers the main calculation and the sign-change condition, but the 'guess' parameter is entirely undocumented, and the return format (a single number vs. an object) is not stated. For a simple financial calculation, this is adequate but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate for parameter documentation. It only references 'cashflows' indirectly via the sign-change requirement and does not explain the expected ordering (e.g., initial investment as negative) or the purpose of the 'guess' parameter at all. This leaves significant ambiguity for a tool with only two parameters.

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 it computes the internal rate of return, defined as the per-period rate where NPV=0. This directly distinguishes it from the sibling calc_npv tool by describing the relationship to NPV. The verb 'COMPUTE' is generic, but the resource and mathematical definition are explicit.

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 a clear usage precondition: 'Requires a sign change in cashflows.' This tells the agent when it is appropriate to use the tool. However, it does not explicitly mention alternatives (e.g., calc_npv) or exclusions beyond the sign-change requirement, so it falls just 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?

With no annotations provided, the description carries the full burden. It mentions 'No parameters' but does not explicitly state that the operation is read-only, non-destructive, or describe the return format beyond listing metrics. Minimal behavioral context is provided, so a score of 2 is appropriate.

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 with only two sentences. The 'COMPUTE.' prefix is unnecessary and adds no value, and 'No parameters' repeats schema information. Otherwise, it is front-loaded with the action ('List') and efficiently communicates the output contents.

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 low complexity (no parameters, no output schema, no annotations), the description provides the essential information about what it lists. However, it lacks explicit context about when to use this tool versus alternatives, and it does not specify the output format. It is adequate but not complete, so a score of 3 is warranted.

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 confirms this. The description adds redundant confirmation ('No parameters') but does not need to explain anything else. Baseline for 0 params is 4, and the description aligns with the schema without contradiction.

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 tool's purpose with a specific verb ('List') and resource ('every supported metric'), and it distinguishes itself from sibling tools like calc_metric by focusing on enumeration rather than computation. The inclusion of 'with descriptions and required/optional params' further clarifies the output scope.

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: this tool is likely used to discover available metrics before calling calc_metric or other computation tools. However, it does not explicitly state when to use it versus alternatives or provide any exclusions, so it only achieves the 'implied usage' level.

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 of transparency, and it does disclose the tool's outputs (monthly payment, total interest, payoff, optional full schedule). However, it omits behavioral details such as how extra payments affect results, rounding rules, or handling of invalid inputs. The optional schedule is mentioned, which is a useful behavioral hint.

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

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

The description is a single, front-loaded sentence that efficiently conveys the core purpose and outputs. There is no filler, but it is so brief that it sacrifices informative detail for brevity.

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 tool with 6 parameters, no output schema, and no annotations, the description is too minimal. It fails to explain the purpose of two parameters (extra_payment, currency) and does not describe the schedule format or edge cases. This leaves significant gaps 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?

Schema description coverage is 0%, and the description does not compensate by explaining the parameters. It mentions outputs that map to principal, rate, and term, but entirely misses 'extra_payment' and 'currency', leaving their roles ambiguous. The agent cannot infer their meaning from the description.

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 'COMPUTE' with a clear resource 'level-payment loan' and lists concrete outputs (monthly payment, total interest, payoff, schedule). This distinguishes it from sibling tools like calc_irr or calc_npv, which handle different financial calculations.

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 for standard amortization loans with level payments, giving some context. However, it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions like adjustable-rate loans or non-standard payment schedules.

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 the decimal convention for rates/margins ('0.05=5%') and the 'Exact' computation guarantee, but it does not mention error handling, output format, or behavior for unsupported metrics, leaving notable gaps.

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

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

The description is two sentences: a front-loaded 'COMPUTE' command followed by a compact list of metrics and a pointer to calc_list_metrics. There is no fluff; every word serves a 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 complexity (14 metrics, nested params object, no output schema, no annotations), the description provides the metric list and decimal convention but relies heavily on another tool (calc_list_metrics) for parameter schemas. It does not explain return values or edge cases, making it moderately complete but not self-contained.

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

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

Schema description coverage is 0%, so the description must compensate. It adds value by enumerating valid values for the 'metric' parameter, but does not describe the structure of the 'params' object or the 'currency' parameter. Pointing to calc_list_metrics for schemas is partial compensation, but the tool is not fully self-descriptive.

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?

Description starts with 'COMPUTE' and specifies 'Exact business/SaaS/finance metric', followed by an explicit enumeration of 14 metric names (ltv, cac, etc.). This clearly identifies both the verb and resource, and distinguishes it from sibling calc_* tools (e.g., calc_business_days, calc_irr).

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 explicitly lists all supported metric names, making the scope clear, and directs users to 'Call calc_list_metrics for schemas' to obtain parameter details. It does not explicitly say when not to use the tool versus other calc tools, but the metric list effectively bounds usage.

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 the period-0 convention for cashflows[0], which is a useful behavioral detail. However, it does not specify the expected rate format (decimal vs percent), how currency is handled, or 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 a single, tightly written sentence with a formula and a key clarification. Every element is informative, with no fluff or repetition.

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 calculation tool, the description covers the core logic but omits important context such as rate format, currency semantics, and expected output. Given no annotations and no output schema, these gaps make it only minimally viable.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for 'rate' and 'cashflows' via the formula and the period-0 explanation. However, 'currency' is left completely unexplained, and the rate's unit (decimal vs percent) is not clarified.

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 tool computes Net Present Value using the provided formula, naming the exact operation and resource. It distinguishes itself from sibling tools like calc_irr and calc_compound_growth by specifying the discounted cash flow method.

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

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

No guidance is provided on when to use this tool versus alternatives such as calc_irr or calc_compound_growth. There is no mention of typical use cases, prerequisites, 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 does disclose the output contents (winner, full ranking, per-criterion breakdowns, methodology, weights, explanation), which is helpful. However, it omits behavior around edge cases, invalid input, tie handling, or whether the operation is purely computational, leaving some uncertainty.

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 dense sentence with no redundant filler; every clause adds information. The 'DECIDE.' prefix and long list of return items could be more structured, but overall it is concise and 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?

This is a complex tool with nested objects, no output schema, no annotations, and zero schema description coverage. The description lists return fields but does not specify the scores matrix format, options type, or the semantics of criteria weight and direction. It is insufficient for an agent to reliably construct valid inputs.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by defining criteria as [{name, weight, direction}] and listing method enum values. Still, it does not explain the expected shape of the scores matrix or the format of options, which are required parameters. Partial compensation only.

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 tool ranks named options against weighted criteria and returns winner, ranking, breakdowns, methodology, weights, and explanation. This specific verb+resource combination distinguishes it from sibling tools like decide_compare_two and decide_score, which focus on narrower functions.

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 what inputs to provide (options, criteria structure, scores matrix) and lists method choices with a default. However, it does not explicitly say when to use this tool versus siblings like decide_sensitivity or decide_compare_two, nor when to choose each method. Usage guidance is mostly 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, the description carries the burden and does disclose the output nature ('per-criterion win counts and margin') and input constraints. It does not state whether the operation is read-only, or how edge cases (e.g., both option_a and options provided) are handled, so it's only partially 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 two sentences, front-loaded with the core purpose and followed by input instructions. No unnecessary words; the 'DECIDE.' prefix is a brand tag but harmless.

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

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

The description covers the essential input-output concept but lacks detail on the scores structure, the meaning of 'margin,' and the method parameter. Since there is no output schema and no annotations, these gaps could lead to incorrect 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 description clarifies that options can be provided as two separate strings or a 2-element array, and it names criteria and scores as required. However, it omits the 'method' parameter entirely and does not explain the structure of the 'scores' object, leaving significant semantic gaps given 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 uses a specific verb ('comparison') and resource ('exactly two options'), and it differentiates from sibling tools like 'decide' by emphasizing the head-to-head pairing and the per-criterion win counts/margin output. This makes the tool's purpose clear and distinct.

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 tool's scope ('exactly two options') and how to supply inputs ('Pass option_a/option_b (or a 2-element options array), criteria, and scores'), giving the agent a clear when-to-use condition. It does not name alternative tools for other cases, but the specificity of comparing two options is sufficient.

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 explicitly describes the output content: the scoring methods, normalization details, and usage guidance. The verb 'List' implies a non-destructive, read-only operation, which is appropriate. No side effects or requirements are mentioned, but for a basic informational tool, this is sufficient.

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 front-loads the verb 'List' and immediately specifies the exact methods and the type of information included. Every word contributes value, and the sentence is well-structured and concise.

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 parameters, no output schema—the description completely specifies what the agent will receive: the three scoring methods with normalization details and when to use each. This is fully sufficient for correct invocation and understanding.

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

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

The tool has zero parameters, and the schema is an empty object. The description redundantly states 'No parameters,' which is harmless but adds no new semantic meaning. According to the baseline for 0 params, a score of 4 is appropriate.

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

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

The description clearly states 'List the scoring methods' with a specific verb and resource, and explicitly names the three methods (weighted_sum, weighted_product, topsis). This distinguishes it from sibling tools like decide_score or decide_compare_two, which likely perform scoring or comparison rather than listing methods.

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 says 'with normalization details and when to use each,' which provides guidance on method selection. However, it does not explicitly state when to use this list tool versus other decision tools, such as decide_score or decide_compare_two. The purpose is clear enough to infer usage, but it lacks an explicit alternative or exclusion statement.

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

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

With no annotations, the description carries the full burden. It discloses the output scope (matrix + ranking, no narrative) and input condition (scores separate), but does not explain normalization details, input validation, or edge cases. The core behavior is transparent enough for a calculation tool, but lacks depth.

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, front-loaded with 'DECIDE' and immediately states the action and output. Every word earns its place, with 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?

Given 4 parameters (3 required), nested objects, no output schema, and no annotations, the description is too brief. It does not explain the shape of the scores object, the role of options/criteria, or how normalization/ranking are computed. An agent would likely need additional context to invoke this correctly.

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

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

Schema coverage is 0%, so the description must compensate. It hints that 'scores' contains per-option, per-criterion data and that scores are provided separately, but it does not explain the structure of 'options', 'criteria', or 'method'. This leaves significant gaps for agents needing to construct valid inputs.

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 tool's function: returning a full normalized scored matrix per option and criterion, plus ranking. It also distinguishes itself from sibling tools by noting it works 'when scores are supplied separately' and omits the 'winner narrative,' 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 provides clear context for when to use the tool: when scores are supplied separately and a full matrix/ranking is desired without a winner narrative. It does not explicitly name alternatives or exclusions, but the conditional phrasing effectively signals its niche among the decide_* family.

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

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

With no annotations provided, the description carries the full burden of disclosure. It transparently describes the sweep behavior ('Sweeps each weight +/- variation') and the outputs ('robustness score + flip points'), which is valuable behavioral context beyond the tool name. It does not mention side effects, but as a sensitivity analysis tool, it implies a read-only computation.

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 concise, using only two sentences to convey purpose, distinction from a sibling, the sweep method, and outputs. Every sentence earns its place, and the 'DECIDE.' prefix is a meaningful category marker rather than 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 (6 parameters, nested objects, no output schema, no annotations), the description is reasonably helpful but not fully complete. It explains the core behavior and output, but does not clarify parameter meanings for 'method' and 'steps', nor the expected shape of the 'scores' object. This is adequate for basic invocation but leaves gaps for precise use.

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

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

Schema coverage is 0%, so the description must compensate for missing parameter details. It adds meaning for 'variation' and 'criteria' by explaining that weights are swept +/- 'variation'. However, it does not explain the semantics of 'method', 'steps', or the structure of 'scores', leaving some parameter ambiguity.

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

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

The description clearly states a specific verb ('Test') and resource ('decision winner') with a precise focus on changes in criteria weights. It explicitly distinguishes itself from sim_sensitivity by contrasting weight variation vs. scenario inputs, making the tool's unique 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 explicitly names the sibling tool sim_sensitivity and explains the distinction: this tool varies criteria weights, while sim_sensitivity varies scenario inputs. This gives clear guidance on when to use this tool versus an alternative.

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

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

Without annotations, the description carries the transparency burden. It explains the process (simulate each option, rank outcomes), but does not explicitly state side effects, permissions, or that it is a read-only analysis. It also omits any details about output format, which is a notable gap.

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

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

The description is concise at three sentences, front-loading the purpose. It uses a compact label 'COMPOSITE' and provides necessary structural input details, though the density might require careful reading.

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

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

Given no output schema and 7 parameters, the description covers the core workflow but omits the return value format and the roles of parameters like 'method', 'horizon', and 'period_label'. It is complete enough for a high-level understanding but lacks details needed for full autonomous 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?

With 0% schema coverage, the description compensates well for the most important parameters: 'options' as [{name, inputs}], 'criteria' as [{metric, weight, direction}], and 'template' as a base. However, it does not clarify 'inputs', 'method', 'horizon', or 'period_label', which remain ambiguous.

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

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

The description clearly states what the tool does: it projects each option as a scenario and ranks them against weighted criteria derived from scenario outcomes. It distinguishes itself from siblings by explicitly stating it 'Combines ScenarioSim + DecisionMatrix', making its composite nature obvious.

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 comparing multiple options via simulation and decision matrix, but does not explicitly mention when to use it over alternatives like sim_run or decide_score. It lacks when-not guidance, so usage 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?

No annotations are provided, so the description carries full responsibility. It only states the tool aggregates health/status and has no parameters, but reveals nothing about return format, potential side effects, or operational characteristics like read-only safety or failure behavior.

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

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

The description is a single concise sentence, front-loading the core purpose and including the no-parameters note. Every word earns its place 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?

Without an output schema or annotations, the description leaves room for ambiguity about what health/status entails and how results are presented. However, the tool's zero-parameter simplicity and the mention of the whole stack provide adequate context for an agent to select it.

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?

There are zero parameters, and the description explicitly notes this. The schema already defines an empty object, so the description adds no parameter-level details, but no parameters means the baseline of 4 applies.

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 tool provides aggregated health/status for the whole stack, specifying 'all three engines + composites.' It distinguishes itself from sibling calculation/decision tools, though 'health/status' is somewhat broad.

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 for checking overall system health but does not explicitly state when to use this tool or when to prefer alternatives. Since no sibling health check exists, the context is somewhat obvious but still implicit.

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 reveals the tool is a discovery read operation, lists the types of information returned, and notes 'No parameters,' implying a safe, side-effect-free call. Without explicit safety hints, still clear enough for an index tool.

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

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

A single, front-loaded sentence uses a colon to list the tool's contents, followed by an imperative usage directive. Every word earns its place; 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?

For a simple discovery tool with no parameters and no output schema, the description adequately explains the return categories and the recommended call order. The lack of an exact return format is acceptable given the tool's purpose, though a bit more detail on the 'links' could improve completeness.

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

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

The tool has zero parameters and the description explicitly states 'No parameters,' which reinforces the schema. As a 0-parameter tool, the baseline is 4, and the description adds no conflicting or unnecessary information.

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

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

The description clearly identifies the tool as a discovery/index for AgentStack, listing exactly what it exposes (namespaces, composite tools, profile filters, server links). This distinguishes it from the sibling tools which perform specific calculations or decisions.

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

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

Explicitly instructs to 'Call this first to see everything AgentStack exposes,' providing clear when-to-use guidance. This is a strong directive that differentiates it from the specific tools it helps discover.

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

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

With no annotations, the description carries the full burden. It discloses the core behavior: simulating, extracting a cash-flow line, and computing three valuation metrics. It also explains the role of initial_investment. But it does not disclose potential side effects, prerequisites, or error behavior; for a non-mutating calculation tool this is adequate 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 compact and front-loaded with the composite nature, then explains the process and key parameters with a concrete example. Every sentence adds value without redundancy, fitting within two sentences.

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

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

For a complex composite tool with 9 parameters and no output schema, the description provides a high-level overview and names the exact outputs (NPV, IRR, undiscounted total). However, it omits details about how the template and inputs interact, the shape of the returned object, and edge cases. It is sufficient for a first understanding but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It effectively explains cashflow_metric (with examples), rate, and initial_investment, and implies template's purpose. However, other parameters (inputs, metrics, currency, period_label, horizon) remain unexplained, and their relationships are vague. The description adds meaningful value for the required parameters but not for the rest.

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 tool's function: it projects a scenario, extracts a cash-flow line, and computes NPV, IRR, and undiscounted total. The term 'COMPOSITE (simulate -> compute)' distinguishes it from sibling tools that only simulate or only calculate, giving a specific verb+resource and clear scope.

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 context: use when you need to combine scenario simulation with financial valuation. It notes the need for a template, cashflow_metric, and rate, and that initial_investment is needed for IRR. However, it does not explicitly contrast with alternatives like calc_npv or sim_run, so usage guidance is clear but lacks explicit 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 behavioral disclosure. It reveals the method (deterministic bisection) but does not explain edge cases such as what happens if no solution exists, whether it is a safe read-only operation, or what the return format is. Significant behavioral information is missing for a solver 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 a single, well-structured sentence with a 'SIMULATE' prefix that immediately sets context. It is concise, front-loaded with the core purpose, and includes the essential required parameters without unnecessary verbosity.

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 complex (8 parameters, no output schema, no annotations), but the description only covers the core purpose and three parameter names. Missing details on return values, bounds behavior, solution existence, and relationship to sibling tools make it incomplete for an agent to invoke 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%, and the description only lists three required parameter names (template, solve_for, target_value) without explaining their meanings or relationships. Parameters like bounds, inputs, horizon, period_label, and target_metric are entirely unexplained, so the description adds minimal value over 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 states a specific action: 'Solve for the scenario input value required to make an output metric hit a target value' using deterministic bisection. This clearly differentiates it from sibling tools like sim_run or sim_sensitivity which likely run or vary simulations. The required parameter names are also explicitly listed.

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 break-even analysis (solving for an input to hit a target) but does not explicitly state when to use this tool versus alternatives like sim_run or sim_sensitivity. It mentions required parameters but provides no exclusions or explicit alternative tool references.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does explain the output style ('side by side with deltas vs the first') and the winner selection logic ('compare_metric + goal (max|min) picks a winner'). However, it does not mention whether the tool is read-only, what happens with invalid scenarios, or any edge-case behavior. This is adequate but not comprehensive.

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

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

The description is two sentences, front-loaded with 'SIMULATE' for immediate context, and every word earns its place. It efficiently conveys the core action, comparison method, and optional winner selection without fluff 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 absence of an output schema, the description should explain return values, but it only says 'key_results side by side with deltas' without specifying structure or data types. It also fails to explain the effect of 'horizon' and 'include_projections', which are likely important for simulation scenarios. With many sibling tools (sim_run, sim_sensitivity, etc.), more contextual guidance would be needed to integrate this tool effectively.

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 only clarifies 'compare_metric' and 'goal' (e.g., 'goal (max|min) picks a winner'). The required 'scenarios' parameter is only hinted at via 'Run 2-3 scenarios', but no format is given. 'horizon' and 'include_projections' are entirely unmentioned, leaving them unclear. This is insufficient for a 5-parameter tool.

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 tool's purpose: 'Run 2-3 scenarios and compare their key_results side by side with deltas vs the first (baseline)'. This is a specific verb+resource combination that distinguishes it from sibling tools like sim_run (which likely runs a single scenario) and sim_sensitivity (which analyzes sensitivity). The optional 'compare_metric' and 'goal' for picking a winner further clarifies its unique functionality.

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 scenario comparison ('Run 2-3 scenarios and compare'), but it does not explicitly mention when to use this tool versus alternatives or when not to use it. For example, it does not state that for more than 3 scenarios one should use a different tool, or that sim_compare is preferred over sim_run when side-by-side comparison is needed. The context is clear but lacks explicit exclusions or alternative references.

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 clearly states the tool lists templates and explicitly says 'No parameters,' which implies a read-only, side-effect-free operation. However, it does not explicitly disclose whether permissions are required or mention any potential errors, though for a simple listing tool this is adequate.

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

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

The description is a single, front-loaded sentence that covers the tool's purpose and output contents without any superfluous filler. Every word contributes to understanding, making it highly concise and well-structured.

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 parameters, no output schema), the description sufficiently covers what is returned and the scope (all templates, custom-model format, period labels). It could be slightly more explicit about the exact return format, but for a listing tool with this simplicity, it is nearly complete.

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

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

The tool has zero parameters, and the description explicitly states 'No parameters.' According to the guidelines, a baseline of 4 is appropriate for 0-parameter tools, and the description reinforces this clarity, so no further documentation is needed.

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' with a clear resource 'every scenario template' and specifies the content: inputs, defaults, outputs, custom-model format, and period labels. This distinguishes it from sibling simulation tools like sim_run or sim_compare, which execute simulations rather than list templates.

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 a usage context (when you need to know available templates before running simulations) but does not explicitly state when to use this instead of alternatives, nor does it mention any exclusions. It lacks the explicit alternative guidance seen in higher-scoring examples.

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

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

No annotations exist, so the description carries the full burden. It discloses the deterministic nature and lists return fields (per-period projections, key_results, assumptions_used, methodology, explanation), providing valuable behavioral context beyond a simple definition.

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

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

The description is a single, front-loaded sentence with a powerful verb ('SIMULATE') and a structured list of outputs. It avoids redundancy, making every word earn 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?

With 5 parameters, nested objects, no output schema, and no annotations, the description should provide thorough guidance. It covers overall purpose and outputs but omits parameter usage, input structure, and differentiation from other simulation tools, leaving significant gaps for correct invocation.

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

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

Schema coverage is 0%, and the description only mentions 'template' and 'metrics' model, leaving 'inputs', 'horizon', and 'period_label' unexplained. It partially compensates but fails to define crucial parameters, especially given the nested object inputs.

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 tool simulates deterministic what-if projections from templates or a free-form metrics model. It lists specific templates and output sections, which distinctly differentiates it from sibling calculation and decision 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 usage for what-if projections, but it does not explicitly state when to use this tool versus sim_break_even, sim_sensitivity, or sim_compare. It gives context but no exclusions or alternative recommendations, making it merely adequate.

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 the sensitivity analysis method (one-at-a-time) and the output (elasticity, ranking), but does not mention whether the operation is read-only, any side effects, or return format details.

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

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

The description is two sentences, front-loaded with 'SIMULATE', and every word adds value. It efficiently covers purpose, method, output, and key requirements without fluff.

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 (12 parameters, nested objects, no output schema, no annotations), a two-sentence description is insufficient for an agent to invoke it correctly. It lacks guidance on parameter combinations, value ranges, and expected result structure.

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 12 parameters with 0% description coverage. The description only clarifies the role of 'template' and 'variable'/'variables', leaving other parameters like min, max, steps, variation, and target_metric unexplained. This does not adequately compensate for the lack of schema descriptions.

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 tool's function: varying scenario inputs to show impact on a target metric. It explicitly specifies 'one-at-a-time' and includes 'elasticity + most-influential ranking', which distinguishes it from sibling tools like sim_run or sim_compare.

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 guidance is implied rather than explicit. The description indicates it requires 'template' and 'variable' (or 'variables'), but does not mention when to prefer this tool over alternatives like decide_sensitivity or stress_test_decision, nor any 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 provided, the description carries the full burden of behavioral disclosure. It explains the output (robustness and flips) and the composite nature, which is helpful. However, it does not explicitly state whether the tool is read-only, if it has side effects, or any limitations or prerequisites. The phrase 'report how often...' implies a non-mutating calculation, but this is not confirmed.

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

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

The description is two sentences, starts with a clear category label, and packs key information: composite nature, operation, output, and parameter guidance. Every word earns its place; 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 complex composite tool with 8 parameters, no output schema, and no annotations, the description is incomplete. It explains the core behavior and the stress parameter but omits details about the other arguments, the exact output format, and any constraints. It relies on knowledge of evaluate_options_with_scenarios, which may not be assumed for a standalone description.

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 all parameters. It only details the 'stress' parameter structure ({variable, variation, steps}) and says 'Same args as evaluate_options_with_scenarios' for the rest. This indirect reference does not compensate for the remaining 7 undocumented parameters, such as options, criteria, and method, leaving a significant semantic 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?

The description opens with 'COMPOSITE (simulate x decide)' and clearly states the tool's function: stress one scenario assumption across all options and report robustness and flips. This distinguishes it from sibling tools like sim_sensitivity and decide, which are simpler or more focused. The verb 'stress' and resource 'options-vs-scenarios decision' provide a specific and unambiguous 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 description implies when to use it: for an options-vs-scenarios decision where you want to stress a single assumption. It also references evaluate_options_with_scenarios as the base argument set, suggesting a shared use case. However, it does not explicitly state when not to use this tool or name alternative siblings for comparison, so it stops short of full guidelines.

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