Complete intangible asset valuation library implementing 124+ functions from the Intangible Asset Valuation textbook. Python library + MCP server + AI-Agent Skills.
A production-grade Python library for intangible asset valuation, implementing every formula from the Intangible Asset Valuation textbook by Simon Mak, William Yuen, Paul Wu, and Wayne Hu (Valuation in Practice Series, Ascent Partners). Designed for developers, financial analysts, accountants, and AI agents who need auditable, structured valuation computations for ASC 805 / IFRS 3 compliant workflows.
Three-layer architecture:
graph TB
subgraph Library["Python Library"]
MOD["22 Modules<br/>124+ Functions"] --> VR["ValuationResult"]
end
subgraph MCP["MCP Server"]
VR --> SVR["FastMCP Server<br/>14 folded tools"]
end
subgraph Skills["AI-Agent Skills"]
SVR --> AV["Asset Valuation"]
SVR --> DR["Discount Rates"]
SVR --> PPA["Purchase Price Allocation"]
SVR --> IMP["Impairment Testing"]
end
style Library fill:#0083AB,color:#fff
style MCP fill:#4CAF50,color:#fff
style Skills fill:#9C27B0,color:#fffPython Library — 22 modules, 124+ typed functions, all returning ValuationResult (value + assumptions + steps + formula reference)
MCP Server — 14 folded tools (124+ formulas) for AI agents via stdio and hosted Streamable HTTP
AI-Agent Skills — 4 skill definitions with workflow guidance for valuation domains
Related MCP server: modelforge
pip install intangible-valuation # library only
pip install intangible-valuation[mcp] # + MCP server
pip install intangible-valuation[dev] # + pytest, ruff, mypyfrom intangible_valuation.core.time_value import present_value
from intangible_valuation.core.discount_rates import build_up_discount_rate
from intangible_valuation.income_methods.relief_from_royalty import relief_from_royalty
# Present Value
result = present_value(future_value=500_000, discount_rate=0.10, periods=8)
print(f"PV: ${result.value:,.2f}") # $233,253.69
# Build-Up Discount Rate
rate = build_up_discount_rate(
risk_free_rate=0.04, equity_risk_premium=0.06,
size_premium=0.02, industry_risk_premium=0.01, specific_risk_premium=0.03,
)
print(f"Discount rate: {rate.value:.2%}") # 16.00%
# Relief from Royalty — Patent Valuation
value = relief_from_royalty(
revenue_projections=[1_000_000, 1_100_000, 1_200_000, 1_300_000, 1_400_000],
royalty_rate=0.05, discount_rate=0.12, tax_rate=0.25, useful_life=5,
)
print(f"Patent value: ${value.value:,.2f}")The server exposes 14 tools, each folding a family of formulas behind a
method argument — time value, discount rates, cost/market/income approaches,
IP, technology, customer and human-capital assets, goodwill and purchase price
allocation, impairment, royalty analysis, uncertainty (Monte Carlo / decision
trees), and transfer-pricing / litigation.
Local (stdio):
pip install "intangible-valuation[mcp]"
python mcp_server/server.pyHosted (Streamable HTTP) — no install, no API key:
https://intangible-valuation.simonmak.com/api/mcpOpenCode — add to opencode.json:
"intangible-valuation": {
"type": "remote",
"url": "https://intangible-valuation.simonmak.com/api/mcp",
"timeout": 60000
}Claude Desktop / Cursor — add the HTTP URL
https://intangible-valuation.simonmak.com/api/mcp as an MCP server, or run the
stdio entrypoint above.
MCP Registry — published as
io.github.simonplmak-cloud/intangible-valuation (manifest:
server.json) and listed on
Glama and
the Official MCP Registry. The
glama.json file holds the Glama maintainer entry.
Copy the skills/ directory to your agent's skills folder:
asset-valuation — Patents, trademarks, technology, customer relationships, human capital
discount-rate-construction — Build-up, CAPM, WACC, risk premiums, adjustments
purchase-price-allocation — ASC 805 / IFRS 3 PPA workflow, goodwill calculation
impairment-testing — ASC 350, IAS 36 goodwill and intangible impairment
Category | Methods | Chapter |
Time Value | PV, FV, annuity, perpetuity, growing annuity, terminal value | 2 |
Discount Rates | Build-up, CAPM, WACC, TAB, control premium, DLOM, currency adjustment | 2 |
Statistics | Monte Carlo, decision trees, regression | 2 |
Cost Approach | Reproduction cost, replacement cost | 3 |
Market Approach | Comparable transactions, royalty capitalization | 3 |
Income Methods | Relief from Royalty, MPEEM, incremental cash flow | 4 |
Intellectual Property | Patent, trademark, copyright, trade secret | 5 |
Royalty Analysis | Benchmarking, 25% rule, adjustment | 6 |
Technology | Developed technology, software, data assets, platforms | 7 |
Customer-Related | Customer relationships, distribution network, non-compete | 8 |
Human Capital | Assembled workforce, key person | 9 |
Goodwill & PPA | Goodwill calculation, PPA waterfall | 10 |
Impairment | Goodwill & intangible impairment (ASC 350 / IAS 36) | 11 |
Monte Carlo | Simulation, sensitivity analysis | 15 |
Decision Trees | Backward induction | 16 |
Litigation | Lost profits, pre-judgment interest | 17 |
Transfer Pricing | CUP method, OECD guidelines | 18 |
Auditable — Every function returns ValuationResult with value, method, formula reference, assumptions, and step-by-step calculation breakdown
Textbook-accurate — All 124+ formulas verified against book example values with 1056 unit tests
AI-ready — MCP server (14 folded tools) and Skills for seamless AI agent integration
Complete coverage — All three valuation approaches (cost, market, income) across 19 chapters
Open source — MIT license, extensible, well-documented
# Install dev dependencies
pip install -e ".[dev]"
# Run tests
pytest
# Run with coverage
pytest --cov=src --cov-report=term-missing
# Lint
ruff check .
# Type check
mypy src/
# Regenerate the MCP stdio server from the canonical surface
python scripts/generate_mcp.pyAPI Reference: intangible-valuation.simonmak.com
MCP Server Guide: docs/mcp.md
AI Skills Guide: docs/skills.md
Intangible Asset Valuation: A Comprehensive Guide to Valuing Brands, IP, Technology, and Human Capital
Theory, Methods, Regulation, and Practice — Valuation in Practice Series by Ascent Partners
By Simon Mak, William Yuen, Paul Wu, Wayne Hu · 176 pages · 19 chapters · 3 appendices
@software{intangible_valuation_engine,
author = {Mak, Simon and Yuen, William and Wu, Paul and Hu, Wayne},
title = {Intangible Asset Valuation Engine},
year = {2026},
url = {https://github.com/simonplmak-cloud/intangible-valuation},
license = {MIT},
}Based on formulas from the Intangible Asset Valuation textbook.
MIT — see LICENSE for details.
Transfer pricing and litigation: the Comparable Uncontrolled Price arm's-length range and patent infringement damages with pre-judgment interest. Method selects the formula. Use for OECD transfer-pricing pricing of intercompany intangibles and for patent infringement damages awards. For royalty-rate benchmarking to set a rate use valuation_royalty_analysis; for the substantive asset valuation use valuation_ip or valuation_income_methods. Per method: cup_transfer_price needs controlled_price + uncontrolled_prices; patent_infringement_damages needs lost_profits_or_royalty + infringement_period + discount_rate + prejudgment_interest_rate. uncontrolled_prices must contain at least one comparable price for the arm's-length range. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: cup_transfer_price = Arm's-length range from comparable uncontrolled prices.; patent_infringement_damages = Lost profits or reasonable royalty plus prejudgment interest. | |
| discount_rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| controlled_price | No | Intercompany (controlled) price, in currency units. | |
| infringement_period | No | Infringement period in years. | |
| uncontrolled_prices | No | Comparable uncontrolled prices, in currency units. | |
| lost_profits_or_royalty | No | Annual lost profits or reasonable royalty, in currency units. | |
| prejudgment_interest_rate | No | Pre-judgment interest rate as a decimal. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial non-derivable behavior: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, parameters from other methods silently accepted and ignored, and errors returned for unknown methods or missing method-required parameters.
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?
Dense but front-loaded: purpose first, then routing alternatives, then per-method parameter requirements, then behavioral guarantees. Every sentence carries distinct information 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?
With an output schema present, return values need not be explained, yet the description still notes 2-decimal rounding. Combined with method routing, conditional parameter requirements, error behavior and purity guarantees, an agent has everything needed 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?
Although schema coverage is 100%, the description adds genuinely non-derivable semantics: the exact parameter set required per method, that uncontrolled_prices must contain at least one comparable, and that only 'method' is strictly required with the rest method-dependent and defaulted. This is more than the schema conveys.
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 domain (transfer pricing and patent infringement damages), names the two concrete methods (CUP arm's-length range, patent damages with pre-judgment interest), and explicitly distinguishes itself from sibling tools like valuation_royalty_analysis, valuation_ip and valuation_income_methods. An agent can identify the tool's scope without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use conditions (OECD transfer-pricing of intercompany intangibles; patent infringement damages awards) and names the alternative tools for adjacent tasks (royalty-rate benchmarking, substantive asset valuation). It routes the agent both toward and away from this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cost approach: depreciated reproduction cost from a cost breakdown and depreciated replacement cost with equivalent utility, both reduced by obsolescence. Method selects the formula. Use when no income or market evidence exists, or to corroborate income and market indications for internally developed intangibles. For income-based indications use valuation_income_methods; for market evidence use valuation_market_approach. Per method: reproduction_cost needs development_costs (optional: obsolescence_factors); replacement_cost needs current_cost (optional: obsolescence_factors). obsolescence_factors values are decimals that are summed and applied to the cost base; omit them for no obsolescence. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: reproduction_cost = Sum of cost categories less total obsolescence.; replacement_cost = Current cost of equivalent utility less obsolescence. | |
| current_cost | No | Current cost to replace the asset with equivalent utility, in currency units. | |
| development_costs | No | Cost breakdown by category, e.g. {"r_and_d": 1000000, "testing": 250000}, in currency units. | |
| obsolescence_factors | No | Obsolescence factors, e.g. {"functional": 0.10, "technological": 0.15, "economic": 0.05}. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, but the description adds substantial context beyond them: method-dependent parameter requirements, how obsolescence_factors are summed and applied, defaults for omitted parameters, acceptance and ignoring of other methods' parameters, no I/O or external calls, rounding to 2 decimals, and error behavior for unknown or missing required parameters. This is rich, specific disclosure.
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 front-loaded and every sentence carries necessary information: purpose, method routing, usage guidance, alternatives, per-method parameter rules, arithmetic behavior, and error handling. No filler or 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?
Given an output schema exists, the description need not explain return values, but it still adds helpful computation details (rounding, no I/O) and error behavior. Combined with the rich schema and annotations, 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 documents each parameter's meaning. The description adds significant conditional semantics beyond the schema: which parameters are required per method, that obsolescence_factors are decimals summed and applied to the cost base (omitting them means no obsolescence), and that parameters for unselected methods are accepted but ignored. That conditional guidance is valuable, though it does not add deep syntax 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?
States a specific valuation method and distinguishes it from siblings by naming valuation_income_methods and valuation_market_approach. An agent can tell exactly what this tool computes without opening any schema.
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 guidance ('no income or market evidence exists, or to corroborate income and market indications') and routes to the alternative tools for income and market indications. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Customer-related intangibles: customer relationships with attrition, distribution networks by channel profitability, and non-compete agreements on protected profits. Method selects the formula. Use for customer relationships, distribution networks, and non-compete assets; customer_relationships projects multi-period revenue with a retention rate. For the workforce and key-person assets use valuation_human_capital; for technology assets use valuation_technology. Per method: customer_relationships needs customer_count + avg_revenue_per_customer + retention_rate + profit_margin + discount_rate + projection_period; distribution_network needs channel_count + revenue_per_channel + channel_margin + useful_life + discount_rate; non_compete needs protected_revenue + profit_margin + term + enforcement_probability + discount_rate. retention_rate and enforcement_probability are in [0,1]; projection_period sets the number of discounted periods. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | Non-compete term in years. | |
| method | Yes | Formula to apply. Options: customer_relationships = Multi-period revenue net of attrition, discounted.; distribution_network = Channel revenue times margin over the useful life.; non_compete = Protected profit under an enforcement probability, discounted. | |
| useful_life | No | Useful life in years n. | |
| channel_count | No | Number of distribution channels. | |
| discount_rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| profit_margin | No | Profit margin as a decimal (0.20 = 20%). | |
| channel_margin | No | Channel profit margin as a decimal. | |
| customer_count | No | Number of customers. | |
| retention_rate | No | Annual customer retention rate, in [0,1]. | |
| projection_period | No | Projection horizon in years. | |
| protected_revenue | No | Annual revenue protected by the non-compete, in currency units. | |
| revenue_per_channel | No | Annual revenue per channel, in currency units. | |
| enforcement_probability | No | Probability the non-compete is enforceable, in [0,1]. | |
| avg_revenue_per_customer | No | Average annual revenue per customer, in currency units. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare a safe, idempotent, closed-world read, the description adds genuinely new behavioral context: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, extra method-specific parameters accepted and ignored, defaults applied, and a defined failure mode (unknown method or missing required parameter returns an error rather than a value).
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?
Front-loaded with purpose and routing, then the method-to-parameter mapping and behavioral notes. It is dense and mostly earns its length given 14 parameters, but repeats the method list ('Use for customer relationships, distribution networks, and non-compete assets') after already enumerating them, a small 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 multi-method calculator with 14 optional parameters and an existing output schema, the description covers what matters: method selection, per-method inputs, unit conventions, optionality rules, error behavior, and precision of returned values. Return-value explanation is correctly omitted since an output schema exists.
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 per-parameter meanings are already documented, but the description adds a mapping the schema cannot express: which of the 14 parameters each method consumes, plus the [0,1] ranges and which fields are required vs. ignored. This materially reduces invocation errors on a large parameter set, though individual parameter semantics largely restate 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 names the specific asset class (customer relationships, distribution networks, non-competes) and the three formulas the tool can apply, giving a concrete verb+resource picture. It also explicitly distinguishes itself from sibling tools (valuation_human_capital for workforce, valuation_technology for technology), so an agent can route correctly without opening 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?
It states when to use this tool, names the two nearest alternatives with the condition that selects each ('for the workforce and key-person assets use valuation_human_capital'), and explains the selection rule ('method selects the formula'). Exclusions and alternatives are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Construct discount and capitalization rates: build-up, CAPM, WACC, tax-amortization benefit, control premium, Finnerty DLOM, and currency/country-risk adjustment. Method selects the formula. Use to derive the rate that feeds every income-based method; build_up and capm estimate cost of equity, wacc blends debt and equity. For a cross-border rate with currency and country premia use method currency_adjusted; for the cash flows the rate discounts use valuation_time_value. Per method: build_up needs risk_free_rate + equity_risk_premium (optional: size_premium, industry_risk_premium, specific_risk_premium); capm needs risk_free_rate + beta + market_return; wacc needs equity_value + debt_value + cost_of_equity + cost_of_debt + tax_rate; tax_amortization_benefit needs discount_rate + useful_life + tax_rate + asset_value; control_premium needs minority_price + control_price; dlom_finnerty needs restricted_period + volatility + risk_free_rate; currency_adjusted needs base_rate (optional: currency_risk_premium, country_risk_premium). All rates and premiums are decimals; wacc requires both equity_value and debt_value, and dlom_finnerty volatility is an annualized decimal. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| beta | No | Systematic risk beta (market = 1.0). | |
| method | Yes | Formula to apply. Options: build_up = r = Rf + ERP + size + industry + specific premiums.; capm = r = Rf + beta * (Rm - Rf).; wacc = WACC = (E/V) Re + (D/V) Rd (1 - Tc).; tax_amortization_benefit = PV of the tax shield from amortizing the asset.; control_premium = (Control price - minority price) / minority price.; dlom_finnerty = Finnerty average-strike put option DLOM.; currency_adjusted = r = base rate + currency premium + country premium. | |
| tax_rate | No | Marginal tax rate as a decimal (0.25 = 25%). | |
| base_rate | No | Base discount rate before currency/country adjustment, as a decimal. | |
| debt_value | No | Market value of debt D, in currency units. | |
| volatility | No | Annualized volatility sigma as a decimal (0.30 = 30%). | |
| asset_value | No | Asset value the tax amortization benefit is computed on, in currency units. | |
| useful_life | No | Useful life in years n. | |
| cost_of_debt | No | Pre-tax cost of debt Rd as a decimal. | |
| equity_value | No | Market value of equity E, in currency units. | |
| size_premium | No | Small-size premium as a decimal. | |
| control_price | No | Controlling-interest share price or value, in currency units. | |
| discount_rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| market_return | No | Expected market return as a decimal (0.10 = 10%). | |
| cost_of_equity | No | Cost of equity Re as a decimal. | |
| minority_price | No | Minority (pre-control) share price or value, in currency units. | |
| risk_free_rate | No | Risk-free rate as a decimal (0.04 = 4%). | |
| restricted_period | No | Restricted / marketability period in years t. | |
| equity_risk_premium | No | Equity risk premium as a decimal (0.06 = 6%). | |
| country_risk_premium | No | Country risk premium as a decimal. | |
| currency_risk_premium | No | Currency risk premium as a decimal. | |
| industry_risk_premium | No | Industry risk premium as a decimal. | |
| specific_risk_premium | No | Company-specific risk premium as a decimal. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, but the description adds substantial non-structured behavior: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, parameters from other methods accepted and ignored, and error semantics for unknown methods or missing required params. None of this is in the 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?
Front-loaded with purpose, then per-method routing, then parameter mapping, then behavioral notes. The middle per-method parameter block is dense but every clause is load-bearing given seven methods. Slightly long, but 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?
With an output schema present, return-value explanation is unnecessary, and the description covers selection, per-method inputs, error behavior, and unit conventions. For a 23-parameter, 7-method tool this is complete enough for correct invocation.
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 real value beyond the schema by mapping each method to its required and optional parameters (e.g. wacc needs equity_value + debt_value + cost_of_equity + cost_of_debt + tax_rate) and flagging unit conventions like annualized volatility. This conditional dependency structure is not expressed in the flat 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 ('construct') and resource ('discount and capitalization rates') and enumerates the concrete formulas covered (build-up, CAPM, WACC, tax-amortization benefit, control premium, Finnerty DLOM, currency adjustment). It also explicitly separates itself from sibling valuation_time_value, so an agent can identify it without opening a schema.
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?
Gives explicit when-to-use guidance per method ('build_up and capm estimate cost of equity, wacc blends debt and equity'), names the condition that selects currency_adjusted, and routes the agent to valuation_time_value for the cash flows being discounted. This is genuine routing, not implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Goodwill and purchase price allocation: goodwill as the residual, a full PPA waterfall across identified intangibles, and useful-life estimation. Method selects the formula. Use for ASC 805 / IFRS 3 business combinations; purchase_price_allocation allocates consideration to identified intangibles with the remainder to goodwill. For subsequent goodwill and intangible impairment testing use valuation_impairment; for individual intangible fair values feed valuation_ip, valuation_technology or valuation_customer into the allocation. Per method: goodwill needs purchase_price + fair_value_net_identifiable_assets; purchase_price_allocation needs purchase_price + tangible_assets_fv + identified_intangibles (optional: liabilities_fv); useful_life needs asset_type (optional: legal_life, economic_factors, obsolescence_rate). identified_intangibles values are summed before goodwill is taken as the residual; liabilities_fv reduces net identifiable assets. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: goodwill = Goodwill = purchase price - fair value of net identifiable assets.; purchase_price_allocation = Allocate consideration across identified intangibles.; useful_life = Estimate economic/legal useful life of an intangible. | |
| asset_type | No | Asset type, e.g. "patent", "trademark", "software", "customer_list". | |
| legal_life | No | Legal protection period in years (overrides the asset-type default). | |
| liabilities_fv | No | Fair value of assumed liabilities, in currency units. | |
| purchase_price | No | Total consideration / purchase price, in currency units. | |
| economic_factors | No | Economic adjustment factors, e.g. {"market_growth": 0.05, "competition": 0.4, "tech_change": 0.1}. | |
| obsolescence_rate | No | Annual obsolescence rate as a decimal. | |
| tangible_assets_fv | No | Fair value of tangible assets, in currency units. | |
| identified_intangibles | No | Identified intangibles, each {name, value} or {name, fair_value}. | |
| fair_value_net_identifiable_assets | No | Fair value of net identifiable assets, in currency units. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavioral context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, method-specific parameters for other methods accepted and ignored, and an explicit error contract for unknown methods or missing required params.
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?
Front-loaded with purpose, then per-method requirements, then the error/no-I/O contract. It is long, but for a 10-parameter multi-method tool nearly every sentence carries routing or contract information; the opening clause mildly restates the title.
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 an output schema present the description need not explain returns, and it still covers method selection, required/optional params per method, residual arithmetic, defaults, error behavior, and sibling routing – everything an agent needs to invoke this 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 baseline is 3, but the description adds real semantics beyond the schema: which params each method requires, that identified_intangibles values are summed before goodwill is taken as residual, and that liabilities_fv reduces net identifiable assets. Only the operational detail of the economic_factors/obsolescence_rate inputs is left thin.
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+resource (goodwill as residual, PPA waterfall, useful-life estimation) and explicitly distinguishes itself from valuation_impairment for downstream impairment testing. An agent can route between siblings without opening any schema.
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?
Gives explicit when-to-use (ASC 805 / IFRS 3 business combinations), names the alternative for impairment (valuation_impairment), and routes feeding tools (valuation_ip/technology/customer) into the allocation. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Human capital: assembled-workforce value by replacement cost and key-person value from revenue contribution and departure risk. Method selects the formula. Use for assembled workforce and key-person intangibles; assembled_workforce nets training and attrition into a replacement cost. For customer-related assets use valuation_customer; for technology assets use valuation_technology. Per method: assembled_workforce needs employee_count + avg_replacement_cost + training_cost + productivity_factor + attrition_rate; key_person needs revenue_contribution + replacement_cost + departure_probability + discount_rate. attrition_rate is in [0,1]; productivity_factor scales the replacement cost (1.0 = parity). Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: assembled_workforce = Replacement cost including training, net of attrition.; key_person = Revenue contribution and replacement cost under departure risk. | |
| discount_rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| training_cost | No | Training cost per employee, in currency units. | |
| attrition_rate | No | Annual attrition rate, in [0,1]. | |
| employee_count | No | Number of employees. | |
| replacement_cost | No | Cost to replace the key person, in currency units. | |
| productivity_factor | No | Productivity factor on replacement cost (1.0 = parity). | |
| avg_replacement_cost | No | Average cost to replace one employee, in currency units. | |
| revenue_contribution | No | Annual revenue contribution, in currency units. | |
| departure_probability | No | Annual probability the key person departs, in [0,1]. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds material context they cannot: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, cross-method parameters are silently ignored, and invalid input returns an error rather than a value. This is exactly the behavioral detail an agent needs to predict outcomes.
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?
Front-loaded with purpose then alternatives then per-method requirements, and every sentence carries information. It is dense and long, but with 10 parameters and two methods the length is largely earned; a slightly tighter phrasing could reduce it further.
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 two-method computational tool with 10 params and an output schema, the description covers selection, per-method inputs, error behavior, and result formatting. Nothing an agent needs to invoke it 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?
Although schema coverage is already 100%, the description adds method-to-parameter mapping (which of the 10 params each method requires) and semantic constraints (attrition_rate in [0,1], productivity_factor 1.0 = parity), plus the key rule that only method is required and the rest are method-dependent.
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 resource (human capital intangibles) and the two distinct computations (assembled-workforce replacement cost, key-person value), then explicitly disambiguates from siblings valuation_customer and valuation_technology. An agent can tell exactly what this tool computes without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions ('Use for assembled workforce and key-person intangibles') plus named alternatives for adjacent asset classes. It goes further by stating that other methods' parameters are accepted-and-ignored and that unknown methods or missing required params error out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Impairment testing: goodwill impairment and intangible impairment under US GAAP (ASC 350) or IFRS (IAS 36). Method selects the formula. Use for annual or triggering-event impairment testing; goodwill_impairment compares a reporting unit's carrying value with its fair value. To compute the initial goodwill or allocation use valuation_goodwill_ppa; for the underlying asset fair values use the relevant asset-type tool. Per method: goodwill_impairment needs carrying_value + fair_value (optional: reporting_unit, standard); intangible_impairment needs carrying_value (optional: fair_value, recoverable_amount, standard). fair_value is required for ASC350; recoverable_amount is required for IAS36. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: goodwill_impairment = Impairment = carrying value - fair value (if positive).; intangible_impairment = Impairment of an intangible under ASC 350 or IAS 36. | |
| standard | No | Accounting standard: ASC350 for US GAAP, IAS36 for IFRS. | |
| fair_value | No | Fair value of the reporting unit or asset, in currency units. | |
| carrying_value | No | Carrying value of the reporting unit or asset, in currency units. | |
| reporting_unit | No | Reporting unit name (goodwill only). | |
| recoverable_amount | No | Recoverable amount (IAS 36), in currency units. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, but the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, foreign-method parameters accepted and ignored, and specific error conditions (unknown method, missing required parameter).
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?
Dense but front-loaded: purpose and method selection come first, then per-method parameter requirements, then behavioral notes. Nearly every sentence earns its place, though the length is borderline for a single-purpose calculator.
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 an output schema exists, return values need not be explained, yet the description still notes 2-decimal rounding. Combined with method-dependent parameter rules and error behavior, an agent has everything needed 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 coverage is 100%, so per-field types are already documented, but the description adds cross-parameter dependency logic the schema cannot express: which parameters each method requires, that fair_value is required for ASC350 and recoverable_amount for IAS36, and that only method is mandatory. This meaningfully exceeds 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?
States a specific verb and resource (impairment testing of goodwill and intangibles) and immediately scopes it to US GAAP ASC 350 / IFRS IAS 36. It also differentiates from siblings by naming valuation_goodwill_ppa for initial goodwill and pointing to asset-type tools for underlying fair values.
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 it (annual or triggering-event impairment testing), which method to pick for which case, and names the alternatives (valuation_goodwill_ppa, relevant asset-type tool) with the condition that selects each. Routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Income approach: relief from royalty, multi-period and single-period excess earnings, incremental cash flow, and contributory asset charges. Method selects the formula. Use for the income-approach arithmetic: relief_from_royalty for IP with observable royalty rates, and excess earnings (mpeem or single_period_excess_earnings) for the residual intangible. For a complete asset-specific valuation of customer, technology, IP or workforce assets, prefer the dedicated valuation_customer, valuation_technology, valuation_ip and valuation_human_capital tools. For royalty-rate inputs use valuation_royalty_analysis; for asset-specific income valuations use valuation_customer, valuation_technology, valuation_ip or valuation_human_capital; for cost or market indications use valuation_cost_approach and valuation_market_approach. Per method: relief_from_royalty needs revenue_projections + royalty_rate + discount_rate + tax_rate + useful_life (optional: tab_enabled); mpeem needs cash_flow_projections + contributory_asset_charges + discount_rate + tax_rate (optional: tab_enabled); single_period_excess_earnings needs normalized_earnings + contributory_asset_charges + capitalization_rate; incremental_cashflow needs cash_flows_with + cash_flows_without + discount_rate; contributory_asset_charges needs assets. cash_flow_projections and contributory_asset_charges must be period-aligned; cash_flows_with and cash_flows_without must be equal length. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| assets | No | Contributory assets, each {value, return_rate}. | |
| method | Yes | Formula to apply. Options: relief_from_royalty = PV of after-tax royalties avoided by ownership.; mpeem = PV of excess earnings after contributory asset charges.; single_period_excess_earnings = Capitalize one period of excess earnings.; incremental_cashflow = PV of cash flows with the asset minus without it.; contributory_asset_charges = Total contributory asset charges. | |
| tax_rate | No | Marginal tax rate as a decimal (0.25 = 25%). | |
| tab_enabled | No | Whether to include the tax amortization benefit in the result. | |
| useful_life | No | Useful life in years n. | |
| royalty_rate | No | Royalty rate as a decimal (0.05 = 5% of revenue). | |
| discount_rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| cash_flows_with | No | Cash flows per period with the asset, in currency units. | |
| cash_flows_without | No | Cash flows per period without the asset, in currency units. | |
| capitalization_rate | No | Capitalization rate as a decimal (0.15 = 15%). | |
| normalized_earnings | No | Single-period normalized earnings, in currency units. | |
| revenue_projections | No | Projected revenue per period t=1..n, in currency units. | |
| cash_flow_projections | No | Projected after-tax cash flows per period t=1..n, in currency units. | |
| contributory_asset_charges | No | Contributory asset charge per period t=1..n, in currency units. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-open-world, but the description goes well beyond them: it discloses that the tool is pure arithmetic with no I/O or external calls, that results are rounded to 2 decimals, that off-method parameters are silently accepted and ignored, and that an unknown method or a missing required param yields an error rather than a value. These are exactly the behavioral facts an agent cannot infer from structured fields.
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?
Dense and front-loaded: purpose, then routing, then per-method parameter requirements, then behavior. Every sentence carries information, though the parameter-dependency walkthrough is long and somewhat list-like, making it heavier than the routing content that precedes it.
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?
An output schema exists, so return values need not be explained, and the description still notes the 2-decimal rounding. Combined with complete schema coverage, explicit method selection, parameter dependencies, alignment rules, and error behavior, an agent has everything needed to invoke it correctly for any of the five methods.
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, but the description adds cross-parameter constraints the schema cannot express: which parameters each method requires, that method is the only universally required field, that others are method-dependent and should be omitted, and the alignment invariants ('period-aligned,' 'equal length'). This is genuine added semantic value over per-field 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?
Opens with a specific domain ('Income approach') and enumerates the five concrete formulas the tool computes, in a single clear verb+resource framing. It also explicitly distinguishes the family of sibling tools (valuation_cost_approach, valuation_market_approach, valuation_customer, etc.) so an agent can place it in the tool taxonomy without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing rules: 'relief_from_royalty for IP with observable royalty rates,' 'excess earnings for the residual intangible,' and a full set of when-not/prefer alternatives ('prefer the dedicated valuation_customer, valuation_technology, valuation_ip and valuation_human_capital tools,' plus royalty and cost/market pointers). An agent can select this tool vs any sibling from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Intellectual property: risk-adjusted patent value, trademark/brand value, copyright income value, and trade-secret value under secrecy risk. Method selects the formula. Use to value a specific IP right; patent weights projected cash flows by probability of success, trademark uses brand strength to set the royalty. For technology, software, data, and platform assets use valuation_technology; for customer and workforce assets use valuation_customer and valuation_human_capital. Per method: patent needs remaining_life + cash_flow_projections + probability_of_success + discount_rate (optional: comparable_license_rates); trademark needs revenue + profit_margin + brand_strength_index + discount_rate + useful_life (optional: brand_method); copyright needs projected_revenue + useful_life + discount_rate + royalty_rate; trade_secret needs development_cost + economic_life + competitive_advantage_period + discount_rate + secrecy_probability. cash_flow_projections for patent run over remaining_life. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: patent = Risk-adjusted DCF over the patent's remaining life.; trademark = Brand value by relief-from-royalty or excess earnings.; copyright = PV of expected copyright royalty income.; trade_secret = Value under secrecy risk over the economic life. | |
| revenue | No | Annual revenue attributable to the asset, in currency units. | |
| useful_life | No | Useful life in years n. | |
| brand_method | No | Trademark method: relief_from_royalty adjusts the royalty rate by brand strength; excess_earnings capitalizes excess earnings. | |
| royalty_rate | No | Royalty rate as a decimal (0.05 = 5% of revenue). | |
| discount_rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| economic_life | No | Economic life in years. | |
| profit_margin | No | Profit margin as a decimal (0.20 = 20%). | |
| remaining_life | No | Remaining legal/economic life of the patent in years. | |
| development_cost | No | Development or acquisition cost, in currency units. | |
| projected_revenue | No | Projected annual revenue subject to the copyright royalty, in currency units. | |
| secrecy_probability | No | Probability the trade secret remains secret, in [0,1]. | |
| brand_strength_index | No | Brand strength index on a 0-100 scale (75 = strong). | |
| cash_flow_projections | No | Projected after-tax cash flows per period t=1..n, in currency units. | |
| probability_of_success | No | Probability of technical and commercial success, in [0,1]. | |
| comparable_license_rates | No | Comparable license royalty rates as decimals. | |
| competitive_advantage_period | No | Years the competitive advantage is expected to persist. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, and the description adds important operational traits beyond them. It states that computation is pure arithmetic with no I/O or external calls, results are rounded to two decimals, irrelevant method parameters are ignored, and missing required parameters or an unknown method produce an error rather than a value.
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 front-loaded with purpose and usage before diving into method-specific parameter mappings and behavioral notes. It is longer than average but mostly earns its length by encoding method dependencies and error behavior that are not available in the schema alone.
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 17-parameter tool with rich annotations and an output schema, the description supplies all critical context an agent needs: when to use it versus siblings, method-specific required parameters, ignored-parameter behavior, error conditions, and return-value precision.
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 schema coverage is 100%, the description adds method-level parameter semantics not captured by the field descriptions. It specifies exactly which parameters each method requires and which are optional, and clarifies that only method is required while other parameters are method-dependent and ignored if supplied for the wrong method.
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: valuing a specific IP right across patent, trademark, copyright, and trade-secret methods. It distinguishes itself from siblings by explicitly routing technology/software/data/platform assets to valuation_technology and customer/workforce assets to valuation_customer and valuation_human_capital.
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?
It gives explicit when-to-use guidance and names the correct alternative tools for adjacent asset classes. The condition for selecting this tool is clear: use it for a specific IP right, not for technology, customer, or human-capital assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market approach: value from comparable transaction revenue multiples or capitalize a royalty stream into a perpetuity value. Method selects the formula. Use when reliable comparable transactions or royalty rates exist for the subject asset. For income-based excess earnings use valuation_income_methods; for royalty-rate selection and adjustment use valuation_royalty_analysis. Per method: comparable_transactions needs comparables + subject_revenue (optional: adjustments); royalty_capitalization needs revenue + royalty_rate + discount_rate. Each comparable is {revenue, multiple}; comparable_transactions applies the comparable multiple to subject_revenue. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: comparable_transactions = Subject revenue times the median comparable multiple.; royalty_capitalization = Value = (revenue * royalty rate) / discount rate. | |
| revenue | No | Annual revenue attributable to the asset, in currency units. | |
| adjustments | No | Optional multiplicative adjustments, e.g. {"size": 0.9, "growth": 1.1}. | |
| comparables | No | Comparable transactions, each {revenue, multiple}. | |
| royalty_rate | No | Royalty rate as a decimal (0.05 = 5% of revenue). | |
| discount_rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| subject_revenue | No | Subject company revenue, in currency units. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds that the tool is pure arithmetic with no I/O or external calls, returns values rounded to 2 decimals, ignores parameters belonging to other methods, and errors on unknown methods or missing required method parameters. 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?
The description is dense but front-loaded and structured: purpose, usage condition, alternatives, per-method parameters, and behavioral notes. Every sentence contributes necessary invocation context, and the length is justified by the tool's method-dependent complexity.
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?
Annotations and an output schema are present, and the description still supplies method selection, parameter mapping, ignored-parameter behavior, and error conditions. It is complete enough for an agent to call the tool correctly without opening the schema.
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 already 100%, but the description adds method-dependent conditional semantics: comparable_transactions needs comparables plus subject_revenue, royalty_capitalization needs revenue plus royalty_rate and discount_rate, each comparable is {revenue, multiple}, and other method parameters are accepted and ignored. This meaningfully extends beyond the field-level schema 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?
States a specific valuation function: market approach using comparable transaction multiples or royalty capitalization, with the method selecting the formula. It explicitly distinguishes itself from valuation_income_methods and valuation_royalty_analysis, so the agent can identify scope and sibling boundaries.
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?
Gives an explicit when-to-use condition: reliable comparable transactions or royalty rates exist. It also names the alternative tools for income-based excess earnings and royalty-rate selection, and spells out the per-method parameter requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Royalty analysis: benchmark royalty-rate ranges by IP type and industry, adjust a base rate for deal factors, and apply the 25% rule of thumb. Method selects the formula. Use to select and support a royalty rate before a relief-from-royalty or royalty-capitalization valuation. To apply the chosen rate in a valuation use valuation_income_methods (relief_from_royalty) or valuation_market_approach (royalty_capitalization); for transfer-pricing pricing use valuation_compliance. Per method: benchmark needs ip_type + industry (optional: comparable_database); adjust needs base_royalty_rate + adjustment_factors; twenty_five_percent_rule needs licensee_expected_profit (optional: profit_attribution_to_ip). adjustment_factors multiply the base rate, so values above 1.0 raise the rate. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: benchmark = Benchmark royalty-rate range by IP type and industry.; adjust = Adjusted rate = base rate * product of factors.; twenty_five_percent_rule = Royalty = licensee profit * IP attribution * 25%. | |
| ip_type | No | Intellectual-property type, e.g. "patent", "trademark", "copyright", "trade_secret". | |
| industry | No | Industry, e.g. "software", "pharmaceutical". | |
| base_royalty_rate | No | Base royalty rate before adjustment, as a decimal (0.05 = 5%). | |
| adjustment_factors | No | Multiplicative adjustment factors, e.g. {"profitability": 1.1, "market": 0.9}. | |
| comparable_database | No | Optional comparable licenses, each {rate} or {royalty_rate}. | |
| licensee_expected_profit | No | Licensee expected profit, in currency units. | |
| profit_attribution_to_ip | No | Fraction of profit attributable to the IP, in [0,1]. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds valuable context beyond that: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, errors on unknown method or missing required parameters, and other method parameters being accepted and ignored.
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?
Front-loaded with purpose and usage, then method-specific parameters and behavior. Dense but every sentence earns its place; it could be slightly more scannable with bullets, but there is 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?
Given 3 methods, 8 parameters, and an output schema, the description covers required and optional parameters per method, error behavior, rounding, and routing to sibling tools. It is complete enough for an agent to invoke 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?
Schema description coverage is 100% so the baseline is 3, but the description adds method-to-parameter mapping (benchmark needs ip_type and industry; adjust needs base_royalty_rate and adjustment_factors; twenty_five_percent_rule needs licensee_expected_profit) and explains that adjustment factors are multiplicative. This meaningfully clarifies which parameters matter for each method.
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 specific verbs and resources: benchmark royalty-rate ranges, adjust a base rate, apply the 25% rule. It explicitly names sibling tools to distinguish itself from valuation_income_methods and valuation_market_approach, so an agent can identify its role without opening either schema.
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 it (select/support a royalty rate before a relief-from-royalty or royalty-capitalization valuation) and names the alternative tools for applying the rate and for transfer-pricing use. No inference is left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uncertainty analysis: Monte Carlo valuation, Monte Carlo sensitivity ranking, decision-tree expected values, and one-at-a-time sensitivity analysis. Method selects the formula. Use to quantify and stress the uncertainty around a point valuation; monte_carlo simulates all listed inputs, monte_carlo_sensitivity ranks the drivers. For a single deterministic point value use the relevant valuation tool; sensitivity_analysis varies one parameter of a core function only. Per method: monte_carlo needs input_distributions (optional: iterations, seed); monte_carlo_sensitivity needs base_params + distributions (optional: iterations, seed); decision_tree needs tree; sensitivity_analysis needs function_name + parameter_name + parameter_range + fixed_parameters. monte_carlo_sensitivity requires iterations between 1000 and 100000. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed for reproducible simulations. | |
| tree | No | Decision tree {"nodes": [...], "edges": [...]}; node types decision, chance, terminal. | |
| method | Yes | Formula to apply. Options: monte_carlo = Simulate all listed inputs, sum-based valuation.; monte_carlo_sensitivity = Rank parameters by their impact on the valuation.; decision_tree = Backward induction over a decision tree.; sensitivity_analysis = One-at-a-time sensitivity of a core function. | |
| iterations | No | Simulation iterations; monte_carlo_sensitivity requires 1000-100000. | |
| base_params | No | Base values for all parameters, including those held fixed. | |
| distributions | No | Map of parameter name to {distribution, params} for the simulated inputs. | |
| function_name | No | Core function to vary, e.g. "present_value", "capm_discount_rate", "wacc". | |
| parameter_name | No | Name of the parameter to vary. | |
| parameter_range | No | Values to test for the varied parameter. | |
| fixed_parameters | No | Values for all other parameters, held constant. | |
| input_distributions | No | Inputs to simulate, each {name, distribution, params}; distribution is normal (mean, std), uniform (low, high) or triangular (low, high, mode). |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, non-destructive read, and the description adds substantial extra behavior: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, parameters for other methods are accepted and ignored, and that an unknown method or a missing required parameter returns an error instead of a value.
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?
It is front-loaded with the purpose, then alternatives, then per-method parameter requirements, then behavioral notes. It is long but dense, with only minor redundancy ('uncertainty analysis' restated as 'quantify and stress the uncertainty').
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 an output schema present, return-value details are unnecessary, and the description still covers the hard parts: conditional per-method parameters, defaults, iteration bounds, error semantics, and the ignored-extra-parameter behavior. 11 parameters with only one required are adequately disambiguated.
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 schema documents each field individually and the baseline would be 3. The description goes beyond this by mapping which parameters are required per method and by clarifying that only 'method' is required while the rest are method-dependent and should be supplied/omitted accordingly, which the schema cannot express on its own.
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 names the resource (uncertainty analysis) and enumerates the four concrete methods it computes (Monte Carlo valuation, Monte Carlo sensitivity ranking, decision-tree expected values, one-at-a-time sensitivity), with method selecting the formula. It also differentiates itself from siblings by stating that a single deterministic point value belongs to 'the relevant valuation tool' rather than here.
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?
It gives explicit routing: use this to quantify/stress uncertainty around a point valuation; use a valuation tool for a deterministic point value; use sensitivity_analysis only to vary one parameter of a core function. It further states per-method requirements (which parameters each method needs) and the 1000-100000 iteration bound for monte_carlo_sensitivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Technology assets: developed technology under life-cycle risk, software under cost and income, data assets with a quality adjustment, and platforms with network effects. Method selects the formula. Use for developed technology, software, data, and platform intangibles; developed_technology and software blend cost and income evidence. For patents, trademarks, copyrights, and trade secrets use valuation_ip; for customer relationships use valuation_customer. Per method: developed_technology needs rd_costs + life_cycle_stage + competitive_advantage + discount_rate + cash_flow_projections; software needs development_cost + maintenance_cost + user_base + revenue_model + useful_life + discount_rate; data_asset needs acquisition_cost + quality_score + revenue_contribution + useful_life + discount_rate; platform needs network_size + network_effects_coefficient + revenue_per_user + growth_rate + discount_rate. cash_flow_projections for developed_technology run over the remaining useful life. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: developed_technology = Cost and income value adjusted for life-cycle stage.; software = Software value from development, maintenance, and revenue.; data_asset = Quality-adjusted revenue contribution plus acquisition cost.; platform = Network-effect revenue grown and discounted. | |
| rd_costs | No | Cumulative research and development costs, in currency units. | |
| user_base | No | Number of users. | |
| growth_rate | No | Per-period growth rate as a decimal (0.03 = 3%). | |
| useful_life | No | Useful life in years n. | |
| network_size | No | Number of network participants. | |
| discount_rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| quality_score | No | Data quality score, in [0,1]. | |
| revenue_model | No | Revenue model, e.g. {"subscription_price": 20, "paying_users": 10000}. | |
| acquisition_cost | No | Cost to acquire the data, in currency units. | |
| development_cost | No | Development or acquisition cost, in currency units. | |
| life_cycle_stage | No | Life-cycle stage, e.g. "growth", "mature", "decline". | |
| maintenance_cost | No | Annual maintenance cost, in currency units. | |
| revenue_per_user | No | Revenue per user, in currency units. | |
| revenue_contribution | No | Annual revenue contribution, in currency units. | |
| cash_flow_projections | No | Projected after-tax cash flows per period t=1..n, in currency units. | |
| competitive_advantage | No | Years of competitive advantage. | |
| network_effects_coefficient | No | Network-effects coefficient scaling revenue with network size. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, string-method errors, missing-required-param errors, and the notable rule that parameters belonging to other methods are accepted and ignored. That last point is behavior an agent cannot infer from the 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?
Front-loaded with purpose and routing, then the per-method parameter lists. Efficient and every sentence carries content, but the dense run-on parameter enumeration is long and slightly harder to scan than it could be.
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 an 18-parameter, method-dispatching calculator with an output schema, the description covers routing, per-method inputs, error behavior, rounding, and extraneous-parameter handling. Return values need no explanation since an output schema exists.
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 schema coverage is 100%, the schema does not say which parameters each method requires. The description supplies the exact method-to-parameter mapping for all four methods, notes that only method is required, that others have documented defaults, and that foreign-method params are ignored.
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 names the specific resource (technology intangibles) and enumerates the four valuation methods it covers, then explicitly distinguishes itself from valuation_ip and valuation_customer by naming those siblings. An agent can route correctly without opening any schema.
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?
It states when to use this tool (developed technology, software, data, platform intangibles) and gives explicit when-not guidance by naming the correct alternatives for patents/trademarks/copyrights/trade secrets (valuation_ip) and customer relationships (valuation_customer).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time value of money: discount or compound a single sum, value level and growing annuities and perpetuities, and compute a terminal value by Gordon growth or exit multiple. Method selects the formula. Use to move cash flows through time or to value a terminal value in a DCF; combine with a rate from valuation_discount_rate. For uneven multi-period cash flows use valuation_income_methods; for rate construction use valuation_discount_rate. Per method: present_value needs future_value + discount_rate + periods; future_value needs present_value + discount_rate + periods; annuity_pv needs payment + discount_rate + periods; perpetuity_pv needs payment + discount_rate; growing_annuity_pv needs payment + discount_rate + growth_rate + periods; terminal_value_gordon_growth needs final_year_cashflow + perpetual_growth_rate + discount_rate; terminal_value_exit_multiple needs final_year_cashflow + exit_multiple. Rates and growth are decimals (0.10 = 10%); for terminal_value_gordon_growth the discount rate must exceed the perpetual growth rate. Only method is required; other parameters are method-dependent, so supply those named for the selected method and omit the rest (documented defaults apply where defined). Pure arithmetic: no I/O and no external calls, and numeric results are returned rounded to 2 decimals. Parameters belonging to other methods of this tool are accepted and ignored. Supplying an unknown method, or leaving unset a parameter that the chosen method requires, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | Formula to apply. Options: present_value = PV = FV / (1 + r)^n.; future_value = FV = PV * (1 + r)^n.; annuity_pv = PV = PMT * [1 - (1 + r)^-n] / r.; perpetuity_pv = PV = PMT / r.; growing_annuity_pv = PV of a constant-growth annuity.; terminal_value_gordon_growth = TV = FCF * (1 + g) / (r - g).; terminal_value_exit_multiple = TV = FCF * exit multiple. | |
| payment | No | Recurring payment per period, in currency units. | |
| periods | No | Number of periods n (non-negative). | |
| growth_rate | No | Per-period growth rate as a decimal (0.03 = 3%). | |
| future_value | No | Future cash amount to discount, in currency units. | |
| discount_rate | No | Per-period discount rate as a decimal (0.10 = 10%). | |
| exit_multiple | No | Exit multiple applied to the final-year cash flow (e.g. 8.0 for 8x). | |
| present_value | No | Present amount to compound, in currency units. | |
| final_year_cashflow | No | Final-year projected cash flow (FCF), in currency units. | |
| perpetual_growth_rate | No | Perpetual growth rate g as a decimal; must be below discount_rate for Gordon growth. |
| Name | Required | Description |
|---|---|---|
| error | No | Error message when the call fails. |
| steps | No | Intermediate calculation steps for traceability (one string per step). |
| value | Yes | Computed valuation, rate, or metric. |
| method | No | Formula / method name that produced the result. |
| assumptions | No | Modelling assumptions applied (list of strings or key/value object). |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds substantial behavior beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, extra method parameters accepted and ignored, and an explicit error contract (unknown method or missing required parameter returns an error instead of a value). It also states the Gordon-growth constraint that the discount rate must exceed the perpetual growth rate.
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?
Front-loaded with the capability statement and routing rules before drilling into the per-method parameter listing, so the important information comes first. It is dense and quite long, but nearly every clause carries distinct information; only the per-method list edges toward verbosity against a 100%-covered 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?
For a single-entry, method-dispatched calculator with an output schema present, the description covers selection, parameter requirements, units, edge constraints, and error behavior. An agent has everything needed to call it correctly on any method without further inference.
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, but the description adds genuine value the schema cannot: a per-method parameter dependency map (present_value needs future_value + discount_rate + periods, perpetuity_pv needs only payment + discount_rate, etc.) and the decimal convention (0.10 = 10%). The only remaining gap is that it does not restate the enum-option formulas, which the schema already carries.
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 domain (time value of money) and enumerates the exact computations it performs: discount/compound a single sum, value level and growing annuities and perpetuities, and terminal value by Gordon growth or exit multiple. It also names the siblings it is not (valuation_income_methods, valuation_discount_rate), so an agent can separate it from alternatives without opening any schema.
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 it ('to move cash flows through time or to value a terminal value in a DCF'), how to pair it ('combine with a rate from valuation_discount_rate'), and routes the agent elsewhere for adjacent needs ('for uneven multi-period cash flows use valuation_income_methods; for rate construction use valuation_discount_rate'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.4valuation_compliance2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_cost_approach2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_customer2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_discount_rate2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_goodwill_ppa2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_human_capital2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_impairment2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_income_methods2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_ip2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_market_approach2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_royalty_analysis2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_simulation2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_technology2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"valuation_time_value2 fields changedOutput schema / properties / steps / descriptionPrevious value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."Output schema / properties / steps / items / typeRemoved value: -"object"v0.1.0valuation_compliancevaluation_cost_approachvaluation_customervaluation_discount_ratevaluation_goodwill_ppavaluation_human_capitalvaluation_impairmentvaluation_income_methodsvaluation_ipvaluation_market_approachvaluation_royalty_analysisvaluation_simulationvaluation_technologyvaluation_time_valueScored across 14 tools
Each tool targets a distinct valuation area (impairment, rate construction, cost/market/income approaches, asset types, goodwill, royalty, simulation, compliance), and descriptions cross-reference alternatives. Minor overlap exists between general tools like valuation_income_methods and dedicated asset tools (valuation_ip, valuation_technology, valuation_customer), but the guidance to prefer dedicated tools when applicable reduces misselection.
All 14 tools use the same valuation_ prefix followed by a descriptive snake_case name. The pattern is predictable and unambiguous.
Fourteen tools are well within a reasonable range for a broad intangible asset valuation domain. Each tool is a multi-method dispatcher, so the effective functional surface is large but organized into coherent buckets.
The surface covers the full valuation lifecycle: rate construction, time value, cost/market/income approaches, all major intangible asset classes, goodwill PPA, impairment, royalty analysis, simulation, and compliance. No obvious operational gap exists for the stated domain.
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.
Institutional hotel valuations in seconds: NOI/cap rate, USALI P&L, IRR/MOIC, markets, compsets.
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.
IFRS engine: 31 standards, 21 tools. Journal entries, XBRL tags, ECL, CGU impairment, deferred tax.
