MONARK

cascade

Estimated liquidable amount from the real UKEMI cascade primitives (imported, never re-implemented): an Eisenberg-Noe clearing of the interbank system (L, e) with alpha=beta=1 yields the largest clearing vector L*; each node is then read as a leveraged position — collateral is its cleared balance-sheet value (external assets plus interbank receipts under L*), debt is its nominal obligations, liquidation threshold K=1 — and liquidableAmount sums the debts of the nodes whose cleared value, once shocked by the caller-carried 24h fraction, no longer covers their obligations. Shocking the whole cleared value is a v0 simplification; no source supports shocking interbank receivables. yhat is that liquidable amount: a monetary quantity in the reference asset, a single point that HIKAE conformalizes downstream — no guarantee, no score. Downstream, no cascade calibration is committed; the gate abstains (under_calib) on this class. This cascade tool is v0, replaced at U-5.

Input Schema

TableJSON Schema

Name	Required	Description
`L`	Yes	Nominal interbank liabilities matrix L[i][j] = what node i owes node j. Square, entries >= 0, zero diagonal.
`e`	Yes	External assets (liquidation value) per node at the clearing date. One value per node.
`shock`	Yes	24h collateral price shock fraction in [0,1] — a declared fixture parameter, not a dynamics model.
`producedAt`	Yes	Caller-carried RFC3339 instant, injected for hash stability (D4); the tool reads no clock.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`yhat`	Yes
`task_class`	Yes
`produced_at`	Yes
`predictor_id`	Yes
`schema_version`	Yes
`features_digest`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 18, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description carries the full transparency burden and does so richly. It discloses the algorithm, the simplification ('Shocking the whole cleared value is a v0 simplification'), the constraint ('no source supports shocking interbank receivables'), the output semantics ('no guarantee, no score'), and the downstream treatment ('no cascade calibration is committed'). This gives an agent a complete behavioral picture.

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 description is dense and long, but every sentence carries substantive information about algorithm, assumptions, downstream behavior, or version status. It is front-loaded with the primary purpose. It could be better structured with clearer separation of algorithm vs. caveats, but it does not waste words.

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 mathematically complex tool with an output schema and no annotations, the description covers the algorithm, input interpretations, simplifications, output nature (single point, monetary, no score), downstream calibration abstention, and versioning/replacement. An agent can understand what the tool computes, what its limitations are, and how its output relates to the broader pipeline.

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. The description goes beyond the schema by explaining how L and e feed the clearing computation, how shock applies to the cleared value, and that producedAt is 'caller-carried' for 'hash stability (D4)' and that the tool 'reads no clock.' This adds algorithmic and protocol-level meaning to each 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 opens with a specific verb-plus-resource statement: 'Estimated liquidable amount from the real UKEMI cascade primitives.' It then precisely describes the mechanism (Eisenberg-Noe clearing, liquidation threshold K=1) and the exact output (yhat, a monetary quantity). This is clearly distinguished from general-purpose tools and from siblings by its mathematical and pipeline role.

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

Usage Guidelines3/5

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

The description provides context and caveats: 'This cascade tool is v0, replaced at U-5' and 'the gate abstains (under_calib) on this class.' However, it never explicitly states when to use this tool versus alternatives such as attest, calibrate, or gate, nor does it name a preferred alternative. Usage is implied through the pipeline explanation rather than stated as a decision rule.

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

All MONARK 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.