Deterministic finance tools for AI agents — IRR, NPV, MOIC, DCF, WACC and sensitivity.
Calculate the cost of equity using the Capital Asset Pricing Model (CAPM): the risk-free rate plus beta times the market risk premium. Formula: Re = Rf + beta x (Rm - Rf). WHEN TO USE: Use to estimate the required return on equity — an input to WACC (calculate_wacc) and DCF discount rates, or as a standalone return hurdle. WHEN NOT TO USE: Do NOT use for companies where beta is a poor risk measure (private companies without a traded beta — consider building up from comparable betas via calculate_unlever_beta / calculate_relever_beta first). BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive; identical inputs always produce identical outputs. Division by zero, non-finite inputs, or mathematically undefined combinations return an explicit error instead of a number. RETURNS: JSON object { cost_of_equity: decimal (e.g. 0.115 = 11.5%), cost_of_equity_pct: number (e.g. 11.5), inputs }. PARAMETERS: risk_free_rate (required): Risk-free rate as a decimal, e.g. 0.04 = 4% (typically the 10-year government bond yield; never pass percentage points). beta (required): Equity beta (levered, if the company has debt), e.g. 1.2. Use unlevered/relevered betas when comparing capital structures. market_return (required): Expected market return (Rm) as a decimal, e.g. 0.10 = 10% (never pass percentage points). The market risk premium is computed internally as Rm - Rf.
| Name | Required | Description | Default |
|---|---|---|---|
| beta | Yes | Equity beta (levered, if the company has debt), e.g. 1.2. Use unlevered/relevered betas when comparing capital structures. | |
| market_return | Yes | Expected market return (Rm) as a decimal, e.g. 0.10 = 10% (never pass percentage points). The market risk premium is computed internally as Rm - Rf. | |
| risk_free_rate | Yes | Risk-free rate as a decimal, e.g. 0.04 = 4% (typically the 10-year government bond yield; never pass percentage points). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations by specifying deterministic calculation, no network or storage access, and explicit error behavior for division by zero or non-finite inputs. It also clarifies that the market risk premium is computed internally. This fully discloses the tool's runtime behavior with no contradictions.
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?
Though lengthy, the description is tightly structured with clear labels (formula, WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, PARAMETERS). Every section earns its place by addressing a distinct decision or execution need: purpose, routing, safety, output format, and unit pitfalls. No filler or redundancy.
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 3-parameter numeric tool with no output schema, the description covers everything an agent needs: formula, application context, unit conventions, error handling, return shape with examples, and sibling routing. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's PARAMETERS section essentially repeats the schema's already-detailed field descriptions (decimal format, 'never pass percentage points', beta examples), adding no new parameter-level meaning. The formula in the purpose section does add relational context, but not beyond what the schema fields already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Calculate the cost of equity using the Capital Asset Pricing Model'), provides the exact formula, and distinguishes itself from siblings by naming WACC as a downstream consumer and by flagging when CAPM is inappropriate. This gives an agent a precise, non-confusable understanding of the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections state both the intended contexts (WACC input, DCF discount rate, standalone hurdle) and the exclusion case (private companies without a traded beta), with concrete alternative tools named (calculate_unlever_beta / calculate_relever_beta). This is exactly the decision guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a Discounted Cash Flow (DCF) valuation: enterprise value from projected free cash flows plus a Gordon-growth terminal value. WHEN TO USE: to value a company or asset from its projected free cash flows, WACC and perpetual terminal growth rate (standard corporate/asset valuation). WHEN NOT TO USE: for a single-exit lump-sum investment (use calculate_irr), or when you need the discount rate itself (use calculate_wacc). BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive. Terminal value uses the Gordon Growth Model; it is only defined when wacc is strictly greater than terminal_growth_rate. RETURNS: JSON object { inputs, results: { present_value, terminal_value, enterprise_value } }, each rounded to 2dp. present_value is the discounted explicit-period FCFs; enterprise_value = present_value + discounted terminal value (debt and cash are NOT netted — this is enterprise value, not equity value). PARAMETERS: free_cash_flows (array of per-period projected free cash flows, typically positive; the first element is discounted by one period), wacc (decimal, e.g. 0.10 = 10% — never pass percentage points; must be > terminal_growth_rate), terminal_growth_rate (decimal perpetual growth rate, e.g. 0.03 = 3% — never pass percentage points; must be < wacc).
| Name | Required | Description | Default |
|---|---|---|---|
| wacc | Yes | Weighted average cost of capital as a decimal, e.g. 0.10 = 10% (never pass percentage points). Must be strictly greater than terminal_growth_rate. | |
| free_cash_flows | Yes | Projected free cash flows per period, e.g. [5000000, 6000000, 7000000, 8000000, 9000000]. Typically positive; first element discounted one period. | |
| terminal_growth_rate | Yes | Perpetual terminal growth rate as a decimal, e.g. 0.03 = 3% (never pass percentage points). Must be strictly less than wacc, otherwise terminal value is undefined. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive,' reinforcing the readOnlyHint and idempotentHint annotations. It also discloses the Gordon Growth Model constraint (wacc > terminal_growth_rate) and clarifies that debt and cash are not netted, adding meaningful behavioral context beyond the annotations.
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 longer and structured with uppercase section headers, but every sentence carries substantive guidance: purpose, when to use/not use, behavior, return shape, and param semantics. It is front-loaded with the core purpose and not padded.
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?
This is a complex financial tool with three required parameters and no output schema, yet the description fully covers return structure, rounding, the mathematical constraint, and the distinction between enterprise and equity value. Combined with annotations, the agent has everything needed to invoke and interpret the result 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 the baseline is 3. The description's PARAMETERS section largely restates the schema: decimals not percentages, first FCF discounted one period, and the wacc/growth constraint. It adds no new meaning beyond what the schema already provides, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Compute a Discounted Cash Flow (DCF) valuation: enterprise value from projected free cash flows plus a Gordon-growth terminal value.' It clearly distinguishes itself from siblings by naming calculate_irr and calculate_wacc as alternatives for different cases. The purpose is unambiguous and action-oriented.
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?
The description explicitly provides 'WHEN TO USE' and 'WHEN NOT TO USE' sections with named alternative tools: calculate_irr for single-exit lump-sum investments and calculate_wacc for discount-rate needs. This gives the agent direct routing instructions, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate enterprise value (EV): the total value of a business to all capital providers — equity value plus net debt (total debt minus cash and equivalents). Formula: EV = Equity Value + Total Debt - Cash & Equivalents. WHEN TO USE: Use as the capital-structure-neutral measure of a company’s total value — the standard starting point for valuation multiples (EV/EBITDA, EV/Revenue) and M&A transaction values. WHEN NOT TO USE: Do NOT confuse EV with equity value (market cap) — EV is what you would pay to own the whole enterprise including its debt; use equity value for per-share figures. BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive; identical inputs always produce identical outputs. Division by zero, non-finite inputs, or mathematically undefined combinations return an explicit error instead of a number. RETURNS: JSON object { enterprise_value: number (currency), inputs }. PARAMETERS: equity_value (required): Equity value / market capitalisation, e.g. 5000000. Must be >= 0. total_debt (required): Total interest-bearing debt (short + long term), e.g. 2000000. Must be >= 0. cash_and_equivalents (required): Cash and cash equivalents to subtract, e.g. 500000. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| total_debt | Yes | Total interest-bearing debt (short + long term), e.g. 2000000. Must be >= 0. | |
| equity_value | Yes | Equity value / market capitalisation, e.g. 5000000. Must be >= 0. | |
| cash_and_equivalents | Yes | Cash and cash equivalents to subtract, e.g. 500000. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral context: pure deterministic calculation, no side effects, no network/storage access, identical inputs yield identical outputs, and explicit error behavior for division by zero or non-finite inputs. This goes well beyond the annotations without contradicting them.
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 well-organized with labeled sections (BEHAVIOUR, WHEN TO USE, PARAMETERS) and front-loads the formula. It is somewhat verbose, with the formula stated twice and parameter descriptions nearly duplicating the schema, but each section serves a clear purpose and the length is justified by the completeness.
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 3-parameter deterministic calculation with no output schema, the description covers everything needed: formula, input meanings with examples, constraints, return shape ({ enterprise_value, inputs }), error behavior, and use-case guidance. Nothing required to call the tool 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. The description adds value by embedding each parameter in the formula context, providing concrete examples (e.g., 5000000, 2000000, 500000), and restating the minimum-zero constraint in natural language. It does not introduce semantics absent from the schema, but the examples and formula linkage justify a score above baseline.
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 ('Calculate enterprise value'), provides the formula (EV = Equity Value + Total Debt - Cash & Equivalents), and explicitly distinguishes EV from equity value, which is a key confusion point. Among siblings it clearly differentiates itself as the base EV calculation rather than EV/EBITDA or EV/Revenue multiples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' section identifies EV as the capital-structure-neutral measure and starting point for valuation multiples and M&A values. Explicit 'WHEN NOT TO USE' section warns against confusing EV with equity value and directs agents to use equity value for per-share figures. This gives clear selection guidance relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the EV/EBITDA multiple: enterprise value divided by EBITDA — the most widely used valuation multiple for comparing companies independent of capital structure, tax and depreciation policy. Formula: EV/EBITDA = Enterprise Value / EBITDA. WHEN TO USE: Use for relative valuation of cash-generative businesses against peer multiples or transaction comps; a lower multiple may indicate relative undervaluation (or justified risk). WHEN NOT TO USE: Do NOT use when EBITDA is negative or near zero, or for early-stage companies with no meaningful EBITDA — the multiple is meaningless there (use EV/Revenue). BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive; identical inputs always produce identical outputs. Division by zero, non-finite inputs, or mathematically undefined combinations return an explicit error instead of a number. RETURNS: JSON object { ev_to_ebitda: number (e.g. 8.5 = 8.5x), inputs }. PARAMETERS: enterprise_value (required): Enterprise value in currency units, e.g. 10000000. Must be > 0. ebitda (required): Earnings before interest, tax, depreciation and amortisation, e.g. 1200000. Must be > 0 for a meaningful multiple.
| Name | Required | Description | Default |
|---|---|---|---|
| ebitda | Yes | Earnings before interest, tax, depreciation and amortisation, e.g. 1200000. Must be > 0 for a meaningful multiple. | |
| enterprise_value | Yes | Enterprise value in currency units, e.g. 10000000. Must be > 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior well beyond the annotations: pure deterministic calculation, no side effects, idempotent, non-destructive, and explicit error behavior for division by zero or non-finite inputs. This adds meaningful context on top of readOnlyHint and idempotentHint.
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 well structured with clear sections: definition, formula, use guidance, behavior, returns, and parameters. It is detailed but every section earns its place, and the core definition is front-loaded.
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 simple two-parameter deterministic calculation with no output schema, the description is complete: it defines the formula, states valid input conditions, describes error behavior, and specifies the return shape. Nothing needed to invoke the tool 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 both parameters with examples and constraints. The description restates the parameter meaning but does not add significant new semantics beyond the formula and the restriction that values must be positive for a meaningful multiple.
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: calculates EV/EBITDA, with the formula explicitly given. It also distinguishes the multiple from EV/Revenue, which is a sibling tool, making it clear what this one is for versus alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit WHEN TO USE and WHEN NOT TO USE sections, including the condition of negative or near-zero EBITDA and a direct pointer to EV/Revenue as the alternative. This fully routes the agent to the correct tool for the right situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the EV/Revenue (EV/Sales) multiple: enterprise value divided by revenue — a valuation multiple usable for companies with thin, negative or zero EBITDA (e.g. high-growth or pre-profit businesses). Formula: EV/Revenue = Enterprise Value / Revenue. WHEN TO USE: Use for valuing pre-profit / high-growth companies, or as a cross-check alongside EV/EBITDA for mature ones. WHEN NOT TO USE: Do NOT use revenue multiples alone — they ignore profitability entirely (a company can have a low EV/S and still destroy value); pair with margin and growth context. BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive; identical inputs always produce identical outputs. Division by zero, non-finite inputs, or mathematically undefined combinations return an explicit error instead of a number. RETURNS: JSON object { ev_to_revenue: number (e.g. 3.2 = 3.2x), inputs }. PARAMETERS: enterprise_value (required): Enterprise value in currency units, e.g. 10000000. Must be > 0. revenue (required): Revenue (net sales) over the trailing period, e.g. 3100000. Must be > 0.
| Name | Required | Description | Default |
|---|---|---|---|
| revenue | Yes | Revenue (net sales) over the trailing period, e.g. 3100000. Must be > 0. | |
| enterprise_value | Yes | Enterprise value in currency units, e.g. 10000000. Must be > 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds concrete behavior: pure deterministic calculation, no side effects, no network or storage access, identical inputs produce identical outputs, and division-by-zero or non-finite inputs return explicit errors. This is exactly the kind of context annotations alone do not provide.
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 well-structured with labeled sections and is front-loaded with the core purpose. There is minor redundancy — the formula appears both in the opening sentence and again as 'Formula: EV/Revenue = Enterprise Value / Revenue' — but overall every section earns its place.
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 simple two-parameter calculation, the description covers the formula, use cases, exclusions, behavioral guarantees, error handling, and return format. Since there is no output schema, the explicit RETURNS section is valuable and leaves nothing an agent needs to know to call 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 the schema already documents both parameters with examples and the 'Must be > 0' constraint. The description's PARAMETERS section mostly echoes the schema rather than adding new semantic meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Calculate the EV/Revenue (EV/Sales) multiple' — and immediately gives the formula. It also differentiates this from the sibling calculate_ev_to_ebitda by stating it is usable for companies with thin, negative, or zero EBITDA.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections tell the agent to use this for pre-profit/high-growth companies and as a cross-check alongside EV/EBITDA, while warning against relying on revenue multiples alone. This fully routes the agent to and away from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, but the description goes further by asserting 'pure deterministic calculation — no side effects, no network or storage access, no randomness' and details the Newton-Raphson with bisection fallback. This adds concrete behavioral context that neither the annotations nor the schema communicate.
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 uses a clear sectioned structure (WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, PARAMETERS) and front-loads the core purpose and scoping. However, the PARAMETERS section is redundant with the input schema, so not every sentence earns its place. The length is otherwise justified by the lack of an 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?
Since there is no output schema, the description compensates by fully specifying the return object: concept, definition, formula, calculation (including IRR percentage string, MOIC, cash_flows array), interpretation, and sensitivity breakdown. It also covers input constraints, algorithm behavior, and intended use cases, making the tool safely and correctly invokable by an agent.
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%, with each parameter already well-documented in the input schema. The description's PARAMETERS section simply repeats that information and does not add meaningful new semantics beyond what the schema provides. The baseline 3 applies because the schema carries the full burden, and the description does not compensate or extend it.
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 ('Calculate') and resource ('Internal Rate of Return (IRR), MOIC and an IRR sensitivity table'), then narrows the exact scope: a single lump-sum equity investment with one exit value after a whole-year hold period. It additionally distinguishes itself from sibling tools by emphasizing what it is not, so an agent can clearly separate it from calculate_npv, calculate_moic, and irr_sensitivity.
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?
Contains explicit WHEN TO USE and WHEN NOT TO USE sections. It names the alternative tools (calculate_npv, calculate_moic, irr_sensitivity) and the conditions that select them, such as multiple intermediate distributions or needing only the sensitivity grid. This is a textbook example of clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Multiple on Invested Capital (MOIC): total distributions divided by total invested, with no discounting and no time value. WHEN TO USE: for a quick money-multiple answer from a cash-flow schedule when you do not need a discount rate or annualised return. WHEN NOT TO USE: when time value of money matters (use calculate_irr for annualised return, or calculate_npv for discounted value). BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive. MOIC is computed as sum of positive cash flows divided by sum of absolute negative cash flows; returns 0 if there is no invested capital. RETURNS: JSON object { moic: number rounded to 2dp (e.g. 2.5 = 2.5x), cash_flows }. PARAMETERS: cash_flows (ordered number array starting at time 0; negatives are investments, positives are distributions), e.g. [-100000, 0, 0, 0, 0, 250000].
| Name | Required | Description | Default |
|---|---|---|---|
| cash_flows | Yes | Ordered cash flows starting at time 0. Negative = invested capital, positive = distributions. Example: [-100000, 0, 0, 0, 0, 250000]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the calculation is deterministic, side-effect-free, idempotent, and non-destructive, adding behavioral context beyond the annotations. It also documents the edge case of zero invested capital returning 0 and states the output format with rounding behavior.
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 well-structured with clear labels for definition, usage, behavior, returns, and parameters. Every section carries distinct value and there is minimal redundancy despite the thorough coverage.
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 single-parameter pure calculation tool with no output schema, the description fully covers what the agent needs: formula, sign conventions, edge case, output shape, rounding, and sibling distinctions. No important calling information 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?
Although the schema already documents cash_flows well, the description adds formula-level semantics: sum of positive cash flows divided by sum of absolute negative cash flows, explicit sign conventions, and a concrete example. This meaningfully supplements 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?
The description clearly defines MOIC as total distributions divided by total invested, specifies no discounting and no time value, and distinguishes it from related financial metrics. The exact calculation formula makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE and WHEN NOT TO USE sections state that this tool is for quick money-multiple answers without a discount rate, and it names calculate_irr and calculate_npv as alternatives when time value of money matters. This fully guides tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Net Present Value (NPV) of an ordered cash-flow series discounted at a given rate. The first cash flow is treated as time 0 and is NOT discounted (typically the negative initial investment). WHEN TO USE: to evaluate whether an investment creates or destroys value at a required discount rate, or to compare competing projects on a present-value basis when you have a full cash-flow schedule. WHEN NOT TO USE: for a single lump-sum investment with one exit value (use calculate_irr), or when you only need a money multiple with no time value (use calculate_moic). BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive; identical inputs always produce identical outputs. RETURNS: JSON object { npv: number rounded to 2dp, rate, cash_flows }. A positive NPV means the investment clears the discount-rate hurdle. PARAMETERS: rate (decimal discount rate, e.g. 0.10 = 10% — express as a decimal, never as percentage points), cash_flows (ordered number array starting at time 0; negative values are investments/outflows, positive values are distributions/inflows), e.g. [-100000, 0, 0, 0, 0, 250000].
| Name | Required | Description | Default |
|---|---|---|---|
| rate | Yes | Discount rate as a decimal, e.g. 0.10 = 10%. Never pass percentage points (10 is invalid for 10%). | |
| cash_flows | Yes | Ordered cash flows starting at time 0 (first element is not discounted). Negative = investment/outflow, positive = distribution/inflow. Example: [-100000, 0, 0, 0, 0, 250000]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by stating the calculation is 'pure deterministic' with 'no side effects, no network or storage access,' and that 'identical inputs always produce identical outputs.' It also discloses the return format and interpretation of positive NPV, adding real behavioral context beyond readOnlyHint and idempotentHint.
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 organized into clear labeled sections: WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, and PARAMETERS. It front-loads the core definition and every section earns its place without filler or redundancy.
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?
Although there is no output schema, the description fully documents the return object shape and numeric rounding, plus the meaning of a positive NPV. Combined with full input schema coverage and safety annotations, nothing needed to invoke the tool 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 meaningful reinforcement: it explains rate must be a decimal rather than percentage points, defines cash-flow sign conventions, notes the first cash flow is not discounted, and gives a concrete example. It largely mirrors the schema but adds the typical initial-investment framing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Calculate the Net Present Value (NPV) of an ordered cash-flow series discounted at a given rate.' It explains the time-0 non-discounting convention and distinguishes itself from siblings in the WHEN NOT TO USE section by naming calculate_irr and calculate_moic.
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?
WHEN TO USE explicitly describes investment evaluation and project comparison, while WHEN NOT TO USE names specific alternatives and the conditions that should route to them, such as single lump-sum investments going to calculate_irr. This is direct, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relever an unlevered (asset) beta to a target capital structure using the Hamada formula — restoring financial risk for the specific debt/equity mix of the company or deal being valued. Formula: Beta(levered) = Beta(unlevered) x (1 + (1 - tax rate) x Debt/Equity). WHEN TO USE: Use AFTER unlevering comparable betas: apply the average unlevered beta to your target company’s (or transaction’s) capital structure to obtain the beta for WACC. WHEN NOT TO USE: Do NOT relever onto an unrealistic target structure — extreme leverage produces extreme betas that may overstate risk; sanity-check the resulting cost of equity. BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive; identical inputs always produce identical outputs. Division by zero, non-finite inputs, or mathematically undefined combinations return an explicit error instead of a number. RETURNS: JSON object { levered_beta: number (e.g. 1.15), inputs }. PARAMETERS: unlevered_beta (required): Unlevered (asset) beta, e.g. 0.85. Must be > 0. tax_rate (required): Corporate tax rate as a decimal between 0 and 1, e.g. 0.25 = 25%. debt_to_equity (required): Target debt-to-equity ratio (market values preferred), e.g. 0.6 = 0.6x. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| tax_rate | Yes | Corporate tax rate as a decimal between 0 and 1, e.g. 0.25 = 25%. | |
| debt_to_equity | Yes | Target debt-to-equity ratio (market values preferred), e.g. 0.6 = 0.6x. Must be >= 0. | |
| unlevered_beta | Yes | Unlevered (asset) beta, e.g. 0.85. Must be > 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, but the description adds valuable detail beyond that: 'pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive' and explicitly documents error behavior for division by zero or non-finite inputs. This goes well beyond the annotations without contradicting them.
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 uses clearly labeled sections (formula, when to use, when not to use, behavior, returns, parameters) and front-loads the core purpose and formula. Every sentence adds useful guidance; no filler or redundant restatement of the tool name.
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 deterministic calculation tool with 100% parameter schema coverage, readOnly/idempotent annotations, no output schema, and sibling tools covering related finance operations, the description is complete. It covers purpose, formula, usage timing, exclusion cases, return shape, error behavior, and parameter constraints.
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 fully documents each parameter. The description's Parameters section largely mirrors the schema with examples, and adds only minor context such as 'market values preferred' for debt_to_equity. This is adequate but not a substantial increment over the structured 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 ('Relever'), the resource (unlevered beta), the target state (target capital structure), and the exact formula (Hamada). It clearly differentiates from sibling calculate_unlever_beta, which performs the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says WHEN TO USE: 'AFTER unlevering comparable betas... apply the average unlevered beta to your target company’s capital structure to obtain the beta for WACC.' It also gives a WHEN NOT TO USE caution about unrealistic leverage, and the WACC mention connects it to calculate_wacc without needing to inspect siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unlever a (levered) equity beta to its asset beta using the Hamada formula — removing the financial-risk effect of debt so betas of companies with different capital structures can be compared. Formula: Beta(unlevered) = Beta(levered) / (1 + (1 - tax rate) x Debt/Equity). WHEN TO USE: Use when valuing a private company or a deal with a different capital structure than the public comparable — unlever the comps’ betas, average them, then relever at your target structure. WHEN NOT TO USE: Do NOT unlever with an inconsistent tax rate or debt/equity ratio — the result is only as clean as its inputs; for companies with significant non-debt liabilities consider a more advanced formula. BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive; identical inputs always produce identical outputs. Division by zero, non-finite inputs, or mathematically undefined combinations return an explicit error instead of a number. RETURNS: JSON object { unlevered_beta: number (e.g. 0.85), inputs }. PARAMETERS: levered_beta (required): The observed (levered) equity beta of the comparable company, e.g. 1.2. Must be > 0. tax_rate (required): Corporate tax rate as a decimal between 0 and 1, e.g. 0.25 = 25%. debt_to_equity (required): Debt-to-equity ratio of the company whose beta is being unlevered (market values preferred), e.g. 0.5 = 0.5x. Must be >= 0.
| Name | Required | Description | Default |
|---|---|---|---|
| tax_rate | Yes | Corporate tax rate as a decimal between 0 and 1, e.g. 0.25 = 25%. | |
| levered_beta | Yes | The observed (levered) equity beta of the comparable company, e.g. 1.2. Must be > 0. | |
| debt_to_equity | Yes | Debt-to-equity ratio of the company whose beta is being unlevered (market values preferred), e.g. 0.5 = 0.5x. Must be >= 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by stating the calculation is 'pure deterministic,' with 'no side effects, no network or storage access,' idempotent, and non-destructive. It also discloses error behavior for division by zero, non-finite inputs, and undefined combinations, which is highly useful for an agent deciding how to invoke and handle results.
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 well-structured with labeled sections: Formula, WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, and PARAMETERS. Each section earns its place, and the core purpose and formula are front-loaded before usage and behavioral caveats.
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 deterministic calculation tool with no output schema, the description covers all necessary context: formula, parameter constraints, error semantics, return shape, and use cases. An agent has everything needed to select and correctly invoke the 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%, so the baseline is strong, but the description adds the Hamada formula tying the parameters together and clarifications like market values preferred for debt_to_equity. This provides relational meaning beyond the individual parameter schemas.
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 states a specific action and resource: 'Unlever a (levered) equity beta to its asset beta using the Hamada formula.' It also explains the purpose of the calculation—removing financial-risk effect so betas with different capital structures can be compared—and gives the exact formula, making the tool's role unambiguous and distinguishable from siblings like calculate_relever_beta.
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?
The description provides explicit WHEN TO USE and WHEN NOT TO USE guidance, including the valuation context and input-quality caveats. It mentions relevering at a target structure, which implicitly points to the alternative workflow, but it does not explicitly name calculate_relever_beta as the sibling tool to use for that step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate the Weighted Average Cost of Capital (WACC): the blended after-tax cost of a company's equity and debt capital, weighted by market values. WHEN TO USE: to determine the discount rate for a DCF valuation from equity market value, debt market value, costs of capital and corporate tax rate. WHEN NOT TO USE: when you already have the discount rate, or for the full valuation itself (use calculate_dcf). BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive. Formula: (E/V) x Re + (D/V) x Rd x (1 - tax_rate), where V = equity_value + debt_value; returns 0 if total value is 0. RETURNS: JSON object { wacc: decimal rounded to 6dp (e.g. 0.105), wacc_percent: percentage rounded to 2dp (e.g. 10.5), inputs }. PARAMETERS: equity_value (market value of equity, >= 0), debt_value (market value of debt, >= 0), cost_of_equity (decimal, e.g. 0.12 = 12%), cost_of_debt (decimal, e.g. 0.06 = 6%), tax_rate (decimal 0-1, e.g. 0.25 = 25%). All rates are decimals, never percentage points.
| Name | Required | Description | Default |
|---|---|---|---|
| tax_rate | Yes | Corporate tax rate as a decimal between 0 and 1, e.g. 0.25 = 25%. | |
| debt_value | Yes | Market value of debt, >= 0, e.g. 5000000. | |
| cost_of_debt | Yes | Cost of debt as a decimal, e.g. 0.06 = 6%. Never pass percentage points. | |
| equity_value | Yes | Market value of equity, >= 0, e.g. 10000000. | |
| cost_of_equity | Yes | Cost of equity as a decimal, e.g. 0.12 = 12%. Never pass percentage points. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description goes further by stating 'pure deterministic calculation — no side effects, no network or storage access' and documents the zero-total-value edge case ('returns 0 if total value is 0'). This adds meaningful behavioral context beyond the annotations.
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 longer than average but uses labeled sections (WHEN TO USE, BEHAVIOUR, RETURNS, PARAMETERS) that make it skimmable. Each sentence contributes either a usage rule, formula, or parameter clarification. Slight redundancy with schema parameter descriptions keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers inputs, formula, edge case, and return object, so an agent can invoke and interpret results correctly. It references calculate_dcf as the alternative, but it does not mention calculate_capm_cost_of_equity, a sibling that could provide the cost_of_equity input. This is a minor gap given the input list is otherwise self-contained.
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 already has a description. The description adds value by tying parameters to the formula (E/V x Re + D/V x Rd x (1 - tax_rate)) and by emphasizing the global rule 'All rates are decimals, never percentage points,' which prevents a common invocation error.
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 precise verb and resource: 'Calculate the Weighted Average Cost of Capital (WACC)' and immediately defines what WACC is. It clearly distinguishes itself from calculate_dcf by noting the tool covers only the discount-rate step, not the full valuation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections give unambiguous selection criteria: use it to derive a DCF discount rate from the listed inputs, avoid it when the discount rate is already known, and defer to calculate_dcf for full valuation. This is model guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute an IRR sensitivity grid across a range of exit multiples and hold periods for a single lump-sum investment. WHEN TO USE: to stress-test how the annualised return varies with exit multiple and holding period before committing to an investment. Complements calculate_irr. WHEN NOT TO USE: when you need one precise IRR for a known exit value (use calculate_irr), or a full valuation (use calculate_dcf). BEHAVIOUR: pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive. NOTE ON GRID GEOMETRY: the byMultiple grid is computed at the SECOND hold period in hold_periods (default 5 years); the byHoldPeriod grid is computed at a 2.5x exit multiple. RETURNS: JSON object { byMultiple: { "2.0x": 14.9, ... } with IRR values as percentage numbers rounded to 1dp, byHoldPeriod: { "5y": 18.4, ... } }. PARAMETERS: initial_investment (number > 0), exit_multiples (optional array of numbers to test, default [1.5, 2.0, 2.5, 3.0, 3.5]), hold_periods (optional array of positive integers (years) to test, default [3, 5, 7, 10]).
| Name | Required | Description | Default |
|---|---|---|---|
| hold_periods | No | Hold periods in whole years to test, e.g. [3, 5, 7, 10]. Defaults to [3, 5, 7, 10]. | |
| exit_multiples | No | Exit multiples to test, e.g. [2.0, 2.5, 3.0, 4.0, 5.0]. Defaults to [1.5, 2.0, 2.5, 3.0, 3.5]. | |
| initial_investment | Yes | Amount invested up front, in currency units, e.g. 100000. Must be positive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that it is a 'pure deterministic calculation' with 'no network or storage access,' and details the grid geometry anchors (second hold period, 2.5x exit multiple) and rounding to 1dp. These are non-obvious behaviors an agent needs to interpret results correctly, and nothing contradicts the annotations.
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 organized into labelled sections (WHEN TO USE, BEHAVIOUR, RETURNS, PARAMETERS) and leads with a clear first sentence. It is longer than minimal, and the PARAMETERS section redundantly repeats schema info, but every section adds operational context such as return shape and grid anchors.
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?
With no output schema, the description fully specifies the return JSON object with examples and rounding behavior, and explains defaults and grid anchors. All input semantics and safety traits are covered either by the description or the schema/annotations, so an agent has what it needs to call 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 coverage is 100% so the baseline is 3; the description adds value by explaining how parameters interact via the grid-geometry note and by summarizing defaults and positivity constraints. It still partially repeats the schema text, so it does not reach the top of the scale.
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 first sentence states a specific verb, resource, and scope: 'Compute an IRR sensitivity grid across a range of exit multiples and hold periods for a single lump-sum investment.' It also differentiates from siblings by naming calculate_irr as the single-point alternative and calculate_dcf as the valuation alternative.
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?
The description includes explicit WHEN TO USE and WHEN NOT TO USE sections, naming calculate_irr and calculate_dcf as alternatives and the conditions that select them. This leaves no ambiguity about when to invoke the tool.
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. Dates show when Glama detected each change.
calculate_capm_cost_of_equitycalculate_dcfcalculate_enterprise_valuecalculate_ev_to_ebitdacalculate_ev_to_revenuecalculate_irrcalculate_moiccalculate_npvcalculate_relever_betacalculate_unlever_betacalculate_waccirr_sensitivityClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
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.
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.
Deterministic what-if & scenario simulation for AI agents: projections, sensitivity & break-even.
Deterministic liquidity and leverage ratio tools for AI agents — current, quick and cash ratios, defensive interval, debt-to-equity, debt-to-assets, equity multiplier and interest coverage via Model Context Protocol. Useful for corporate finance, credit analysis, financial analysis, financial formulas and financial modeling.
Add one secure layer between your agents and this server.
Most tools map cleanly to distinct valuation concepts (CAPM, WACC, DCF, multiples, NPV/IRR/MOIC, beta adjustment), so an agent can generally select correctly. The main ambiguity is that calculate_irr already includes MOIC and an IRR sensitivity table, making irr_sensitivity and calculate_moic partially overlapping in purpose despite their clarifications.
The overwhelming pattern is calculate_<metric>, with clear snake_case and a consistent prefix throughout. The one outlier is irr_sensitivity, which drops the calculate_ prefix and breaks the established verb_noun convention.
Twelve tools is a well-scoped size for a valuation calculation API, covering cost of capital, DCF, multiples, and return metrics without bloat. Each tool represents a meaningful standalone calculation an agent would need.
The core valuation workflow is well covered: cost of equity, WACC, DCF, enterprise value, multiples, and investment return metrics are all present. The notable gap is the reverse of calculate_enterprise_value—deriving equity value from enterprise value—and there is no standalone terminal value calculator, though both are workable gaps.