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

Beyond the annotations (readOnly, idempotent, non-destructive, closed world), the description discloses error behavior for unknown methods and missing required params, that outputs are rounded to 2 decimals, that computation is pure arithmetic with no I/O or external calls, and that there is no auth or rate limiting.

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-loads the techniques, then routing, then method-parameter requirements, then output/behavioral notes. Dense but each sentence carries information; the only slight redundancy is restating return fields when 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 an 8-parameter, method-dispatched tool with an output schema, the description covers method selection, per-method required inputs, units/conventions, failure modes, and side-effect profile — 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 per-parameter meanings are already documented, but the description adds the method-to-parameter mapping (which fields black_scholes/binomial/scenario_analysis require), notes steps only applies to binomial, and clarifies that rate/decimal inputs are fractions in [0,1] — genuine value beyond the schema.

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

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

States specific verbs and resources (Black-Scholes call value, binomial-tree option value, scenario analysis) and explicitly distinguishes itself from sibling tools, naming valuation_probability and valuation_time_value as the alternatives for other tasks.

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 routing: use valuation_probability with method 'probability_weighted' for quick expected values over arbitrary outcome lists, use scenario_analysis here for named bull/base/bear tables, and use valuation_time_value for plain DCF. Each alternative names the condition that selects it.

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/no open world, and the description adds real behavioral context beyond them: pure arithmetic with no I/O or external calls, rounding to 2 decimals, no auth or rate limits, and explicit error behavior for an unknown method or a missing method-required parameter.

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 and information-dense, but the hard-tech exclusion is stated twice ('for hardware or deep tech use valuation_hardware' early, then 'Not for hardware or deep tech — for that use valuation_hardware' later), and the method-parameter mapping is buried in a long run-on middle sentence.

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-param, method-switching calculator with an output schema present, the description covers selection, per-method parameter requirements, edge-case errors, and numerical conventions. 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 description coverage is 100%, so the baseline is 3, but the description adds the conditional dependency structure the flat schema cannot express: peak_sales needs patient_population + penetration + price, decision_tree needs probabilities + terminal_value, pipeline needs drugs + discount_rate. It also clarifies fraction semantics (0.10 = 10%) and that unselected params should be omitted so defaults apply.

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 a specific verb and resource ('risk-adjusted biotech valuation') and enumerates the three concrete models it produces (peak sales, decision tree, rNPV). It also explicitly separates itself from the sibling valuation_hardware, so an agent can route 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?

States the domain ('pharma/drug pipelines'), the exclusion ('not for hardware or deep tech'), and names the alternative tool to use instead. The 'method selects the model' framing plus the required-only-'method' note tells the agent exactly how invocation works.

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, non-destructive, non-open-world behavior, and the description adds real context on top: pure arithmetic with no I/O or external calls, no auth or rate limits, rounding to 2 decimals, and that an unknown method or missing method-required parameter returns an error instead of a value. That is meaningful disclosure of failure modes and side-effect profile.

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 method-dependent parameter mapping, then behavior — a sensible order with almost no filler. It is dense and slightly repetitive on units/weights already stated in the schema, so not quite maximal.

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, method-dependent tool, the description covers method selection, required-vs-optional inputs per method, cross-parameter constraints, input units, error behavior, and integration with sibling valuation tools. An output schema exists, so the brief return summary is redundant but harmless; nothing needed 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 non-schema constraints: the per-method parameter mapping (capm = risk_free_rate + beta + market_return, etc.) and the cross-parameter rule that weights and betas must be equal length. Some unit guidance (fractions, [0,1] sums) duplicates the schema, keeping this below 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 ('Estimate the cost of capital') and enumerates exactly which computations it covers: standard CAPM, startup-adjusted CAPM with size/illiquidity premiums, portfolio beta, and WACC. It explicitly routes the agent away from itself toward valuation_time_value and valuation_international, so it is distinguishable from 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?

