valuation-api

calculate_irr

Read-onlyIdempotent

Calculate the Internal Rate of Return (IRR), MOIC and an IRR sensitivity table for a single lump-sum equity investment that returns one exit value after a whole-year hold period. WHEN TO USE: you have an upfront investment amount, a single exit value and a hold period in whole years (standard PE/VC single-exit scenario) and need the annualised return, the money multiple, or a return stress-test. The result also includes a plain-language interpretation benchmarked against VC/PE/public-market return hurdles. WHEN NOT TO USE: for cash-flow streams with multiple intermediate distributions (use calculate_npv or calculate_moic on the full cash-flow array), or when you only need the sensitivity grid (use irr_sensitivity). BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access, no randomness; idempotent and non-destructive; identical inputs always produce identical outputs. IRR is solved over the cash-flow schedule [-investment, 0, ..., exit_value] via Newton-Raphson with bisection fallback. RETURNS: JSON object with concept, definition, formula, calculation (irr as a percentage string, moic as a multiple, cash_flows array), interpretation, and sensitivity (byMultiple, byHoldPeriod). PARAMETERS: initial_investment (number > 0, currency units), exit_value (number > 0, same currency units), hold_period (integer >= 1 whole years), currency (optional string: GBP default, USD, EUR, JPY, CHF — display only, no conversion).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`currency`	No	Optional display currency code. Defaults to GBP. Used only for formatting output labels — no FX conversion is performed.	GBP
`exit_value`	Yes	Value returned at exit, same currency units as initial_investment, e.g. 250000. Must be positive.
`hold_period`	Yes	Holding period in whole years, e.g. 5. Must be a positive integer (1, 2, 3, ...).
`initial_investment`	Yes	Amount invested up front, in currency units, e.g. 100000. Must be positive.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark read-only and idempotent, and the description strengthens this by detailing determinism, no side effects/network/storage/randomness, and the Newton-Raphson-with-bisection solution method. No contradiction with annotations.

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

Conciseness5/5

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

The description is organized into labeled sections (WHEN, WHEN NOT, BEHAVIOUR, RETURNS, PARAMETERS) and every sentence contributes a distinct fact. It is detailed but efficiently front-loaded with the core scope, then alternatives, then behavior.

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 tool with no output schema, the RETURNS section lists the full JSON shape including sensitivity keys, and the parameter constraints are fully covered. Usage conditions, behavior, and return contract are all present, making safe invocation fully specified.

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

Parameters3/5

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

Schema coverage is 100% with field descriptions already explaining constraints and currency semantics, so the baseline is 3. The description's PARAMETERS section mostly mirrors the schema plus the display-only currency note; it adds little beyond the structured schema.

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?

Opens with a specific verb and resource: 'Calculate the Internal Rate of Return (IRR), MOIC and an IRR sensitivity table' for a precisely scoped single-exit scenario. The scope sentence and WHEN NOT TO USE references to calculate_npv/calculate_moic/irr_sensitivity distinguish it from siblings.

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?

Explicit WHEN TO USE block gives concrete preconditions (upfront amount, single exit value, whole-year hold) and expected outputs. WHEN NOT TO USE names alternatives and their trigger conditions, so an agent can route correctly.

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

All valuation-api tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Each tool maps to a distinct financial formula or calculation, and the when-to-use/when-not-to-use guidance cleanly separates closely related cash-flow metrics like NPV, IRR, and MOIC as well as CAPM, WACC, and DCF. There is no pair of tools that appears to perform the same operation.

Naming Consistency4/5

The overwhelming majority of tools follow a consistent calculate_<metric> snake_case pattern with descriptive names. irr_sensitivity breaks the pattern by omitting the calculate_ prefix, and mixing expanded names like cost_of_equity with abbreviations like wacc and moic is a minor deviation.

Tool Count5/5

Twelve tools is well within the ideal range for a focused financial-calculations server. Each tool covers a distinct valuation, discount-rate, or return-metric need without redundancy, so the count feels appropriately scoped.

Completeness4/5

The tool set covers the core valuation workflow: cost of equity, beta unlevering/relevering, WACC, DCF, enterprise-value multiples, and investment return metrics. It lacks a reverse equity-value calculation and an equity-side multiple like P/E, but those are workable gaps rather than severe dead ends.

Resources

Need Help?