CMD+RVL Receipts

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

Annotations already cover read-only, idempotent, closed-world behavior, so the bar is lower. The description adds valuable limits beyond annotations: current-only scope, dual-sourced agreement stats with single-source reported separately, and an explicit note that deeper coverage, history, bonds, and entitlements require contact. That is meaningful behavioral context.

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 compact and front-loads the coverage scope before the call guidance. The list of covered domains is dense but each item earns its place; nothing is redundant. It is slightly terse in structure rather than wasteful.

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?

Given that this is a zero-parameter meta tool with an output schema, the description provides enough context to understand what the tool returns and when to invoke it. The main missing element is explicit sibling routing—telling the agent when to use verify_* instead—but the core completeness is strong.

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?

With zero parameters and 100% schema description coverage, there is no parameter semantics to document. Baseline for a no-parameter tool is 4, and the description correctly does not waste space on nonexistent inputs.

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 states a specific purpose—documenting what the server covers (deals, loans, field inventory, counterparty roles, agreement stats)—which is clearly distinct from the verify_* and find_* siblings. It does not explicitly name those siblings or say 'not for X', so it stops short of full differentiation.

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 gives an explicit usage trigger: 'Call before reading an UNVERIFIED as meaningful.' That is a clear when-to-use condition. It does not name alternatives or state when not to call it, but for a meta-coverage tool the primary routing instruction is present.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered; the description adds the completeness claim ('every deal this server can verify'), which tells the agent this is the exhaustive enumeration path. It says nothing about result size or pagination, a mild gap for a full-list operation, but the presence of an output schema offsets that.

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?

Two short sentences, zero waste, with the scope and returned fields front-loaded and the sibling redirect placed last.

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?

With no params, full annotation coverage and an output schema that documents return values, the description covers what an agent needs to select and call it. The only missing nuance is expected result volume for an unbounded enumeration.

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 to document; the baseline for a no-param tool applies. The description correctly implies no filtering arguments exist and that filtering requires find_deals.

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 specific verb and resource ('List every deal') plus the scope ('this server can verify') and names the returned fields (CIKs, aliases, filing periods). An agent can distinguish it from find_deals without opening either schema.

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?

Explicitly routes focused lookups to find_deals, which is the nearest sibling and the main confusion risk. It lacks an explicit 'when not to use' beyond that, but the enumerate-vs-lookup split is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, but the description adds genuine behavioral detail beyond them: the two result regimes (single dominant result vs. small ranked set) and what a fuzzy result carries (match reasons, periods, suggested next call). It does not describe no-match behavior or error conditions, which keeps it short of a 5 for a lookup tool.

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?

Three short sentences, front-loaded with the searchable fields and followed by the exact/fuzzy outcome behavior and the sibling exclusion. No filler and no repetition of schema or annotation content.

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?

With an output schema present, return values need not be explained, and the description still adds the decision-relevant result-shape behavior and the sibling routing rule. It is essentially complete for a two-parameter read tool; only edge cases such as no-match or ambiguous multi-hit resolution are left unstated.

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 both parameters are already documented, including the limit default (5), fallback (10) and max (25). The description's list of searchable identifier types largely restates the schema's own query description and adds no syntax or format guidance beyond it, so the 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 specific verb and resource ("Search covered deals") and enumerates the searchable identifier types (id, trust name, CIK, alias, shelf, vintage, deal_ref). It explicitly names the sibling covered_deals and the condition that distinguishes it, so an agent can tell the two apart without opening either schema.

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 concrete routing rules: an exact query returns one dominant result and the agent should proceed; a fuzzy query returns a ranked set with match reasons and a suggested next call. It also states the exclusion for the alternative ("Use covered_deals only when you need the full universe"), so when-to-use and when-not-to-use are both covered.

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

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 by structured data. The description adds that the payload includes 'scope caveats' and 'next actions', which hints at limitations being disclosed inside the response, but it does not say what those caveats are or how large the manifest is. Additional transparency is modest, not rich.

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?

Two sentences, front-loaded with what the tool is, followed by the when-to-use and the alternative. The middle section is a long comma-delimited inventory of sections ('vocabulary guard, scope caveats, next actions, and contact') that verges on listy, but every element is arguably meaningful to an agent deciding whether to call.

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?

