Intangible Asset Valuation MCP Server

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

Annotations already declare readOnly/idempotent/closed-world, but the description adds real value: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, parameters of non-selected methods silently accepted and ignored, and an explicit error contract for unknown methods or missing required method params. It does not, however, describe output shape in detail (though an output schema exists).

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, then routing to siblings, then per-method parameter requirements, then behavioral/error notes. Every sentence carries information, though the block is longer than strictly necessary for a single calculator 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?

All seven parameters are documented in the schema, an output schema exists so return values need no prose, and the description supplies the method-to-parameter mapping plus error and rounding behavior. An agent has everything needed to invoke either branch correctly.

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

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

Schema coverage is 100% for individual fields, yet the description adds cross-parameter semantics the schema cannot express: which parameters belong to which method (cup_transfer_price needs controlled_price + uncontrolled_prices; patent_infringement_damages needs lost_profits_or_royalty + infringement_period + discount_rate + prejudgment_interest_rate), and the constraint that uncontrolled_prices must contain at least one comparable.

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 computation (Comparable Uncontrolled Price arm's-length range and patent infringement damages with pre-judgment interest) and explicitly scopes it to OECD intercompany-intangible pricing and patent damages. It also names the sibling tools it is NOT (valuation_royalty_analysis, valuation_ip, valuation_income_methods), so an agent can route 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 cases ('OECD transfer-pricing pricing of intercompany intangibles', 'patent infringement damages awards') and names the correct alternatives for adjacent tasks (royalty-rate benchmarking, substantive asset valuation). Method selection is also described per branch, leaving nothing to inference.

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

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

Goes well beyond the readOnly/idempotent annotations: declares pure arithmetic with no I/O or external calls, rounding to 2 decimals, that parameters of other methods are accepted and ignored, and that an unknown method or a missing required method-parameter yields an error rather than a value. These are exactly the behavioral traits 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 the core definition and routing, then method-specific requirements and edge-case behavior. Dense but each sentence carries information; the method-dependent parameter detail makes it longer than strictly minimal, without 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?

An output schema exists so return values need no explanation, and the description still covers method selection, required vs optional parameters, defaults, error conditions, and the arithmetic nature of the tool. Complete for a four-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%, but the description still adds real meaning: which parameters each method requires, that obsolescence_factors are decimals summed and applied to the cost base, that omission means no obsolescence, and that unneeded parameters should be omitted. Slightly less precise on how development_costs categories aggregate, but clearly above the 3 baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the specific resource (cost approach valuation) and the two concrete formulas it computes (depreciated reproduction cost, depreciated replacement cost). It also distinguishes itself from valuation_income_methods and valuation_market_approach, 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?

Explicit when-to-use ('no income or market evidence exists, or to corroborate income and market indications') and names the two alternative sibling tools with their conditions. 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.

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered; the description nonetheless adds real behavioral context: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, extraneous method parameters accepted and ignored, and an error (not a value) for unknown methods or missing required params. It does not restate annotations. A 4 rather than 5 only because it never describes default values beyond noting 'documented defaults apply where defined.'

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?

Lengthy, but front-loaded with the asset scope and method routing before the parameter detail, and every sentence carries distinct information (routing, per-method params, error behavior, output rounding). The dense per-method parameter list is the only part that reads as a wall of text.

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-dispatching calculator with an output schema, the description fully covers method selection, required-vs-ignored parameters, constraints, error semantics, and result formatting; nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the flat schema by grouping parameters per method and stating which set to supply, plus clarifying units/constraints (retention_rate and enforcement_probability in [0,1], projection_period = number of discounted periods), which the flat schema alone does not organize.

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 resource class (customer-related intangibles) and enumerates the three assets it values: customer relationships, distribution networks, and non-compete agreements. It explicitly routes similar-sounding needs to siblings (valuation_human_capital, valuation_technology), so the agent can distinguish it 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 conditions per method and names the alternative tools for adjacent asset classes (workforce/key-person vs technology). The 'Only method is required; other parameters are method-dependent' rule tells the agent exactly how to compose a call.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, but the description adds valuable behavioral context: pure arithmetic with no I/O or external calls, numeric results rounded to 2 decimals, unknown methods or missing required parameters return an error, and parameters belonging to other methods are accepted and ignored.

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

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

The description is dense but appropriately sized for a tool with 23 parameters and 7 distinct formulas. It is front-loaded with purpose and method-selection guidance, then systematically lists per-method parameter needs, and every sentence contributes necessary information without repetition or fluff.

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 complex multi-method calculation tool with full schema coverage, annotations, and an output schema, the description is complete. It covers method selection, per-method prerequisites, default behavior, error handling, numeric rounding, and the fact that irrelevant parameters are ignored, leaving no gaps an agent would need to fill.

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 already documents each parameter individually, but the description adds crucial method-dependent semantics: it maps each of the seven methods to its required and optional parameters, notes that wacc requires both equity_value and debt_value, specifies that dlom_finnerty volatility is annualized, and clarifies that only method is required while other parameters are method-specific.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Construct) and resources (discount and capitalization rates), lists all seven supported methods, and explicitly distinguishes itself from the sibling valuation_time_value for discounted cash flows. An agent can identify exactly what the tool does and how it relates to the income-based methods.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance: method selects the formula, use for the rate that feeds income-based methods, use currency_adjusted for cross-border rates, and use valuation_time_value for the cash flows themselves. It names the alternative tool and the condition that selects it, leaving nothing to inference.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses that only method is required and the rest are method-dependent, that foreign-method params are accepted and ignored, that unknown/missing params error out, and that results are rounded to 2 decimals with no I/O. This is rich behavioral context the structured fields do not 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?

