Comprehensive startup valuation library implementing 80+ formulas from the Startup Valuation textbook. Python library + MCP server + AI-Agent Skills.
A production-grade Python library for startup valuation, implementing every formula from the Startup Valuation textbook by Simon Mak (Valuation in Practice Series, Ascent Partners). Designed for developers, financial analysts, and AI agents who need auditable, structured valuation computations.
Three-layer architecture:
graph TB
subgraph Library["Python Library"]
MOD["14 Modules<br/>80+ Functions"] --> VR["ValuationResult"]
end
subgraph MCP["MCP Server"]
VR --> SVR["FastMCP Server<br/>14 Tools"]
end
subgraph Skills["AI-Agent Skills"]
SVR --> CORE["Core"]
SVR --> ADV["Advanced"]
SVR --> IND["Industry"]
SVR --> STAKE["Stakeholder"]
SVR --> EMER["Emerging"]
end
style Library fill:#0083AB,color:#fff
style MCP fill:#4CAF50,color:#fff
style Skills fill:#9C27B0,color:#fffPython Library — 14 modules, 80+ typed functions, all returning ValuationResult (value + assumptions + sensitivity)
MCP Server — 14 folded tools (80+ formulas) for AI agents via stdio and hosted Streamable HTTP
AI-Agent Skills — 6 skill definitions with workflow guidance for valuation domains
Related MCP server: QuantOracle
pip install startup-valuation # library only
pip install startup-valuation[mcp] # + MCP server
pip install startup-valuation[dev] # + pytest, ruff, mypyfrom startup_valuation.core import scorecard_valuation, vc_method_post_money
from startup_valuation.advanced import black_scholes, scenario_analysis
from startup_valuation.types import Scenario
# Scorecard Method (pre-revenue startups)
result = scorecard_valuation(
average_valuation=1_500_000,
weights=[0.30, 0.25, 0.15, 0.10, 0.10, 0.05, 0.05],
scores=[1.25, 1.50, 1.20, 0.75, 1.00, 0.90, 1.00],
)
print(f"Scorecard: ${result.value:,.0f}") # $1,800,000
# Black-Scholes for real options (startup equity)
result = black_scholes(
underlying=20_000_000, strike=5_000_000,
risk_free_rate=0.05, volatility=0.40, time_to_maturity=1.0,
)
print(f"Option value: ${result.value:,.0f}") # $15,240,000
# Scenario Analysis
scenarios = [
Scenario("bull", 0.20, 10_000_000),
Scenario("base", 0.60, 5_000_000),
Scenario("bear", 0.20, 1_000_000),
]
result = scenario_analysis(scenarios)
print(f"Expected value: ${result.value:,.0f}") # $5,200,000The server exposes 14 tools, each folding a family of formulas behind a method
argument — probability, time value, CAPM, core pre-revenue methods, options,
comparables, SaaS, marketplaces, fintech, biotech, hardware, international,
stakeholder equity, emerging methods, and a triangulated full analysis.
Local (stdio):
pip install "startup-valuation[mcp]"
python mcp_server/server.pyHosted (Streamable HTTP) — no install, no API key:
https://startup-valuation.simonmak.com/apiOpenCode — add to opencode.json:
"startup-valuation": {
"type": "remote",
"url": "https://startup-valuation.simonmak.com/api",
"timeout": 60000
}Claude Desktop / Cursor — add the HTTP URL https://startup-valuation.simonmak.com/api
as an MCP server, or run the stdio entrypoint above.
MCP Registry — published as io.github.simonplmak-cloud/startup-valuation
(manifest: server.json) and listed on
Glama and the
Official MCP Registry. The
glama.json file holds the Glama maintainer entry.
Copy the skills/ directory to your agent's skills folder:
valuation-core — Scorecard, Berkus, VC Method, Risk Factor Summation
valuation-foundations — Probability, time value, CAPM, comparables
valuation-advanced — Black-Scholes, Binomial, Monte Carlo, Scenario Analysis
valuation-industry — SaaS, Biotech, Fintech, Marketplace, Hardware
valuation-stakeholder — Dilution, OPM, PWERM, Liquidation Preference
valuation-emerging — SAFE, Crypto (MV=PQ), ESG, Metcalfe's Law
Category | Methods | Chapter |
Probability | Expected value, joint probability, Poisson | 2 |
Time Value | PV, NPV, annuity | 2 |
CAPM | CAPM, portfolio beta, startup-adjusted | 2 |
Core | Scorecard, Berkus, Risk Factor, VC Method | 3 |
Advanced | Black-Scholes, Binomial, Monte Carlo, Scenario | 4 |
Comparables | P/E, P/S, EV/EBITDA, regression-adjusted | 5 |
SaaS | LTV, CAC, NRR, Magic Number, Rule of 40 | 11 |
Biotech | rNPV, decision tree, peak sales, pipeline | 11 |
Fintech | Payment revenue, lending, neobank, network effects | 11 |
Marketplace | GMV, take rate, liquidity, network density | 11 |
Hardware | TRL-adjusted, break-even, P-weighted DCF | 11 |
International | PPP, CRP, currency-adjusted DCF, Damodaran | 12 |
Stakeholders | Dilution, OPM, PWERM, liquidation, synergies | 13 |
Emerging | SAFE, MV=PQ, ESG, Metcalfe's, data moat | 14 |
Auditable — Every function returns ValuationResult with value, method, inputs, assumptions, and sensitivity analysis
Textbook-accurate — All formulas verified against book example values with unit tests
AI-ready — MCP server and Skills for seamless AI agent integration
Industry-specific — Dedicated modules for SaaS, biotech, fintech, marketplace, and hardware startups
Open source — MIT license, extensible, well-documented
# Install dev dependencies
pip install -e ".[dev]"
# Run tests
pytest
# Run with coverage
pytest --cov=startup_valuation --cov-report=term-missing
# Lint
ruff check .
# Type check
mypy src/startup_valuation --ignore-missing-importsAPI Reference: GitHub Pages
Wiki (Theory & Derivations): GitHub Wiki
Chapter Index: Maps every function to its textbook chapter
Examples: Interactive code snippets for each valuation category
Startup Valuation: A Comprehensive Guide to Valuing Fast-Growing Pre-Revenue Companies
Theory, Methods, Regulation, and Practice — Valuation in Practice Series by Ascent Partners
By Simon Mak · 338 pages · 15 chapters · 300+ exercises · 20+ real-world cases
@software{startup_valuation_engine,
author = {Mak, Simon},
title = {Startup Valuation Engine},
year = {2026},
url = {https://github.com/simonplmak-cloud/startup-valuation},
license = {MIT},
}Based on formulas from the Startup Valuation textbook. See output/ for the full textbook source in markdown.
MIT — see LICENSE for details.
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 cover the safety profile (readOnly, idempotent, closed-world). The description adds real behavioral context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, and explicit error behavior for unknown methods or missing required params. It loses a point only because return-field enumeration is redundant against the existing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with technique names and routing guidance, and dense with actionable detail. Slightly over-long because the return-object field list and the no-auth/no-rate-limit clause restate things already implied by annotations and the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter, method-dispatch tool with a rich schema, output schema, and annotations, the description covers routing, method-parameter contracts, error semantics, and numeric formatting. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds genuine value by mapping which parameters each method requires (black_scholes/binomial need underlying+strike+risk_free_rate+volatility+time_to_maturity, binomial adds steps, scenario_analysis needs scenarios) — a method-to-parameter contract the schema does not express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific techniques (Black-Scholes call value, binomial-tree option value, scenario analysis) and the method-selection mechanism. Explicitly distinguishes itself from valuation_probability and valuation_time_value by name, so the agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use and when-not-to-use: 'For a quick expected value over arbitrary outcome lists, prefer valuation_probability', 'Not for plain discounted cash flow — for that use valuation_time_value'. Names alternatives and the conditions selecting them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuine context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no authentication or rate limits, and concrete failure semantics (unknown method or missing required param returns an error instead of a value).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and method mapping, then behavior, then error semantics — a logical order. It loses a point for repeating the hardware/deep-tech exclusion twice ('for hardware or deep tech use valuation_hardware' and again later), and the return-field enumeration is somewhat redundant given an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with one required parameter, the description covers method selection, per-method parameter requirements, defaults behavior, arithmetic purity, rounding, and error conditions. Since an output schema exists, listing return fields is optional and not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so per-parameter meaning is already documented and the baseline is 3. The description adds real value on top by mapping each method to the parameters it needs (peak_sales → patient_population + penetration + price, decision_tree → probabilities + terminal_value, pipeline → drugs + discount_rate) and clarifying that only method is required while others are method-dependent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Risk-adjusted biotech valuation' covering three named methods (peak sales, decision-tree EV, pipeline rNPV). It explicitly distinguishes the tool from the sibling valuation_hardware by domain (pharma/drug pipelines vs. hardware/deep tech), so an agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use it ('pharma/drug pipelines') and names the alternative for the excluded case ('for hardware or deep tech use valuation_hardware'), plus model-selection guidance ('Method selects the model'). It also states which parameters to supply per method and to omit the rest, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 already declare readOnly, idempotent, non-destructive, closed-world, but the description adds substantial context the annotations cannot: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth/rate limits, and importantly that unknown methods or missing required params return an error rather than a value. That failure-mode disclosure is valuable beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then routing, then a compact method-to-parameter map, then return/behavior notes. It is dense and mostly earns its length, though the requirement that only method is required is stated twice and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter tool with an output schema, the description covers the method-dependent input contract, failure behavior, precision, and routing to related tools. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description contributes cross-parameter semantics the schema does not: which parameters pair with each method, and the constraint that weights and betas must be equal length. This relational guidance genuinely reduces misuse risk.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Estimate the cost of capital') and enumerates the four distinct methods (standard CAPM, startup-adjusted CAPM, portfolio beta, WACC), which cleanly separates it from the other valuation_* siblings. An agent can tell exactly what computation it performs without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing: use it to derive the discount rate that feeds valuation_time_value and DCF models, and add valuation_international for cross-border rates. It also specifies when-supply-what per method and instructs to omit parameters not named for the selected method.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 establish read-only, idempotent, non-destructive, and closed-world behavior, but the description adds meaningful operational context: pure arithmetic with no I/O or external calls, no auth/rate limits, 2-decimal rounding, and error behavior for unknown methods or missing required parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite being fairly long, the description is dense and front-loaded: purpose first, then usage, then parameter rules, then return/behavior details. Every sentence adds actionable information for a 15-parameter, method-branching calculation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex valuation tool with many optional parameters, an output schema, and rich annotations, the description covers the remaining gaps: method selection, alternative tooling, parameter requirements, error cases, determinism, and rounding. Nothing an agent needs to select and call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each field, but the description adds critical method-to-parameter mapping (pe_ratio needs market_cap + net_income, etc.) and states that only method is required while other parameters are method-dependent and should be omitted when unused.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource and the set of computed multiples (P/E, P/S, EV/EBITDA, EV/Revenue, regression multiple), making the tool's output unambiguous. It also distinguishes itself from a sibling by directing pre-revenue/private-startup cases to valuation_core.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('Use when public comparables exist') and a clear alternative for the excluded case ('for pre-revenue or private startups use valuation_core'). The method-dependent parameter guidance further tells the agent how to invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
Beyond the read-only annotations, it discloses that the tool is pure arithmetic with no I/O, external calls, authentication, credentials, or rate limits. It also states that results are rounded to 2 decimals and that invalid method or missing required method parameters return an error rather than a value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded and dense with routing, method-parameter mapping, return details, and safety constraints. It earns most of its length given 17 parameters and 7 methods, though it could be structured with clearer separators for faster scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 17 parameters, seven methods, full schema coverage, and an output schema, the description is complete: it covers routing, required versus optional inputs, return shape, arithmetic behavior, error handling, and security/rate-limit context. An agent has everything needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is already 100%, the description adds meaningful method-to-parameter mapping that the schema does not: it names the exact parameters needed for scorecard, berkus, risk_factor, vc_post_money, vc_pre_money, terminal_value, and triangulated. It also explains that only method is strictly required and that other parameters should be omitted when not needed for the selected method.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific pre-revenue valuation methods covered and explicitly routes to sibling tools for other methods. An agent can distinguish this tool from valuation_emerging, valuation_advanced, and valuation_comparables without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use this tool first (early-stage startups) and gives explicit routing rules to alternatives for SAFEs, tokens, ESG, network effects, options, scenario tables, and public-comparable multiples. It also clarifies that only method is required and the rest are method-dependent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 cover read-only, idempotent, closed-world, non-destructive traits. The description adds beyond that: pure arithmetic with no I/O or external calls, rounding to 2 decimals, no authentication/credentials/rate limits, and explicit error behavior for unknown methods or missing required parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but appropriately sized for a 30-parameter multi-method tool, with purpose front-loaded. Some redundancy: the routing to valuation_core is stated twice, and return values are listed despite an output schema existing, adding minor bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity, 100% schema coverage, and an output schema, the description is complete: it covers routing, method-parameter mapping, error conditions, and operational behavior. An agent has everything needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds substantial value by mapping parameters to each method (e.g., safe_discount needs series_a_price + discount; metcalfe needs n; data_moat needs data_volume + data_uniqueness + monetization_rate + competitive_advantage_years). However, the mapping is incomplete for some methods (nvt_ratio, remote_npv, remote_premium, and precise esg_rate/esg_premium/esg_discount parameter sets are not spelled out).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (valuation methods) and enumerates the alternative approaches covered (SAFE, token, ESG, Metcalfe, data moat, remote-first). Explicitly names sibling tools (valuation_core, valuation_advanced, valuation_comparables) to distinguish scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use routing: 'Use for SAFEs, tokens, ESG...; for classic pre-revenue methods use valuation_core' and further routes to valuation_advanced and valuation_comparables. Leaves no ambiguity about which sibling to pick for a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 readOnly/idempotent/non-destructive/openWorld=false, and the description layers on context those annotations cannot carry: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth/credentials/rate limits, and explicit failure behavior for unknown methods or missing method-required parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and routing before the dense method/parameter mapping, and every clause is functional. Slight redundancy in enumerating return fields (value, method, inputs, assumptions, chapter, formula_number, steps) when an output schema already documents them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter, four-mode calculator with all-null-optional schema, the description supplies mode gating, required-vs-optional semantics, error behavior, and precision policy. With an output schema present, the extra return-shape sentence is redundant but harmless; nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real value the schema cannot express: which parameters each method consumes, that only 'method' is required, that unlisted parameters should be omitted, and that documented defaults apply. Minor gap: 'years' and 'npl_reserves' are not mapped to any method even though lending/payment_processor formulas imply them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Value and size fintech business models') and enumerates the four concrete model families it covers (payment revenue, lending, payment-processor DCF, neobank). It explicitly names the sibling it is not (valuation_saas), so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit routing rule ('Method selects the model. Use for payments, lending, and neobanks; for SaaS-style unit economics use valuation_saas'), naming the alternative and the condition that selects it. The method-parameter dependency table further tells the caller exactly what to supply per mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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/non-destructive/no-open-world, so the safety profile is covered. The description adds real behavioral context beyond that: pure arithmetic, no I/O or external calls, results rounded to 2 decimals, and explicit error behavior for an unknown method or a missing method-required parameter. It also restates the return fields, which is redundant given the output schema, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, method mapping, and constraints in a compact block. It loses a point for redundancy: the 'not for drug pipelines, use valuation_biotech' exclusion appears twice and the return-field enumeration duplicates the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters, a 100%-covered schema, an output schema, and full annotations, the description covers everything an agent needs: method-dependent parameter selection, error semantics, determinism, rounding, and no-auth/no-rate-limit conditions. The output schema removes any need to explain return values in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is individually documented, so the baseline is 3. The description goes beyond the schema by mapping which method requires which parameters (e.g., trl needs market_size + market_share + margin + multiple + trl_discount) and clarifying that non-selected parameters should be omitted with defaults applying. That conditional relationship is not expressed by the flat schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (hardware/deep-tech valuation) and names the three concrete methods it computes (TRL-risk-adjusted valuation, gross margin, break-even volume), immediately distinguishing it from valuation_biotech. An agent can select it over the other valuation_* siblings without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it (hardware/deep tech with technology-readiness risk) and names the alternative with its own condition (drug pipelines -> valuation_biotech). Nothing is left to inference, though the exclusion is stated twice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 readOnly/idempotent/non-destructive/closed-world, and the description adds substantive behavior beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth or rate limits, and precise error semantics for unknown methods or missing required parameters. That error contract is the key operational detail an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then usage, then the method-to-parameter mapping, then return/behavioral notes. Dense but almost every sentence carries a distinct constraint. Minor penalty for run-on sentences with heavy parentheticals that make it slightly harder to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still briefly names the return fields (value, method, inputs, assumptions, chapter, formula_number, steps), which is harmless and mildly helpful. Combined with the error contract and parameter mapping, an agent has everything required to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the enum already embeds the formulas, so the baseline is 3. The description earns extra credit by mapping each method to its required parameter set (ppp→spot_rate+inflation_foreign+inflation_domestic, etc.) and clarifying that only 'method' is required while the rest are method-dependent — a cross-parameter constraint the schema cannot express. It falls short of 5 only because per-parameter semantics are largely left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific domain (cross-border adjustments) and enumerates the three concrete methods (PPP, country risk premium, international CAPM), and explicitly distinguishes itself from the sibling valuation_capm. An agent can route between this and the domestic cost-of-equity tool without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('Use for cross-border cash flows and country risk'), when-not ('Not for the domestic cost of equity — for that use valuation_capm'), and companion tools ('pair with valuation_capm and valuation_time_value'). This is exactly the routing guidance needed in a 14-sibling family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 still adds substantive behavior: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth/credentials/rate limits, and explicit error semantics for unknown methods or missing required parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then routing, then per-method parameter contracts, then return/behavior notes — a logical order with no filler. It is dense and somewhat long, and the return-field enumeration overlaps the output schema, but each sentence carries operational weight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, 4-method calculator with an output schema, the description covers selection, conditional inputs, error behavior, precision, and safety context. An agent has everything needed to choose a method and supply the correct arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds genuinely new information the schema cannot express: the conditional dependency mapping each method to its required inputs (take_rate -> revenue+gmv, gmv_multiple -> gmv+multiple, etc.) and the rule that unneeded parameters should be omitted. It stops short of units or edge-case semantics, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (marketplace health and valuation metrics) and enumerates the four metrics computed. It explicitly names the sibling it is not (valuation_saas) and the domain it serves (two-sided transaction marketplaces), so an agent can separate it from the other 13 valuation_* tools without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('two-sided transaction marketplaces') and when-not ('for subscription software use valuation_saas'), plus the per-method parameter contract and the instruction to omit parameters not named for the selected method. Nothing about invocation is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 establish readOnly/idempotent/non-destructive/no-open-world, so the safety profile is covered structurally. The description adds real behavioral context beyond that: pure arithmetic with no I/O, results rounded to 2 decimals, and explicit error behavior for unknown methods or missing per-method parameters. It also restates auth/rate-limit absence, which is mild duplication of annotation intent rather than a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and method list, then constraints, then routing. Slightly long and the valuation_advanced routing is stated twice (once in the method list, once in the 'Routing:' sentence), costing some economy, but nearly every sentence carries operative information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, 1-required, method-dispatched tool with a full output schema and annotations, the description supplies everything an agent needs: which method, which params per method, list constraints, error conditions, and rounding. Return-value detail is already in the output schema, so its absence would not be a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so per-parameter documentation is already handled and the baseline is 3. The description adds genuine value by mapping parameters to methods (outcomes+probabilities for discrete/probability_weighted, weights+returns for portfolio, mean_events+k for poisson, lower+upper for continuous) and by stating the equal-length and sum-to-1 constraints, which the schema only partially implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compute) and resource (expected value / probability-weighted outcomes) and enumerates the six concrete formulas the tool implements. It explicitly names sibling tools (valuation_advanced, valuation_time_value) and the conditions that separate them, so an agent can route without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('probability-weighted central estimates') and when-not ('named bull/base/bear tables' → valuation_advanced scenario_analysis; option pricing → black_scholes/binomial; discounting → valuation_time_value). Alternatives and their selection conditions are named outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 declare readOnly, idempotent, non-destructive, closed-world; the description goes well beyond by stating this is pure arithmetic with no I/O or external calls, no auth/credentials/rate limits, results rounded to 2 decimals, and that invalid method or missing method-required params return an error rather than a value. That is the operational detail an agent needs before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the metric list followed by routing, per-method parameter requirements, and output/behavioral notes. Very dense with no filler, though the single paragraph runs long and the per-method parameter inventory is the kind of detail some agents would prefer tabulated; still, every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and the description still names the return shape (value, method, inputs, assumptions, chapter, formula_number, calculation steps). Combined with the method-selection rule, parameter dependency map, and error behavior, an agent has everything needed for a 19-parameter, method-dispatch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the enum documents each formula, but the description adds the crucial cross-parameter mapping that the schema cannot express: which parameters each method consumes (ltv→arpu+gross_margin+churn_rate, cac→sales_marketing_expense+new_customers, etc.) and that unlisted params should be omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific domain (SaaS unit economics and valuation) and enumerates the exact metrics computed (LTV, CAC, MRR, ARR, NRR, magic number, Rule of 40, CAC payback, revenue multiple). The sibling differentiation is explicit: marketplace GMV → valuation_marketplace, payments/lending → valuation_fintech, pre-revenue company-level → valuation_core.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'Use for subscription software; for marketplace GMV metrics use valuation_marketplace and for payments/lending use valuation_fintech' plus 'Not for company-level pre-revenue value — for that use valuation_core.' It also states the error condition when an unknown method is passed or a required method parameter is omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 read-only, idempotent, closed-world, non-destructive, but the description goes further: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, no auth/rate limits, and error behavior for unknown methods or missing method-required parameters. These are traits the annotations do not carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and precondition, and the per-method parameter list is compressed into terse phrases. It is long, but the length is largely earned by ten distinct methods and 33 parameters; a small amount of repetition around required-vs-optional could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-model calculator with an output schema present, the description covers the precondition, the method-to-parameter contract, the error surface, and numeric formatting. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds genuinely new semantics by mapping each method to the specific parameters it requires (e.g. dilution needs ownership_before + investment + post_money), information the flat 33-parameter schema cannot express. It also explains that only 'method' is required and other params are method-dependent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Allocate value across stakeholders and equity classes') and enumerates the ten allocation models it implements. It also names the sibling tools it must follow (valuation_core, valuation_saas, valuation_comparables), so an agent can place it precisely in the toolchain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition ('Use only after the company-level value is known') and an explicit exclusion ('for the company value itself do not use this tool'), with the alternatives named. This is a textbook when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 declare readOnly/idempotent/non-destructive, but the description goes further: it discloses that it is pure arithmetic with no I/O or external calls, that results are rounded to 2 decimals, that no auth/credentials/rate limits apply, and that unknown methods or missing method-required params return an error rather than a value. This is behavioral context well beyond the annotation set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The paragraph is long but dense and front-loaded: purpose first, then method semantics, then per-method parameters, then constraints, exclusions, and return/error behavior. Nearly every sentence carries distinct information, though it could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter multi-method calculator, the description covers purpose, per-method param requirements, constraints, exclusions, error behavior, and result rounding; with an output schema present it need not detail the return shape, and it still sketches it. Nothing an agent needs to invoke correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real value the schema lacks: a method-to-parameter mapping (which params each method needs) and validation constraints (growth_rate > -1, cagr needs starting_value > 0 and periods > 0, dcf needs rate > terminal_growth). It also explains that only method is required and the rest should be omitted per method.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names specific verbs (discount, compound, forecast) and the resource (value over time), then enumerates the six concrete formulas it computes. An agent can distinguish it from valuation_capm, valuation_advanced, and valuation_probability purely from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the four main use cases (convert future cash to present, value a forecast with terminal value, project a series forward, derive implied growth) and routes elsewhere for out-of-scope work ('Not for option values (use valuation_advanced)', 'expected values over outcomes (use valuation_probability)'), plus names valuation_capm as the source of the discount rate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.5valuation_capm7 fields changedInput schema / properties / cost_of_debtAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Pre-tax cost of debt Rd as a decimal."
+}Input schema / properties / cost_of_equityAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "After-tax cost of equity Re as a decimal."
+}Input schema / properties / debt_valueAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Market value of debt, in currency units."
+}Input schema / properties / equity_valueAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Value of equity offered, currency units."
+}Input schema / properties / method / descriptionPrevious value: -"Formula to apply. Options: capm = E(R) = Rf + β·(E(Rm) - Rf).; startup_capm = r = Rf + β·MRP + size premium + illiquidity premium.; portfolio_beta = βp = Σ wᵢ·βᵢ."New value: +"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)."Input schema / properties / method / enumPrevious value: -[
- "capm",
- "startup_capm",
- "portfolio_beta"
-]New value: +[
+ "capm",
+ "startup_capm",
+ "portfolio_beta",
+ "wacc"
+]Input schema / properties / tax_rateAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Effective tax rate as a decimal."
+}valuation_time_value3 fields changedInput schema / properties / method / descriptionPrevious value: -"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."New value: +"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."Input schema / properties / method / enumPrevious value: -[
- "present_value",
- "npv",
- "annuity",
- "compound_growth",
- "cagr"
-]New value: +[
+ "present_value",
+ "npv",
+ "annuity",
+ "compound_growth",
+ "cagr",
+ "dcf"
+]Input schema / properties / terminal_growthAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Perpetual growth rate g applied after the forecast window, as a decimal."
+}v0.1.4valuation_time_value5 fields changedInput schema / properties / ending_valueAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Value at t=n to compare against the starting value, in currency units."
+}Input schema / properties / growth_rateAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Revenue growth rate as a decimal (0.40 = 40%)."
+}Input schema / properties / method / descriptionPrevious value: -"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."New value: +"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."Input schema / properties / method / enumPrevious value: -[
- "present_value",
- "npv",
- "annuity"
-]New value: +[
+ "present_value",
+ "npv",
+ "annuity",
+ "compound_growth",
+ "cagr"
+]Input schema / properties / starting_valueAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Value at t=0 (revenue or cash flow) to grow forward, in currency units."
+}v0.1.0valuation_advancedvaluation_biotechvaluation_capmvaluation_comparablesvaluation_corevaluation_emergingvaluation_fintechvaluation_hardwarevaluation_internationalvaluation_marketplacevaluation_probabilityvaluation_saasvaluation_stakeholdervaluation_time_valueScored across 14 tools
Each tool targets a clearly distinct valuation subdomain (time value, CAPM, probability, core pre-revenue, advanced options/scenarios, comparables, vertical-specific models, international, stakeholder allocation, emerging methods). Descriptions explicitly route overlapping areas, such as probability vs. scenario analysis and core vs. emerging methods, reducing misselection risk.
All 14 tools use a consistent snake_case naming pattern with the same valuation_ prefix. No mixed conventions or inconsistent verb styles are present.
Fourteen tools is well within the ideal range and each tool clearly earns its place by covering a distinct family of valuation formulas or metrics. The set is neither too thin nor too heavy for a comprehensive startup-valuation calculator suite.
The surface covers a broad valuation lifecycle: time value, discount rates, probability, pre-revenue methods, advanced options/scenarios, comparables, vertical-specific models, international adjustments, stakeholder allocation, and emerging methods. No obvious gaps remain for the stated domain of startup valuation arithmetic.
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.
44 calculators for AI agents: US tax, finance, business + an MCP engineering & security suite.
13-model stock valuation engine for AI agents - fair values for 5,900+ US stocks, updated daily.
Deterministic time-value-of-money and fund-performance tools for AI agents — future value, present value, CAGR, annuities, perpetuities, loan payments, payback, discounted payback, DPI, RVPI and TVPI via Model Context Protocol. Useful for corporate finance, financial projections, financial analysis, quantitative analysis, financial formulas and financial modeling.
