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

Annotations already cover the safety profile (readOnly, idempotent, closed-world). The description adds real behavioral context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, and explicit error behavior for unknown methods or missing required params. It loses a point only because return-field enumeration is redundant against the existing output schema.

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

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

Front-loaded with technique names and routing guidance, and dense with actionable detail. Slightly over-long because the return-object field list and the no-auth/no-rate-limit clause restate things already implied by annotations and the output schema.

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

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

For an 8-parameter, method-dispatch tool with a rich schema, output schema, and annotations, the description covers routing, method-parameter contracts, error semantics, and numeric formatting. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine value by mapping which parameters each method requires (black_scholes/binomial need underlying+strike+risk_free_rate+volatility+time_to_maturity, binomial adds steps, scenario_analysis needs scenarios) — a method-to-parameter contract the schema does not express.

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

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

States specific techniques (Black-Scholes call value, binomial-tree option value, scenario analysis) and the method-selection mechanism. Explicitly distinguishes itself from valuation_probability and valuation_time_value by name, so the agent can route without opening schemas.

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?

Gives explicit when-to-use and when-not-to-use: 'For a quick expected value over arbitrary outcome lists, prefer valuation_probability', 'Not for plain discounted cash flow — for that use valuation_time_value'. Names alternatives and the conditions selecting them.

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 readOnly/idempotent/non-destructive/closed-world, and the description adds genuine context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no authentication or rate limits, and concrete failure semantics (unknown method or missing required param returns an error instead of a value).

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

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

Front-loaded with purpose and method mapping, then behavior, then error semantics — a logical order. It loses a point for repeating the hardware/deep-tech exclusion twice ('for hardware or deep tech use valuation_hardware' and again later), and the return-field enumeration is somewhat redundant given an output schema exists.

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 9-parameter tool with one required parameter, the description covers method selection, per-method parameter requirements, defaults behavior, arithmetic purity, rounding, and error conditions. Since an output schema exists, listing return fields is optional and not a gap.

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

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

Schema description coverage is 100%, so per-parameter meaning is already documented and the baseline is 3. The description adds real value on top by mapping each method to the parameters it needs (peak_sales → patient_population + penetration + price, decision_tree → probabilities + terminal_value, pipeline → drugs + discount_rate) and clarifying that only method is required while others are method-dependent.

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+resource: 'Risk-adjusted biotech valuation' covering three named methods (peak sales, decision-tree EV, pipeline rNPV). It explicitly distinguishes the tool from the sibling valuation_hardware by domain (pharma/drug pipelines vs. hardware/deep tech), so an agent can route without opening schemas.

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 states when to use it ('pharma/drug pipelines') and names the alternative for the excluded case ('for hardware or deep tech use valuation_hardware'), plus model-selection guidance ('Method selects the model'). It also states which parameters to supply per method and to omit the rest, leaving little 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 readOnly, idempotent, non-destructive, closed-world, but the description adds substantial context the annotations cannot: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth/rate limits, and importantly that unknown methods or missing required params return an error rather than a value. That failure-mode disclosure is valuable beyond the structured hints.

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

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

Front-loaded with purpose, then routing, then a compact method-to-parameter map, then return/behavior notes. It is dense and mostly earns its length, though the requirement that only method is required is stated twice and could be tightened.

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 14-parameter tool with an output schema, the description covers the method-dependent input contract, failure behavior, precision, and routing to related tools. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description contributes cross-parameter semantics the schema does not: which parameters pair with each method, and the constraint that weights and betas must be equal length. This relational guidance genuinely reduces misuse risk.

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

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

States a specific verb and resource ('Estimate the cost of capital') and enumerates the four distinct methods (standard CAPM, startup-adjusted CAPM, portfolio beta, WACC), which cleanly separates it from the other valuation_* siblings. An agent can tell exactly what computation it performs without opening the schema.

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

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

Explicit routing: use it to derive the discount rate that feeds valuation_time_value and DCF models, and add valuation_international for cross-border rates. It also specifies when-supply-what per method and instructs to omit parameters not named for the selected method.

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 read-only, idempotent, non-destructive, and closed-world behavior, but the description adds meaningful operational context: pure arithmetic with no I/O or external calls, no auth/rate limits, 2-decimal rounding, and error behavior for unknown methods or missing required parameters.

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?