Front-loaded with purpose, then routing, then per-method parameter needs. Dense but every sentence carries information; the long run-on per-method clause is the only mild readability cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present the description need not explain returns, and it covers everything else an agent needs: scope standard, method branching, required vs optional params, error behavior, and determinism. Nothing material is missing for a 10-param, 3-method 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 baseline is 3, but the description adds real semantic value: per-method required params, that identified_intangibles are summed before goodwill is the residual, and that liabilities_fv reduces net identifiable assets. It stops short of syntax detail for nested economic_factors, hence not 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?

States a specific verb+resource (goodwill residual, full PPA waterfall, useful-life estimation) and immediately distinguishes siblings by naming valuation_impairment for subsequent testing and valuation_ip/technology/customer for feeding individual intangibles. 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?

Explicitly scopes to ASC 805 / IFRS 3 business combinations and names the when-not alternative (subsequent impairment → valuation_impairment) plus the feeder tools. The method-selection sentence ('Method selects the formula') tells the agent exactly which branch to take.

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

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

Annotations already declare readOnly/idempotent/no-open-world, and the description adds substantial non-obvious behavior: pure arithmetic with no I/O, results rounded to 2 decimals, error on unknown method or missing method-required parameter, and extra method parameters silently ignored. These are failure modes an agent must know and are not derivable from 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-loads purpose, then routing, then per-method parameters, then edge-case behavior — a sensible order with no filler. It is dense and long, with some restatement of schema-documented ranges, but nearly every sentence carries operational weight.

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 10-parameter, method-branching calculator with an output schema, the description covers required vs optional params, defaults, ignore semantics, and error conditions. Return-value explanation is correctly omitted since the 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 units and ranges are already documented; the description's value-add is the per-method parameter grouping (assembled_workforce needs five named params, key_person needs four) and the guidance to supply only the selected method's params and omit the rest. It repeats the [0,1] and 1.0=parity notes already in the schema, 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?

States a specific output (assembled-workforce value by replacement cost, key-person value from revenue contribution and departure risk) and explicitly names the sibling tools it is not (valuation_customer, valuation_technology). An agent can route to it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit use cases ('use for assembled workforce and key-person intangibles') plus exclusion routing to valuation_customer and valuation_technology. The method-selection rule ('Method selects the formula') tells the agent how to choose between the two internal paths.

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuinely new behavior: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, other methods' parameters accepted and ignored, and error-on-unknown-method/missing-required behavior. It does not describe output shape, but an output schema exists.

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

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

Front-loaded with purpose and routing, then the per-method parameter contract, then error semantics. Dense but mostly earns its place; the repeated restatement of method-dependence ('other parameters are method-dependent, so supply those named...') is somewhat 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?

For a calculator tool with an output schema and full annotation coverage, the description supplies everything an agent needs: method enumeration, per-method required/optional inputs, standard-conditional requirements, and error behavior. Nothing essential to correct invocation is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds cross-parameter conditional logic the schema lacks: which parameters each method needs, that fair_value is required for ASC350 and recoverable_amount for IAS36, and that non-selected methods' parameters are ignored. Minor tension between calling fair_value 'optional' for goodwill_impairment and 'required for ASC350' slightly muddies the guidance.

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+resource (impairment testing of goodwill and intangibles) and frames it under named accounting standards (ASC 350 / IAS 36). It explicitly distinguishes itself from valuation_goodwill_ppa (initial goodwill/allocation) and points to asset-type siblings for underlying fair values, 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 ('annual or triggering-event impairment testing') and per-method selection rules (goodwill_impairment vs intangible_impairment). It names the sibling to use instead for initial goodwill/allocation work and for asset fair values, and states the failure conditions (unknown method or missing required parameter errors out) rather than returning a value.

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

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, extra method parameters are accepted and ignored, and unknown methods or missing method-required parameters raise an error rather than returning a value. This is exactly the error/failure behavior 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?