This is a low-complexity, zero-required-parameter orientation tool with an output schema, so the description need not explain return values. It covers purpose, trigger, and sibling routing, which is most of what an agent needs. The only gap is that a reader cannot tell how much content each 'detail' mode yields.

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% and the single 'detail' enum is documented in-schema, including when to pick routing or examples. The description mentions the sections (routing table, examples) but adds no syntax or format detail beyond what the schema already states, so the 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?

The description names the resource precisely (a compact capability manifest for clients) and enumerates what it contains, so an agent knows it is an orientation/onboarding tool rather than a data query. It distinguishes itself from 'coverage' by assigning coverage facts to that sibling. The verb is implicit ('this is a manifest' rather than 'returns a manifest'), and internal jargon like 'vocabulary guard' is opaque, which keeps it off a 5.

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?

'Use when new or context is tight' gives an explicit trigger condition, and 'call coverage for coverage facts' names the alternative and the condition that routes away from this tool. It does not enumerate when-not-to-use beyond that single routing case, but the key selection decision is stated outright.

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

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

Annotations already cover the read-only/idempotent/closed-world profile, and the description adds genuinely non-obvious behavioral context: date or basis mismatches yield DATE_INCOMMENSURATE/BASIS_INCOMMENSURATE rather than CONFLICT/DENY, and results are UNVERIFIED until upstream shards exist. It does not explain what a CONFLICT/DENY outcome implies or what triggers it.

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?

Three short sentences, purpose front-loaded, followed by result-code caveats and availability status. Dense and mostly waste-free, though the DATE_INCOMMENSURATE/BASIS_INCOMMENSURATE vs CONFLICT/DENY contrast is compressed without explaining the latter terms.

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?

With an output schema, full schema coverage, and annotations present, the description covers the essentials: what is compared, how mismatch outcomes are classified, and that results are currently UNVERIFIED. Domain terms (Annex A, ABS-EE) and sibling routing are left unexplained, which is a minor gap.

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 deal, loan_id, claimed_basis, claimed_value, and claimed_value_date; baseline 3 applies. The description adds no parameter-level meaning, and it does not resolve the schema's ambiguity where claimed_value is labeled 'Required.' but is absent from the required array.

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 the specific verb (verify) and resource (issuance appraised value) and names both data sources being reconciled (Annex A vs ABS-EE), which distinguishes it from generic siblings like verify_loan_field or verify_deal_field. It stops short of explicitly routing the agent away from any particular sibling.

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?

Usage is implied by the resource ('verify issuance appraised value') and the 'Until upstream shards exist, returns UNVERIFIED' note usefully signals the tool is currently a no-op for real data. However, there is no explicit when-to-use/when-not guidance and no named alternative for verifying other loan attributes.

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

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

Goes well beyond the readOnly/idempotent annotations by disclosing two non-obvious behaviors: a unit mismatch yields the distinct receipt status UNITS_INCOMMENSURATE rather than CONFLICT/DENY, and the tool currently returns UNVERIFIED until upstream shards are available. That is exactly the kind of degraded-state and return-semantics context an agent needs.

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?

Three compact sentences, each carrying distinct information: what is compared, the unit-status caveat, and the current UNVERIFIED limitation. No repetition of the name or schema.

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 4-param, closed-world read tool with an output schema and full schema coverage, the description supplies the key behavioral caveats (unit handling and temporary UNVERIFIED state). Only the absence of sibling routing keeps it short of complete.

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 coverage is 100%, so deal, loan_id, claimed_unit and claimed_value are already documented, and the baseline is 3. The note that 'units matter' adds a bit of meaning to claimed_unit's role, but deal/loan_id/claimed_value semantics get no elaboration 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?

States a specific verb+resource ('Verify issuance building size') and disambiguates the data sources compared ('Annex A vs ABS-EE'), which tells an agent exactly what is being checked. It is clearly distinct from siblings like verify_appraised_value or verify_loan_field.

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?

The description implies the verification use case and warns about unit mismatch, but never states when to use this tool versus the many sibling verify_* tools (e.g. verify_claims) or what prerequisites exist. Usage is inferable but not spelled out.

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

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

Goes well beyond readOnly/idempotent annotations: unparsed text is surfaced in unchecked_spans and never silently dropped, statuses are answers rather than errors, and per-claim output includes claim_id, citations and confidence. The deterministic four-family grammar scope is also disclosed, which sets expectations for coverage.

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?

