startup-valuation

Probability & Expected Value

valuation_probability

Read-onlyIdempotent

Compute expected value, joint/Poisson probabilities, and probability-weighted startup scenario returns by selecting a method and supplying outcomes, probabilities, weights, or returns.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

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').

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 30, 2026

TDQS

A4.6/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server