Commit / defer / abstain over a conformal coverage region - not a probability of being right.
Scored across 4 tools
The `gate` tool explicitly re-describes `calibrate`'s function ('split-conformal quantile at miscoverage α over caller-supplied nonconformity scores') as its own BYO branch, making the boundary between the two genuinely unclear for an agent. `cascade`, `gate`, and `calibrate` also cross-reference each other (gate abstains on the cascade class, cascade output feeds HIKAE conformalization), so several tools share the same conceptual substrate.
All four names are single lowercase words, which is superficially uniform, but there is no stable verb_noun or verb-only pattern: `attest`/`calibrate`/`gate` read as actions while `cascade` reads as a noun. Mixed conventions, though still readable.
Four tools for a specialized cascade-risk plus conformal-decisioning service is on the thin side but defensible. It is slightly under-provisioned given the depth of the described workflows, but no tool feels redundant by count.
The surface references committed witnesses and calibration commitments but exposes no tool to make or retrieve such commitments, and `gate` explicitly abstains on the cascade class with no tool to remedy it — a dead end. Core lifecycle operations for the stated decisioning domain are missing.
projection of a committed Shōgen-verified witness (Binance BTCUSDT, self-notarized); the verifier is NOT executed at call time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| label | Yes | Honesty label carried OUTSIDE the frozen price (K-1): the witness is demonstrative, not probative. |
| price | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does add one genuinely useful behavioral fact – that the verifier is not run at call time – implying a deterministic read of a committed artifact, plus 'self-notarized' implying authenticity. It stops short of stating read-only semantics, failure modes, or what happens when no witness is committed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single tightly-packed sentence, which is appropriately sized, but the front-loaded clause is the least parseable part and burdens the reader with jargon before delivering the actionable detail (Binance BTCUSDT, no verifier execution). Efficient in length, weak in readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and there are no parameters to document. The remaining gap is that a zero-input, cryptically named tool among equally cryptic siblings gives the agent almost no basis for deciding whether to call it – the fundamental purpose/usage context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. Schema coverage is moot at 0 params, and the description introduces no parameter confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description leans on dense, undefined jargon ('projection of a committed Shōgen-verified witness') and never states plainly what the tool returns or accomplishes. 'Binance BTCUSDT, self-notarized' narrows the domain but does not resolve the core verb+resource. It offers no differentiation from the cryptic siblings calibrate, cascade, and gate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no comparison against the sibling tools. The clause 'the verifier is NOT executed at call time' hints that this is a read of already-committed data rather than a trigger for verification, but that is inference, not instruction. The agent is left to guess the scenario in which attest is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
split-conformal quantile at miscoverage α over caller-supplied nonconformity scores. MONARK does not see, store, or verify the caller's data or model, and does not validate that the supplied numbers are nonconformity scores of any model. Marginal 1−α coverage holds ONLY for future points exchangeable with the supplied scores; non-exchangeable data (e.g. distribution-shifted or time-ordered) voids it. Never a probability of being right.
| Name | Required | Description | Default |
|---|---|---|---|
| nMin | Yes | Minimum calibration count (>= 1); n < nMin fails closed to under_calib. | |
| alpha | Yes | Target miscoverage in the open interval (0,1). | |
| scores | Yes | Caller-supplied nonconformity scores (BYO: the caller owns the score function; MONARK stays agnostic). |
| Name | Required | Description |
|---|---|---|
| n | Yes | The number of supplied scores (echoed). |
| qhat | Yes | The conformal quantile q̂, or null when the calibration is insufficient (fail-closed). |
| alpha | Yes | The target miscoverage (echoed). |
| label | Yes | Honesty label (K-1): the marginal coverage holds only under exchangeability with the supplied scores. |
| method | Yes | The conformal method — always split. |
| reason | Yes | under_calib when q̂ is null, else null on success. |
| set_digest | Yes | calibDigest(scores): recalculable by reference; the audit tie to verdict.calib_digest (C2). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses that MONARK does not see, store, or verify caller data or models, does not validate that inputs are genuine nonconformity scores, and that results are not a probability of being right. These are non-obvious behavioral and trust properties that cannot be inferred from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each load-bearing: the computation, the privacy/statelessness stance, the exchangeability precondition, and the misinterpretation warning. The guarantee-critical constraint is front-loaded and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the schema already documents the fail-closed nMin behavior. Combined with the description's coverage conditions and privacy disclosures, an agent has everything needed to call and correctly interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so nMin, alpha, and scores are already fully documented in the schema (including the fail-closed under_calib behavior). The description adds only the 'BYO / caller owns the score function' framing, which is context rather than new parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource: computes the split-conformal quantile at miscoverage alpha over caller-supplied nonconformity scores. That is unambiguous and an agent can tell it is a calibration/quantile computation, but the description never contrasts it with the sibling tools (attest, cascade, gate), so sibling differentiation is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear applicability condition and an explicit exclusion: marginal 1-alpha coverage holds only for future points exchangeable with the supplied scores, and non-exchangeable data (distribution-shifted or time-ordered) voids it. It does not, however, say when to prefer this tool over the sibling tools, so full routing guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| yhat | Yes | |
| task_class | Yes | |
| produced_at | Yes | |
| predictor_id | Yes | |
| schema_version | Yes | |
| features_digest | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful traits: the clearing uses alpha=beta=1 and threshold K=1, shocking the whole cleared value is flagged as a v0 simplification, the caller-supplied shock is explicitly 'not a dynamics model', and the tool is declared clock-free with producedAt injected for hash stability (D4). It also states outright that no guarantee or score is attached. It stops short of describing failure modes or input validation limits, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense block of run-on domain prose with the core action embedded rather than front-loaded. Multiple concepts (clearing math, node semantics, shock simplification, downstream conformalization, gate abstention) are packed into one paragraph with no structural breaks. Length is not justified by added decision value for the calling agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a numerically complex tool with an output schema present and 100% parameter coverage, the description covers the operational basis, the output's meaning (a monetary point estimate, not a score), and the known simplification. The main gap is the absence of invocation guidance, but the mechanics an agent needs to call it correctly are largely there.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents L, e, shock, and producedAt in detail, making 3 the baseline. The description adds conceptual framing — that L and e feed the Eisenberg-Noe clearing and that shock is applied to the whole cleared value including interbank receivables — but no new syntactic or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete operation: an Eisenberg-Noe clearing of the interbank system that yields a largest clearing vector L*, followed by per-node liquidation assessment and a summed liquidable amount (yhat). A specific verb+resource is recoverable, though it is buried in domain jargon rather than stated up front. It does not reference any sibling (attest/calibrate/gate), so it never differentiates itself positionally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use statement and no comparison to the siblings attest, calibrate, or gate. The agent learns only that HIKAE conformalizes yhat downstream and that the gate abstains on this class — this describes pipeline context, not selection criteria for calling cascade. The reader must infer the invocation context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Coverage-gated decision from the real HIKAE L3 policy (commit/defer/abstain) over a caller-carried authorization budget B_t. Dispatches on task_class. For 'btc-dir-15m' it conformalizes against a committed synthetic calibration derived from the HIKAE S2a instrument (seed 101, n=300 draw), declared synthetic — a plumbing fixture, not a measured predictor. For 'cascade-liquidable-24h' no cascade calibration is committed; the gate abstains (under_calib) on this class. When the caller instead supplies a calibration (its own nonconformity scores plus a mode: interval ⇒ region [yhat - q̂, yhat + q̂], or set ⇒ a conformal set over caller candidates), the gate conformalizes against THOSE caller-supplied scores (BYO): split-conformal quantile at miscoverage α over caller-supplied nonconformity scores. MONARK does not see, store, or verify the caller's data or model, and does not validate that the supplied numbers are nonconformity scores of any model. Marginal 1−α coverage holds ONLY for future points exchangeable with the supplied scores; non-exchangeable data (e.g. distribution-shifted or time-ordered) voids it. Never a probability of being right. The gate only emits a decision; it never calls the named tool.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | ||
| prediction | Yes |
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| allow | Yes | |
| action | Yes | |
| intent | Yes | |
| reason | Yes | |
| verdict | Yes | |
| schema_version | Yes | |
| remaining_budget | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so richly: it discloses that MONARK does not see/store/verify caller data, does not validate supplied scores, that coverage holds only for exchangeable future points and is voided by distribution shift, and that the gate never invokes the named tool. These are exactly the behavioral traits an agent needs and cannot get from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core decision is front-loaded, but the body is a dense run-on block with implementation trivia ('seed 101, n=300 draw', 'ADR-M007 D7') that inflates length without helping an agent select or invoke the tool. Several caveats earn their place; the fixture provenance details do not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex nested tool with an output schema, the description covers behavior, the two calibration paths, and coverage caveats well, so return values need no explanation. Gaps are the absence of sibling routing guidance and any description of the top-level prediction/params envelope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Top-level schema description coverage is 0% (prediction and params are undocumented objects), so the description must compensate, and it does: it explains the calibration object, the interval vs set mode semantics, and caller-supplied nonconformity scores. Nested properties are self-documented, but the top-level prediction/params meaning is only inferable from the prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names the resource and output space precisely: a coverage-gated commit/defer/abstain decision over an authorization budget, dispatched on task_class. It is clear what the tool produces, though the dense domain jargon (HIKAE L3, S2a instrument) adds noise, and no sibling tool (attest/calibrate/cascade) is named to differentiate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when behavior differs by task_class and when a caller-supplied calibration triggers the BYO path, and it states that 'cascade-liquidable-24h' causes an abstain. But it never says when an agent should call gate rather than attest, calibrate, or cascade, leaving sibling selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
attestcalibratecascadegateDeterministic decision layer for autonomous agents. Reproducible PROCEED, REVIEW, SKIP verdicts.
Trust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
AI-agent verifier: verdict committed before the outcome graded against it; /review, /ledger.
Deterministic sealed verdicts on public claims and startup ideas (0-LLM claim-safety guardian).