Despite being fairly long, the description is dense and front-loaded: purpose first, then usage, then parameter rules, then return/behavior details. Every sentence adds actionable information for a 15-parameter, method-branching calculation tool.

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 valuation tool with many optional parameters, an output schema, and rich annotations, the description covers the remaining gaps: method selection, alternative tooling, parameter requirements, error cases, determinism, and rounding. Nothing an agent needs to select and call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents each field, but the description adds critical method-to-parameter mapping (pe_ratio needs market_cap + net_income, etc.) and states that only method is required while other parameters are method-dependent and should be omitted when unused.

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

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

The description names the specific resource and the set of computed multiples (P/E, P/S, EV/EBITDA, EV/Revenue, regression multiple), making the tool's output unambiguous. It also distinguishes itself from a sibling by directing pre-revenue/private-startup cases to valuation_core.

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

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

It gives explicit when-to-use guidance ('Use when public comparables exist') and a clear alternative for the excluded case ('for pre-revenue or private startups use valuation_core'). The method-dependent parameter guidance further tells the agent how to invoke the tool correctly.

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

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

Beyond the read-only annotations, it discloses that the tool is pure arithmetic with no I/O, external calls, authentication, credentials, or rate limits. It also states that results are rounded to 2 decimals and that invalid method or missing required method parameters return an error rather than a value.

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

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

The description is long but front-loaded and dense with routing, method-parameter mapping, return details, and safety constraints. It earns most of its length given 17 parameters and 7 methods, though it could be structured with clearer separators for faster scanning.

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 17 parameters, seven methods, full schema coverage, and an output schema, the description is complete: it covers routing, required versus optional inputs, return shape, arithmetic behavior, error handling, and security/rate-limit context. An agent has everything needed to select and 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?

Although schema coverage is already 100%, the description adds meaningful method-to-parameter mapping that the schema does not: it names the exact parameters needed for scorecard, berkus, risk_factor, vc_post_money, vc_pre_money, terminal_value, and triangulated. It also explains that only method is strictly required and that other parameters should be omitted when not needed for the selected method.

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

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

The description names the specific pre-revenue valuation methods covered and explicitly routes to sibling tools for other methods. An agent can distinguish this tool from valuation_emerging, valuation_advanced, and valuation_comparables without opening their schemas.

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 states when to use this tool first (early-stage startups) and gives explicit routing rules to alternatives for SAFEs, tokens, ESG, network effects, options, scenario tables, and public-comparable multiples. It also clarifies that only method is required and the rest are method-dependent.

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 cover read-only, idempotent, closed-world, non-destructive traits. The description adds beyond that: pure arithmetic with no I/O or external calls, rounding to 2 decimals, no authentication/credentials/rate limits, and explicit error behavior for unknown methods or missing required parameters.

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?

Dense but appropriately sized for a 30-parameter multi-method tool, with purpose front-loaded. Some redundancy: the routing to valuation_core is stated twice, and return values are listed despite an output schema existing, adding minor bloat.

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 high complexity, 100% schema coverage, and an output schema, the description is complete: it covers routing, method-parameter mapping, error conditions, and operational behavior. An agent has everything needed to select and 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 100%, so baseline is 3. The description adds substantial value by mapping parameters to each method (e.g., safe_discount needs series_a_price + discount; metcalfe needs n; data_moat needs data_volume + data_uniqueness + monetization_rate + competitive_advantage_years). However, the mapping is incomplete for some methods (nvt_ratio, remote_npv, remote_premium, and precise esg_rate/esg_premium/esg_discount parameter sets are not spelled out).

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

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

States a specific verb+resource (valuation methods) and enumerates the alternative approaches covered (SAFE, token, ESG, Metcalfe, data moat, remote-first). Explicitly names sibling tools (valuation_core, valuation_advanced, valuation_comparables) to distinguish 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?