Gives explicit when-to-use ('derive the discount rate that feeds valuation_time_value and DCF models') and a conditional alternative ('for cross-border rates add valuation_international'). It further specifies which parameters each method requires and that only 'method' is mandatory, which is actionable 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and explicit error behavior for an unknown method or a missing method-required parameter. It also discloses unit conventions (fractions, 0.10 = 10%; probabilities/weights in [0,1] summing to 1).

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 requirements, then units and return behavior — a logical order with no filler sentences. It is dense and slightly long, and the listing of return fields (value, method, inputs, assumptions, chapter, formula_number, calculation steps) partially duplicates the existing output schema, so it falls just short of maximal conciseness.

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, method-branching calculator with annotations and an output schema, the description covers everything an agent needs: routing, required vs. method-dependent parameters, unit conventions, determinism/rounding, error semantics, and side-effect profile. Nothing material is left to inference.

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 100% schema coverage the baseline would be 3, but the description adds meaning the schema does not: an explicit mapping of which parameters each method requires (pe_ratio needs market_cap + net_income; ev_revenue needs enterprise_value + revenue; regression_multiple needs intercept + growth_rate + growth_coefficient, plus optional maturity/stage/geography terms). That method-to-parameter dependency is the single most useful piece of invocation guidance and is absent from 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?

The opening sentence names the specific resource (market multiples from comparables) and enumerates the exact ratios produced (P/E, P/S, EV/EBITDA, EV/Revenue, regression-adjusted), with 'method selects the ratio' clarifying the tool's controlling input. It also names the sibling it is not (valuation_core) and the condition that routes elsewhere, so an agent can distinguish it 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 guidance: 'Use when public comparables exist; for pre-revenue or private startups use valuation_core.' It further states only `method` is required, that other params are method-dependent, and that callers should supply only those the selected method names and omit the rest. When-to-use, when-not-to-use, and the alternative are all present.

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), yet the description adds substantial behavioral context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and explicit error behavior on unknown method or missing required parameter.

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-loads the method inventory and usage rule, then the per-method parameter mapping, then routing, then output/unit conventions — a logical order with no filler sentences. It is a dense single block and slightly long for one paragraph, but every clause carries decision-relevant 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?