Front-loaded with the core capability, then the routing exclusion, then the grammar scope, then edge-case guarantees. Telegraphic but every clause carries a distinct operational fact; 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?

For a 4-param tool with an output schema, this covers everything an agent needs: what to pass (assertions, exact deal refs), what happens to garbage input (unchecked_spans), the four status values, and the shape of each result. Nothing material is left to inference.

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 coverage is 100% and each parameter already carries a description (including period_hint's confidence-dropping behavior and risk_tolerance's tolerance rules). The description adds only indirect guidance about exact deal references feeding deal_hint; it says nothing about period_hint or risk_tolerance that the schema doesn't already say. Baseline 3.

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?

Opens with a specific verb+resource+mode: 'Bulk verifier: paste text, get per-claim statuses.' It then explicitly separates itself from the single-value siblings (verify_loan_field / verify_deal_field), so an agent can route without opening either schema.

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?

States a hard exclusion ('ASSERTIONS ONLY'), explains the failure mode for violating it ('a QUESTION ... returns total 0'), and names the alternatives to use instead. Also gives a positive usage condition ('EXACT deal references work best') and warns matching is never fuzzy.

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

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

Annotations already declare read-only, closed-world, idempotent, so the description correctly spends its words elsewhere: it discloses the single-source roster scope, the exact-match normalization rule, and the UNVERIFIED fallback for unknown inputs. It does not cover rate limits or caching, but for a read-only lookup that is minor.

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?

Front-loaded with the core adjudication purpose, then the disambiguation and fallback behavior in tight sentences; nothing is wasted. The telegraphic style ('A SINGLE-SOURCE roster fact') is dense but readable.

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 the return values need not be explained, and the description still covers outcome vocabulary (CONFIRM/DENY/UNVERIFIED) and source scope. The one gap is what happens when claimed_name is omitted, given only deal is required.

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 coverage is 100%, so baseline is 3, and the description goes beyond it: it explains that claimed_name is adjudicated under the ledger's name normalization and never fuzzily, and that role today covers master and special servicer with unknown role yielding UNVERIFIED. It also clarifies that 'master' means the roster party, not the tape's primary servicer, which changes how the role value should be interpreted.

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 ('Adjudicate') against a named, single-source resource ('SEC 10-D counterparty roster') for a specific question ('who is the <role> on deal X'). It explicitly draws the boundary against the ABS-EE tape's primary servicer, which distinguishes it from the sibling verify_servicer.

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 clear operating conditions: pass claimed_name to get CONFIRM/DENY, comparison is under the ledger's name normalization and never fuzzy, and unknown deal or role returns UNVERIFIED. It does not name the sibling tool to use for the tape-based servicer question, implying the handoff rather than stating it.

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

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

Annotations already establish read-only, idempotent, closed-world behavior, so the bar is lower. The description adds real behavioral context beyond that: it always reads the CURRENT period only, and it discloses the failure mode (no claim, unknown deal, or unknown field yields UNVERIFIED). It stops short of describing the pass/fail semantics or any comparison tolerance.

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 dense sentences, each carrying distinct information: grain, source comparison, exclusions, and failure mode. The all-caps emphasis is functional but the grain/exclusion points overlap slightly ('pool-level' and 'No loan_id').

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?

With an output schema present, return values need not be explained, and the description covers input semantics, grain constraints, and the UNVERIFIED outcome. It leaves the actual match/mismatch result semantics and any tolerance logic to the output schema, which is acceptable but slightly under-explained.

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 coverage is 100%, so a 3 is the baseline. The description exceeds it by clarifying that claimed_value must be passed even though it is absent from the schema's required list ('no claim = refusal, no value'), and by reinforcing that no loan_id exists at this grain.

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 specific verb+resource with explicit grain: 'Verify one pool-level field of a deal' and names the source pair (ABS-EE loan-tape rollup vs 10-D trustee fact). It actively distinguishes itself from adjacent concepts by ruling out bond/certificate balances and clarifying SCHEDULED vs ACTUAL are distinct fields.

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?

'No loan_id' and 'COLLATERAL (loan-pool) balances ... NOT bond or certificate balances' route the agent away from loan-grain and bond-grain siblings without naming them explicitly. Clear context on when this applies (pool grain, current period only), but no explicit sibling callout such as verify_loan_field or verify_ending_balance.

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

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