Dense but well front-loaded: purpose, then routing, then per-method parameter contracts, then behavioral notes. One flaw is mild redundancy — the asset-specific sibling list ('valuation_customer, valuation_technology, valuation_ip or valuation_human_capital') is repeated twice in adjacent sentences, which 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?

For a 14-parameter, method-branching arithmetic tool with an output schema present, the description covers routing, per-method required inputs, alignment constraints, defaults, and error behavior. Nothing needed to invoke it correctly is missing, and return-value formatting is not required since an output schema exists (the 2-decimal rounding note is a bonus).

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 cross-parameter contract the schema cannot express: per-method required inputs, the period-alignment constraint between cash_flow_projections and contributory_asset_charges, the equal-length requirement for cash_flows_with/cash_flows_without, tab_enabled as optional, and the rule that 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/resource ('income-approach arithmetic' via enumerated formulas: relief_from_royalty, mpeem, single_period_excess_earnings, incremental_cashflow, contributory_asset_charges) and explicitly names the siblings it is not (valuation_customer, valuation_technology, valuation_ip, valuation_human_capital). An agent can select it over the cost/market approach 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 explicit when-to-use routing: 'relief_from_royalty for IP with observable royalty rates' and excess earnings 'for the residual intangible', plus a stated preference rule ('for a complete asset-specific valuation... prefer the dedicated valuation_customer, valuation_technology, valuation_ip and valuation_human_capital tools'). Alternatives for royalty inputs, cost and market indications are named directly.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds genuinely non-derivable behavior: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, parameters for other methods silently accepted and ignored, and errors returned for unknown methods or missing method-required params. The one thing it doesn't do is describe what the returned value looks like, though an output schema exists.

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 method-by-method parameter requirements. It is long, but for 17 parameters across four formulas most sentences carry necessary conditional detail. Minor redundancy between 'Method selects the formula' and the later required/optional explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, return formatting need not be explained, and the description covers the remaining gaps an agent needs: method selection, per-method inputs, default behavior, ignored cross-method params, and error conditions. Nothing needed 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 conditional information the flat schema cannot express: the exact required parameter set per method (e.g. patent = remaining_life + cash_flow_projections + probability_of_success + discount_rate), which parameters are optional, and that cash_flow_projections span remaining_life. It doesn't restate units or decimal conventions, 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 a specific verb and resource ('value a specific IP right') and enumerates the four method variants (patent, trademark, copyright, trade_secret) with the formula each applies. It explicitly names the siblings it is not (valuation_technology, valuation_customer, valuation_human_capital), so an agent can route 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 when-to-use ('value a specific IP right') plus when-not-to-use with named alternatives for technology/software/data/platform and for customer/workforce assets. The condition selecting each alternative is stated, not implied.

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

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

Annotations already establish read-only/idempotent/closed-world/no-destruction, and the description adds substantial context beyond them: pure arithmetic with no I/O or external calls, results rounded to 2 decimals, unknown methods and missing required params return errors rather than values, and parameters for other methods are accepted and ignored.

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

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

Front-loaded with the method definition, then usage routing, then per-method parameter guidance. Dense but each sentence carries distinct information; the description is somewhat long but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an existing output schema, the description needn't explain return values, and it covers the remaining gaps: method selection, per-method required parameters, error behavior, and the arithmetic nature of the 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 goes further: it maps which parameters each method requires (comparables + subject_revenue; revenue + royalty_rate + discount_rate), explains the comparable object shape, and specifies that method-dependent parameters may be omitted with defaults applying. It does not add syntax detail beyond the schema for the numbers themselves.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific valuation method (comparable transaction multiples / royalty capitalization) with the actual formulas, and explicitly distinguishes itself from siblings valuation_income_methods and valuation_royalty_analysis. An agent can tell exactly what this tool computes.

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?

Names the conditions for use ('when reliable comparable transactions or royalty rates exist') and routes to the two alternatives by name with their respective use cases. When-to-use and when-not-to-use are both covered.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds substantial context beyond that: it is pure arithmetic with no I/O or external calls, results are rounded to 2 decimals, method-specific required parameters cause errors when missing, unknown methods return errors, and parameters for other methods are accepted and ignored.

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

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

