Intangible Asset Valuation

Royalty Rate Analysis

valuation_royalty_analysis

Read-onlyIdempotent

Benchmark royalty-rate ranges by IP type and industry, adjust a base rate for deal factors, or apply the 25% rule-of-thumb to select and support a royalty rate for valuation.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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].

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.1.1Oct 2, 2026

addedOutput schema / properties / defaults_applied

Added value: +{
+  "description": "Optional parameters that were not supplied, so their documented defaults were used.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed2 schema fields changedv0.1.4Sep 30, 2026

changedOutput schema / properties / steps / description

Previous value: -"Intermediate calculation steps for traceability."New value: +"Intermediate calculation steps for traceability (one string per step)."

removedOutput schema / properties / steps / items / type
```
Removed value: -"object"
```

First observedv0.1.0Sep 30, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), and the description adds substantive behavior: pure arithmetic with no I/O, 2-decimal rounding, that off-method parameters are accepted and ignored, and that unknown methods or missing required params error out rather than returning 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.

Conciseness4/5

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

Front-loaded with purpose and then routing, with per-method parameter requirements grouped together. It is dense and somewhat long, but nearly every sentence carries distinct routing or parameter information; only minor tightening is possible.

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

Completeness5/5

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

For an 8-parameter, single-required-field tool with an output schema and full annotation coverage, the description supplies everything an agent needs: method-dependent parameter selection, unit conventions, error behavior, and sibling routing.

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

Parameters5/5

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 goes well beyond the schema by mapping each method to the parameters it consumes (benchmark→ip_type+industry; adjust→base_royalty_rate+adjustment_factors; twenty_five_percent_rule→licensee_expected_profit), defining the multiplicative semantics of adjustment_factors, and fixing the decimal convention (0.10 = 10%).

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

Purpose5/5

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

States a specific verb+resource ('benchmark royalty-rate ranges… adjust a base rate… apply the 25% rule') and enumerates the three selectable methods. An agent can distinguish this from valuation_income_methods and valuation_market_approach 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.

Usage Guidelines5/5

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

Explicitly scopes usage ('Use to select and support a royalty rate before a relief-from-royalty or royalty-capitalization valuation') and names the alternatives for the adjacent steps: valuation_income_methods (relief_from_royalty), valuation_market_approach (royalty_capitalization), and valuation_compliance for transfer pricing.

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

Deploy Server