Annotations already cover read-only, idempotent, closed-world behavior, so the bar is lower; the description still adds the meaningful qualifier that the balance is SCHEDULED (not actual) and scoped to the current period. It does not restate the refusal-on-no-claim behavior that lives in the schema, but that is already covered there.

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?

A single sentence, front-loaded with the alias equivalence and followed by the field's meaning and the sibling preference. Nothing is redundant.

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 needn't be explained, and all three parameters are documented in the schema. The only gap is why the alias exists and when it should still be used rather than the canonical 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 deal, loan_id, and claimed_value are fully documented in the schema, including the 'no claim = refusal, no value' rule. The description adds no parameter-level detail beyond the implicit field='ending_balance', so the baseline of 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?

The description states exactly what the tool verifies (a loan's trust-level SCHEDULED ending balance for the current period) and identifies itself as an alias for verify_loan_field with field='ending_balance'. That mapping makes it unambiguous against every sibling, including the parent tool.

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?

"Prefer verify_loan_field" gives explicit routing away from this tool, which is the key selection decision. It stops short of saying when this alias is still appropriate (e.g. legacy callers), so the exclusion is one-sided rather than a full when/when-not rule.

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

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

Annotations cover safety (readOnlyHint, idempotentHint, openWorldHint=false), and the description adds valuable context beyond them: N-source receipt from peer NPORT-P filings by registrant CIK with dissenters included, and the latest-period-only currency limitation. It stops short of describing failure/refusal outcomes outside the schema, so not a full 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?

Front-loaded with verb and resource, then scoping facts (grain, receipt, currency) and the ticker caveat. Dense with domain jargon but every clause carries information an agent needs to select and call it correctly.

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 domain-specific verification tool with annotations and an output schema, the description covers grain, source behavior, currency limits, and identifier pitfalls. Nothing essential for correct invocation is missing; the refusal-on-no-claim rule is adequately captured in the schema.

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 coverage is 100%, so baseline is 3; the description adds rationale beyond schema by explaining ticker non-uniqueness and the claim-driven condition for require_hard_identifier. This reinforces the why behind the flag rather than merely restating it.

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 specific verb (verify) and a specific resource (NPORT cross-filer annualized coupon rate, annualized_rate) at security grain for one identifier. It clearly distinguishes itself from siblings like verify_appraised_value or verify_building_size by naming the exact data point and grain.

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?

Explains conditions: CURRENT-ONLY with latest NPORT period, not historical, and directs the agent to set require_hard_identifier=true when a claim needs a hard identity, contrasting ticker vs ISIN/CUSIP. It gives clear context but does not explicitly name a sibling alternative or state exclusion boundaries.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare read-only, idempotent, closed-world, so the bar is lower; the description still adds real value by disclosing the data provenance (ABS-EE tape), the exact-match adjudication rule, and the UNVERIFIED result for uncovered deals. It stops short of describing return shape, but an output schema exists so that is covered elsewhere.

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?

Front-loaded with purpose and provenance, then the three grains, then the parameter hint. Dense with parentheticals and semicolons, which is efficient but makes it heavier to parse than a cleaner list of grains would.

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 two-parameter verification tool with a full output schema, the description covers what an agent needs: data source, the three mutually exclusive grains, overlap rules, the claimed-adjudication path, and the unverified fallback for unsupported deals.

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 coverage is 100% with an enumerated claim-key list, so the schema carries most weight. The description still adds meaning beyond it: 'Pass `claimed` for exact per-status adjudication' and the per-status semantics (overlap of in_special_servicing, post-pool nature of resolution reasons) that the enum alone cannot convey.

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?

Starts with a specific verb+resource: verifying count claims over loan statuses for a deal, and immediately clarifies the counts are DERIVED from the ABS-EE tape rather than filed. That derivation point is exactly what separates it from generic siblings like verify_claims or verify_loan_field.

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?

Explicitly tells the agent which grain answers which sort of claim ('in_special_servicing' is the count for 'N in special servicing'), warns that grains are never mixed, that in_special_servicing OVERLAPS active and must never be summed, and that resolution-reason counts are loans that already left the pool. It also states the uncovered-deal outcome (UNVERIFIED).

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

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.

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.

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.

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.

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.

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.