startup-valuation

Emerging & Alternative Methods

valuation_emerging

Read-onlyIdempotent

Compute emerging startup valuations: SAFE conversion, token and NVT models, ESG adjustments, Metcalfe network value, data moats, and remote-first NPV or premium.

Instructions

Modern and alternative valuation: SAFE conversion (discount, cap, expected value), token valuation (equation of exchange, NVT), ESG adjustments (rate, premium, discount), Metcalfe network value, data-moat value, and remote-first premium/NPV. Method selects the model. Use for SAFEs, tokens, ESG, network effects, data moats, and remote-first adjustments; for classic pre-revenue methods use valuation_core. Parameters apply per method: safe_discount needs series_a_price + discount; safe_cap needs cap + series_a_price; safe_expected needs investment + cap + discount + series_a_valuation + series_a_price; token_value needs transaction_volume + price_per_tx + velocity + supply; metcalfe needs n; esg_* need base_valuation + a score; data_moat needs data_volume + data_uniqueness + monetization_rate + competitive_advantage_years. Routing: for classic pre-revenue methods (Scorecard, Berkus, Risk-Factor Summation, VC Method) use valuation_core; for options or scenario tables use valuation_advanced; for public-comparable multiples use valuation_comparables. Only method is required; all other parameters are method-dependent, so supply those the selected method names and omit the rest (defaults apply where defined). Rate and decimal inputs are fractions (0.10 = 10%); probability and weight lists are in [0,1] and sum to 1. Returns value, method, inputs, assumptions, chapter, formula_number and calculation steps; pure arithmetic — no I/O and no external calls — rounded to 2 decimals, with no auth or rate limits. An unknown method, or a missing method-required parameter, returns an error instead of a value.

Input Schema

TableJSON Schema

Name	Required	Description
`k`	No	Number of events k for the Poisson probability P(X=k); integer ≥ 0.
`n`	No	Number of users or nodes in the network.
`cap`	No	SAFE valuation cap, currency units.
`rate`	No	Per-period discount rate as a decimal (0.10 = 10%).
`method`	Yes	Formula to apply. Options: safe_discount = Price = Series A price × (1 - discount).; safe_cap = Price = cap / pre-money shares (cap-based).; safe_expected = Expected SAFE value across cap and discount outcomes.; token_value = Value = (volume × price) / (velocity × supply).; nvt_ratio = NVT = market cap / daily transaction volume.; esg_rate = r = base + ESG risk premium - ESG opportunity discount.; esg_premium = Valuation uplift = base × (1 + score × premium per point).; esg_discount = Valuation reduction = base × (1 - risk score × discount per point).; metcalfe = V = k · n².; data_moat = Discounted value of monetised proprietary data.; remote_npv = Perpetuity NPV = annual savings / discount rate.; remote_premium = Valuation premium from cost savings, talent access, and productivity.
`supply`	No	Circulating token supply.
`discount`	No	Conversion discount as a decimal (0.20 = 20% discount).
`velocity`	No	Token velocity (turnover of supply per period).
`esg_score`	No	ESG score in points (e.g. 0-100).
`investment`	No	Amount invested, currency units.
`market_cap`	No	Market capitalisation, currency units.
`data_volume`	No	Volume of proprietary data held.
`price_per_tx`	No	Protocol revenue per transaction, currency units.
`discount_rate`	No	Discount rate as a decimal (0.12 = 12%).
`annual_savings`	No	Annual cost savings, currency units.
`base_valuation`	No	Pre-adjustment baseline valuation, currency units.
`esg_risk_score`	No	ESG risk score in points (higher = riskier).
`series_a_price`	No	Price per share in the next priced (Series A) round.
`data_uniqueness`	No	Uniqueness / scarcity of the data in [0,1].
`cost_savings_pct`	No	Cost savings as a fraction of baseline.
`esg_risk_premium`	No	ESG risk premium added to the rate, as a decimal.
`monetization_rate`	No	Fraction of data value monetisable as a decimal.
`premium_per_point`	No	Valuation premium per ESG point as a decimal.
`productivity_gain`	No	Productivity gain as a decimal.
`discount_per_point`	No	Valuation discount per ESG risk point as a decimal.
`series_a_valuation`	No	Series A post-money valuation, currency units.
`transaction_volume`	No	Total payment transaction volume, currency units.
`talent_access_premium`	No	Talent-access premium as a decimal.
`esg_opportunity_discount`	No	ESG opportunity discount subtracted from the rate.
`competitive_advantage_years`	No	Years the data moat is expected to last.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Error message when the call fails.
`steps`	No	Intermediate steps for traceability.
`value`	Yes	Computed valuation or metric.
`inputs`	No	Echo of the normalised inputs used.
`method`	No	Formula / method name that produced the result.
`chapter`	No	Source textbook chapter.
`assumptions`	No	Modelling assumptions applied.
`formula_number`	No	Source textbook formula number (e.g. '3.1').
`defaults_applied`	No	Optional parameters that were not supplied, so their documented defaults were used.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.1.1Oct 2, 2026

changedInput schema / properties / k / description

Previous value: -"Number of events k for the Poisson probability P(X=k)."New value: +"Number of events k for the Poisson probability P(X=k); integer ≥ 0."

addedOutput schema / properties / defaults_applied

Added value: +{
+  "description": "Optional parameters that were not supplied, so their documented defaults were used.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

First observedv0.1.0Sep 30, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description still adds genuinely new behavior: 'pure arithmetic — no I/O and no external calls', 'no auth or rate limits', results 'rounded to 2 decimals', and the error contract ('An unknown method, or a missing method-required parameter, returns an error instead of a value'). The enumerated return fields (value, method, inputs, assumptions, chapter, formula_number, steps) largely restate the output schema and are the only soft spot, keeping this below a 5.

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

Conciseness4/5

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

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

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

Completeness5/5

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

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

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

Parameters5/5

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

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

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

Purpose5/5

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

The description opens with a named, specific set of methods (SAFE conversion, token valuation, ESG adjustments, Metcalfe, data moat, remote-first) and states 'Method selects the model', so the verb (value/compute) and resource (emerging & alternative methods) are unambiguous. It explicitly carves out the sibling boundary by naming valuation_core, valuation_advanced, and valuation_comparables, letting an agent distinguish this tool from all 13 siblings without opening the schema.

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

Usage Guidelines5/5

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

It gives explicit when-to-use ('Use for SAFEs, tokens, ESG, network effects, data moats, and remote-first adjustments') and when-not ('for classic pre-revenue methods use valuation_core'), plus a full routing paragraph mapping alternatives: valuation_core for Scorecard/Berkus/Risk-Factor/VC, valuation_advanced for options/scenarios, valuation_comparables for multiples. Nothing about tool selection is left to inference.

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

Deploy Server