CMD+RVL Receipts

Verify a deal's servicer (deprecated)

verify_servicer

Read-onlyIdempotent

Deprecated alias of verify_counterparty (claimed_servicer = claimed_name).

Input Schema

Name	Required	Description
`deal`	Yes	Deal name or alias.
`role`	No
`claimed_servicer`	No

Output Schema

Name	Required	Description	Default
`message`	Yes
`claim_verdict`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedNov 2, 2026

removedInput schema / properties / claimed_servicer / description

Removed value: -"Optional: a servicer name to adjudicate against the roster value (normalized comparison)."

changedInput schema / properties / deal / description

Previous value: -"Deal name or alias, e.g. 'WFCM 2020-C58'."New value: +"Deal name or alias."

removedInput schema / properties / role / description

Removed value: -"The servicer role. Default special_servicer. • master_servicer — The deal's MASTER servicer (the lead servicer that services the pool day-to-day), as named in the cited 10-D counterparties/servicer roster exhibit (role_normalized='master_servicer' in wrgl_edgar_cmbs_confirmation__servicer_roster / stg_edgar_cmbs_10d__counterparties). DUAL-CONFIRMED when the ABS-EE loan tape's per-loan primaryServicerName matches this roster master (STATUS=CONFIRMED in the servicer-roster ledger); the string comparison is the ledger's own deterministic name normalization (SOURCE_*_NORM: strip legal suffixes/punctuation, upper-case), NEVER fuzzy matching. NOT the special servicer and NOT a sub-servicer. Role attribution comes from matching the roster exhibit, so a servicer transfer the roster snapshot has not yet caught surfaces as CONFLICT/SINGLE_SOURCE, not a silent confirm.\n• special_servicer — The deal's SPECIAL servicer (the party that takes over workout/resolution of loans transferred to special servicing), as named in the cited 10-D counterparties/servicer roster exhibit (role_normalized='special_servicer'). This is a SINGLE-SOURCE roster fact: the ABS-EE loan tape carries no special-servicer field, so there is no independent second source to confirm it against (confirmation SINGLE_SOURCE, reporting party SEC:10-D). It names WHO the deal's special servicer is; it does NOT assert that any particular loan is currently in special servicing (br-3ia: never infer special-servicing status from the tape's primary-servicer name)."

removedOutput schema / properties / as_of

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

removedOutput schema / properties / claim

Removed value: -{
-  "additionalProperties": false,
-  "description": "Claim-adjudication detail.",
-  "properties": {
-    "abs_diff": {
-      "type": [
-        "number",
-        "null"
-      ]
-    },
-    "basis": {
-      "anyOf": [
-        {
-          "$ref": "#/properties/claim/properties/claimed_value/anyOf/0"
-        },
-        {
-          "type": "null"
-        }
-      ]
-    },
-    "claimed_basis": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "claimed_unit": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "claimed_value": {
-      "anyOf": [
-        {
-          "type": [
-            "number",
-            "string"
-          ]
-        },
-        {
-          "type": "null"
-        }
-      ]
-    },
-    "claimed_value_date": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "rationale": {
-      "type": "string"
-    },
-    "rel_bps_diff": {
-      "type": [
-        "number",
-        "null"
-      ]
-    },
-    "tolerance_kind": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "tolerance_used": {
-      "type": [
-        "number",
-        "null"
-      ]
-    },
-    "within_tolerance": {
-      "type": [
-        "boolean",
-        "null"
-      ]
-    }
-  },
-  "required": [
-    "claimed_value",
-    "tolerance_kind",
-    "tolerance_used",
-    "abs_diff",
-    "rel_bps_diff",
-    "within_tolerance",
-    "basis",
-    "rationale"
-  ],
-  "type": "object"
-}

removedOutput schema / properties / claim_verdict / description
```
Removed value: -"Caller-claim verdict; DENY only here."
```

removedOutput schema / properties / claim_verdict / enum

Removed value: -[
-  "CONFIRM",
-  "DENY",
-  "CONFLICT",
-  "UNVERIFIED"
-]

removedOutput schema / properties / receipt

Removed value: -{
-  "additionalProperties": true,
-  "description": "sf-receipt 0.3; schema https://cmdrvl.com/schemas/sf-receipt/v0/schema.json; context https://cmdrvl.com/contexts/obs-receipt/v0/context.json",
-  "properties": {},
-  "type": "object"
-}

removedOutput schema / properties / resolved_deal

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "candidates": {
-      "description": "Suggested deal ids when unmatched/ambiguous.",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "cik": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "id": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "matched": {
-      "type": "boolean"
-    },
-    "name": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "query": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "query",
-    "matched",
-    "id",
-    "name",
-    "cik",
-    "candidates"
-  ],
-  "type": "object"
-}

changedOutput schema / required

Previous value: -[
-  "claim_verdict",
-  "claim",
-  "receipt",
-  "resolved_deal",
-  "as_of",
-  "message"
-]New value: +[
+  "claim_verdict",
+  "message"
+]

First observedNov 2, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description's only added behavioral fact is the delegation mapping (claimed_servicer = claimed_name), which is useful but thin; it says nothing about whether the call is a pure passthrough or adds validation.

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?

A single front-loaded sentence with the deprecation status first and the mapping in parentheses. Nothing is wasted and no reading further is required to act.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 deprecation notice is the essential fact. However, a 3-parameter tool with one undocumented enum still leaves an agent guessing about 'role' semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33%, so the schema leaves 'role' and 'claimed_servicer' undocumented. The description compensates for the most confusing one by mapping claimed_servicer to verify_counterparty's claimed_name, but 'role' and its enum values remain unexplained in both places.

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?

The description states plainly that this is a deprecated alias of verify_counterparty and gives the parameter mapping, so an agent knows exactly what the call resolves to. It does not explain what 'verifying a servicer' means, but the equivalence to a named sibling removes ambiguity about behavior.

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?

The word 'deprecated' plus the pointer to verify_counterparty is an explicit steer toward the replacement tool. There is no explicit 'do not call' instruction or removal timeline, but the implied routing is clear.

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.