Deterministic valuation tools for AI agents — IRR, NPV, MOIC, DCF, WACC and sensitivity analysis for companies and assets via Model Context Protocol.
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 discloses that the calculation is pure, deterministic, idempotent, non-destructive, and fault-tolerant with explicit errors for invalid inputs. This meaningfully extends the annotations, especially the error behavior and no side effects.
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 and front-loaded with the formula and purpose. Though the PARAMETERS section duplicates the input schema descriptions, the other sections are focused and free of filler.
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 compensates by documenting the exact return shape with examples. It also covers input constraints, error behavior, and typical use cases, making the tool fully actionable for an AI 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 description coverage is 100%, so the schema already documents each parameter in detail. The description's PARAMETERS section largely repeats the schema text rather than adding new meaning, which keeps this 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 clearly states the tool calculates cost of equity using CAPM, gives the exact formula, and names the formula components. It explicitly distinguishes itself by mentioning CAPM, a specific model, unlike the many generic sibling calculators.
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?
Includes explicit WHEN TO USE and WHEN NOT TO USE sections. It names concrete alternatives (calculate_unlever_beta, calculate_relever_beta) and describes the exact condition (private companies with poor beta) where this tool should not be used.
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?
Beyond the readOnlyHint and idempotentHint annotations, the description adds meaningful behavioral detail: no side effects, no network/storage access, pure deterministic calculation, and a terminal value condition (wacc must be strictly greater than terminal_growth_rate). It also discloses the exact return shape and rounding behavior, which is especially valuable because there is no 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?
The description is long but well-structured with clear labeled sections: purpose, WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, and PARAMETERS. Each section earns its place; some redundancy with annotations exists, but the organized format makes the content easy to scan and act on.
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 complete description for a tool of moderate complexity. It covers input semantics, constraints, return format, rounding, the Gordon Growth condition, and a key interpretive caveat: enterprise value vs equity value (debt and cash are not netted). Since there is no output schema, the explicit RETURNS section fills an important 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 the baseline is 3. The description reinforces parameter meaning with examples and constraints, such as 'wacc (decimal, e.g. 0.10 = 10% — never pass percentage points)' and 'the first element is discounted by one period,' but most of this is already present in the schema descriptions. It adds minimal new semantic value beyond 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 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.' This clearly distinguishes the tool from siblings like calculate_irr and calculate_wacc, and the scope of what is computed is 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?
The description includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections. It names concrete alternatives: use calculate_irr for single-exit lump-sum investments and calculate_wacc when the discount rate itself is needed, leaving no doubt about tool selection.
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 like P/E. 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 readOnly, idempotent, and non-destructive behavior. The description adds concrete guarantees beyond the annotations: no network/storage access, deterministic results, and explicit error handling for invalid inputs. This is rich behavioral context that helps an agent trust and safely invoke the tool.
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 (formula, when to use, when not to use, behavior, returns, parameters) and front-loads the core calculation. It is longer than strictly necessary because the PARAMETERS section largely duplicates the schema, but the organization and signal density are strong.
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 a 3-param pure calculation tool with annotations and no output schema, the description is complete: it explains the formula, return shape, error behavior, and covers all parameters. There is nothing essential missing for an agent to call it 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 repeats the parameter definitions rather than adding substantially new meaning; the formula and relationship between equity value, debt, and cash provide useful context, but each parameter is already well-described in 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 states a specific verb ('Calculate') and a specific resource ('enterprise value') with an explicit formula. It also distinguishes EV from equity value, which is a common confusion and a different concept covered by sibling tools.
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, telling the agent when EV is the correct metric (valuation multiples, M&A) and when to prefer equity value instead. This directly guides tool selection among the many sibling financial-calculator tools.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructiveHint, and the description reinforces these with explicit statements: pure deterministic calculation, no side effects, no network/storage access, and idempotent behavior. It also discloses error behavior for division by zero and non-finite inputs, which adds transparency 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 well-structured with labeled sections for definition, formula, when to use, when not to use, behavior, returns, and parameters. It is longer than average but every section earns its place by providing operationally useful guidance.
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?
Despite having no output schema, the description explicitly states the return format: a JSON object containing ev_to_ebitda and inputs. It also covers formula, parameter constraints, error cases, and usage boundaries, making the tool fully usable without additional context.
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 input schema already documents both enterprise_value and ebitda with constraints and examples. The description repeats these parameter details rather than adding substantial new meaning, keeping this dimension at the baseline 3.
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 identifies the tool's function: calculating the EV/EBITDA multiple from enterprise value and EBITDA, with a formula and statement of its use as a valuation multiple. It also distinguishes itself from related siblings by explicitly naming EV/Revenue as the alternative when EBITDA is unusable.
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, including concrete conditions such as negative or near-zero EBITDA and early-stage companies. It even names the alternative metric (EV/Revenue), giving an agent clear decision criteria for selecting this tool over siblings.
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 discloses that it is a pure deterministic calculation, has no side effects, and returns explicit errors for division by zero or non-finite inputs. This gives the agent a complete behavioral model.
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 and front-loaded purpose and formula. Though detailed, every section earns its place and no content is redundant or filler.
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 compensates by specifying the return shape ({ ev_to_revenue, inputs }), error behavior, and valid input ranges. For a two-parameter financial calculation, this is fully complete.
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%, and the description largely repeats the parameter details already present in the schema. It adds the formula and the example values, but not substantial new semantic meaning beyond what the schema provides.
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 verb and resource ('Calculate the EV/Revenue multiple') and gives the exact formula. It clearly distinguishes this from sibling valuation tools by noting it applies to 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 provide clear selection guidance, including when to pair it with EV/EBITDA and why it should not be used alone. This fully covers usage context 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 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?
The BEHAVIOUR section adds context beyond annotations: 'pure deterministic calculation — no side effects, no network or storage access, no randomness; idempotent and non-destructive' plus the solving method ('Newton-Raphson with bisection fallback') and cash-flow schedule shape. Since annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description's additional algorithmic detail earns a 4 rather than a 5. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Though long, the description is modular with scannable labels — WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, PARAMETERS — and the core purpose is front-loaded in the first sentence. Every sentence carries information proportional to the tool's complexity (three outputs, sensitivity grid, algorithmic disclosure).
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 present, the RETURNS section fully documents the JSON shape: 'concept, definition, formula, calculation (irr as a percentage string, moic as a multiple, cash_flows array), interpretation, and sensitivity (byMultiple, byHoldPeriod)'. Combined with 100% parameter coverage, named sibling alternatives, and behavioral disclosure, nothing an agent needs to invoke this 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 baseline is 3; each parameter already carries a schema description covering positivity, currency units, integer restriction, and the currency enum with 'display only — no conversion'. The PARAMETERS section in the description largely restates the schema rather than adding new meaning, so it does not push 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?
The opening sentence names a specific verb and resource — 'Calculate the Internal Rate of Return (IRR), MOIC and an IRR sensitivity table' — and precisely scopes it to 'a single lump-sum equity investment that returns one exit value after a whole-year hold period.' This immediately distinguishes it from siblings like 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?
The WHEN TO USE section states the exact trigger condition ('an upfront investment amount, a single exit value and a hold period in whole years'), and WHEN NOT TO USE routes to named alternatives ('use calculate_npv or calculate_moic on the full cash-flow array', 'use irr_sensitivity'). Tool selection is fully explicit with no inference required.
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 goes beyond annotations by stating the calculation is pure deterministic, has no side effects/network/storage access, and returns 0 when there is no invested capital. It also clarifies the exact MOIC computation rule, adding behavioral detail not present in annotations alone.
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 labeled sections and front-loads the core definition and formula. Each sentence adds useful context, and the labels make it easy to scan for purpose, behavior, return shape, and parameters.
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?
Despite having no output schema, the description documents the return JSON shape, rounding behavior, and an example output. Combined with parameter details, usage boundaries, and edge-case behavior, it provides everything an agent needs to call this 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?
The schema already fully describes cash_flows with ordering, sign convention, and an example, so the description adds little new parameter-level meaning. It restates the same semantics and formula, which is helpful but not a substantive addition beyond 100% schema coverage.
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 identifies the tool as calculating MOIC with an explicit formula (distributions / invested) and states it has no discounting or time value. This distinguishes it from sibling tools like calculate_irr and calculate_npv even before reading 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?
The description provides explicit 'WHEN TO USE' and 'WHEN NOT TO USE' guidance, including named alternatives (calculate_irr for annualized return, calculate_npv for discounted value). An agent can decide between sibling tools with no ambiguity.
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?
Annotations already convey readOnly, idempotent, non-destructive behavior; the description adds 'no side effects, no network or storage access' and 'identical inputs always produce identical outputs.' It also documents return rounding to 2dp and the sign interpretation of NPV, though some statements simply restate 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 long but organized into labeled sections that front-load purpose and then add usage, behavior, returns, and parameters. Every sentence carries distinct routing or invocation information, and there is no filler or repetition that bloats the definition.
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?
Despite having no output schema, the description specifies the return object shape, rounding, cash-flow ordering, sign conventions, discount-rate format, and decision meaning of positive NPV. With only two fully documented parameters, an agent has everything needed to 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 the schema already explains rate as a decimal and the ordered cash-flow sign convention. The description largely paraphrases these details and adds only a worked example, not new parameter semantics beyond 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?
Uses a specific verb and resource ('Calculate the Net Present Value') and defines the core semantics: ordered cash-flow series, first flow at time 0 not discounted. It explicitly names the alternatives calculate_irr and calculate_moic in the WHEN NOT TO USE section, so it is distinguishable from siblings.
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 an explicit WHEN TO USE and WHEN NOT TO USE with named alternatives (calculate_irr, calculate_moic), which is strong routing guidance. It does not mention calculate_dcf, a semantically close sibling, so the agent is not fully told how to choose between NPV and DCF.
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?
The description goes well beyond the annotations by detailing that the tool is a pure deterministic calculation with no side effects, no network or storage access, and identical outputs for identical inputs. It also discloses error behavior for division by zero, non-finite inputs, and undefined combinations, which the annotations do not specify.
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 into labeled sections (WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, PARAMETERS), making it scannable and front-loaded with the core purpose and formula. Despite its length, every sentence contributes useful information without repetition.
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 provides the return shape ({ levered_beta: number, inputs }) and error behavior, which is essential. It also gives enough financial context and constraints to call the tool correctly for a WACC-related valuation workflow.
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 covers all three parameters at 100%, the description adds meaningful context by embedding them in the Hamada formula and noting that debt_to_equity should use market values. It reinforces validation constraints with examples, which helps an agent understand the practical meaning of each parameter beyond 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 states a specific action — 'Relever an unlevered (asset) beta to a target capital structure using the Hamada formula' — with the exact formula and financial rationale. This clearly distinguishes it from sibling tools like calculate_unlever_beta and calculate_wacc by naming its role in building a levered beta for WACC.
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. It instructs agents to apply this tool AFTER unlevering comparable betas and warns against relevering onto unrealistic capital structures, providing practical decision-making guidance.
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 explicitly stating the calculation is 'pure deterministic', has 'no side effects, no network or storage access', is idempotent, and that division by zero/non-finite inputs 'return an explicit error instead of a number'. This adds concrete behavioral expectations that the readOnly/idempotent hints alone do not convey.
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?
Although lengthy, the description is organized into clearly labeled sections (formula, WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, RETURNS, PARAMETERS), making it scannable. Every sentence carries distinct information: no filler, no repetition of annotations, and the core formula 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?
Even without an output schema, the description specifies the return shape ('JSON object { unlevered_beta: number, inputs }'), error behavior, and all required parameter constraints. For a pure calculation tool, it covers everything an agent needs to call it correctly and interpret results.
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?
The schema already documents each parameter thoroughly with 100% coverage, so the baseline is 3. The description adds modest value by including the formula linking parameters, an example output, and the nuance that debt_to_equity should use market values ('market values preferred'), which is genuinely additional guidance beyond 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 uses a specific verb ('Unlever'), a precise resource ('a (levered) equity beta to its asset beta'), and names the exact method ('Hamada formula') with the formula written out. It clearly distinguishes itself from the sibling calculate_relever_beta by defining the inverse operation and framing the use case around comparing capital structures.
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 'WHEN TO USE' section provides a concrete scenario (valuing a private company/deal with different capital structure) and prescribes a workflow: unlever comps, average, and relever at target structure. The 'WHEN NOT TO USE' section lists specific conditions (inconsistent tax rate/D/E, non-debt liabilities) where the tool is inappropriate, giving agents clear decision criteria.
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?
While annotations already declare readOnlyHint, idempotentHint, and destructiveHint, the description adds a dedicated BEHAVIOUR section: 'pure deterministic calculation — no side effects, no network or storage access; idempotent and non-destructive.' It also discloses the edge-case behavior 'returns 0 if total value is 0', which is not present in annotations or 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?
The description is long but well-organized into labeled sections (WHEN TO USE, WHEN NOT TO USE, BEHAVIOUR, Formula, RETURNS, PARAMETERS), each earning its place. Key information is front-loaded and scanning-friendly, with no filler.
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?
Despite having no output schema, the description fully specifies the return shape (JSON object with wacc rounded to 6dp and wacc_percent rounded to 2dp). It covers inputs, formula, edge case, and usage boundaries. For a 5-parameter calculation tool, nothing needed for correct invocation 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 value by giving a concise parameter rundown with concrete examples and the repeated warning 'All rates are decimals, never percentage points.' It also ties parameters together in the formula (E/V x Re + D/V x Rd x (1 - tax_rate)), clarifying each parameter's role beyond the schema's individual descriptions.
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?
Description opens with a specific verb+resource: 'Calculate the Weighted Average Cost of Capital (WACC)', then defines it as the blended after-tax cost of equity and debt weighted by market values. It distinguishes itself from calculate_dcf and other ratio siblings by stating it produces the discount rate for a DCF, 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' section states the exact scenario: determining the discount rate for a DCF valuation from equity/debt market values, costs of capital, and tax rate. 'WHEN NOT TO USE' names the alternative (calculate_dcf) and the condition that selects it (already having the discount rate), leaving no ambiguity.
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 (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral context: pure deterministic calculation, no side effects, no network/storage access, and the unusual grid geometry where byMultiple uses the second hold period and byHoldPeriod uses a 2.5x multiple. It also specifies rounding to 1dp and the exact return shape.
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 every section earns its place: purpose, usage, behavior, grid geometry, return format, and parameters are all labeled and front-loaded. The structure makes it easy for an agent to parse the critical routing and output details quickly.
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?
Despite having no output schema, the description explicitly details the return JSON structure with example keys and values, grid geometry, defaults, and rounding. Given the tool's moderate complexity and rich annotations, nothing essential is missing for an agent to invoke it 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 all parameters and constraints. The description repeats the defaults and adds brief examples, but it does not significantly expand on the schema's meaning. This meets the baseline for a fully documented 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 opens with a specific verb and resource: 'Compute an IRR sensitivity grid across a range of exit multiples and hold periods for a single lump-sum investment.' It clearly differentiates the tool from calculate_irr and calculate_dcf by naming them as alternatives, so an agent can select this tool without inspecting sibling 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?
The description includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, telling the agent to use this for stress-testing returns across scenarios and to use calculate_irr for a single precise IRR or calculate_dcf for full valuation. This is direct, unambiguous routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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!
Add one secure layer between your agents and this server.
Every tool targets a distinct financial metric or formula, and the WHEN TO USE / WHEN NOT TO USE guidance clearly separates closely related concepts like DSO vs. receivables turnover, current vs. quick vs. cash ratio, and DPI/RVPI/TVPI. Even the overlapping investment-return tools (NPV, IRR, MOIC, payback) are explicitly differentiated.
The overwhelming majority of tools follow a clean calculate_<metric> snake_case pattern, making the set highly predictable. The single exception is irr_sensitivity, which breaks the calculate_ prefix convention but is still readable and not chaotic.
At 52 tools, this far exceeds the 25+ threshold where a tool set becomes too heavy for its scope. Although each tool is a distinct pure calculation, the sheer breadth creates a large navigation and selection burden for agents.
The server covers an unusually broad range of valuation workflows: time value of money, DCF/WACC/cost of capital, relative valuation multiples, profitability/liquidity/efficiency ratios, and private equity fund metrics. Minor gaps exist, such as no dedicated free cash flow, net debt, or EBITDA margin calculators, but these are workable around.