Startup valuation for AI agents: 14 tools, 80+ pre-revenue formulas.
Scored across 14 tools
Tools are organized by distinct valuation domains (core, SaaS, fintech, biotech, etc.) and each description includes explicit routing hints ('Not for X — use Y'). Minor overlap exists between valuation_advanced's probability_weighted/scenario_analysis and valuation_probability, and between valuation_advanced's option pricing and valuation_stakeholder's OPM, but cross-references largely disambiguate them.
All 14 tools follow a perfectly consistent snake_case pattern with the valuation_ prefix (valuation_core, valuation_saas, valuation_time_value, etc.). No deviations in style or verb choice.
14 tools is well within the ideal 3-15 range for a computational valuation server. Each tool covers a coherent domain with multiple methods, so no tool feels redundant or trivial.
The surface comprehensively covers startup valuation: pre-revenue methods, DCF/time value, cost of capital, comparables, probability/expected value, industry-specific models (biotech, hardware, fintech, SaaS, marketplace), emerging methods (SAFEs, tokens, ESG), international adjustments, and stakeholder allocation. No obvious gaps for the stated purpose.
Advanced techniques: Black-Scholes call value, binomial-tree option value, and scenario analysis. Method selects the technique. For a quick expected value over arbitrary outcome lists, prefer valuation_probability with method 'probability_weighted'; scenario_analysis here is for explicit named bull/base/bear scenario tables. Parameters apply per method: black_scholes and binomial need underlying + strike + risk_free_rate + volatility + time_to_maturity (binomial adds steps); scenario_analysis needs scenarios. Not for plain discounted cash flow — for that use valuation_time_value. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | Binomial tree time steps (integer ≥ 1; higher = more accurate). | |
| method | Yes | Formula to apply. Options: black_scholes = C = N(d₁)S - N(d₂)Ke^(-rT).; binomial = Cox-Ross-Rubinstein binomial option value.; scenario_analysis = E[V] = Σ pᵢ·Vᵢ over named scenarios. | |
| strike | No | Strike / exercise price K, currency units. | |
| scenarios | No | Scenario objects: {name: str, probability: 0-1, value: currency}; probabilities should sum to 1. | |
| underlying | No | Underlying asset value S, currency units. | |
| volatility | No | Annualised volatility σ as a decimal (0.80 = 80%). | |
| risk_free_rate | No | Risk-free rate as a decimal (e.g. 0.04 for 4%). | |
| time_to_maturity | No | Time to expiry in years T, must be ≥ 0. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, the description discloses that it is pure arithmetic with no I/O, no external calls, no auth, and no rate limits, that results are rounded to 2 decimals, and that an unknown method or missing method-required parameter returns an error rather than a value. This is substantive behavioral context 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?
It is a dense block rather than short, but the most decision-relevant content (method selects technique, sibling routing) is front-loaded and nearly every sentence earns its place by carrying method routing, unit conventions, error behavior, or return shape. Slightly heavy for a single paragraph, but not padded.
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-switched tool with an output schema, the description supplies the method-to-parameter mapping, unit conventions, error semantics, and side-effect profile, while leaving return-value detail to the output schema. 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 is 3, but the description adds real meaning: it maps 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), states that only method is required and the rest are method-dependent and should be omitted when unused, and clarifies that rate/decimal inputs are fractions and probability/weight lists sum 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+resource ('Advanced techniques: Black-Scholes call value, binomial-tree option value, and scenario analysis') and explains that 'Method selects the technique'. It explicitly differentiates itself from siblings valuation_probability and valuation_time_value, so an agent can route 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 and when-not-to-use rules: use valuation_probability with 'probability_weighted' for a quick expected value over arbitrary outcome lists, use scenario_analysis here for named bull/base/bear tables, and 'Not for plain discounted cash flow — for that use valuation_time_value'. Alternatives are named with the condition that selects them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Risk-adjusted biotech valuation: peak sales, decision-tree expected value, and full pipeline rNPV across drugs. Method selects the model. Use for pharma/drug pipelines; for hardware or deep tech use valuation_hardware. Parameters apply per method: peak_sales needs patient_population + penetration + price; decision_tree needs probabilities + terminal_value; pipeline needs drugs + discount_rate. Not for hardware or deep tech — for that use valuation_hardware. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| drugs | No | Pipeline drugs: {name, peak_sales, probability, years_to_market, multiple(optional)}. | |
| price | No | Price per unit / treatment, currency units. | |
| method | Yes | Formula to apply. Options: peak_sales = Peak = population × penetration × price × compliance.; decision_tree = EV = Π pᵢ × terminal value.; pipeline = V = Σ(peak sales × multiple × P_success) / (1+r)^n. | |
| compliance | No | Compliance / adherence rate as a decimal. | |
| penetration | No | Market penetration as a decimal (0.10 = 10%). | |
| discount_rate | No | Discount rate as a decimal (0.12 = 12%). | |
| probabilities | No | Probability of each outcome or stage, each in [0,1]; the list must sum to 1 where it is exhaustive. | |
| terminal_value | No | Expected exit / terminal value, currency units. | |
| patient_population | No | Target patient population treated per year. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
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 still adds materially: rounding to 2 decimals, unknown-method and missing-parameter error behavior, and that the operation is pure arithmetic with no I/O, auth, or rate limits. That is well beyond the annotation baseline.
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 dense, but it wastes text: 'for hardware or deep tech use valuation_hardware' appears twice, and the return-value enumeration duplicates the output schema. Trimming the redundancy would sharpen it without losing 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?
Covers method selection, parameter gating, numeric conventions, error paths, and safety posture for a 9-param tool. Its return-field listing is unnecessary given the output schema exists, but 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 is 3, but the description adds genuine value the schema doesn't: the method-to-parameter mapping (peak_sales → population/penetration/price, etc.), the rule that only method is required and unused params should be omitted, and the [0,1] and sum-to-one conventions. It does not add much on individual field meaning 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?
Names a specific domain (risk-adjusted biotech valuation) and enumerates the three concrete outputs (peak sales, decision-tree EV, pipeline rNPV). It explicitly distinguishes itself from 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 when to use it (pharma/drug pipelines) and names the alternative plus its condition (hardware or deep tech → valuation_hardware). It also spells out method-selection criteria and which parameter set each method demands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the cost of capital: standard CAPM, startup-adjusted CAPM with size and illiquidity premiums, portfolio beta from weighted asset betas, and WACC blending after-tax cost of equity and debt. Method selects the formula. Use to derive the discount rate that feeds valuation_time_value and DCF models; for cross-border rates add valuation_international. Parameters apply per method: capm needs risk_free_rate + beta + market_return; startup_capm adds size_premium and liquidity_premium; portfolio_beta needs weights + betas, which must be equal length; wacc needs equity_value + debt_value + cost_of_equity + cost_of_debt + tax_rate. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| beta | No | Systematic risk beta (market = 1.0). | |
| betas | No | Asset betas aligned with weights; typically 0.5–3.0 (market = 1.0). | |
| method | Yes | Formula to apply. Options: capm = E(R) = Rf + β·(E(Rm) - Rf).; startup_capm = r = Rf + β·MRP + size premium + illiquidity premium.; portfolio_beta = βp = Σ wᵢ·βᵢ.; wacc = WACC = (E/V)·Re + (D/V)·Rd·(1 − T). | |
| weights | No | Portfolio or factor weights, each in [0,1] and summing to 1 (same order as the paired value list). | |
| tax_rate | No | Effective tax rate as a decimal in [0,1]. | |
| debt_value | No | Market value of debt, in currency units. | |
| cost_of_debt | No | Pre-tax cost of debt Rd as a decimal. | |
| equity_value | No | Value of equity offered, currency units. | |
| size_premium | No | Small-cap / size premium as a decimal. | |
| market_return | No | Expected market return as a decimal (e.g. 0.10 for 10%). | |
| cost_of_equity | No | After-tax cost of equity Re as a decimal. | |
| risk_free_rate | No | Risk-free rate as a decimal (e.g. 0.04 for 4%). | |
| liquidity_premium | No | Illiquidity premium as a decimal. | |
| market_risk_premium | No | Market risk premium as a decimal (e.g. 0.06). |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds materially more: pure arithmetic with no I/O or external calls, rounding to 2 decimals, no auth or rate limits, and error behavior for unknown methods or missing required parameters. That is exactly the operational context an agent needs to call it confidently.
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 front-loaded: purpose first, then when-to-use, then per-method parameter requirements and conventions. Given four distinct methods and 14 parameters, the length is largely earned, though the run-on method-parameter sentence 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?
Complete for a 14-parameter, 4-method tool: method routing, required vs optional parameters, defaults, input conventions, return fields, determinism, and error cases are all stated. The output schema exists, so return-shape detail in the description is appropriately brief.
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 goes beyond by mapping each method to its required parameters, noting beta/weights lists must be equal length, stating that only method is required and others are method-dependent, and fixing the fraction conventions (0.10 = 10%, weights in [0,1] summing to 1). This adds real value over 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 verb (estimate) and resource (cost of capital) and enumerates the four methods (standard CAPM, startup-adjusted CAPM, portfolio beta, WACC) so an agent can distinguish it from valuation_international and other siblings. The scope is unambiguous before any schema is opened.
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 says when to use it ('derive the discount rate that feeds valuation_time_value and DCF models') and names the alternative/complement ('for cross-border rates add valuation_international'). Method selection is routed by name rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market multiples from comparables: P/E, P/S, EV/EBITDA, EV/Revenue, and a regression-adjusted multiple. Method selects the ratio. Use when public comparables exist; for pre-revenue or private startups use valuation_core. Parameters apply per method: pe_ratio needs market_cap + net_income; ps_ratio needs market_cap + revenue; ev_ebitda needs enterprise_value + ebitda; ev_revenue needs enterprise_value + revenue; regression_multiple needs intercept + growth_rate + growth_coefficient (plus optional maturity/stage/geography terms). Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| stage | No | Company stage indicator. | |
| ebitda | No | EBITDA, currency units. | |
| method | Yes | Formula to apply. Options: pe_ratio = P/E = market cap / net income.; ps_ratio = P/S = market cap / revenue.; ev_ebitda = EV/EBITDA = enterprise value / EBITDA.; ev_revenue = EV/Revenue = enterprise value / revenue.; regression_multiple = Multiple = β0 + β1·g + β2·M + β3·S + β4·G. | |
| revenue | No | Revenue for the period, currency units. | |
| geography | No | Geography indicator. | |
| intercept | No | Regression intercept β0 (base multiple). | |
| market_cap | No | Market capitalisation, currency units. | |
| net_income | No | Net income (earnings), currency units. | |
| growth_rate | No | Revenue growth rate as a decimal (0.40 = 40%). | |
| market_maturity | No | Market maturity indicator. | |
| enterprise_value | No | Enterprise value (market cap + net debt), currency units. | |
| stage_coefficient | No | Regression slope on stage. | |
| growth_coefficient | No | Regression slope on growth (multiple points per unit growth). | |
| maturity_coefficient | No | Regression slope on market maturity. | |
| geography_coefficient | No | Regression slope on geography. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/non-open-world, and the description adds substantial 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 (unknown method or missing required parameter 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?
Dense and front-loaded: purpose first, then usage routing, then the method→parameter mapping, then unit/error conventions. Every sentence carries information, though the packed semicolon-heavy sentences demand careful parsing.
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 15 parameters, an output schema (so return values needn't be described), and rich annotations, the description covers the essentials: method-dependent parameter selection, input conventions, determinism, and error cases. Completeness is high with only minor room to tighten.
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%, so the baseline is 3, but the description adds real value beyond the schema by mapping each method to its required parameters (pe_ratio → market_cap + net_income, etc.) and clarifying that only 'method' is required while others are method-dependent. It also documents unit conventions (fractions 0.10=10%).
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 ('Market multiples from comparables'), enumerates the exact ratios computed (P/E, P/S, EV/EBITDA, EV/Revenue, regression-adjusted multiple), and names the routing sibling valuation_core. An agent can distinguish this from the other valuation_* tools 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?
Explicitly states when to use it ('when public comparables exist') and the when-not case with an alternative ('for pre-revenue or private startups use valuation_core'). It doesn't route among the other 13 siblings, but for the primary decision point the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The textbook's pre-revenue methods: Scorecard, Berkus, Risk-Factor Summation, VC Method (post- and pre-money), and exit terminal value. Use these first for early-stage startups. Method selects the formula, and each method names its own parameters: scorecard needs average_valuation + weights + scores; berkus takes five factor awards; risk_factor needs base_valuation + risk_ratings; vc_post_money needs terminal_value + target_return; vc_pre_money needs post_money + investment; terminal_value needs projected_revenue + multiple; triangulated needs the scorecard inputs plus terminal_value/target_return/investment. Routing: for SAFEs, tokens, ESG, network effects, or data-moat methods use valuation_emerging; for options or bull/base/bear scenario tables use valuation_advanced; for public-comparable multiples use valuation_comparables. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: scorecard = V = V_avg · Σ(wᵢ·sᵢ) across 7 factors.; berkus = V = Σ factor awards, each capped at $500K.; risk_factor = V = V_base + Σ(rᵢ·$250K) over 12 risks.; vc_post_money = Post = Terminal / target ROI.; vc_pre_money = Pre = Post - Investment.; terminal_value = Terminal = projected revenue × multiple.; triangulated = Runs Scorecard and the VC Method together and returns their mean. | |
| scores | No | Factor multipliers aligned with weights (1.0 = average, >1 above average). | |
| weights | No | Portfolio or factor weights, each in [0,1] and summing to 1 (same order as the paired value list). | |
| multiple | No | Exit or market multiple applied to the metric. | |
| prototype | No | Berkus award for prototype / technology, 0 to 500,000. | |
| investment | No | Amount invested, currency units. | |
| post_money | No | Post-money valuation, currency units. | |
| sound_idea | No | Berkus award for soundness of the idea, 0 to 500,000 (USD). | |
| quality_team | No | Berkus award for management team, 0 to 500,000. | |
| risk_ratings | No | 12 risk factor ratings in [-2,2] (very low to very high); each unit shifts value ±250,000. | |
| target_return | No | VC target return multiple (e.g. 10 for a 10x target). | |
| base_valuation | No | Pre-adjustment baseline valuation, currency units. | |
| terminal_value | No | Expected exit / terminal value, currency units. | |
| product_rollout | No | Berkus award for product rollout / sales, 0 to 500,000. | |
| average_valuation | No | Average pre-revenue valuation for the sector, currency units. | |
| projected_revenue | No | Projected revenue at exit, currency units. | |
| strategic_relationships | No | Berkus award for strategic relationships, 0 to 500,000. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, the description discloses that it is pure arithmetic with no I/O or external calls, rounds to 2 decimals, has no auth or rate limits, and returns an error (not a value) for an unknown method or missing required parameter. These are meaningful behavioral traits not derivable from 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?
Dense but front-loaded: purpose, then method-to-parameter mapping, then sibling routing, then units and return behavior. Every sentence carries information, though the method/parameter list is long enough that it could be tightened slightly given the schema already documents fields.
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 17-parameter, 7-method tool with an output schema, the description covers method selection, per-method parameter requirements, unit conventions, error behavior, and alternative tools. Return-field enumeration slightly duplicates the output schema, but overall 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 does not: it maps each method to the parameters it consumes (e.g. 'scorecard needs average_valuation + weights + scores', 'berkus takes five factor awards') and clarifies fraction vs. [0,1] conventions. This is genuine semantic guidance beyond the 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 verb+resource ('The textbook's pre-revenue methods') and enumerates the exact methods covered (Scorecard, Berkus, Risk-Factor, VC Method, terminal value) plus the early-stage scope. This is clearly distinguishable from valuation_advanced, valuation_emerging, etc.
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 'use these first for early-stage startups' guidance and routes the agent away to three named siblings with the exact conditions ('for SAFEs, tokens, ESG... use valuation_emerging; for options or scenario tables use valuation_advanced; for public-comparable multiples use valuation_comparables'). When/when-not/alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modern and alternative valuation: SAFE conversion (discount, cap, expected value), token valuation (equation of exchange, NVT), ESG adjustments (rate, premium, discount), Metcalfe network value, data-moat value, and remote-first premium/NPV. Method selects the model. Use for SAFEs, tokens, ESG, network effects, data moats, and remote-first adjustments; for classic pre-revenue methods use valuation_core. Parameters apply per method: safe_discount needs series_a_price + discount; safe_cap needs cap + series_a_price; safe_expected needs investment + cap + discount + series_a_valuation + series_a_price; token_value needs transaction_volume + price_per_tx + velocity + supply; metcalfe needs n; esg_* need base_valuation + a score; data_moat needs data_volume + data_uniqueness + monetization_rate + competitive_advantage_years. Routing: for classic pre-revenue methods (Scorecard, Berkus, Risk-Factor Summation, VC Method) use valuation_core; for options or scenario tables use valuation_advanced; for public-comparable multiples use valuation_comparables. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of events k for the Poisson probability P(X=k); integer ≥ 0. | |
| n | No | Number of users or nodes in the network. | |
| cap | No | SAFE valuation cap, currency units. | |
| rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| method | Yes | Formula to apply. Options: safe_discount = Price = Series A price × (1 - discount).; safe_cap = Price = cap / pre-money shares (cap-based).; safe_expected = Expected SAFE value across cap and discount outcomes.; token_value = Value = (volume × price) / (velocity × supply).; nvt_ratio = NVT = market cap / daily transaction volume.; esg_rate = r = base + ESG risk premium - ESG opportunity discount.; esg_premium = Valuation uplift = base × (1 + score × premium per point).; esg_discount = Valuation reduction = base × (1 - risk score × discount per point).; metcalfe = V = k · n².; data_moat = Discounted value of monetised proprietary data.; remote_npv = Perpetuity NPV = annual savings / discount rate.; remote_premium = Valuation premium from cost savings, talent access, and productivity. | |
| supply | No | Circulating token supply. | |
| discount | No | Conversion discount as a decimal (0.20 = 20% discount). | |
| velocity | No | Token velocity (turnover of supply per period). | |
| esg_score | No | ESG score in points (e.g. 0-100). | |
| investment | No | Amount invested, currency units. | |
| market_cap | No | Market capitalisation, currency units. | |
| data_volume | No | Volume of proprietary data held. | |
| price_per_tx | No | Protocol revenue per transaction, currency units. | |
| discount_rate | No | Discount rate as a decimal (0.12 = 12%). | |
| annual_savings | No | Annual cost savings, currency units. | |
| base_valuation | No | Pre-adjustment baseline valuation, currency units. | |
| esg_risk_score | No | ESG risk score in points (higher = riskier). | |
| series_a_price | No | Price per share in the next priced (Series A) round. | |
| data_uniqueness | No | Uniqueness / scarcity of the data in [0,1]. | |
| cost_savings_pct | No | Cost savings as a fraction of baseline. | |
| esg_risk_premium | No | ESG risk premium added to the rate, as a decimal. | |
| monetization_rate | No | Fraction of data value monetisable as a decimal. | |
| premium_per_point | No | Valuation premium per ESG point as a decimal. | |
| productivity_gain | No | Productivity gain as a decimal. | |
| discount_per_point | No | Valuation discount per ESG risk point as a decimal. | |
| series_a_valuation | No | Series A post-money valuation, currency units. | |
| transaction_volume | No | Total payment transaction volume, currency units. | |
| talent_access_premium | No | Talent-access premium as a decimal. | |
| esg_opportunity_discount | No | ESG opportunity discount subtracted from the rate. | |
| competitive_advantage_years | No | Years the data moat is expected to last. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, 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 explicit error 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?
Purpose and method list are front-loaded, then usage, then parameter mapping, then routing, then return/behavior. It is long for a description but nearly every sentence carries routing or parameter-mapping value; the sibling-routing information is stated twice (once inline, once under 'Routing'), which is mild redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 30-parameter, 12-method dispatcher, the description covers purpose, sibling differentiation, per-method parameter requirements, unit conventions, return fields, and error semantics. With an output schema present, it need not detail return values further, so nothing material 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 genuinely non-schema information by mapping each method to its required parameter set (e.g. safe_expected needs investment + cap + discount + series_a_valuation + series_a_price). It also states unit conventions (fractions, [0,1] probabilities) — though those largely duplicate schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb/domain ('modern and alternative valuation') and enumerates the exact method families covered (SAFE conversion, tokens, ESG, Metcalfe, data moat, remote-first). It also explicitly contrasts itself with the sibling valuation_core for classic pre-revenue methods, 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?
Gives explicit routing rules for four siblings (valuation_core, valuation_advanced, valuation_comparables) with the condition that selects each, and states 'Use for SAFEs, tokens, ESG, network effects, data moats...'. It further 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.
Value and size fintech business models: payment revenue, lending valuation, payment-processor DCF, and neobank customer-based valuation. Method selects the model. Use for payments, lending, and neobanks; for SaaS-style unit economics use valuation_saas. Parameters apply per method: payment_revenue needs transaction_volume + take_rate; lending needs loan_book + roe + pe_multiple; payment_processor adds growth_rate + discount_rate + terminal_multiple; neobank needs customers + arpu + gross_margin + churn_rate + pe_multiple. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| roe | No | Return on equity as a decimal (0.20 = 20%). | |
| arpu | No | Average revenue per user per month, currency units. | |
| years | No | Forecast horizon in years; integer ≥ 1. | |
| method | Yes | Formula to apply. Options: payment_revenue = Revenue = volume × take rate.; lending = V = loan book × ROE × P/E - NPL reserves.; payment_processor = DCF of payment revenue with a terminal multiple.; neobank = Customer LTV × P/E applied to the customer base. | |
| customers | No | Number of customers. | |
| loan_book | No | Outstanding loan book / principal, currency units. | |
| take_rate | No | Take rate as a decimal (0.15 = 15% of GMV). | |
| churn_rate | No | Periodic churn rate as a decimal (0.02 = 2% per month). | |
| growth_rate | No | Revenue growth rate as a decimal (0.40 = 40%). | |
| pe_multiple | No | Price/earnings multiple applied to earnings. | |
| gross_margin | No | Gross margin as a decimal (0.80 = 80%). | |
| npl_reserves | No | Non-performing loan reserves deducted, currency units. | |
| discount_rate | No | Discount rate as a decimal (0.12 = 12%). | |
| terminal_multiple | No | Terminal value multiple applied at the horizon. | |
| transaction_volume | No | Total payment transaction volume, currency units. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds valuable context beyond annotations: pure arithmetic with no I/O or external calls, rounding to 2 decimals, no auth or rate limits, and explicit error behavior (unknown method or missing required parameter returns an error). This fully discloses the tool's operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded with purpose and usage, then method-specific parameters, then behavior. It is appropriately sized for a 15-parameter, 4-method tool. However, it lists return fields (value, method, inputs, assumptions, chapter, formula_number, calculation steps) even though an output schema exists, which is redundant and slightly reduces 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?
Given the tool's complexity (15 parameters, 4 methods, output schema, annotations), the description covers method-dependent parameter requirements, input units, error handling, and operational behavior. With the output schema documenting return values, no critical information is missing for an agent to call 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%, but the description adds significant meaning by grouping parameters per method (e.g., lending needs loan_book + roe + pe_multiple). It also clarifies that inputs are fractions and that only method is required. A minor gap: the payment_processor wording 'adds growth_rate + discount_rate + terminal_multiple' could be clearer that it also requires the payment_revenue inputs (transaction_volume and take_rate).
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 sub-models it supports. It explicitly names the sibling valuation_saas as the tool for SaaS-style unit economics, enabling an agent to distinguish it from at least one alternative 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 says when to use it: 'Use for payments, lending, and neobanks' and provides the alternative for SaaS-style unit economics ('use valuation_saas'). No inference is needed to select between this and the named sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hardware and deep-tech valuation: TRL-risk-adjusted valuation, gross margin, and break-even volume. Method selects the metric. Use for hardware and deep tech with technology-readiness risk; for drug pipelines use valuation_biotech. Parameters apply per method: 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. Not for drug pipelines — for those use valuation_biotech. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| asp | No | Average selling price per unit, currency units. | |
| margin | No | Profit margin as a decimal. | |
| method | Yes | Formula to apply. Options: trl = V = market × share × margin × multiple × (1 - TRL discount).; gross_margin = GM = (ASP - COGS) / ASP.; break_even_volume = Units = fixed costs / (ASP - variable cost). | |
| multiple | No | Exit or market multiple applied to the metric. | |
| fixed_costs | No | Fixed costs for the period, currency units. | |
| market_size | No | Total addressable market, currency units. | |
| market_share | No | Target market share as a decimal in [0,1]. | |
| trl_discount | No | TRL risk discount as a decimal (applied as 1 - discount). | |
| variable_cost | No | Variable cost per unit, currency units. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, 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 error behavior when the method is unknown or a required parameter is missing. That is exactly the extra operational detail annotations cannot 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?
Well front-loaded: domain, method selection, then parameter requirements, then caveats and return info. Slightly redundant in restating the valuation_biotech exclusion twice and in re-explaining the return payload despite an output schema, but every other sentence is load-bearing.
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, single-required-param arithmetic tool with full schema coverage, annotations, and an output schema, the description covers method selection, parameter requirements per method, units, error behavior, and non-I/O nature. An agent has everything needed to call 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 baseline is 3, but the description goes further by mapping each method to the parameters it needs (trl → market_size/market_share/margin/multiple/trl_discount, etc.), which the schema does not express. It also clarifies units (fractions, [0,1] probability/weight ranges) beyond the per-field schema notes.
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 (hardware/deep-tech valuation) and the three concrete metrics it computes (TRL-risk-adjusted valuation, gross margin, break-even volume). It explicitly distinguishes itself from the sibling valuation_biotech, 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 explicit when-to-use ('hardware and deep tech with technology-readiness risk'), explicit when-not ('Not for drug pipelines'), and names the alternative (valuation_biotech) twice. 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.
Cross-border adjustments: purchasing-power parity, country risk premium, and international CAPM. Method selects the adjustment. Use for cross-border cash flows and country risk; pair with valuation_capm and valuation_time_value. Parameters apply per method: ppp needs spot_rate + inflation_foreign + inflation_domestic; country_risk_premium needs sovereign_yield + us_treasury_yield; intl_capm needs risk_free_rate + beta + mrp + crp. Not for the domestic cost of equity — for that use valuation_capm. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| crp | No | Country risk premium as a decimal. | |
| mrp | No | Market risk premium as a decimal. | |
| beta | No | Systematic risk beta (market = 1.0). | |
| method | Yes | Formula to apply. Options: ppp = Eₜ = E₀·(1+π_foreign)/(1+π_domestic).; country_risk_premium = CRP = sovereign yield - US Treasury yield.; intl_capm = r = Rf + β·MRP + CRP. | |
| spot_rate | No | Spot FX rate (domestic per foreign), e.g. 7.2 CNY/USD. | |
| risk_free_rate | No | Risk-free rate as a decimal (e.g. 0.04 for 4%). | |
| sovereign_yield | No | Foreign sovereign bond yield as a decimal. | |
| inflation_foreign | No | Foreign inflation rate as a decimal. | |
| us_treasury_yield | No | US Treasury yield as a decimal. | |
| inflation_domestic | No | Domestic inflation rate as a decimal. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which already declare readOnly/idempotent/non-destructive/closed-world), the description discloses determinism ('pure arithmetic — no I/O and no external calls'), rounding to 2 decimals, no auth or rate limits, and explicit failure semantics (unknown method or missing method-required parameter returns an error instead of a value). This is a rich behavioral profile an agent cannot infer from the structured fields alone.
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 every sentence carries information: method mapping, usage routing, units, error behavior, and return shape. It is somewhat long for one paragraph, though the per-method mapping and the exclusion are front-loaded enough 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?
Complete for a 10-parameter conditional calculator: an output schema exists so return values need not be detailed, yet the description still names the key return fields, and it covers units, required-vs-optional handling, defaults, and error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuinely new semantics the schema does not express: the per-method parameter groupings (ppp → spot_rate + inflation_foreign + inflation_domestic, etc.), that only method is required, that non-selected parameters should be omitted with defaults applied, and the fraction/[0,1] input conventions.
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?
Opens with a specific verb+resource pair ('Cross-border adjustments') and enumerates the three concrete methods (PPP, country risk premium, international CAPM). It explicitly distinguishes itself from valuation_capm, 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?
States when to use it ('cross-border cash flows and country risk'), names sibling companions ('pair with valuation_capm and valuation_time_value'), and gives an explicit exclusion with the correct alternative ('Not for the domestic cost of equity — for that use valuation_capm').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marketplace health and valuation: take rate, GMV revenue-multiple valuation, buyer retention, and network density. Method selects the metric. Use for two-sided transaction marketplaces; for subscription software use valuation_saas. Parameters apply per method: take_rate needs revenue + gmv; gmv_multiple needs gmv + multiple; buyer_retention needs buyers_period_1 + buyers_repeat; network_density needs active_buyers + active_sellers + total_users. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| gmv | No | Gross merchandise value (total transaction volume), currency units. | |
| method | Yes | Formula to apply. Options: take_rate = Take rate = revenue / GMV.; gmv_multiple = Valuation = GMV × multiple.; buyer_retention = Retention = repeat buyers / base-period buyers.; network_density = Density = active buyers × active sellers / total users. | |
| revenue | No | Revenue for the period, currency units. | |
| multiple | No | Exit or market multiple applied to the metric. | |
| total_users | No | Total users (buyers + sellers) in the period. | |
| active_buyers | No | Active buyers in the period. | |
| buyers_repeat | No | Distinct buyers from the base period who purchased again. | |
| active_sellers | No | Active sellers in the period. | |
| buyers_period_1 | No | Distinct buyers in the base period. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only/idempotent/no-side-effects, and the description adds rich context beyond them: it discloses the retrieval/return payload (value, method, inputs, assumptions, chapter, formula_number, calculation steps), rounding to 2 decimals, no I/O, no auth, no rate limits, and explicit error behavior for unknown method or missing required params.
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 method-to-parameter mapping, then behavioral notes. Dense but every sentence carries information; only reason for docking is that the parameter-method mapping sentence is a long run-on that could be split.
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?
Coverage is comprehensive: purpose, method selection, per-method params, input conventions (fractions, [0,1] weights), required-only-method rule, default behavior, and error semantics are all present. Output schema exists, so return-value explanation is supplementary rather than required.
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 semantic constraints not present in the schema: rate/decimal inputs are fractions, probability/weight lists are in [0,1] and sum to 1, only method is required, and the mapping of which params each method needs vs. when 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?
Description states a specific verb+resource ('Marketplace health and valuation') and enumerates the four metrics computed (take rate, GMV multiple, buyer retention, network density). It explicitly distinguishes itself from the sibling valuation_saas ('for subscription software use valuation_saas').
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?
Provides a clean routing rule: use for two-sided transaction marketplaces; use valuation_saas for subscription software. Also explains that method selects the metric and which parameters each method requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute expected value and probability-weighted outcomes for startup scenarios: discrete E[X], joint probability of sequential events, probability-weighted value, VC portfolio expected return, Poisson event probability, and continuous E[X] over a range. Method selects the formula. Use for probability-weighted central estimates; for named bull/base/bear tables or option pricing use valuation_advanced, and to discount cash flows use valuation_time_value. Parameters apply per method: expected_value_discrete and probability_weighted need outcomes + probabilities; portfolio_return needs weights + returns; poisson needs mean_events + k; expected_value_continuous needs lower + upper. outcomes and probabilities must be equal length, and the probabilities should sum to 1. Routing: use valuation_advanced method 'scenario_analysis' for named bull/base/bear scenario tables, and its black_scholes/binomial methods for option pricing; use this tool for arbitrary outcome lists and probability-weighted central estimates. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of events k for the Poisson probability P(X=k); integer ≥ 0. | |
| lower | No | Lower integration bound (standard-normal domain, e.g. -1.0). | |
| upper | No | Upper integration bound (standard-normal domain, e.g. 1.0). | |
| method | Yes | Formula to apply. Options: expected_value_discrete = E[X] = Σ xᵢ·P(X=xᵢ) over a discrete outcome list.; joint_probability = P(total) = Π pᵢ for independent sequential events.; probability_weighted = E[V] = Σ pᵢ·Vᵢ.; portfolio_return = E[R] = Σ wᵢ·Rᵢ across a VC portfolio.; poisson = P(X=k) = e^-λ λ^k / k! for rare events.; expected_value_continuous = E[X] = ∫ x·f(x) dx over [lower, upper] on the standard normal. | |
| returns | No | Return of each asset or scenario as a decimal (0.20 = 20%), aligned with weights. | |
| weights | No | Portfolio or factor weights, each in [0,1] and summing to 1 (same order as the paired value list). | |
| outcomes | No | Possible outcome values x_i, in any currency unit (must match probabilities in length/order). | |
| mean_events | No | Poisson mean λ = expected number of events in the interval. | |
| probabilities | No | Probability of each outcome or stage, each in [0,1]; the list must sum to 1 where it is exhaustive. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and non-open-world behavior. The description adds meaningful context beyond that: pure arithmetic with no I/O or external calls, no auth or rate limits, rounding to 2 decimals, and error 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?
The description is long but front-loaded with purpose, methods, alternatives, parameter rules, return behavior, and error behavior. It is dense and mostly earns its place, though the later 'Routing:' sentence partially repeats the earlier valuation_advanced guidance, making it 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?
Given nine parameters, one required enum, full schema coverage, annotations, and an output schema, the description is complete enough to call the tool correctly. It covers method-dependent inputs, constraints, return fields, determinism, rounding, and error cases without needing to explain output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by mapping each method to its required parameters, stating that outcomes and probabilities must be equal length, that probability/weight lists are in [0,1] and sum to 1, and that rate inputs are fractions. These constraints are partly in the schema but the method-to-parameter pairing is useful extra guidance.
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 ('Compute expected value and probability-weighted outcomes for startup scenarios') and enumerates the six supported methods. It clearly distinguishes itself from valuation_advanced and valuation_time_value by naming when those siblings apply instead.
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 says to use this tool for probability-weighted central estimates, routes named bull/base/bear tables and option pricing to valuation_advanced, and routes cash-flow discounting to valuation_time_value. The routing guidance is explicit and leaves little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SaaS unit economics and valuation: LTV, CAC, MRR, ARR, net revenue retention, magic number, Rule of 40, CAC payback, and ARR revenue-multiple valuation. Method selects the metric. Use for subscription software; for marketplace GMV metrics use valuation_marketplace and for payments/lending use valuation_fintech. Parameters apply per method: ltv needs arpu + gross_margin + churn_rate; cac needs sales_marketing_expense + new_customers; arr needs subscription_values; nrr needs starting_revenue + ending_revenue; revenue_multiple needs arr + revenue_multiple. Not for company-level pre-revenue value — for that use valuation_core. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| arr | No | Annual recurring revenue, currency units. | |
| cac | No | Customer acquisition cost per customer, currency units. | |
| arpu | No | Average revenue per user per month, currency units. | |
| method | Yes | Formula to apply. Options: ltv = LTV = ARPU × gross margin / churn.; cac = CAC = S&M expense / new customers.; mrr = MRR = ARR / 12 (reverse of ARR).; arr = ARR = Σ monthly subscriptions × 12.; nrr = NRR = (start + expansion) / start, net of churn.; magic_number = Magic Number = net new ARR / prior-quarter S&M.; rule_of_40 = Score = growth rate + profit margin.; cac_payback = Months to recover CAC from gross profit.; revenue_multiple = Valuation = ARR × multiple. | |
| arr_value | No | Annual recurring revenue, currency units. | |
| churn_rate | No | Periodic churn rate as a decimal (0.02 = 2% per month). | |
| growth_rate | No | Revenue growth rate as a decimal (0.40 = 40%). | |
| net_new_arr | No | Net new ARR added in the period, currency units. | |
| gross_margin | No | Gross margin as a decimal (0.80 = 80%). | |
| new_customers | No | Number of customers acquired in the period. | |
| profit_margin | No | Profit margin as a decimal (0.15 = 15%). | |
| ending_revenue | No | Revenue from the same cohort at period end, currency units. | |
| mrr_per_customer | No | Monthly recurring revenue per customer, currency units. | |
| revenue_multiple | No | SaaS revenue multiple (e.g. 8 for 8x ARR). | |
| sm_expense_prior | No | Sales & marketing expense in the prior period, currency units. | |
| starting_revenue | No | Revenue from the cohort at period start, currency units. | |
| expansion_revenue | No | Expansion revenue from the cohort in the period. | |
| subscription_values | No | Monthly subscription revenue per customer (summed x12 for ARR). | |
| sales_marketing_expense | No | Sales & marketing spend for the period, currency units. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but 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 unknown methods or missing required parameters. Slight deduction because it does not describe the chapter/formula_number fields it says are returned, though an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The scope statement and routing guidance are front-loaded, and the dense sentences carry real information with little redundancy. It is long, but nearly every clause (method-parameter mapping, input conventions, error behavior) earns its place, so it stays efficient despite the density.
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 19-parameter, method-dependent calculator, the description supplies everything an agent needs: metric coverage, method selection semantics, per-method parameter requirements, input units, error behavior, and sibling routing. An output schema exists, so return-value explanation is not required.
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 goes well beyond the schema by mapping each method to its required parameter set (e.g. ltv needs arpu + gross_margin + churn_rate; nrr needs starting_revenue + ending_revenue), which is not encoded in the schema. It also clarifies input conventions (fractions 0.10 = 10%, weight lists in [0,1] 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?
The description 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). It explicitly differentiates itself from siblings by routing marketplace GMV to valuation_marketplace, payments/lending to valuation_fintech, and pre-revenue company value 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?
Explicit when-to-use (subscription software) and when-not-to-use with named alternatives for each boundary case (marketplace, fintech, pre-revenue). It also states that only method is required and that other parameters are method-dependent and should be supplied only 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.
Allocate value across stakeholders and equity classes: single-round dilution, OPM common stock, PWERM, liquidation value, M&A synergy, employee-option values, vesting adjustment, cash-vs-equity break-even, and asset-based loan capacity. Method selects the model. Use only after the company-level value is known (from valuation_core, valuation_saas, or valuation_comparables) to split that value across the cap table; for the company value itself do not use this tool. Parameters apply per method: dilution needs ownership_before + investment + post_money; opm needs enterprise_value + liquidation_pref + time_to_exit + volatility; pwerm and employee_option need scenarios; liquidation needs assets + recovery_rates; risk_adjusted_synergy needs revenue_synergies + cost_synergies; vesting_adjusted needs total_value + vested_fraction; max_asset_loan takes collateral values. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| cash | No | Cash and equivalents, currency units. | |
| years | No | Forecast horizon in years; integer ≥ 1. | |
| assets | No | Map of asset name to book value, e.g. {"cash": 500000}. | |
| method | Yes | Formula to apply. Options: dilution = Ownership = before × (1 - investment / post-money).; opm = Option-pricing allocation of equity value to common shares.; pwerm = Probability-weighted expected return method across exit scenarios.; liquidation = V = Σ(asset × recovery rate).; risk_adjusted_synergy = Probability-weighted, discounted M&A revenue + cost synergies.; intrinsic_option = Intrinsic value = max(0, FMV - strike) × shares.; employee_option = Probability-weighted employee option value across scenarios.; vesting_adjusted = Option value adjusted for vesting schedule and retention probability.; cash_equity_breakeven = Break-even comparing salary reduction against discounted equity.; max_asset_loan = Borrowing capacity from asset collateral values. | |
| shares | No | Number of option shares. | |
| tax_rate | No | Effective tax rate as a decimal in [0,1]. | |
| equipment | No | Equipment, currency units. | |
| inventory | No | Inventory, currency units. | |
| prob_cost | No | Probability of realising cost synergies, 0-1. | |
| scenarios | No | Scenario objects: {name: str, probability: 0-1, value: currency}; probabilities should sum to 1. | |
| investment | No | Amount invested, currency units. | |
| post_money | No | Post-money valuation, currency units. | |
| volatility | No | Annualised volatility σ as a decimal (0.80 = 80%). | |
| real_estate | No | Real estate, currency units. | |
| total_value | No | Total grant value, currency units. | |
| equity_value | No | Value of equity offered, currency units. | |
| prob_revenue | No | Probability of realising revenue synergies, 0-1. | |
| strike_price | No | Option strike price, currency units. | |
| time_to_exit | No | Expected time to exit / liquidity in years. | |
| discount_rate | No | Discount rate as a decimal (0.12 = 12%). | |
| cost_synergies | No | Cost synergy value, currency units. | |
| recovery_rates | No | Map of asset name to recovery rate in [0,1], matching assets. | |
| retention_prob | No | Probability the holder stays, 0-1. | |
| vested_fraction | No | Fraction vested in [0,1]. | |
| years_remaining | No | Years of vesting remaining. | |
| annual_vest_rate | No | Annual vesting rate as a decimal. | |
| enterprise_value | No | Enterprise value (market cap + net debt), currency units. | |
| liquidation_pref | No | Liquidation preference amount, currency units. | |
| ownership_before | No | Founder ownership before the round as a decimal (0.60 = 60%). | |
| salary_reduction | No | Annual salary foregone for equity, currency units. | |
| fair_market_value | No | Current fair market value per share, currency units. | |
| revenue_synergies | No | Revenue synergy value, currency units. | |
| accounts_receivable | No | Accounts receivable, currency units. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Going beyond the annotations, it discloses that the tool is pure arithmetic with no I/O or external calls, rounds to 2 decimals, requires no auth and has no rate limits, and returns an error (not a value) on an unknown method or missing required parameter. It also specifies fraction conventions for rates and [0,1]-with-sum-to-1 for probability/weight lists.
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 — a logical flow with no filler sentences. It is dense and somewhat long, but each sentence carries distinct information, so the length is justified by the ten-method surface.
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 33 parameters, one required field, an output schema, and full annotations, the description supplies everything the schema cannot: method routing, precondition against siblings, unit conventions, error behavior, and precision. Nothing an agent needs to invoke a specific method 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 real cross-parameter meaning that no single field description conveys: which parameters each method requires, that only `method` is required, and that unneeded parameters should be omitted with defaults applying. It does not restate the numeric meaning of individual fields, which the schema already handles.
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?
Opens with a specific verb and resource ('Allocate value across stakeholders and equity classes') and enumerates the ten supported allocation methods, so the agent knows exactly which class of task this covers. It also explicitly separates itself from the company-value siblings by stating it splits an already-known value across the cap table.
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 (from valuation_core, valuation_saas, or valuation_comparables)') and an explicit exclusion ('for the company value itself do not use this tool'). It also routes per-method parameter requirements, so the agent knows which fields to supply for each branch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discount, compound, and forecast value over time: single future value PV, net present value of a cash-flow stream, annuity present value, discounted cash flow with a Gordon terminal value, constant-rate compound growth of revenue or cash flow, and the implied compound annual growth rate (CAGR). Method selects the formula. Use to convert future cash to today's value, to value a full forecast with a terminal value (dcf), to project a revenue or cash-flow series forward, or to derive the growth rate implied by two values; get the discount rate from valuation_capm or valuation_international. Parameters apply per method: present_value needs future_value + rate + periods; npv needs cash_flows + rate; annuity needs payment + rate + periods; dcf needs cash_flows + rate (optional: terminal_growth); compound_growth needs starting_value + growth_rate + periods; cagr needs starting_value + ending_value + periods. growth_rate must be greater than -1, cagr requires starting_value > 0 and periods > 0, and dcf requires rate greater than terminal_growth. Not for option values (use valuation_advanced) or for expected values over outcomes (use valuation_probability). Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| method | Yes | Formula to apply. Options: present_value = PV = C / (1+r)^t.; npv = NPV = Σ Cₜ / (1+r)^t.; annuity = PV = P·[1-(1+r)^-n]/r.; compound_growth = V_n = V_0 (1+g)^n.; cagr = CAGR = (V_n / V_0)^(1/n) - 1.; dcf = DCF = Σ Cₜ/(1+r)^t + [C_n(1+g)/(r−g)]/(1+r)^n. | |
| payment | No | Recurring payment per period, in currency units. | |
| periods | No | Number of compounding periods, must be ≥ 1 (may be fractional). | |
| cash_flows | No | Cash flows by period, first element at t=1; negatives allowed for outflows. | |
| growth_rate | No | Revenue growth rate as a decimal (0.40 = 40%). | |
| ending_value | No | Value at t=n to compare against the starting value, in currency units. | |
| future_value | No | Future cash amount to discount, in currency units. | |
| starting_value | No | Value at t=0 (revenue or cash flow) to grow forward, in currency units. | |
| terminal_growth | No | Perpetual growth rate g applied after the forecast window, as a decimal. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate steps for traceability. |
| value | Yes | Computed valuation or metric. |
| inputs | No | Echo of the normalised inputs used. |
| method | No | Formula / method name that produced the result. |
| chapter | No | Source textbook chapter. |
| assumptions | No | Modelling assumptions applied. |
| formula_number | No | Source textbook formula number (e.g. '3.1'). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
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 context beyond them: pure arithmetic with no I/O or external calls, no auth or rate limits, rounding to 2 decimals, returned fields, and explicit error behavior (unknown method or missing method-required parameter returns an error rather than a value). That is exactly the kind of behavioral disclosure annotations cannot 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?
Dense but front-loaded: the capability list and routing come first, then per-method parameter requirements, then constraints, then return/behavioral notes. Nearly every sentence carries new information, though the description is long and the method-to-parameter mapping partially duplicates the method enum's formula descriptions in the 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 a 10-parameter tool with a single required enum selector, the description supplies the method-to-parameter mapping, validity constraints, unit conventions, error semantics, and alternative routing. Output schema exists, so return-value explanation is optional and its brief inclusion is harmless; nothing an agent needs to call 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 goes further by mapping each method to its required parameters (present_value needs future_value+rate+periods, npv needs cash_flows+rate, etc.) and by stating conditional constraints absent from the schema (growth_rate > -1, cagr requires starting_value > 0 and periods > 0, dcf requires rate > terminal_growth). It also explains the fraction convention and that unspecified params should be omitted with defaults applied.
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 a specific verb set (discount, compound, forecast) and resource (value over time), then enumerates the six formulas behind the method enum, making it distinguishable from siblings like valuation_capm or valuation_probability. An agent can tell exactly which calculation family this tool covers 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 when-to-use scenarios are given (convert future cash to today's value, value a forecast with terminal value, project a series, derive implied growth) plus routing to alternatives: get the discount rate from valuation_capm or valuation_international, and explicit exclusions ('Not for option values (use valuation_advanced)', 'not for expected values over outcomes (use valuation_probability)').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
valuation_advancedvaluation_biotechvaluation_capmvaluation_comparablesvaluation_corevaluation_emergingvaluation_fintechvaluation_hardwarevaluation_internationalvaluation_marketplacevaluation_probabilityvaluation_saasvaluation_stakeholdervaluation_time_value13-model stock valuation engine for AI agents - fair values for 5,900+ US stocks, updated daily.
SEC filings and financial data for AI agents: 59 tools for statements, valuation and supply chains.
19 market-data tools for AI agents: company KYC, SEC filings, patents, auctions, tenders
Deterministic company valuation and corporate finance tools for AI agents — IRR, NPV, MOIC, DCF, WACC, enterprise value, EV multiples, CAPM, beta and sensitivity analysis via Model Context Protocol. Useful for financial analysis, equity analysis, quantitative analysis, financial projections, financial formulas and financial modeling.
Add one secure layer between your agents and this server.
