Intangible asset valuation: 14 tools, 124+ formulas for IP, technology, goodwill, PPA, impairment.
Scored across 14 tools
Tools are organized by asset class and valuation approach (income, cost, market), with metric-level entry points for discount rates and time value. Some boundary overlap exists between valuation_income_methods/generic methods and asset-specific tools (customer, technology, IP), but descriptions clearly delineate when to use each. An agent should generally select the correct tool, though occasional hesitation is possible.
All tool names follow a consistent snake_case pattern with the 'valuation_' prefix followed by a domain noun (e.g., valuation_income_methods, valuation_cost_approach). This predictable convention makes the set easy to navigate.
With 14 tools, the set is well-scoped to cover major intangible asset valuation domains and cross-cutting analytics (discount rates, time value, simulation) without redundancy. Each tool corresponds to a distinct valuation area, earning its place.
The surface covers all three valuation approaches (income, market, cost), asset-specific methods for IP, technology, customer, and human capital, plus impairment, PPA, compliance, and uncertainty analysis. No obvious gaps in lifecycle or methodological coverage for intangible valuation.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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 (≥ 0). | |
| 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 (e.g. 0.05 = 5%). |
| 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish a safe read-only, idempotent, closed-world profile, yet the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, rounding to 2 decimals, cross-method parameters accepted and ignored, and error-on-unknown-method or missing-required-parameter behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded, leading with purpose then alternatives then method-specific params. Slightly repetitive around the method-dependency of parameters, but every clause carries operational information for a complex tool.
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?
Output schema exists so return values need no explanation, and the description covers the remaining gaps: method selection, method-dependent required inputs, decimal-format convention for rates, default handling, and failure modes. Complete for a 7-parameter computational tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so per-parameter meanings are already documented, but the description adds cross-parameter semantics the schema cannot express: the per-method required parameter sets, that only method is required with the rest method-dependent, and that unspecified defaults apply. It stops short of fully detailing every interaction but adds real value.
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 with concrete subtasks: CUP arm's-length range and patent infringement damages with pre-judgment interest. It names the sibling tools it is not (valuation_royalty_analysis, valuation_ip, valuation_income_methods), so an agent can distinguish it without inspecting 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?
Explicitly says when to use it (OECD transfer-pricing pricing of intercompany intangibles; patent infringement damages awards) and routes the agent away for royalty-rate benchmarking and substantive asset valuation, naming the correct alternatives.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| 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 behavior beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, parameters for other methods being accepted and ignored, and explicit failure modes (unknown method or missing method-required parameter returns an error). That is exactly the kind of context annotations can't carry.
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, usage, alternatives, then per-method parameter rules, then arithmetic/error behavior. The decimal-convention sentence ('rates and premiums are decimals') is slightly redundant since no rate parameter exists, but overall little waste.
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 4-param, nested-object, method-dispatched calculator with an output schema, the description covers everything an agent needs: conditional parameter requirements, defaults, numeric conventions, error behavior, and delegation to siblings. Return values are correctly left to the output 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?
Despite 100% schema coverage, the schema cannot express the conditional, method-dependent requirements. The description supplies them: reproduction_cost needs development_costs, replacement_cost needs current_cost, obsolescence_factors is optional and its values are summed decimals applied to the cost base with omission meaning no obsolescence, and only method is required.
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: computes the cost approach (depreciated reproduction cost and depreciated replacement cost), with obsolescence reduction. It explicitly names the two competing approaches (valuation_income_methods, valuation_market_approach), so an agent can place it among siblings 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?
Gives explicit when-to-use ('no income or market evidence exists', or to corroborate indications for internally developed intangibles) and names the exact alternative tools for income and market cases. 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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | Non-compete term in years (≥ 0). | |
| 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 (integer ≥ 1). | |
| channel_count | No | Number of distribution channels (integer ≥ 0). | |
| 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 in [0,1]. | |
| customer_count | No | Number of customers (integer ≥ 0). | |
| retention_rate | No | Annual customer retention rate, in [0,1]. | |
| projection_period | No | Projection horizon in years (integer ≥ 1). | |
| 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| 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/openWorld=false, but the description goes well beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, decimals-not-percent convention, method-dependent defaults, and the fact that parameters belonging to other methods are accepted and ignored. This is exactly the extra context annotations cannot carry.
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: the asset scope comes first, then routing, then per-method parameter lists, then conventions and error behavior. Every sentence carries information, though the run-on per-method parameter enumeration is heavy and could be more scannable.
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 14-parameter, method-dispatch tool with one required field, the description supplies everything an agent needs: method selection, required inputs per branch, defaults/ignored-parameter behavior, unit conventions, and error semantics. An output schema exists, so return-value detail is not needed.
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%, yet the description adds the crucial cross-parameter structure: which parameters each method requires (e.g. customer_relationships needs customer_count + avg_revenue_per_customer + retention_rate + profit_margin + discount_rate + projection_period), the [0,1] bounds on retention_rate/enforcement_probability, and the meaning of projection_period as the number of discounted periods. That grouping is not derivable from 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?
The description names the exact asset family (customer-related intangibles) and the three concrete formulas it supports (customer relationships, distribution networks, non-compete), with a specific verb (valuation via method selection). It explicitly routes the workforce and technology cases to valuation_human_capital and valuation_technology, so an agent can separate it from 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?
Explicit when-to-use is given ('Use for customer relationships, distribution networks, and non-compete assets') plus named alternatives for the adjacent domains ('for workforce and key-person assets use valuation_human_capital; for technology assets use valuation_technology'). The default behavior and the failure condition (unknown method or missing method-required parameter returns an error) are also stated.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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 (e.g. 0.12 = 12%). | |
| 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 (integer ≥ 1). | |
| cost_of_debt | No | Pre-tax cost of debt Rd as a decimal (e.g. 0.06 = 6%). | |
| equity_value | No | Market value of equity E, in currency units. | |
| size_premium | No | Small-size premium as a decimal (e.g. 0.03 = 3%). | |
| 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 (e.g. 0.12 = 12%). | |
| 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 (≥ 0). | |
| equity_risk_premium | No | Equity risk premium as a decimal (0.06 = 6%). | |
| country_risk_premium | No | Country risk premium as a decimal (e.g. 0.03 = 3%). | |
| currency_risk_premium | No | Currency risk premium as a decimal (e.g. 0.02 = 2%). | |
| industry_risk_premium | No | Industry risk premium as a decimal (e.g. 0.02 = 2%). | |
| specific_risk_premium | No | Company-specific risk premium as a decimal (e.g. 0.03 = 3%). |
| 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| 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 behavior, and the description adds meaningful extra context: pure arithmetic with no I/O or external calls, rounding to 2 decimals, that only method is required, that other-method parameters are accepted and ignored, and that unknown methods or missing required parameters return errors. This is rich behavioral disclosure beyond the annotations, though it could say more about output shape (which the output schema covers).
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 long but dense and front-loaded with purpose and the key alternative, and the per-method parameter list earns its place given the 23-parameter, method-dependent design. A reader gets routing guidance and requirements without wasted sentences, though the length is at the upper end.
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 that covers return values and annotations that cover the safety profile, the description supplies the remaining essentials: method selection, per-method inputs, unit conventions, defaults, and error behavior. Nothing an agent needs to call 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?
Schema description coverage is 100%, so the baseline is 3, but the description adds conditional method-to-parameter mapping (e.g. wacc needs equity_value + debt_value; dlom_finnerty volatility is annualized) that JSON Schema cannot express on its own. It also clarifies decimal conventions and default handling, giving it value above the schema alone.
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 ('Construct discount and capitalization rates') and enumerates the supported methods, so the agent knows exactly what the tool computes. It also names the sibling valuation_time_value as the tool for the cash flows this rate discounts, distinguishing it from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('derive the rate that feeds every income-based method') and routes cross-border cases to method currency_adjusted, while pointing to valuation_time_value for the discounted cash flows. Both the use condition and the alternative are named.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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 in [0,1]. | |
| 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only/idempotent/no-network profile, and the description goes further: it discloses decimal conventions, that parameters of non-selected methods are silently ignored, that all other params are method-dependent, and that unknown/missing method-required params return 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 then method routing then per-method parameters; dense but every sentence carries operational information. Slightly long and clause-heavy, but not redundant.
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 no explanation, and the description still covers method selection, per-method inputs, defaults, error behavior, and numeric conventions — nothing an agent needs to call 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?
Despite 100% schema coverage, the description adds meaning the schema cannot express: which parameters each method requires (goodwill needs purchase_price + fair_value_net_identifiable_assets), which are optional, that identified_intangibles are summed before the residual, and that liabilities_fv reduces net identifiable assets.
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 the residual', 'a full PPA waterfall', 'useful-life estimation') and explicitly names what it is not for by routing impairment to valuation_impairment and component fair values to valuation_ip/technology/customer.
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'), when-not-to-use (subsequent impairment testing), and names the exact sibling tools to feed components into the allocation.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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 (integer ≥ 0). | |
| 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| 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, closed-world, non-destructive. The description adds meaningful behavioral context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, parameters for other methods accepted and ignored, and error-on-unknown-method/missing-required-parameter semantics. It does not state default values or output shape explicitly, but the output schema covers returns.
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 well front-loaded: purpose, then alternatives, then per-method parameters, then arithmetic/convention notes. Every sentence carries information. It is longer than strictly necessary for a 10-parameter tool, which keeps it short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema and full annotation coverage, the description supplies everything an agent needs: what it computes, when to use it, which sibling to prefer, exactly which parameters each method requires, unit conventions, and error behavior. No material gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes further by grouping parameters per method, stating that only method is required while all others are method-dependent, clarifying range conventions ([0,1], decimals as 0.10 = 10%) and the productivity_factor parity semantics. This adds real routing value over 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 resource and computation ('assembled-workforce value by replacement cost and key-person value'), names the two methods, and explicitly routes customer-related and technology assets to valuation_customer and valuation_technology. An agent can distinguish it from all siblings 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 ('for assembled workforce and key-person intangibles') and names two concrete alternatives with the condition that selects them (customer-related, technology). Method selection guidance is also provided via the enum-driven formulas.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| 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, closed-world behavior, and the description goes well beyond that: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, out-of-method parameters silently accepted and ignored, and error rather than value on unknown/missing required input. These are exactly the failure-mode disclosures an agent needs.
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 sibling routing, then method requirements, then behavioral notes — a sensible ordering with little waste. It is dense and slightly run-on in the method-requirements sentence, costing a point.
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 needn't explain return values, and annotations cover safety. Between them the definition covers method selection, conditional parameters, error semantics, and arithmetic behavior — nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and enums are self-documenting, yet the description adds method-conditional requirements not derivable from the schema: fair_value required for ASC350, recoverable_amount required for IAS36, and which optional fields belong to which method. It also clarifies decimal formatting.
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?
Names a specific resource (impairment testing), splits it into two named methods (goodwill vs intangible), and cites the governing standards (ASC 350 / IAS 36). It clearly distinguishes itself from valuation_goodwill_ppa, which it explicitly routes away from.
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?
States when to use it (annual or triggering-event impairment testing) and names the alternatives: valuation_goodwill_ppa for initial goodwill/allocation and the relevant asset-type tool for underlying fair values. The selection rule for each method is spelled out.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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 (integer ≥ 1). | |
| 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint and non-destructive, but the description adds significant context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, rates as decimals, cross-method parameters silently ignored, and errors returned for unknown methods or missing method-required parameters. Only the output shape (covered by the output schema) and the tax-amortization-benefit mechanics are left implicit.
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 largely front-loaded, moving from purpose to alternatives to per-method parameters to global semantics. It loses a little to repetition, listing the same four asset-specific sibling tools twice (once in the routing sentence, once in the alternatives clause), but each remaining sentence carries real information.
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 14-parameter multi-formula calculator with an output schema and full annotation coverage, the description supplies everything needed to invoke it correctly: method routing, per-method required inputs, cross-parameter constraints, numeric conventions, and error behavior. No material gap remains.
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%, but the description goes further with relational and numeric constraints the schema cannot express: which parameters each method requires, that only method is required and the rest are method-dependent, the decimal convention, and array-length constraints (cash_flow_projections/contributory_asset_charges period-aligned; cash_flows_with/cash_flows_without equal length). This is meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Income approach: relief from royalty, multi-period and single-period excess earnings...') and names the sibling tools it is not (valuation_customer, valuation_technology, valuation_ip, valuation_human_capital, valuation_royalty_analysis, valuation_cost_approach, valuation_market_approach). An agent can separate this income-approach arithmetic tool from the asset-specific and alternate-approach siblings immediately.
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: relief_from_royalty for IP with observable royalty rates, excess earnings for the residual intangible, and a clear directive to prefer dedicated asset tools for asset-specific valuations, valuation_royalty_analysis for royalty inputs, and cost/market tools for those indications. When/when-not plus named alternatives are all present.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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 (integer ≥ 1). | |
| 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 (≥ 1). | |
| profit_margin | No | Profit margin as a decimal (0.20 = 20%). | |
| remaining_life | No | Remaining legal/economic life of the patent in years (≥ 0). | |
| 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 (≥ 0). |
| 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| 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, so the bar is lower, yet the description adds substantial context: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, parameters belonging to other methods accepted and ignored, and error behavior for unknown methods or missing method-required parameters. This is behavior an agent cannot derive from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and routing, then parameter requirements, then behavioral notes. Dense but nearly every clause carries information; the per-method parameter enumeration is lengthy, though justified by 17 parameters and four methods.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 100%-covered schema, an output schema (so return values need no explanation), and full annotations, the description fills the remaining gaps: method-to-parameter mapping, unit conventions (decimals), rounding, ignored parameters, and error semantics. Nothing an agent needs to call 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?
Schema coverage is 100%, so the baseline is 3, but the description goes further by mapping which parameters each method requires (patent vs trademark vs copyright vs trade_secret) and flagging optional ones like comparable_license_rates and brand_method. That cross-parameter, method-conditional grouping is not expressed in the flat schema and materially aids correct invocation.
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 (valuation of intellectual property) and enumerates the four IP sub-types it covers (patent, trademark, copyright, trade secret) with the valuation approach for each. It explicitly names the siblings it is not (valuation_technology, valuation_customer, valuation_human_capital), so an agent can route without opening other 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?
Gives an explicit when-to-use ('Use to value a specific IP right') and when-to-use-something-else ('For technology, software, data, and platform assets use valuation_technology; for customer and workforce assets use valuation_customer and valuation_human_capital'). It also states that only method is required and that other parameters are method-dependent and should be supplied/omitted accordingly.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, 2-decimal rounding, rate format as decimals, method-dependent parameter handling, and explicit error behavior 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-loads purpose, then usage, then alternatives, then per-method parameters and behavioral notes — a logical order with each sentence carrying information. It is dense and slightly long as a single block, but there is little that could be cut without losing method-parameter detail.
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 7-parameter, enum-driven tool with an output schema, the description covers everything an agent needs: method selection, per-method parameter requirements, optional/ignored parameters, unit conventions, error behavior, and the fact that no I/O occurs. 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 the schema alone already documents every parameter. The description still adds value by mapping parameters to methods, noting which are optional per method, clarifying decimal units, and stating that parameters belonging to other methods are accepted and ignored — semantics not derivable from 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?
Opens with a specific verb-and-resource statement ('Market approach: value from comparable transaction revenue multiples or capitalize a royalty stream') and explicitly names the siblings it is not (valuation_income_methods, valuation_royalty_analysis). An agent can distinguish it from related valuation tools 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 an explicit use condition ('Use when reliable comparable transactions or royalty rates exist') and routes the agent to two named alternatives with the conditions that select them. Both when-to-use and when-to-use-something-else are stated.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, closed-world), and the description adds substantive behavior beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, defaults applied where defined, foreign-method parameters silently accepted and ignored, and errors returned for unknown methods or missing required params. This is exactly the disclosure an agent needs to invoke it safely.
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 routing, then the method/parameter contract and units. Every sentence carries information, though the method-parameter enumeration makes it denser than strictly necessary and could be tightened.
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 return values; it covers everything else an agent needs — method selection, method-dependent parameters, unit conventions, error behavior, and the boundary against sibling valuation tools.
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%, yet the description still adds meaning the schema lacks: the per-method parameter mapping (benchmark needs ip_type+industry; adjust needs base_royalty_rate+adjustment_factors; twenty_five_percent_rule needs licensee_expected_profit), the direction of adjustment_factors ('values above 1.0 raise the rate'), and the decimal convention (0.10 = 10%).
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 a specific verb and resource ('benchmark royalty-rate ranges... adjust a base rate... apply the 25% rule') and explicitly distinguishes itself from siblings valuation_income_methods, valuation_market_approach, and valuation_compliance. An agent can identify its role as the rate-selection step preceding a valuation without reading any sibling definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('Use to select and support a royalty rate before a relief-from-royalty or royalty-capitalization valuation') plus three named alternative tools for the downstream apply/transfer-pricing cases. The method-dependency rules further clarify which parameter set applies in each case.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, returns an error instead of a value.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Random seed (integer ≥ 0) 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly/idempotent/non-destructive), yet the description adds substantial behavioral context beyond them: pure arithmetic with no I/O or external calls, rounding to 2 decimals, decimal convention for rates/premiums, the 1000-100000 iteration constraint, that foreign-method parameters are accepted and ignored, and the 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 the purpose and method routing, then a compact per-method parameter block. It is dense rather than bloated, but the per-method parameter listing partly restates the schema and adds length; still, nearly every clause carries actionable information.
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 11-parameter, four-method tool with nested objects, an output schema, and full annotation coverage, the description supplies everything an agent needs: method selection, per-method inputs, defaults, constraints, and error behavior. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description meaningfully exceeds it by mapping each method to its required/optional parameters and stating defaults and cross-method tolerance. It does not add syntax details for nested structures like tree or distributions beyond what the schema provides, so it stops short of a 5.
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?
Names the specific resource (uncertainty/sensitivity analysis) and enumerates the four methods (monte_carlo, monte_carlo_sensitivity, decision_tree, sensitivity_analysis), each with a one-line characterization. It explicitly contrasts itself with the sibling class ('For a single deterministic point value use the relevant valuation tool'), 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?
Gives explicit when-to-use ('quantify and stress the uncertainty around a point valuation'), when-not ('for a single deterministic point value use the relevant valuation tool'), and the nearest alternative ('sensitivity_analysis varies one parameter of a core function only'). It also states per-method requirements, which effectively tells the agent which method to pick for a given input set.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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 (integer ≥ 0). | |
| growth_rate | No | Per-period growth rate as a decimal (0.03 = 3%). | |
| useful_life | No | Useful life in years n (integer ≥ 1). | |
| network_size | No | Number of network participants (integer ≥ 0). | |
| 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 (≥ 0). | |
| network_effects_coefficient | No | Network-effects coefficient scaling revenue with network size (typically 0.5–2.0). |
| 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| 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 substantial behavioral context beyond them: pure arithmetic with no I/O, rounding to 2 decimals, decimal-format rates, that non-matching parameters are silently ignored, that defaults apply, and that an 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-loads the asset scope before the routing rules and parameter map, which is the right order. The parameter inventory is dense and partly restates the method lists, so it is slightly longer than strictly necessary, but nearly every clause carries operative information.
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-dispatched calculator with an output schema already present, the description supplies everything an agent needs: scope, sibling routing, per-method parameter requirements, format conventions, error behavior, and the fact that omitted defaults apply. Return values are rightly left to the output 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 100% so the baseline is 3, but the description adds real value by mapping each method to its required parameter set (e.g. data_asset needs acquisition_cost + quality_score + revenue_contribution + useful_life + discount_rate) and by clarifying the cash_flow_projections horizon for developed_technology. It stops short of explaining every parameter's individual meaning, which the schema already handles.
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 the specific resource (technology intangibles) and enumerates the four covered asset types plus the method-driven formula selection. It explicitly names valuation_ip and valuation_customer as the tools for adjacent asset classes, so the agent can distinguish it from 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 (developed technology, software, data, platform) and when-not (patents/trademarks/copyrights/trade secrets → valuation_ip; customer relationships → valuation_customer). The routing conditions are stated, not implied.
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; all other parameters are method-dependent — supply those the selected method names and omit the rest (defaults apply where defined). Rates and premiums are decimals (0.10 = 10%). Pure arithmetic: no I/O and no external calls, rounded to 2 decimals; parameters belonging to other methods are accepted and ignored. An unknown method, or a missing method-required parameter, 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). |
| defaults_applied | No | Optional parameters that were not supplied, so their documented defaults were used. |
| formula_reference | No | Mathematical formula or reference applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), and the description goes well beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, parameters for other methods accepted and ignored, and errors returned for unknown methods or missing method-required parameters. This is substantial behavioral context an agent could not derive from the schema or 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?
Long but well front-loaded: purpose, then method-parameter mapping, then unit conventions and error behavior. It loses a point for repeating the decimal convention twice ('Rates and growth are decimals (0.10 = 10%)' appears in two sentences), which is redundant in an otherwise dense passage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and rich annotations, and the description still covers the pieces those structured fields omit: method-required parameters, unit conventions, the r > g edge case, error conditions, and the ignoring of non-selected parameters. For a 10-parameter dispatcher tool, 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?
Schema coverage is 100%, so the baseline is 3, but the description adds genuinely new semantics the schema lacks: a per-method mapping of which parameters each formula requires (e.g. perpetuity_pv needs payment + discount_rate, terminal_value_exit_multiple needs final_year_cashflow + exit_multiple). It also notes the r > g constraint for Gordon growth, adding meaning beyond the schema's property 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?
The description states a specific verb and resource ('discount or compound a single sum', 'value level and growing annuities and perpetuities', 'compute a terminal value') and explicitly distinguishes itself from siblings: valuation_income_methods for uneven cash flows and valuation_discount_rate for rate construction. 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 both when to use this tool ('move cash flows through time or value a terminal value in a DCF; combine with a rate from valuation_discount_rate') and the exact conditions that select alternatives ('for uneven multi-period cash flows use valuation_income_methods'). 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.
valuation_compliancevaluation_cost_approachvaluation_customervaluation_discount_ratevaluation_goodwill_ppavaluation_human_capitalvaluation_impairmentvaluation_income_methodsvaluation_ipvaluation_market_approachvaluation_royalty_analysisvaluation_simulationvaluation_technologyvaluation_time_valueStartup valuation for AI agents: 14 tools, 80+ pre-revenue formulas.
IFRS engine: 31 standards, 21 tools. Journal entries, XBRL tags, ECL, CGU impairment, deferred tax.
Free SME valuation, sell-readiness, M&A pricing, partner and deal-referral tools in EN/FR/ES/PT.
13-model stock valuation engine for AI agents - fair values for 5,900+ US stocks, updated daily.
Add one secure layer between your agents and this server.