Gives clear when-to-use routing: 'Use for SAFEs, tokens, ESG...; for classic pre-revenue methods use valuation_core' and further routes to valuation_advanced and valuation_comparables. Leaves no ambiguity about which sibling to pick for a given scenario.

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 readOnly/idempotent/non-destructive/openWorld=false, and the description layers on context those annotations cannot carry: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth/credentials/rate limits, and explicit failure behavior for unknown methods or missing method-required parameters.

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

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

Front-loaded with purpose and routing before the dense method/parameter mapping, and every clause is functional. Slight redundancy in enumerating return fields (value, method, inputs, assumptions, chapter, formula_number, steps) when an output schema already documents them.

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 15-parameter, four-mode calculator with all-null-optional schema, the description supplies mode gating, required-vs-optional semantics, error behavior, and precision policy. With an output schema present, the extra return-shape sentence is redundant but harmless; nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value the schema cannot express: which parameters each method consumes, that only 'method' is required, that unlisted parameters should be omitted, and that documented defaults apply. Minor gap: 'years' and 'npl_reserves' are not mapped to any method even though lending/payment_processor formulas imply them.

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

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

States a specific verb+resource ('Value and size fintech business models') and enumerates the four concrete model families it covers (payment revenue, lending, payment-processor DCF, neobank). It explicitly names the sibling it is not (valuation_saas), so an agent can route without opening either schema.

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

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

Gives an explicit routing rule ('Method selects the model. Use for payments, lending, and neobanks; for SaaS-style unit economics use valuation_saas'), naming the alternative and the condition that selects it. The method-parameter dependency table further tells the caller exactly what to supply per mode.

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 readOnly/idempotent/non-destructive/no-open-world, so the safety profile is covered. The description adds real behavioral context beyond that: pure arithmetic, no I/O or external calls, results rounded to 2 decimals, and explicit error behavior for an unknown method or a missing method-required parameter. It also restates the return fields, which is redundant given the output schema, so it falls short of a 5.

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

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

Front-loaded with purpose, method mapping, and constraints in a compact block. It loses a point for redundancy: the 'not for drug pipelines, use valuation_biotech' exclusion appears twice and the return-field enumeration duplicates the output schema.

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

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

Given nine parameters, a 100%-covered schema, an output schema, and full annotations, the description covers everything an agent needs: method-dependent parameter selection, error semantics, determinism, rounding, and no-auth/no-rate-limit conditions. The output schema removes any need to explain return values in the 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 coverage is 100% and each parameter is individually documented, so the baseline is 3. The description goes beyond the schema by mapping which method requires which parameters (e.g., trl needs market_size + market_share + margin + multiple + trl_discount) and clarifying that non-selected parameters should be omitted with defaults applying. That conditional relationship is not expressed by the flat schema.

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

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

States a specific verb+resource (hardware/deep-tech valuation) and names the three concrete methods it computes (TRL-risk-adjusted valuation, gross margin, break-even volume), immediately distinguishing it from valuation_biotech. An agent can select it over the other valuation_* siblings without opening the schema.

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

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

Explicitly states when to use it (hardware/deep tech with technology-readiness risk) and names the alternative with its own condition (drug pipelines -> valuation_biotech). Nothing is left to inference, though the exclusion is stated twice.

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 readOnly/idempotent/non-destructive/closed-world, and the description adds substantive behavior beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and precise error semantics for unknown methods or missing required parameters. That error contract is the key operational detail an agent needs.

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

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

Front-loaded with purpose, then usage, then the method-to-parameter mapping, then return/behavioral notes. Dense but almost every sentence carries a distinct constraint. Minor penalty for run-on sentences with heavy parentheticals that make it slightly harder to scan.

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

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

An output schema exists, yet the description still briefly names the return fields (value, method, inputs, assumptions, chapter, formula_number, steps), which is harmless and mildly helpful. Combined with the error contract and parameter mapping, an agent has everything required 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 100% and the enum already embeds the formulas, so the baseline is 3. The description earns extra credit by mapping each method to its required parameter set (ppp→spot_rate+inflation_foreign+inflation_domestic, etc.) and clarifying that only 'method' is required while the rest are method-dependent — a cross-parameter constraint the schema cannot express. It falls short of 5 only because per-parameter semantics are largely left to the schema.

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

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

