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

Although annotations already mark the operation as read-only and idempotent, the description adds substantial behavioral detail: flows[0] is not discounted, outflows are negative, IRR can be unavailable with specific reasons, and multiple sign changes may produce multiple IRRs. This goes well beyond the annotations and helps the agent interpret results correctly.

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 and front-loaded with the core purpose, followed by usage guidance, parameter clarifications, return behavior, and examples. Every block earns its place; there is no fluff, and the examples compactly convey common use cases.

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 financial-analysis tool with edge cases, the description covers the essential caveats: non-discounted period 0, IRR unavailability conditions, multiple IRR ambiguity, and signChanges as a trust signal. Since an output schema exists, detailed return values are not required here, but the description still provides the most important return semantics.

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 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: period determines annualization behavior, the first element is not discounted, outflows must be negative, and discount_rate_annual uses effective annual rate with an example. It also clarifies the minimum length requirement for flows.

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 and resource: 'Compute NPV, IRR and payback directly on a list of period cash flows'. It clearly distinguishes itself from contract-based siblings by stating 'with no contract model involved', and the later contrast with cashflow_evaluate_contract removes ambiguity.

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 states when to use the tool ('when the numbers already exist', spreadsheet flows, sanity check), gives concrete example queries, and provides a direct exclusion: 'Don't use when: you have contract terms rather than flows (use cashflow_evaluate_contract)'. This is exemplary routing guidance.

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

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

Annotations already mark this readOnly and idempotent, and the description adds substantial behavioral detail: how contingency is folded into contribution margin, the exclusion of escalation, handling of fixed revenue offset, and edge cases returning null or unitsUnreachable. This goes well beyond what annotations provide and fully discloses the computation's assumptions.

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 well-structured: a one-line summary, then logic, args, returns, and examples. It front-loads the purpose and uses sections effectively. Some sentences about contingency could be considered verbose, but they are essential to prevent misuse, so a 4 is fair.

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 complexity of the model, the description covers assumptions, edge cases (null, unitsUnreachable), return fields, and usage scenarios. It is complete enough for an agent to invoke correctly, and the output schema (though not shown) is further supported by the listed return fields.

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 describes volume_factor ('Scales planned volume before solving'), and the description adds a default of 1 and clarifies that model has the same shape as cashflow_evaluate_contract. This adds some context, but with only 50% schema coverage the description does not fully compensate for the lack of documentation on the nested model fields, which are already described in the schema itself. Baseline 3 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 opens with a specific verb and resource: 'Compute the monthly volume at which a contract stops losing money, without running the full schedule.' It clearly distinguishes from the sibling cashflow_evaluate_contract by noting it avoids the full schedule, and it explains the core purpose unambiguously.

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

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

The description gives explicit 'Use when' examples ('How many units a month do we need to cover costs?', 'How much headroom is there between plan and break-even?'). It also contrasts with the full schedule, implying the alternative is cashflow_evaluate_contract, but it does not explicitly name that tool or state when not to use this one, so a 4 rather than 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety behavior is covered. The description adds valuable behavioral details: variants are ordered best-first by the chosen metric, each entry includes headline metrics and financing cost, a winner is named, and IRR-less variants are ranked last because an absent IRR is not a low one. This goes well beyond the 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 well structured with clear sections: purpose, args, returns, ranking nuance, and examples. It front-loads the core purpose and uses the examples efficiently. The phrase 'Built for the question these models exist to answer' is slightly unnecessary but not harmful.

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 tool with nested model objects and an output schema, this description is sufficiently complete. It covers input constraints (2–5 variants), ranking metric defaults, response formats, output shape, ranking behavior, and practical examples. The schema and output schema handle the remaining parameter and return-structure details.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the shape of variants and the defaults for rank_by and response_format, but it does not add meaningful semantic depth beyond what the input schema already provides.

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: 'Evaluate two to five named contract variants and rank them side by side.' It clearly differentiates this from sibling tools like cashflow_evaluate_contract by framing it specifically as a multi-variant comparison, and the examples reinforce the intended use cases.

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 explicit 'Use when' examples, such as comparing 24-month interest-free versus 36-month with interest, and comparing 3-year versus 5-year terms. It does not name sibling tools or state when not to use this tool, but the context is clear enough for an agent to select it for comparison questions.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, establishing the tool's safety profile. The description adds valuable behavioral context by explaining the formulas for each convention, warning that mixing conventions 'quietly distorts every downstream number,' and noting the return format includes both conventions side-by-side. This goes beyond the annotations and enriches the agent's understanding.

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 and appropriately sized. It starts with the core purpose, then explains the conventions, lists arguments, describes the return, and ends with usage examples. Every sentence adds value—the warning about distortion and the concrete examples are essential, not filler. It is concise yet comprehensive.

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 and the richness of the schema (100% coverage) and output schema, the description is complete. It covers all parameters, explains the math, provides usage examples, and highlights the critical pitfall. The agent has everything needed to correctly select and invoke the tool without additional context.

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

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

Schema coverage is 100% and each parameter has a description, so the baseline is 3. However, the description adds significant meaning: it provides the exact mathematical formula for the 'convention' parameter ('(1 + annual)^(1/12) - 1' vs 'annual / 12') and gives a concrete example for 'value' ('0.14 for 14%'). This goes well beyond the schema's generic wording, making the semantics much clearer.

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 annual and monthly rates under two conventions, using specific verbs and resources. It distinguishes itself from sibling tools (analysis, modeling, evaluation, etc.) by focusing solely on rate conversion, so an agent can easily identify its unique 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 explicitly provides two 'Use when' examples that illustrate concrete scenarios, guiding the agent on when to invoke this tool. While it doesn't list alternatives, the clear examples and distinct focus make the intended usage unambiguous relative to the sibling tools.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't restate safety. It adds valuable behavioral nuance beyond annotations: null semantics for irrAnnual (with irrUnavailableReason) and paybackMonth, and error handling that names the offending field on malformed input. This transparency helps agents interpret results correctly and handle failures gracefully.

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 longer than a single sentence but well-structured with sections for purpose, args, examples, and error handling. Each section earns its place, and the core scoping statement is front-loaded. The length is justified by the tool's complexity, and there's no filler 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?

