CMD+RVL Receipts

Verify a loan-grain field

verify_loan_field

Read-onlyIdempotent

Verify one loan-grain field of a CMBS loan against the SEC 10-D and ABS-EE filings. Values are TRUST-LEVEL (this trust's piece, not the whole loan). Always the CURRENT period; the receipt stamps its as-of. Pass claimed_value: you get CONFIRM / DENY / CONFLICT / UNVERIFIED plus an sf-receipt. No claim, or an unknown deal, loan or field: UNVERIFIED.

Input Schema

Name	Required	Description
`deal`	Yes	Deal name or alias, e.g. 'WFCM 2020-C58' or 'Wells Fargo 2020-C58'.
`field`	Yes	The loan-grain field to verify. One of (full definitions: coverage, or the receipt's field_definition): • beginning_balance — trust-level SCHEDULED balance at period start • ending_balance — trust-level SCHEDULED balance at period end (not the actual/as-paid balance) • scheduled_principal — principal applied: scheduled amortization plus unscheduled (curtailments, payoffs) • scheduled_interest — scheduled interest, trust-level • note_rate — current note rate in percent (not origination rate, not pool WAC) • servicer_advances — Taxes & Insurance (escrow) advances outstanding, not P&I advances • paid_through_date — paid-through date (a date; exact match)
`loan_id`	Yes	Loan / entity id within the deal, e.g. '25'.
`claimed_value`	No	Claim to receipt (number, or date string for paid_through_date). Required: no claim = refusal, no value.

Output Schema

Name	Required	Description
`as_of`	Yes
`claim`	Yes	Adjudication: claimed_value, tolerance_*, within_tolerance, rationale.
`message`	Yes
`receipt`	Yes	sf-receipt 0.3; schema https://cmdrvl.com/schemas/sf-receipt/v0/schema.json; context https://cmdrvl.com/contexts/obs-receipt/v0/context.json
`claim_verdict`	Yes	Caller-claim verdict; DENY only here.
`resolved_deal`	Yes	Deal resolution: matched, id, cik, candidates.

Schema Changelog

Changes observed during successful MCP inspections.

Changed24 schema fields changedNov 2, 2026

changedInput schema / properties / field / description

Previous value: -"The loan-grain field to verify. One of:\n• beginning_balance — Beginning scheduled balance of this loan's securitized note in THIS trust at the start of the filing period, as reported in the cited 10-D remittance and ABS-EE tape (ABS-EE REPORTPERIODBEGINNINGSCHEDULELOANBALANCEAMOUNT vs the 10-D beginning-balance column). Trust-level, NOT whole-loan.\n• ending_balance — Ending SCHEDULED balance of this loan's securitized note in THIS trust for the filing period (ABS-EE REPORTPERIODENDSCHEDULEDLOANBALANCEAMOUNT vs the 10-D Mortgage Loan Detail ending-scheduled-balance column). The SCHEDULED basis, NOT the actual (as-paid) balance: the two diverge on distressed loans and the 10-D carries no actual column (br-3n91). Trust-level, NOT the whole-loan balance: pari passu companions, B-notes and mezz outside this trust are excluded.\n• scheduled_principal — Total principal APPLIED to this loan's securitized note in THIS trust for the period — scheduled amortization PLUS unscheduled principal (curtailments, prepayments, payoffs). Named 'scheduled_principal' for ledger stability, but the confirmation ledger composes ABS-EE SCHEDULEDPRINCIPALAMOUNT + UNSCHEDULEDPRINCIPALCOLLECTEDAMOUNT to match the single 10-D 'Scheduled Principal' column, which commingles both (br-m04). Trust-level, NOT whole-loan.\n• scheduled_interest — Scheduled interest on this loan's securitized note in THIS trust for the period, as reported in the cited 10-D remittance and ABS-EE tape (ABS-EE SCHEDULEDINTERESTAMOUNT vs the 10-D scheduled-interest column). Trust-level, NOT whole-loan.\n• note_rate — The current-period note (coupon) interest rate on this loan as reported for the filing period, in percent — NOT the origination rate and NOT the pool weighted-average coupon (WAC). Reconciled as ABS-EE REPORTPERIODINTERESTRATEPERCENTAGE (normalized to percentage scale) vs the 10-D note-rate column to an absolute tolerance of 0.001 percentage points. A rate, not a dollar amount.\n• servicer_advances — Outstanding servicer advances on this loan as reported for the period — specifically the Taxes & Insurance (escrow) advances balance, NOT principal-and-interest (P&I) advances. The confirmation ledger pairs ABS-EE TOTALTAXESINSURANCEADVANCESOUTSTANDINGAMOUNT against the 10-D servicer-advances column (verified dollar-exact against the T&I field); P&I advances are a separate bucket not reconciled here.\n• paid_through_date — The date through which this loan's payments are paid (the 'paid-through date') as reported in the cited 10-D remittance and ABS-EE tape for the period (ABS-EE PAIDTHROUGHDATE vs the 10-D paid-through-date column, matched exactly). A date, not a dollar amount."New value: +"The loan-grain field to verify. One of (full definitions: coverage, or the receipt's field_definition):\n• beginning_balance — trust-level SCHEDULED balance at period start\n• ending_balance — trust-level SCHEDULED balance at period end (not the actual/as-paid balance)\n• scheduled_principal — principal applied: scheduled amortization plus unscheduled (curtailments, payoffs)\n• scheduled_interest — scheduled interest, trust-level\n• note_rate — current note rate in percent (not origination rate, not pool WAC)\n• servicer_advances — Taxes & Insurance (escrow) advances outstanding, not P&I advances\n• paid_through_date — paid-through date (a date; exact match)"

changedOutput schema / properties / claim / additionalProperties
```
Previous value: -falseNew value: +true
```

changedOutput schema / properties / claim / description

Previous value: -"Claim-adjudication detail."New value: +"Adjudication: claimed_value, tolerance_*, within_tolerance, rationale."

removedOutput schema / properties / claim / properties / abs_diff

Removed value: -{
-  "type": [
-    "number",
-    "null"
-  ]
-}

removedOutput schema / properties / claim / properties / basis

Removed value: -{
-  "anyOf": [
-    {
-      "$ref": "#/properties/claim/properties/claimed_value/anyOf/0"
-    },
-    {
-      "type": "null"
-    }
-  ]
-}

removedOutput schema / properties / claim / properties / claimed_basis
```
Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}
```
removedOutput schema / properties / claim / properties / claimed_unit
```
Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}
```

removedOutput schema / properties / claim / properties / claimed_value

Removed value: -{
-  "anyOf": [
-    {
-      "type": [
-        "number",
-        "string"
-      ]
-    },
-    {
-      "type": "null"
-    }
-  ]
-}

removedOutput schema / properties / claim / properties / claimed_value_date
```
Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}
```
removedOutput schema / properties / claim / properties / rationale
```
Removed value: -{
-  "type": "string"
-}
```
removedOutput schema / properties / claim / properties / rel_bps_diff
```
Removed value: -{
-  "type": [
-    "number",
-    "null"
-  ]
-}
```
removedOutput schema / properties / claim / properties / tolerance_kind
```
Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}
```
removedOutput schema / properties / claim / properties / tolerance_used
```
Removed value: -{
-  "type": [
-    "number",
-    "null"
-  ]
-}
```
removedOutput schema / properties / claim / properties / within_tolerance
```
Removed value: -{
-  "type": [
-    "boolean",
-    "null"
-  ]
-}
```

removedOutput schema / properties / claim / required

Removed value: -[
-  "claimed_value",
-  "tolerance_kind",
-  "tolerance_used",
-  "abs_diff",
-  "rel_bps_diff",
-  "within_tolerance",
-  "basis",
-  "rationale"
-]

changedOutput schema / properties / resolved_deal / additionalProperties
```
Previous value: -falseNew value: +true
```

addedOutput schema / properties / resolved_deal / description

Added value: +"Deal resolution: matched, id, cik, candidates."

removedOutput schema / properties / resolved_deal / properties / candidates

Removed value: -{
-  "description": "Suggested deal ids when unmatched/ambiguous.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

removedOutput schema / properties / resolved_deal / properties / cik

Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}

removedOutput schema / properties / resolved_deal / properties / id

Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}

removedOutput schema / properties / resolved_deal / properties / matched
```
Removed value: -{
-  "type": "boolean"
-}
```
removedOutput schema / properties / resolved_deal / properties / name
```
Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}
```
removedOutput schema / properties / resolved_deal / properties / query
```
Removed value: -{
-  "type": "string"
-}
```

removedOutput schema / properties / resolved_deal / required

Removed value: -[
-  "query",
-  "matched",
-  "id",
-  "name",
-  "cik",
-  "candidates"
-]

First observedNov 2, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only/idempotent/closed-world, but the description adds real behavioral context: values are trust-level rather than whole-loan, the period is always current and stamped by the receipt, and the output is one of four verdicts plus an sf-receipt. It stops short of explaining what CONFLICT means operationally or how to resolve it.

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?

Four dense sentences, front-loaded with the highest-value facts (grain, source, trust-level scope) before the verdict/fallback mechanics. No filler, no restatement of the title.

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?

Annotations carry the safety profile and an output schema exists, so the description focuses correctly on grain semantics, period semantics, and the refusal/UNVERIFIED path. Nothing an agent needs in order to call this correctly is missing.

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 adds meaning the schema does not: claimed_value is not in the schema's required list yet is semantically mandatory because omitting it yields a refusal rather than a lookup. It also clarifies the date-vs-number type split for paid_through_date, which the schema only hints at.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (verify), a specific resource (one loan-grain field of a CMBS loan) and names the authoritative sources (SEC 10-D and ABS-EE). The 'loan-grain' scoping implicitly separates it from deal-grain siblings such as verify_deal_field, but the overlap with verify_ending_balance (ending_balance is also a field here) is left unaddressed.

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

Usage Guidelines4/5

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

Gives clear operating conditions: always the CURRENT period, as-of comes from the receipt, and passing claimed_value is what produces a verdict. Explicitly states the failure path (no claim, or unknown deal/loan/field → UNVERIFIED). No 'use X instead' routing to alternatives, which keeps it short of a 5.

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

All CMD+RVL Receipts 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.