States a specific domain (cross-border adjustments) and enumerates the three concrete methods (PPP, country risk premium, international CAPM), and explicitly distinguishes itself from the sibling valuation_capm. An agent can route between this and the domestic cost-of-equity tool without opening either schema.

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

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

Gives explicit when-to-use ('Use for cross-border cash flows and country risk'), when-not ('Not for the domestic cost of equity — for that use valuation_capm'), and companion tools ('pair with valuation_capm and valuation_time_value'). This is exactly the routing guidance needed in a 14-sibling 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description still adds substantive behavior: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth/credentials/rate limits, and explicit error semantics for unknown methods or missing required parameters.

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

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

Front-loaded with purpose, then routing, then per-method parameter contracts, then return/behavior notes — a logical order with no filler. It is dense and somewhat long, and the return-field enumeration overlaps the output schema, but each sentence carries operational weight.

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 9-parameter, 4-method calculator with an output schema, the description covers selection, conditional inputs, error behavior, precision, and safety context. An agent has everything needed to choose a method and supply the correct arguments.

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, but the description adds genuinely new information the schema cannot express: the conditional dependency mapping each method to its required inputs (take_rate -> revenue+gmv, gmv_multiple -> gmv+multiple, etc.) and the rule that unneeded parameters should be omitted. It stops short of units or edge-case semantics, so not a 5.

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

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

States a specific verb+resource (marketplace health and valuation metrics) and enumerates the four metrics computed. It explicitly names the sibling it is not (valuation_saas) and the domain it serves (two-sided transaction marketplaces), so an agent can separate it from the other 13 valuation_* tools without opening a schema.

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

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

Gives an explicit when-to-use ('two-sided transaction marketplaces') and when-not ('for subscription software use valuation_saas'), plus the per-method parameter contract and the instruction to omit parameters not named for the selected method. Nothing about invocation 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 establish readOnly/idempotent/non-destructive/no-open-world, so the safety profile is covered structurally. The description adds real behavioral context beyond that: pure arithmetic with no I/O, results rounded to 2 decimals, and explicit error behavior for unknown methods or missing per-method parameters. It also restates auth/rate-limit absence, which is mild duplication of annotation intent rather than a contradiction.

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

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

Front-loaded with purpose and method list, then constraints, then routing. Slightly long and the valuation_advanced routing is stated twice (once in the method list, once in the 'Routing:' sentence), costing some economy, but nearly every sentence carries operative information.

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

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

For a 9-parameter, 1-required, method-dispatched tool with a full output schema and annotations, the description supplies everything an agent needs: which method, which params per method, list constraints, error conditions, and rounding. Return-value detail is already in the output schema, so its absence would not be a gap.

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

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

Schema coverage is 100%, so per-parameter documentation is already handled and the baseline is 3. The description adds genuine value by mapping parameters to methods (outcomes+probabilities for discrete/probability_weighted, weights+returns for portfolio, mean_events+k for poisson, lower+upper for continuous) and by stating the equal-length and sum-to-1 constraints, which the schema only partially implies.

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

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

States a specific verb (compute) and resource (expected value / probability-weighted outcomes) and enumerates the six concrete formulas the tool implements. It explicitly names sibling tools (valuation_advanced, valuation_time_value) and the conditions that separate them, so an agent can route without reading the schema.

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

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

Gives explicit when-to-use ('probability-weighted central estimates') and when-not ('named bull/base/bear tables' → valuation_advanced scenario_analysis; option pricing → black_scholes/binomial; discounting → valuation_time_value). Alternatives and their selection conditions are named outright.

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 readOnly, idempotent, non-destructive, closed-world; the description goes well beyond by stating this is pure arithmetic with no I/O or external calls, no auth/credentials/rate limits, results rounded to 2 decimals, and that invalid method or missing method-required params return an error rather than a value. That is the operational detail an agent needs before invoking.

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

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