Despite 17 parameters and 7 enum methods, the description supplies the per-method parameter mapping, unit semantics, error cases, and result shape; the output schema covers return fields (value, method, inputs, assumptions, chapter, formula_number, steps) which the description points to without duplicating. An agent has everything needed to call any method 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%, so the baseline would be 3, but the description adds cross-parameter conditional logic the schema cannot express: which parameters each method requires (scorecard → average_valuation + weights + scores; vc_pre_money → post_money + investment, etc.) plus unit conventions (fractions like 0.10, weight/probability lists in [0,1] summing to 1, method-dependent optional parameters that 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 resource (pre-revenue valuation methods) and enumerates exactly which methods it covers: Scorecard, Berkus, Risk-Factor Summation, VC Method both variants, and terminal value. It explicitly distinguishes itself from the sibling emerging/advanced/comparables tools, so an agent can route without opening any 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 these first for early-stage startups') plus three named alternatives with the exact conditions that select them (SAFEs/tokens/ESG/network effects → valuation_emerging; options or bull/base/bear tables → valuation_advanced; public comps → valuation_comparables). 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 readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description still adds genuinely new behavior: 'pure arithmetic — no I/O and no external calls', 'no auth or rate limits', results 'rounded to 2 decimals', and the error contract ('An unknown method, or a missing method-required parameter, returns an error instead of a value'). The enumerated return fields (value, method, inputs, assumptions, chapter, formula_number, steps) largely restate the output schema and are the only soft spot, keeping this below 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?

The description is long but front-loaded and densely organized: method inventory, then usage, then per-method parameter dependencies, then routing, then input conventions, then return/error contract. Every section earns its place for a 30-parameter polymorphic tool, though the opening method roster partially duplicates the method enum and the per-method table could be slightly tighter.

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 a 30-param, one-of-N-method tool with an output schema present, the description covers everything an agent needs: which method to pick, which params each method requires, the fraction/percent and [0,1] conventions, sibling routing, error semantics, and determinism. Return-value detail is appropriately delegated to the output schema. The only minor looseness is 'esg_* need base_valuation + a score', which does not name esg_score vs esg_risk_score, but the enum plus schema fields resolve 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?

Schema coverage is 100%, so the baseline is 3, but the description materially exceeds it by mapping conditional parameter dependencies per method (safe_expected needs investment + cap + discount + series_a_valuation + series_a_price; metcalfe needs n; data_moat needs data_volume + data_uniqueness + monetization_rate + competitive_advantage_years). It also supplies unit conventions the schema states only per-field ('Rate and decimal inputs are fractions (0.10 = 10%)') and the omit-the-rest/defaults rule for the 29 optional params.

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 named, specific set of methods (SAFE conversion, token valuation, ESG adjustments, Metcalfe, data moat, remote-first) and states 'Method selects the model', so the verb (value/compute) and resource (emerging & alternative methods) are unambiguous. It explicitly carves out the sibling boundary by naming valuation_core, valuation_advanced, and valuation_comparables, letting an agent distinguish this tool from all 13 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?

It gives explicit when-to-use ('Use for SAFEs, tokens, ESG, network effects, data moats, and remote-first adjustments') and when-not ('for classic pre-revenue methods use valuation_core'), plus a full routing paragraph mapping alternatives: valuation_core for Scorecard/Berkus/Risk-Factor/VC, valuation_advanced for options/scenarios, valuation_comparables for multiples. Nothing about tool selection 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 readOnly/idempotent/non-destructive, but the description adds substantial behavior beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and explicit failure behavior on unknown method 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 diving into the parameter matrix, and every clause is informative. It is long and has minor redundancy ('all other parameters are method-dependent, so supply those the selected method names and omit the rest'), but nothing is 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 15-parameter, 4-mode tool with an output schema present, the description covers routing, per-method inputs, unit conventions, error behavior, and a brief return-value summary without duplicating the output schema in detail. An agent has everything needed 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 coverage is 100%, so per-parameter meaning is already documented. The description still adds real value the schema cannot express: a method-to-required-parameter matrix (e.g. lending needs loan_book + roe + pe_multiple; neobank needs customers + arpu + gross_margin + churn_rate + pe_multiple) plus unit conventions (fractions, probability lists summing to 1).

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 ('Value and size fintech business models') and enumerates the four sub-models it covers (payment revenue, lending, processor DCF, neobank). It also names the sibling it is not (valuation_saas), so an agent can distinguish it without opening sibling 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?

Explicit routing guidance: 'Use for payments, lending, and neobanks; for SaaS-style unit economics use valuation_saas.' It also explains the selection mechanism (method selects the model) and the exclusion condition (missing/unknown method returns an error rather than a value).

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 adds that unknown methods or missing method-required parameters return an error, that inputs are fractions (0.10 = 10%), that probability/weight lists are in [0,1] summing to 1, and that it is pure arithmetic with no auth or rate limits. The return fields are listed, though an output schema exists so that is bonus rather than necessary.

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 purpose, then method routing, then the 'not for' exclusion, parameter guidance, and input conventions. It is information-dense and every sentence carries useful content, though the 'Not for drug pipelines — for those use valuation_biotech' clause repeats the earlier sibling exclusion, which is slightly 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?

For a 9-parameter tool with one required parameter, method-dependent inputs, an output schema, and enum-valued method, the description covers selection, per-method inputs, conventions, error behavior, and return shape. An agent has everything needed 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 coverage is 100%, so the schema already documents each parameter type and meaning; baseline would be 3. The description adds method-to-parameter mapping (trl needs market_size + market_share + margin + multiple + trl_discount; gross_margin needs asp + variable_cost; break_even_volume needs fixed_costs + asp + variable_cost) and the fraction/list conventions, which is meaningful cross-parameter semantics the schema does not encode.

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 specific verbs and resources — 'TRL-risk-adjusted valuation, gross margin, and break-even volume' — matching the three enum methods. It explicitly distinguishes from the sibling valuation_biotech, making it easy for an agent to select among the valuation_* family.

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 when-to-use ('for hardware and deep tech with technology-readiness risk') and when-not ('Not for drug pipelines — for those use valuation_biotech'), naming the alternative tool twice. Method-dependent parameter requirements are also spelled out so the agent knows which inputs to supply.

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/no-open-world, and the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, no auth or rate limits, rounding to 2 decimals, and the failure mode (unknown method or missing method-required parameter returns an error rather than a value). It even lists the return fields.

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 purpose and method-selection logic, then parameter rules and return behavior; every sentence is substantive. Slightly overlong and includes the irrelevant 'probability and weight lists' clause that appears carried over from a sibling 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?

Covers purpose, method selection, per-method parameter requirements, units, error behavior, and return contents. With a 10-parameter schema, one required parameter, and an output schema present, nothing essential is missing 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 100%, so baseline would be 3, but the description adds the crucial method-to-parameter mapping (ppp needs spot_rate + inflation_foreign + inflation_domestic, etc.) and unit conventions (0.10 = 10%) that the schema does not express. Minor noise from mentioning 'probability and weight lists in [0,1] sum to 1', which do not exist in this 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 resource (cross-border valuation adjustments) and enumerates the three supported methods (PPP, country risk premium, international CAPM), so the agent knows exactly what computation this tool performs. It explicitly distinguishes itself from valuation_capm for domestic cost of equity, making it separable from siblings 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?

Explicitly names the use case ('cross-border cash flows and country risk'), names the alternatives ('pair with valuation_capm and valuation_time_value'), and states the exclusion ('Not for the domestic cost of equity — for that use valuation_capm'). It also tells the agent exactly which parameters to supply per method and to omit the rest.

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 cover safety (readOnly, idempotent, closed-world), and the description adds strong behavioral context: defaults apply where defined, fractions convention, [0,1] probability constraints, rounding to 2 decimals, no auth/rate limits, and that unknown methods or missing method-required parameters return an error. This is exactly the sort of value-add the annotations cannot provide.

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 per-method parameter mapping. Dense but no wasted sentences; the method-parameter block is long but earns its place given 9 params and 4 methods. Slightly overloaded for a single paragraph.

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-param, 4-method calculator with an output schema present, the description covers selection, per-method inputs, conventions, error behavior, and return fields. 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 already 100%, but the description adds crucial cross-parameter semantics: which params each method consumes, that only method is required, that method-dependent params should be supplied and others omitted, and the fraction/[0,1] conventions. This meaningfully exceeds the schema's per-field 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?

States a specific domain (two-sided transaction marketplaces) and enumerates the metrics (take rate, GMV multiple valuation, buyer retention, network density). Explicitly distinguishes itself from the subscription sibling by naming valuation_saas and the condition that selects it.

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 a when-to-use-other ('for subscription software use valuation_saas'), plus per-method parameter requirements. An agent can route without opening the schema.

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 safe read-only, idempotent, closed-world profile, and the description goes well beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and the explicit error behavior when method is unknown or a required parameter is missing.

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 core purpose and method list, and each block is useful. However the valuation_advanced routing for bull/base/bear tables is stated twice, which is mild redundancy in an already dense description.

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, enum-driven calculator with an output schema, the description covers everything an agent needs: which method needs which inputs, input-format conventions, and the return payload. The listed return fields are redundant with the output schema but do no harm.

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%, but the description adds a method-to-parameter mapping the schema does not encode (discrete/probability_weighted need outcomes+probabilities, portfolio_return needs weights+returns, poisson needs mean_events+k, continuous needs lower+upper) plus constraints (equal length, probabilities sum to 1, fractions). Slight leftover gap: it doesn't spell out the joint_probability parameter pairing.

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 ('Compute expected value and probability-weighted outcomes') and enumerates the concrete computations (discrete E[X], joint probability, portfolio return, Poisson, continuous E[X]). It explicitly distinguishes itself from siblings valuation_advanced and valuation_time_value.

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 routing: use this tool for arbitrary outcome lists and probability-weighted central estimates, and names the alternatives with the exact conditions that select them ('use valuation_advanced method scenario_analysis for named bull/base/bear tables', 'use valuation_time_value to discount cash flows').

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?

Although annotations already declare read-only/idempotent/non-destructive/closed-world, the description adds real behavioral context: pure arithmetic with no I/O or external calls, rounded to 2 decimals, no auth or rate limits, a documented error path for unknown methods or missing method-required parameters, and the shape of the returned assumptions/steps. 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?

For a 19-parameter, nine-method tool the length is justified and the purpose/routing is front-loaded before parameter mechanics. It is a dense single block, however, and the per-method parameter list would read better structured, so it is efficient rather than exemplary.

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?

Output schema exists so return values need not be re-explained, yet the description still summarizes the return shape and documents failure behavior. Sibling routing, parameter conventions, and the error contract are all present, leaving nothing an agent needs 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 coverage is 100% (baseline 3), but the description adds value the schema does not encode: the per-method parameter mapping (ltv→arpu+gross_margin+churn_rate, cac→sales_marketing_expense+new_customers, etc.) and the grouping convention (only method required, omit the rest). It covers only five of the nine methods, leaving mrr, magic_number, rule_of_40, and cac_payback unmapped, so it stops short of a 5.

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

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

The description names the exact resource (SaaS unit economics and valuation), enumerates the specific metrics computed (LTV, CAC, MRR, ARR, NRR, magic number, Rule of 40, CAC payback, revenue multiple), and states that the `method` argument selects among them. It explicitly distinguishes itself from siblings valuation_marketplace, valuation_fintech, and valuation_core by domain.

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 (subscription software), when not to (marketplace GMV → valuation_marketplace; payments/lending → valuation_fintech; pre-revenue company-level → valuation_core), and which parameters each method requires. Routing to alternatives is explicit rather than inferred.

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: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and deterministic error behavior for unknown methods or missing method-required parameters. That is meaningful behavioral disclosure beyond structured fields.

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 method list and per-method parameter map are front-loaded and dense, and every clause carries routing or invocation information about a 33-parameter tool. It is a long semicolon-chained sentence, but the length is largely justified by the surface area, with only minor density cost.

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 broad multi-method calculator with 33 parameters and an output schema, the description covers selection, prerequisites, per-method inputs, unit conventions, error cases, and return fields. An agent has everything needed to invoke it correctly, and return-value detail is optional given the output schema.

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 by mapping each method to its required parameters (e.g. opm needs enterprise_value + liquidation_pref + time_to_exit + volatility) and stating unit conventions (fractions, probability lists in [0,1] summing to 1). It stops short of documenting every parameter/method pair, so it beats the baseline without being exhaustive.

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 (allocate value) and resource (stakeholders and equity classes), then enumerates the ten supported methods so the agent knows the exact scope. It also positions itself against siblings, making it clearly distinguishable from valuation_core and the vertical valuation 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?

Gives an explicit when-to-use ('only after the company-level value is known') and names the three upstream tools that produce that value, plus an explicit when-not-to-use ('for the company value itself do not use this tool'). Nothing about routing 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 readOnly, idempotent, non-destructive, closed-world, but the description adds substantive context: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and error behavior (unknown method or missing method-required parameter returns an error). The validation constraints (growth_rate > -1, cagr needs starting_value > 0 and periods > 0, dcf needs rate > terminal_growth) further disclose failure modes.

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

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

It is long but front-loaded: purpose and method list first, then usage, then per-method parameter requirements, then constraints and exclusions. Nearly every sentence carries load, though the density is high and a few clauses could be trimmed. No filler or restating of the name.

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, six-method, multi-constraint tool this covers everything an agent needs: method selection, per-method inputs, required constraints, unit conventions, error behavior, and sibling routing. An output schema exists, so return-value explanation is optional, yet the description still summarizes the return shape, which is a bonus rather than 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 each parameter is already documented individually (baseline 3). The description adds meaning the schema does not: the per-method parameter mapping, the rule that only method is required and the rest are method-dependent and should be omitted, and the fractions convention. This is genuine added value over the flat schema, though the parameter-level definitions themselves largely duplicate schema text.

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

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

The description leads with specific verbs (discount, compound, forecast) and enumerates six concrete methods, each tied to a named financial computation. It explicitly distinguishes itself from sibling tools by naming valuation_advanced (options) and valuation_probability (expected values) as the wrong choices, so an agent can route correctly without opening any 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?

It gives a when-to-use clause per method ('to convert future cash to today's value', 'to value a full forecast with a terminal value', 'to derive the growth rate implied by two values') and routes the agent to valuation_capm or valuation_international for the discount rate. Exclusions are explicit and named, covering the full when/when-not/alternatives triad.

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