Fair Value MCP Server

Credit loss and impairment

calculate_credit_loss

Read-onlyIdempotent

Credit-risk engine (IFRS 9 / HKFRS 9). Compute 12-month, lifetime, and staged expected credit loss, PD/LGD/EAD, provision matrices, hazard rates, and CVA/DVA. Use this for impairment, fair-value credit adjustment, and loan-loss provisioning; for the credit component of a specific convertible bond use calculate_convertible_bond, and for liquidity, control or marketability discounts rather than credit loss use calculate_fair_value_adjustment. Methods: ecl_12m: ead, pd, lgd; ecl_lifetime: ead, pd_lifetime, lgd; ecl_staged: ead, pd_12m, pd_lifetime, lgd, stage; provision_matrix: receivables_ageing, loss_rates; pd_from_spread: credit_spread, recovery, tenor_years; cumulative_pd: annual_pd, years; hazard: hazard_rate, tenor_years; cva_dva: exposure_profile, pd, lgd, discount_rate. Supply exactly one method with its declared inputs (no defaults). An unknown method, a missing input, or an extra field returns an error envelope (code INVALID_ARGUMENT) instead of raising.

Input Schema

TableJSON Schema

Name	Required	Description
`pd`	No	Probability of default over the horizon, in [0,1].
`ead`	No	Exposure at default in currency units.
`lgd`	No	Loss given default in [0,1] (1 - recovery rate).
`stage`	No	IFRS 9 stage (1, 2 or 3).
`years`	No	Number of projection years n; equal len(cash_flows) when both are supplied.
`method`	Yes	Formula to apply; the tool description lists the exact inputs each value requires.
`pd_12m`	No	12-month PD in [0,1].
`recovery`	No	Recovery rate in [0,1].
`annual_pd`	No	Annual PD in [0,1].
`loss_rates`	No	Loss rate per ageing bucket.
`hazard_rate`	No	Default hazard rate as a decimal.
`pd_lifetime`	No	Lifetime PD in [0,1].
`tenor_years`	No	Tenor in years (>0).
`credit_spread`	No	Credit spread over the risk-free rate (decimal).
`discount_rate`	No	Discount rate as a decimal (0.10 = 10%); pre-tax when method=viu_pre_tax.
`exposure_profile`	No	Expected exposure per period.
`receivables_ageing`	No	Ageing buckets [{bucket, amount}].

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Error detail, present only when status='error'.
`steps`	No	Ordered computation steps, when the method reports them.
`value`	No	Primary result: a number for scalar methods, an object for valuation methods.
`method`	No	Method or tool name that produced the result.
`status`	Yes	'ok' on success, 'error' on failure.
`ticker`	No	Ticker the result pertains to, when applicable.
`assumptions`	No	Inputs and assumptions used, echoed for traceability.
`formula_ref`	No	Formula or standards reference for the method.
`data_timestamp`	No	ISO-8601 UTC timestamp of the underlying data, when fetched.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 14, 2026

TDQS

A4.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the error contract (unknown method, missing input, or extra field returns an INVALID_ARGUMENT envelope rather than raising) and the no-defaults, exactly-one-method constraint. It stops short of describing result shape or precision, but the output schema covers return values.

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

Conciseness5/5

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

Purpose and domain are front-loaded, followed by routing, then the compact method-to-input contract, then the error contract. The method list is dense but every clause is load-bearing for a tool with 8 mutually exclusive methods; there is no filler.

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 high-complexity multi-method calculator, the description covers purpose, sibling routing, the full method/input matrix, and failure semantics, while the output schema handles return values. An agent has everything needed to select a method and assemble a valid call.

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 the method enum's schema description explicitly defers to the tool description for required inputs. The description supplies exactly that per-method mapping (ecl_12m: ead/pd/lgd; provision_matrix: receivables_ageing/loss_rates; cva_dva: exposure_profile/pd/lgd/discount_rate, etc.), which the schema alone cannot convey given 17 optional parameters and one discriminator.

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 (compute expected credit loss) and anchors it in a named domain (IFRS 9 / HKFRS 9), listing the concrete outputs (12-month/lifetime/staged ECL, PD/LGD/EAD, provision matrices, hazard rates, CVA/DVA). It explicitly distinguishes itself from calculate_convertible_bond and calculate_fair_value_adjustment, so 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.

Usage Guidelines5/5

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

Gives explicit when-to-use cases (impairment, fair-value credit adjustment, loan-loss provisioning) and two named when-not cases with the correct alternative for each (convertible bond credit component, liquidity/control/marketability discounts). This is exactly the routing information the sibling set requires.

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

All Fair Value 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.