Front-loaded with the metric list followed by routing, per-method parameter requirements, and output/behavioral notes. Very dense with no filler, though the single paragraph runs long and the per-method parameter inventory is the kind of detail some agents would prefer tabulated; still, every sentence carries information.

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

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

An output schema exists and the description still names the return shape (value, method, inputs, assumptions, chapter, formula_number, calculation steps). Combined with the method-selection rule, parameter dependency map, and error behavior, an agent has everything needed for a 19-parameter, method-dispatch tool.

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

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

Schema coverage is 100% and the enum documents each formula, but the description adds the crucial cross-parameter mapping that the schema cannot express: which parameters each method consumes (ltv→arpu+gross_margin+churn_rate, cac→sales_marketing_expense+new_customers, etc.) and that unlisted params should be omitted.

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

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

States a specific domain (SaaS unit economics and valuation) and enumerates the exact metrics computed (LTV, CAC, MRR, ARR, NRR, magic number, Rule of 40, CAC payback, revenue multiple). The sibling differentiation is explicit: marketplace GMV → valuation_marketplace, payments/lending → valuation_fintech, pre-revenue company-level → valuation_core.

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 routes the agent: 'Use for subscription software; for marketplace GMV metrics use valuation_marketplace and for payments/lending use valuation_fintech' plus 'Not for company-level pre-revenue value — for that use valuation_core.' It also states the error condition when an unknown method is passed or a required method parameter is omitted.

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 read-only, idempotent, closed-world, non-destructive, but the description goes further: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth/rate limits, and error behavior for unknown methods or missing method-required parameters. These are traits the annotations do not carry.

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

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

Front-loaded with purpose and precondition, and the per-method parameter list is compressed into terse phrases. It is long, but the length is largely earned by ten distinct methods and 33 parameters; a small amount of repetition around required-vs-optional could be trimmed.

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 multi-model calculator with an output schema present, the description covers the precondition, the method-to-parameter contract, the error surface, and numeric formatting. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds genuinely new semantics by mapping each method to the specific parameters it requires (e.g. dilution needs ownership_before + investment + post_money), information the flat 33-parameter schema cannot express. It also explains that only 'method' is required and other params are method-dependent.

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

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

States a specific verb and resource ('Allocate value across stakeholders and equity classes') and enumerates the ten allocation models it implements. It also names the sibling tools it must follow (valuation_core, valuation_saas, valuation_comparables), so an agent can place it precisely in the toolchain.

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?

Gives an explicit precondition ('Use only after the company-level value is known') and an explicit exclusion ('for the company value itself do not use this tool'), with the alternatives named. This is a textbook when/when-not 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?

Annotations already declare readOnly/idempotent/non-destructive, but the description goes further: it discloses that it is pure arithmetic with no I/O or external calls, that results are rounded to 2 decimals, that no auth/credentials/rate limits apply, and that unknown methods or missing method-required params return an error rather than a value. This is behavioral context well beyond the annotation set.

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 paragraph is long but dense and front-loaded: purpose first, then method semantics, then per-method parameters, then constraints, exclusions, and return/error behavior. Nearly every sentence carries distinct information, though it could be split for readability.

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 10-parameter multi-method calculator, the description covers purpose, per-method param requirements, constraints, exclusions, error behavior, and result rounding; with an output schema present it need not detail the return shape, and it still sketches it. Nothing an agent needs to invoke correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value the schema lacks: a method-to-parameter mapping (which params each method needs) and validation constraints (growth_rate > -1, cagr needs starting_value > 0 and periods > 0, dcf needs rate > terminal_growth). It also explains that only method is required and the rest should be omitted per method.

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?

Names specific verbs (discount, compound, forecast) and the resource (value over time), then enumerates the six concrete formulas it computes. An agent can distinguish it from valuation_capm, valuation_advanced, and valuation_probability purely from the description.

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

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

Explicitly states the four main use cases (convert future cash to present, value a forecast with terminal value, project a series forward, derive implied growth) and routes elsewhere for out-of-scope work ('Not for option values (use valuation_advanced)', 'expected values over outcomes (use valuation_probability)'), plus names valuation_capm as the source of the discount rate.

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