The description is front-loaded: purpose and method selection come first, then usage routing, then per-method parameter requirements, then behavioral constraints. Every sentence earns its place for a multi-method tool with method-dependent parameters; there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with three distinct formulas, eight parameters, and method-dependent requirements, the description covers method selection, required and optional parameters per method, error conditions, I/O behavior, rounding, and sibling routing. With an output schema present, return format need not be explained, and 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 each parameter is already documented in the input schema. The description still adds value by mapping parameters to specific methods (e.g., benchmark needs ip_type + industry; adjust needs base_royalty_rate + adjustment_factors; twenty_five_percent_rule needs licensee_expected_profit), clarifying that adjustment_factors multiply the base rate, and noting that other method parameters are ignored.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource (royalty-rate analysis) and enumerates the three formulas it supports: benchmark, adjust, and the 25% rule. It distinguishes itself from siblings by naming valuation_income_methods, valuation_market_approach, and valuation_compliance as the tools for downstream application and transfer pricing.

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 explicitly says when to use this tool (to select and support a royalty rate before a relief-from-royalty or royalty-capitalization valuation) and when to use alternatives (valuation_income_methods, valuation_market_approach, valuation_compliance). The routing guidance is unambiguous and leaves nothing to inference.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses that computations are pure arithmetic with no I/O or external calls, that results are rounded to 2 decimals, that foreign-method parameters are silently accepted and ignored, and that unknown methods or missing required parameters return an error rather than a value. It also carries the 1000-100000 iterations constraint on monte_carlo_sensitivity.

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 routing rule before the per-method parameter inventory, and every sentence carries operational content. The middle section is a dense list, but the information density justifies the length.

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 complex 11-parameter multi-method tool, the description covers routing, per-method parameter requirements, error behavior, and computational side-effects, and an output schema exists so return payloads need not be re-explained. 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 real value the flat schema lacks: a per-method required/optional breakdown (monte_carlo needs input_distributions; decision_tree needs tree; sensitivity_analysis needs function_name + parameter_name + parameter_range + fixed_parameters) and the rule that only method is required while others are method-dependent. It stops short of documenting the base_params/distributions shapes beyond what the schema already gives.

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 concrete capability set (Monte Carlo valuation, sensitivity ranking, decision-tree expected values, one-at-a-time sensitivity) with a clear verb+resource framing, and the method enum maps each formula to a distinct operation. It also names the sibling class it is not ('the relevant valuation tool') for point values, so an agent can separate it from the thirteen valuation_* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states when to use the tool ('quantify and stress the uncertainty around a point valuation'), when not (single deterministic point value -> relevant valuation tool), and how sensitivity_analysis differs from the core functions it wraps. Routing conditions are explicit rather than inferred.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses that the tool is pure arithmetic with no I/O or external calls, rounds results to two decimals, accepts and ignores parameters from other methods, and returns an error for unknown methods or missing required parameters. This is rich behavioral context that goes well beyond the annotations.

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

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

The description is dense but front-loaded: purpose first, then usage and sibling routing, then method-specific parameters, then behavioral notes. Every sentence serves a clear need, and the long parameter mapping is necessary given the 18-parameter schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description does not need to explain return values. It fully covers purpose, usage, method-parameter dependencies, error conditions, and computational behavior, leaving no significant gap for an agent to invoke it correctly.

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

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

Although schema coverage is 100%, the description adds critical semantic value by mapping each method to its required parameters (e.g., developed_technology needs rd_costs, life_cycle_stage, competitive_advantage, discount_rate, cash_flow_projections) and clarifying that only method is required and other parameters are method-dependent. This conditional grouping is not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific domain — technology asset valuation — and enumerates the four method-specific assets it handles (developed technology, software, data, platform). It explicitly distinguishes itself from siblings by directing patents/trademarks/copyrights/trade secrets to valuation_ip and customer relationships to valuation_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?

It gives explicit when-to-use guidance, names the alternative sibling tools for other asset classes, and provides per-method parameter requirements so the agent knows exactly which inputs to supply for each selected method.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond them: pure arithmetic with no I/O, results rounded to 2 decimals, out-of-method parameters silently accepted and ignored, and error (rather than a value) on unknown method or missing required parameter. It also states the Gordon-growth constraint that discount rate must exceed perpetual growth.

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 usage, then per-method requirements, then edge-case behavior; each block is dense and purposeful. It runs long and restates some formula/parameter detail the schema already carries, which costs a point on conciseness.

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 10-parameter, method-dispatched arithmetic tool with an output schema present, the description covers what it computes, when to use it, what each method requires, unit conventions, error behavior, and rounding. Return values need not be explained given the output schema; nothing needed 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% with per-parameter descriptions, so the baseline is 3; however, the description adds the method-to-parameter requirement mapping that the flat schema does not express (e.g. perpetuity_pv needs only payment + discount_rate, terminal_value_exit_multiple needs final_year_cashflow + exit_multiple), plus the decimal convention. That is real meaning beyond the schema, though it duplicates some formula text already in the enum description.

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 family (discount/compound/value/terminal value) over a specific resource (cash flows, annuities, perpetuities) and explicitly distinguishes itself from valuation_income_methods and valuation_discount_rate. An agent can route between this and its 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 ('move cash flows through time or value a terminal value in a DCF'), names two alternatives with the conditions that select them ('uneven multi-period cash flows' -> valuation_income_methods; 'rate construction' -> valuation_discount_rate), and prescribes combining with valuation_discount_rate. Nothing is left to inference.

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