Intangible Asset Valuation MCP Server

Impairment Testing

valuation_impairment

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

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

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.

First observedOct 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Intangible Asset Valuation MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.