Given the tool's complexity (nested model object, many fields), the description provides enough to call it correctly: it points to cashflow_model_template for shaping the model, explains null returns, and describes error handling. The output schema is present, so return details are covered elsewhere. It's comprehensive without being exhaustive.

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 67%, so the description must add meaning beyond the schema. It does: for schedule_detail it warns that 'monthly' can return 61 rows for a 60-month contract and should only be requested when a specific month matters; for response_format it clarifies that structured data is always returned in structuredContent. It also advises calling cashflow_model_template when unsure how to shape the model. These add practical guidance over the schema's bare 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 opens with a specific verb and resource: 'Expand a contract into a month-by-month cash flow schedule and compute the metrics that follow from it,' naming IRR, NPV, payback, MOIC, ROI, working capital, break-even, and financing cost. It then declares itself the 'main entry point' for evaluating deals, which clearly distinguishes it from siblings like cashflow_compare_contracts and cashflow_run_sensitivity. The purpose is unambiguous and differentiated.

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 explicit use cases ('Use when: Is this 5-year service contract worth signing?') and explicit non-use cases with alternatives ('Don't use when: comparing two or more variants (use cashflow_compare_contracts)'). This is exactly the when/when-not guidance agents need, with sibling tools named. Nothing is left to inference.

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

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

Annotations already declare the tool read-only and idempotent. The description adds valuable behavioral detail beyond that: it matches spreadsheet PMT(rate/12, nper, -pv), handles the zero-rate case, and divides the annual rate by 12 rather than compounding it. This is exactly the kind of context that prevents incorrect invocation or misinterpretation.

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

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

The description is front-loaded with the core purpose, then the critical rate convention, then arguments, return values, and examples. Every sentence adds value: the PMT convention, the rate warning, and the examples are all substantive and non-redundant.

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

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

Given the output schema exists and annotations cover safety, the description is complete: it explains what the tool computes, the important rate convention, the optional amortization output, and provides realistic usage examples. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, and the Args section mostly restates the schema descriptions (principal, term_months, annual_rate, include_amortization). The global rate-convention warning is useful but not parameter-specific, so the description adds little meaning beyond what the schema already provides.

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?

Purpose is stated with a specific verb and resource: 'Compute the level monthly payment that amortizes a principal, plus the total paid and the interest it costs.' The reference to spreadsheet PMT and the rate-convention warning clearly distinguish it from sibling cash-flow tools that analyze flows, run sensitivity, or convert rates.

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 concrete 'Use when' examples and explicitly warns against mixing the loan rate division convention with compounding discounting used elsewhere in the server. This gives clear context for when the tool is appropriate, though it does not name sibling alternatives or provide an explicit when-not-to-use list.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds valuable behavioral context: the returned object is 'guaranteed to validate,' includes model/notes/conventions, and each template shape's coverage is described. No contradiction exists.

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

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

The description is well-structured with a lead sentence, a 'when to use' rationale, bulleted shape explanations, args/returns sections, and examples. Every sentence adds useful information, and the most important guidance is front-loaded.

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

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

For a single-parameter, high-level template tool with an output schema, the description is complete: it covers purpose, expected return shape, template options, defaults, and usage context. Nothing an agent needs to know before calling it is missing.

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

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

Although the schema already documents the single template parameter at 100% coverage, the description enriches each enum value with meaning: 'managed_service' exercises every field, 'subscription' has flat fee/no metered volume, 'equipment_lease' has fully metered revenue. It also clearly states the default.

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: 'Return a filled-in, valid contract model to copy and edit.' It then distinguishes itself from sibling analysis/evaluation tools by positioning itself as the first step when building a model, not analyzing one.

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?

Explicit usage guidance is provided: 'Call this first when you are about to build a model and are unsure how the fields fit together.' It also gives concrete examples ('Help me model a service contract' and no model exists yet) and compares to assembling from schema, making when-to-use vs alternatives clear.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral detail: the five default scenarios, the fact that custom scenarios override them, the emphasis on volume as the most fragile assumption, and the return semantics (base case unmodified, deltas in percentage points, null IRR handling). No contradiction with 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 well-organized with Args, Returns, and Examples sections, front-loading the purpose and default behavior. The extended note about volume is somewhat digressive but still adds useful domain context. Overall, every section earns its place with minimal 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 complex nested schema and existing output schema, the description is quite complete: it covers default scenarios, override behavior, return fields, and example use cases. It stops short of explicitly routing to sibling tools or stating exclusions, which would make it 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 coverage is 67%, and the description compensates well. It describes the model as 'same shape as cashflow_evaluate_contract', lists scenario fields succinctly, and explains response_format options. This goes beyond the raw schema entries by clarifying the relationship to other tools and the effect of custom scenarios.

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: 'Re-evaluate a contract under a set of scenarios and report each one against the base case.' This is a specific verb+resource that distinguishes it from a simple single evaluation, though it does not explicitly name sibling tools to differentiate itself.

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

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

The description provides explicit 'Use when' examples, such as 'What happens to this deal if volume comes in 20% under plan?' and 'How fragile is the return to the inflation clause?'. This gives clear context for when the tool is appropriate, but it does not mention alternatives or when-not-to-use conditions.

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