Startup valuation for AI agents: 14 tools, 80+ pre-revenue formulas.
Scored across 14 tools
Each tool is scoped to a distinct valuation family (core pre-revenue, time value/DCF, CAPM, comparables, SaaS, fintech, marketplace, biotech, hardware, emerging, probability, advanced options, international, stakeholder), and descriptions contain explicit routing rules pointing to the correct sibling tool. The riskiest overlaps (probability vs advanced scenario/options, core vs emerging, revenue multiples across comparables/SaaS/marketplace) are each resolved by naming the alternative tool and its trigger conditions.
Every tool follows the identical valuation_<domain> snake_case pattern, with a shared method-dispatch convention and uniform return shape (value, method, inputs, assumptions, chapter, formula_number, steps). No mixed casing or verb-style drift.
14 tools sit squarely in the well-scoped 3-15 range, and each tool earns its place by covering a coherent domain rather than a single formula. The method-dispatcher design keeps the count low while exposing a large formula surface.
The surface spans the full valuation lifecycle: discounting/time value, cost of capital (CAPM/WACC), comparables, pre-revenue and emerging methods, sector models (SaaS, fintech, marketplace, biotech, hardware), probability/options, cross-border adjustments, and cap-table/stakeholder allocation. No obvious dead ends or missing lifecycle operations for a valuation domain.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | Binomial tree time steps (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. |
| 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: pure arithmetic, no I/O or external calls, results rounded to 2 decimals, no auth/credentials/rate limits, and explicit error behavior for an unknown method or a missing method-required parameter. This is exactly the kind of operational detail annotations cannot convey.
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, leading with the method options before routing and parameter guidance. The sentence enumerating return fields (value, method, inputs, assumptions, chapter, formula_number, steps) is somewhat redundant given an output schema exists, which is the one small piece of unearned length.
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 three-method tool, the definition covers method selection, per-method parameter requirements, defaults, error behavior, and the operational profile, and it need not explain return shape because an output schema exists. An agent has everything required to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter, but the description adds genuine method-dependent semantics the schema does not: which parameters each method requires (underlying + strike + risk_free_rate + volatility + time_to_maturity, plus steps for binomial; scenarios for scenario_analysis), that only 'method' is required, and that non-applicable parameters should be omitted so defaults apply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names three concrete techniques (Black-Scholes call value, binomial-tree option value, scenario analysis) and ties them to the 'method' selector, so the agent knows exactly what the tool computes. It also explicitly distinguishes itself from siblings valuation_probability and valuation_time_value, which is the strongest form of purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing rules: use valuation_probability with 'probability_weighted' for quick expected values over arbitrary outcome lists, use scenario_analysis only for named bull/base/bear tables, and use valuation_time_value for plain DCF. Both a when-to-use and a when-not-to-use alternative are stated, leaving nothing to inference.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, non-destructive), but the description adds material behavior beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, documented defaults applying, and explicit failure semantics for an unknown method or a missing required parameter. That is exactly the kind of context 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?
The critical content is front-loaded and useful, but the router sentence is duplicated almost verbatim ('for hardware or deep tech use valuation_hardware' appears twice), and the pure-arithmetic note partly repeats what the readOnly/idempotent annotations already convey. Trimming would make it tighter 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?
For a 9-parameter, method-dispatching calculator with an output schema, the description covers purpose, routing, per-method parameters, defaults, error behavior, and return shape. An agent has everything needed to select a method and construct a valid call.
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, and the description earns above baseline by mapping methods to their required parameter sets (peak_sales -> patient_population/penetration/price, decision_tree -> probabilities/terminal_value, pipeline -> drugs/discount_rate), which the enum descriptions do not do. It only slips by omitting compliance from the peak_sales list, though the schema documents it as defaulting to 1.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Risk-adjusted biotech valuation') and enumerates the three supported models (peak sales, decision tree, pipeline rNPV). It explicitly names the sibling it is not (valuation_hardware), so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('Use for pharma/drug pipelines') and a when-not with the named alternative ('for hardware or deep tech use valuation_hardware'). It also tells the agent which parameters to supply per method and to omit the rest, which is actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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. | |
| 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. | |
| 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only establish the safe-read profile (readOnly/idempotent/non-destructive/closed-world). The description adds real behavioral context on top: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and error behavior for unknown methods or missing required parameters. This is substantive disclosure beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the sibling routing are front-loaded, and the method-to-parameter mapping is useful, so nearly every sentence earns its place. However, it is delivered as one very dense paragraph covering purpose, routing, per-method params, return shape, arithmetic guarantees, and error behavior, which makes it heavier than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter computational tool, the definition covers method selection, per-method required inputs, defaults, arithmetic/rounding guarantees, error conditions, and even return fields (redundant given the output schema, but harmless). Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so per-parameter meaning is already documented. The description still adds value by mapping the 14 parameters to each method (capm needs risk_free_rate+beta+market_return; portfolio_beta needs weights+betas of equal length; wacc needs five fields) and clarifying that only method is required and the rest are method-dependent. It goes beyond the schema, though the raw parameter semantics largely restate the schema's own docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Estimate the cost of capital') and enumerates the four exact methods it covers (standard CAPM, startup-adjusted CAPM, portfolio beta, WACC). It further distinguishes itself from siblings by naming valuation_time_value and valuation_international, so an agent can place 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?
It states when to use it ('to derive the discount rate that feeds valuation_time_value and DCF models') and when to add a sibling ('for cross-border rates add valuation_international'), plus the rule that 'method selects the formula.' Routing and selection conditions are explicit rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/no-open-world, and the description adds substantive context beyond them: pure arithmetic with no I/O, no external calls, results rounded to 2 decimals, no auth/credentials/rate limits, defaults applied where defined, and predictable error behavior on invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph, but front-loaded with purpose and organized into semicolon-delimited clauses (methods, routing, per-method params, returns, behavior). Every clause carries information; the 'no authentication, credentials, or rate limits' sentence is the closest to filler but still useful for an agent deciding whether it can call this freely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-method, 15-parameter tool this covers routing, method-parameter coupling, error semantics, numeric formatting, and side-effect profile. The return-value enumeration (value, method, inputs, assumptions, chapter, formula_number, steps) is partly redundant given an output schema exists, but nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the enum description already carries the formulas, so baseline is 3. The description goes further by mapping each method to the exact parameter set it consumes (pe_ratio→market_cap+net_income, regression_multiple→intercept+growth_rate+growth_coefficient plus optional maturity/stage/geography), a cross-parameter dependency that the per-property schema cannot express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (market multiples from comparables) and enumerates the exact ratios produced (P/E, P/S, EV/EBITDA, EV/Revenue, regression-adjusted), plus the method-driven selection mechanism. It also names the sibling it is not (valuation_core) for the pre-revenue/private case, so an agent can distinguish it from the thirteen other valuation_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: 'Use when public comparables exist; for pre-revenue or private startups use valuation_core.' It further says only `method` is required and the remaining parameters are method-dependent, with an explicit error condition for unknown methods or missing required params. When-to-use, when-not-to-use, and the alternative are all stated.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, yet the description still adds genuinely new behavior: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth/credentials/rate limits, and explicit error semantics for unknown methods or missing method-required parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose, then routing, then parameter mapping, then return shape and behavioral notes in a logical order. The parameter-per-method sentence is a dense run-on that packs many clauses, but each clause carries needed information and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter, method-dispatching arithmetic tool, the description covers method selection, parameter requirements per method, sibling routing, return shape (which the output schema also covers), and error behavior. An agent has everything needed to select a method and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real value the schema cannot: the method-to-parameter dependency map (e.g. scorecard needs average_valuation + weights + scores, vc_pre_money needs post_money + investment). It also clarifies that only method is required, other params are method-dependent, and documented defaults apply when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (the textbook's pre-revenue methods) and enumerates the seven concrete methods covered (Scorecard, Berkus, Risk-Factor, VC Method post/pre-money, terminal value, triangulated). It explicitly distinguishes itself from siblings by naming valuation_emerging, valuation_advanced, and valuation_comparables with their respective domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('Use these first for early-stage startups') plus full routing rules: SAFEs/tokens/ESG/network-effects/data-moat go to valuation_emerging, options/scenario tables to valuation_advanced, public comparables to valuation_comparables. Nothing is left to inference about alternatives.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of events k for the Poisson probability P(X=k). | |
| 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: pure arithmetic, no I/O, no external calls, results rounded to 2 decimals, no auth/credentials/rate limits, and explicit failure behavior (unknown method or missing required parameter returns an error instead of a value). This is unusually complete behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and method list, then routing, then parameter mapping, then behavior. Dense and well organized, but the parameter-per-method enumeration is lengthy and partially duplicates the enum text already in the schema. Every sentence is informative, though a bit more could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 30-parameter, method-dispatch tool this covers everything an agent needs: purpose, routing, per-method parameter requirements, required/optional semantics, default handling, error behavior, and the return shape (value, method, inputs, assumptions, chapter, formula_number, steps). An output schema exists, so the return description is bonus rather than load-bearing.
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 per-parameter text is already in the schema and the baseline would be 3. The description adds genuine value beyond the schema by grouping parameters per method (e.g. safe_expected needs investment + cap + discount + series_a_valuation + series_a_price), which the flat schema does not express, and by stating that only 'method' is required while others are method-dependent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific domain of action ('Modern and alternative valuation') and enumerates the exact model families it computes (SAFE conversion, token valuation, ESG adjustments, Metcalfe, data moat, remote-first). It explicitly distinguishes itself from siblings by naming when valuation_core, valuation_advanced, and valuation_comparables 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?
Provides explicit routing rules: 'for classic pre-revenue methods use valuation_core; for options or scenario tables use valuation_advanced; for public-comparable multiples use valuation_comparables,' plus a use-case list ('Use for SAFEs, tokens, ESG, network effects, data moats, and remote-first adjustments'). When-to-use and when-to-look-elsewhere are both covered.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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. | |
| 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, closed-world read, but the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, defaults applied where defined, and explicit failure behavior for unknown methods or missing method-required parameters. This covers the exact traits an agent needs to predict the call's outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and sibling routing, and nearly every sentence carries signal. It is dense and list-heavy, with a slightly redundant 'Method selects the model' fragment, but no real padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter, method-dispatch tool this is complete: model selection, per-method inputs, error semantics, determinism, rounding, and return shape are all covered. The output schema exists, so the description need not explain return values further, yet it still names the returned fields helpfully.
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 cross-parameter conditional logic the schema cannot express: it maps each method to the exact parameters it requires and clarifies that only method is mandatory while the rest are method-dependent and should be omitted otherwise. That materially exceeds the schema's per-parameter 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 and resource ('Value and size fintech business models') and enumerates the four supported models (payment revenue, lending, payment-processor DCF, neobank). It also explicitly distinguishes itself from the sibling valuation_saas, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('Use for payments, lending, and neobanks') and a named alternative with the selecting condition ('for SaaS-style unit economics use valuation_saas'). The method-selection guidance ('Method selects the model') further directs invocation.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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. | |
| 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, and the description goes further: pure arithmetic, no I/O or external calls, rounding to 2 decimals, no auth/rate limits, and explicit error behavior for unknown methods or missing method-required parameters. This is exactly the kind of beyond-annotation context the bar rewards.
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 well organized, but the sibling exclusion is stated twice ('for drug pipelines use valuation_biotech' appears verbatim again as 'Not for drug pipelines — for those use valuation_biotech'), which is padding and hurts the otherwise efficient structure. The parameter-to-method mapping is dense but earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, yet the description still gives the response shape (value, method, inputs, assumptions, chapter, formula_number, steps) and rounding behavior. For a 9-param, method-dispatch arithmetic tool this covers 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% and the method enum already embeds the formulae, so baseline is 3. The description adds genuinely new semantics the schema cannot express: the conditional group mapping (trl needs market_size+market_share+margin+multiple+trl_discount; gross_margin needs asp+variable_cost; break_even_volume needs fixed_costs+asp+variable_cost) and that only method is required with defaults applying elsewhere.
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 and verb (hardware/deep-tech valuation) plus the three concrete methods (TRL-risk-adjusted, gross margin, break-even volume), and explicitly names the sibling it is not for (drug pipelines). An agent can distinguish it from valuation_biotech and valuation_core 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?
Explicitly says when to use it (hardware/deep tech with technology-readiness risk) and names the alternative tool for the excluded case (drug pipelines -> valuation_biotech). Nothing is left to inference; the routing decision is fully specified.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe-read profile (readOnly, idempotent, non-destructive, closed-world), so the description goes beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and explicit error behavior for an unknown method or a missing method-required parameter. That failure-mode disclosure is exactly what an agent needs before calling.
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 per-method parameter map, then behavior and error semantics — no sentence is filler. It is a dense single paragraph, and the return-key list is partly redundant with the output schema, which keeps it just short of optimal.
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, enum-driven, method-switching tool, the description covers selection, parameter dependencies, error conditions, and output shape. With annotations plus an output schema already carrying safety and return structure, nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds the conditional dependency structure the schema cannot express: which parameters each method requires (ppp → spot_rate + inflation_foreign + inflation_domestic; country_risk_premium → sovereign_yield + us_treasury_yield; intl_capm → risk_free_rate + beta + mrp + crp), plus the rule that only method is required and the rest should be omitted. This maps parameters to methods, not just to meanings.
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 the specific resource (cross-border adjustments) and the three concrete techniques it implements (PPP, country risk premium, international CAPM), then states its scope: cross-border cash flows and country risk. It also explicitly carves itself out from valuation_capm, so an agent can separate it from siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives positive selection criteria ('use for cross-border cash flows and country risk'), an explicit exclusion with an alternative ('Not for the domestic cost of equity — for that use valuation_capm'), and companion tools to pair with (valuation_capm, valuation_time_value). This is a complete routing spec.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new operational facts: purely arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and explicit error behavior for an unknown method or a missing required parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and front-loaded, with the domain and method mapping stated first. It is somewhat long, and the return-shape sentence partially repeats the output schema, but every sentence carries actionable routing or contract information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, method-dispatched calculation tool, it covers routing, per-method inputs, required-vs-optional behavior, return contents, numeric precision, and error handling. Combined with the existing output schema and annotations, 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. The description goes beyond it by spelling out the conditional parameter-to-method mapping (take_rate needs revenue + gmv, gmv_multiple needs gmv + multiple, etc.) and clarifying that only method is required while the rest are method-dependent — conditional logic the flat schema cannot express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific domain (marketplace health and valuation) and enumerates the concrete metrics it computes: take rate, GMV revenue-multiple valuation, buyer retention, and network density. It explicitly distinguishes itself from the sibling valuation_saas by naming the wrong domain (subscription software). An agent can route between the two 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 (two-sided transaction marketplaces) and when-not (subscription software → use valuation_saas). It further routes at the method level, stating which parameters each method requires and instructing the caller to supply only those and omit the rest.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of events k for the Poisson probability P(X=k). | |
| 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds real behavioral context beyond them: pure arithmetic with no I/O or external calls, no auth/credentials/rate limits, numeric results rounded to 2 decimals, and explicit error behavior for unknown methods or missing required parameters. That is exactly the extra operational detail annotations cannot express.
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 text is dense and front-loaded, starting with purpose, then method-to-parameter mapping, then routing, then return/behavioral notes. It is somewhat long and the routing information about valuation_advanced is stated twice (once in the usage sentence and again in the "Routing:" sentence), which is mild redundancy rather than a structural flaw.
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 method-dependent parameters, one required field, a rich enum, and an output schema, the description covers every gap an agent needs: method-to-parameter pairing, requirement to omit unused params, defaults note, error conditions, and a brief return summary (value, method, inputs, assumptions, chapter, formula_number, steps) even though the output schema exists. Nothing necessary for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline would be 3, but the description goes further by mapping parameter sets to methods (expected_value_discrete/probability_weighted need outcomes+probabilities, portfolio_return needs weights+returns, poisson needs mean_events+k, expected_value_continuous needs lower+upper) and by stating cross-parameter constraints (equal length, probabilities sum to 1). This adds dependency semantics the per-field schema text does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ("Compute expected value and probability-weighted outcomes for startup scenarios") and enumerates the six supported formulas, so the agent knows exactly what the tool computes. It explicitly names the sibling tools it is not (valuation_advanced, valuation_time_value) and the boundary that separates them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ("probability-weighted central estimates; arbitrary outcome lists") and names alternatives with the conditions that select them: valuation_advanced for named bull/base/bear tables and black_scholes/binomial option pricing, valuation_time_value for discounting cash flows. There is even a dedicated "Routing" sentence, so nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, but the description adds substantial behavior beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no authentication or rate limits, and explicit error semantics 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?
It is dense but front-loaded with purpose and routing before diving into per-method parameter detail, and every clause carries information. Slightly long and run-on in the middle section, costing it the top score.
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 19 parameters, an output schema, and full annotation coverage, the description supplies everything an agent needs: domain routing, method-to-parameter mapping, arithmetic-only behavior, rounding, and error conditions. 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 the baseline is 3, but the description adds the cross-parameter dependency map (which parameters each method requires) that the per-field schema cannot express. It also clarifies the method-dependent supply/omit contract, going beyond raw field definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific domain (SaaS unit economics and valuation) and enumerates the concrete metrics computed (LTV, CAC, MRR, ARR, NRR, magic number, Rule of 40, CAC payback, revenue multiple). It explicitly differentiates itself from siblings valuation_marketplace, valuation_fintech, and valuation_core by naming the domains they serve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: 'Use for subscription software; for marketplace GMV metrics use valuation_marketplace and for payments/lending use valuation_fintech.' It also states the negative case ('Not for company-level pre-revenue value — for that use valuation_core') and explains per-method parameter selection with the fallback that only method is required.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| cash | No | Cash and equivalents, currency units. | |
| years | No | Forecast horizon in years. | |
| 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. | |
| 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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds real context beyond that: pure arithmetic with no I/O or external calls, rounding to 2 decimals, no auth or rate limits, and the failure mode (unknown method or missing required parameter returns an error rather than a value). Solid, though the safety profile itself is annotation-derived.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then routing guidance, then parameter rules, then return/behavioral notes. Dense and useful, but the long run-on parameter sentence is heavy to parse; it earns its place but could be structured as a list.
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 an output schema exists, the return shape need not be explained, yet the description still notes it returns value/method/inputs/assumptions/chapter/formula_number/steps. Combined with per-method parameter requirements, error behavior, and defaults, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3, but the description goes further by mapping each method to its required inputs (dilution needs ownership_before+investment+post_money, opm needs enterprise_value+liquidation_pref+time_to_exit+volatility, etc.) and noting only `method` is required with others method-dependent. That mapping is not in the schema and materially helps with 33 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Allocate value across stakeholders and equity classes') and enumerates the concrete methods (dilution, OPM, PWERM, liquidation, etc.), making it unambiguous against siblings like valuation_core that compute company-level value. The scope is clearly post-company-value cap table splitting.
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 ('Use only after the company-level value is known') and when-not-to-use ('for the company value itself do not use this tool'), and it names the exact siblings that should be used first (valuation_core, valuation_saas, valuation_comparables). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Returns an object with value, method, inputs, assumptions, chapter, formula_number and calculation steps. Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. No authentication, credentials, or rate limits apply. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, 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 (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'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world behavior, but the description adds substantial context beyond them: pure arithmetic with no I/O, results rounded to 2 decimals, method-dependent parameter requirements, and explicit error behavior for unknown methods or missing required parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but given six methods and ten parameters nearly every clause carries distinct information, and it is front-loaded with purpose, then usage, then parameter rules. Slight density cost relative to the tightest possible phrasing keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-method calculator with an output schema, the description supplies everything needed to pick a method, supply its parameters, and anticipate errors, while correctly relying on the output schema for return-shape details rather than re-explaining them at length.
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 and adding validation constraints absent from the schema (growth_rate > -1, cagr requires starting_value > 0 and periods > 0, dcf requires rate > terminal_growth). It also clarifies that only method is required and the rest are method-dependent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource and enumerates all six supported computations (PV, NPV, annuity, DCF with Gordon terminal value, compound growth, CAGR), so an agent knows exactly which formulas are available. It also distinguishes itself from siblings by pointing option values to valuation_advanced and expected values to valuation_probability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states each when-to-use case explicitly ('convert future cash to today's value', 'value a full forecast with a terminal value', 'project a revenue series forward', 'derive the growth rate implied by two values') and names the upstream tools for the discount rate (valuation_capm, valuation_international). It also gives two explicit when-not-to-use exclusions with named alternatives.
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.
