Intangible Asset Valuation

Transfer Pricing & Litigation

valuation_compliance

Read-onlyIdempotent

Calculates arm's-length ranges for OECD transfer-pricing compliance and patent infringement damages with prejudgment interest, using comparable prices or lost profits/royalty.

Instructions

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.

Input Schema

TableJSON Schema

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

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 changedv2.0.1Oct 1, 2026

changedInput schema / properties / infringement_period / description

Previous value: -"Infringement period in years."New value: +"Infringement period in years (≥ 0)."

changedInput schema / properties / prejudgment_interest_rate / description

Previous value: -"Pre-judgment interest rate as a decimal."New value: +"Pre-judgment interest rate as a decimal (e.g. 0.05 = 5%)."

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.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds substantial behavior the agent cannot infer: pure arithmetic with no I/O, rounding to 2 decimals, foreign-method parameters being accepted and silently ignored, and error-on-unknown-method or missing-required-param. That is exactly the extra context the annotation bar asks for.

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?

The definition is front-loaded with purpose, then the alternative routing, then per-method requirements, then behavioral rules, then error semantics – a logical order. It is dense but each sentence carries distinct information; only mild tightening is possible in the per-method parameter list.

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 a method-dispatching calculator with an output schema present, the description covers everything an agent needs: which method, what each method requires, unit conventions, additional-parameter handling, and failure modes. Return-value explanation is 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.

Parameters4/5

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 stating which parameters each method requires (cup_transfer_price needs controlled_price + uncontrolled_prices; patent_infringement_damages needs lost_profits_or_royalty + infringement_period + discount_rate + prejudgment_interest_rate), the decimal convention, and that only method is universally required. It stops short of explaining the formula mechanics behind each price/rate parameter.

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?

The description states two specific computations – the CUP arm's-length range and patent infringement damages with pre-judgment interest – with the resource (transfer pricing / litigation) named explicitly. It also names the sibling tools it is not (valuation_royalty_analysis, valuation_ip, valuation_income_methods), so an agent can disambiguate 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.

Usage Guidelines5/5

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

It gives explicit when-to-use conditions for both methods ('OECD transfer-pricing pricing of intercompany intangibles', 'patent infringement damages awards') and routes the agent away to specific alternatives for royalty-rate benchmarking and substantive asset valuation. Both the positive and the exclusion cases are covered.

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

Deploy Server