Rates by 402rates

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

Annotations already set readOnlyHint=true and openWorldHint=true, so the description adds value beyond that: it discloses the temporal nature ('right now'), the validity period, the scope of the fee figure, and what is intentionally excluded (no table, no runner-up, no components, no provenance). This contextualizes the tool's minimal behavior well without contradicting annotations.

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 three sentences with zero filler. It front-loads the core purpose and outputs, then explains the costs and tradeoff, then points to the alternative. Every sentence earns its place and the contrast with compare_settlement_costs is efficient.

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 simple one-parameter, read-only tool with no output schema, the description covers the returned data (fee, scope, validity), the temporal nature, and the minimal scope. An agent can reasonably expect the return to be a simple record containing those fields; a fully explicit JSON shape is absent, but given the tool's intentional minimalism and annotations, this is sufficient.

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 schema documentation already describes the 'chains' parameter with a full list and default behavior (100% coverage), and the description adds no additional meaning about how to format or choose the comma-separated chains. Baseline of 3 is appropriate since the schema carries the parameter semantics.

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 verb and resource: 'Returns only the cheapest chain for a USDC transfer' and enumerates the exact outputs (fee in USD, scope, validity). It also differentiates from the sibling paid tool compare_settlement_costs by describing what it deliberately omits, so an agent can tell it apart immediately.

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 clear context: this is a free, minimal tool for a single cheapest chain 'right now', while explicitly naming the alternative paid tool compare_settlement_costs that offers full comparison. It does not formally state 'do not use when X', but the tradeoff is evident from the wording, satisfying the 'clear context, no exclusions' level.

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 the safety profile (readOnlyHint, openWorldHint=false), and the description adds meaningful behavior: 'Free', 'Input provenance is not verified', the actual/365 day-count with a 28-32 day range, and the disclaimer that the spread establishes neither fees nor causality. These are real traits beyond the annotations.

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 key scope statement is front-loaded and the remainder is a tight sequence of short caveat sentences. Dense but generally economical, with each sentence carrying a distinct constraint.

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 output schema, the description hints at the return ('The spread') and supplies the domain caveats an agent needs to interpret it. It is nearly complete, only omitting an explicit statement of the response shape and any sibling routing.

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 (snapshot, benchmark) are already fully documented, including constraints like positive start/end values and the us_treasury_total_return_index kind. The description adds only the 'identical dates' and caller-supplied framing, so baseline 3 is appropriate.

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 verb (arithmetic comparison) and both resources precisely: a saved measured USD instrument response versus caller-supplied US Treasury total-return index levels. This is clearly distinguishable from siblings like compare_rwa_snapshots and compare_settlement_costs.

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 explicit applicability constraints (identical dates, 28-32 day window, USD only) and clear exclusions (spot rates, unmatched windows, quoted yields, other currencies are not comparable). It stops short of naming an alternative sibling tool to route to, but the when/when-not framing is strong.

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 give readOnlyHint=true and openWorldHint=false, but the description adds key behaviors: it does not perform authentication, does not re-fetch any data, does not reconstruct history, and does not assign economic significance. This meaningfully explains the tool's boundary and fallibility without repeating the annotations verbatim. The 'examples are synthetic' parenthetical is a perfect transparency addition.

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 lean three-point list: purpose, behavior, caveat. It front-loads the primary action and then names exclusions in a tight list. It is not bloated or redundant, though 'Examples are synthetic.' could arguably be dropped or moved to a parenthetical, but it is short and earns its place.

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 no output schema, the description still tells the agent that results are 'threshold crossings' without economic interpretation, and that the tool takes two snapshots plus a threshold in basis points. The schema covers the structure of `after`, `before`, and `threshold_bps`, and the preceding notes about no data access set expectations. The main remaining gap is the absence of an explicit output format, but for a comparison tool this is acceptable because the return is predictable for a human, and the agent can infer it.

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?

Since schema_description_coverage is 100%, the baseline is 3. The description adds a little context by mentioning 'threshold crossings' and 'threshold_bps', but it does not explain how each parameter maps to the comparison logic beyond what the schema already does (e.g., 'before' describes schema_version). The additional 'Issuer origin not confirmed' for `after` is schema content, not description content, so the description adds no new parameter semantics.

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 specific verb ('compare') and resource ('two 402rates Treasury snapshots'), then enumerates the exact fields covered (yield, issuer divergence, source identifiers, calculation windows, data availability). It immediately differentiates from siblings like compare_settlement_costs by specifying 'issuer_vs_basis_bps' threshold crossing and 'Treasury snapshots'.

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 tool's purpose itself implies when to use it (whenever you need to diff two saved Treasury snapshots), but there is no stronger 'use this over X' guidance. The description only lists exclusions ('no new data access, no authentication, no historical reconstruction, no automatic monitoring') rather than actively routing the agent away from possible alternative tools. Some of those negatives are constraints, not usage criteria.

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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses significant behavioral details: it uses simulated gas, current token prices, fresh chain heads, and rollup L1 fees; it excludes unmeasurable chains rather than estimating them; it orders results cheapest first; and it mentions pricing and terms. No contradiction with annotations. This is rich, helpful 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 somewhat long but well-structured, with each sentence contributing distinct information: methodology, output characteristics, exclusion behavior, terms, and pricing. It front-loads the core purpose and avoids fluff. Slightly verbose due to pricing/terms, but acceptable for a paid tool.

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?

There is no output schema, so the description must explain the return format. It says 'Inputs and block references accompany each figure' and 'cheapest first,' but it does not specify whether the output is a list of objects, units, or exact fields. While the overall behavior is clear, the lack of explicit output structure leaves some ambiguity for an agent.

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 only parameter 'chains' is fully described in the schema with a comma-separated list and default behavior. The description reiterates the chain names and adds the output ordering (cheapest first), but does not add additional meaning to the parameter itself. With 100% schema coverage, the baseline of 3 is appropriate.

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 clearly states the tool measures USDC transfer costs across five named chains, with specific details on methodology (simulated gas, token prices, chain heads, rollup L1 fees). It also distinguishes from siblings by noting it provides a comparison ('cheapest first') rather than just identifying the cheapest chain, as implied by the sibling 'cheapest_settlement_chain'.

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 gives clear context on what the tool does and its scope, but does not explicitly state when to use it over alternatives like 'cheapest_settlement_chain' or when not to use it. The business/professional use note and pricing provide usage conditions, but no direct comparison to siblings. The context is clear, but exclusions/alternatives are absent.

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=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: null/unknown costs propagate as unknown, locked capital is held separately from expenditure, comparison happens only within a currency, and that the tool never fetches, pays or verifies. These are useful traits not derivable 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 tight sentences, front-loaded with the core capability and followed by constraints. Dense but no filler; every sentence carries information. Slightly compressed syntax costs it the top mark.

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 read-only estimation tool with no output schema, the description should sketch what the result contains (per-profile totals, comparison output). It hints at comparison within a currency but never states the return shape, leaving an agent to guess the result structure.

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 coverage is only 33% (calls and profiles have no descriptions), though the nested profile properties are richly documented. The description gestures at the inputs (prices, fees, setup costs, locked capital, batches) and clarifies unknown handling, but does not explain the meaning of calls or the workload identifier. Baseline 3 is appropriate given the nested schema does most of the heavy lifting.

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 specific verb and object: an exact-decimal calculation from caller-supplied prices, fees and setup costs for a planned number of calls. It adds scope detail (locked capital vs batches, same-currency comparison). It stops short of naming or contrasting any sibling such as compare_settlement_costs or cheapest_settlement_chain, so sibling differentiation is left to inference.

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 context is implied (planning a workload for a given number of calls) and the closing sentence lists clear exclusions: no exchange-rate conversion, no external fee measurement, no payment or verification. There is no explicit when-to-use vs. the settlement/RWA comparison siblings, so an agent must infer the boundary.

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 and openWorldHint. The description adds the useful scoping fact that it returns only this product and shared service info, but does not describe return format or operational behavior. This is adequate but 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 short sentences, directly on topicapper. The first sentence restates the title somewhat, but the second adds a meaningful scoping constraint. 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?

Low complexity tool with one optional parameter and safe read action; description says what the manifest contains. Does not describe return format, but OpenAPI manifest is self-explanatory; without output schema, a bit more detail would help.

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% for the sole parameter (base_url) and the description adds no parameter-specific meaning. 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 clearly identifies the tool as returning an OpenAPI manifest for 'Rates by 402' and explicitly scopes the contents ('this product and shared service information only'). This is better than a bare verb phraseate but does not fully differentiate from a general 'get manifest' concept.

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 states what the manifest contains but gives no explicit guidance on when to choose this tool over siblings, nor any exclusions. The 'only' phrase implies scope, but there is no direct when-to-use or when-not-to-use guidance.

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?

Despite readOnlyHint and openWorldHint annotations, the description adds substantial behavioral detail: point fields (value, date, source id, revision, source-time vs read-time dating), a reserved sentinel with data-use URL for five current-only issuer series, and the shared rolling-hour breadth limit. There is no contradiction with annotations.

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?

Every sentence earns its place and the core purpose is front-loaded. The density of domain jargon ('reconstructible recorder source', 'HISTORY_SOURCE_RESERVED', 'current-only issuer series') makes it less immediately scannable than a plainer two-sentence definition, so it is not a 5.

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 output schema, the description compensates by specifying the per-point return fields, the sentinel/list mode behavior, and the shared breadth limit. Combined with 100% schema coverage and the read-only/open-world annotations, an agent has what it needs to invoke and interpret the tool correctly.

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 all four parameters. The description mostly restates the 'omit source_id' listing mode and 'inclusive date window,' adding only the 'reconstructible recorder source' nuance, which is not enough to lift it past the baseline.

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 opens with a specific verb and resource: 'Returns free normalized observations for one tracked instrument, one reconstructible recorder source and one inclusive date window.' This clearly narrows the tool against siblings like get_rwa_yields or compare_rwa_snapshots, which are about yields or snapshots rather than source history.

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 main use case (historical observations by source) and gives in-tool query variants such as 'Omit source_id to list the instrument's audited sources.' However, it never names sibling tools or states when to prefer get_rwa_yields or compare_rwa_snapshots, so alternatives and exclusions are left to inference.

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 only carry readOnly/openWorld, but the description adds substantial context the annotations cannot: a 3-distinct-tickers-per-rolling-hour free quota, repeats stay free, the fourth call returns BREADTH_LIMIT, and explicit-unavailable-reason semantics instead of silent failure. This is exactly the quota and error behavior an agent needs before spending a call.

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 dense sentences, front-loaded with what is returned before quota and edge-case behavior. Slightly packed with domain jargon (issuer-term evidence cells, Open Treasury Yield Basis) but no sentence is wasted.

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?

No output schema exists, so the description carries return-value explanation and it does list the major payload components plus the BREADTH_LIMIT failure mode. It stops short of describing the shape of the ticker-list response or the exact unavailable-reason fields, leaving minor gaps.

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 both ticker and version are already documented, including the omit-ticker behavior and the version 1 vs 2 difference. The description restates the omitted-ticker case but adds no new syntax or format detail beyond the schema, 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 specific verb and resource — 'Returns the free frozen-contract state view for one tracked tokenized treasury' — and enumerates the payload contents (identity, yield basis result, evidence cells, deployments, dates). The singular 'one tracked' contrasts implicitly with the plural list sibling, so an agent can distinguish it without opening a 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 clear conditions: one ticker per call, omitted ticker returns only the ticker list, and hitting the fourth distinct ticker routes to the paid complete-snapshot path. It does not name that paid tool explicitly nor mention when to prefer compare_rwa_snapshots or get_rwa_history, so alternatives are only partially resolved.

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 readOnlyHint/openWorldHint by disclosing price (5 USDC per call over x402), terms URL, attribution requirements, separation of continuous access/change notices/customer-facing use, and business/professional-use restrictions. These are material behavioral and access constraints an agent would otherwise not know.

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 front-loaded with the purpose and included fields, then proceeds to licensing and pricing. It is dense but largely earns its length by covering scope, return contents, and access terms without obvious 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 paid read-only snapshot with no output schema, the description identifies the record count, enumerates key returned fields, notes equivalence to the free instrument view, and specifies price, terms, and usage restrictions. This gives an agent enough context to call it correctly and understand the commercial constraints.

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?

There is only one optional parameter, version, and the schema provides 100% description coverage including the distinction between version 1 and 2. The tool description adds no parameter details, but this is acceptable because the schema fully documents the sole parameter.

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 resource and scope: a complete evidence snapshot for 13 tokenized treasury funds, with a long list of included data fields. It clearly distinguishes itself as an all-instruments snapshot, though it does not explicitly name or compare against the singular get_rwa_instrument 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 'complete evidence snapshot for 13 tokenized treasury funds' and 'same records as the free instrument view,' which suggests when this all-in-one view is appropriate. It also states licensing/use restrictions, but does not explicitly say when to choose this over get_rwa_instrument, get_rwa_yields, or comparison siblings.

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=true, so the read-only nature is covered. The description adds valuable context beyond that: it discloses a per-call cost (0.03 USDC over x402) and a terms link, plus a professional-use restriction. These are behavioral or operational traits not captured by the annotations. It does not contradict the annotations or introduce ambiguous behaviors, so a 4 is appropriate.

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 longer than minimal but each sentence earns its place: the primary purpose is front-loaded, followed by methodological details, data features, restrictions, and finally pricing/terms. It is well-organized and not redundant, though it could be slightly more compact by merging some clauses. Overall, it is structured effectively without being bloated.

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 data retrieval tool with no output schema, the description provides a solid overview of what the response will contain: rows with observations, sources, dates, issuer figures, differences, and explicit handling of unavailable/quoted rows. It also notes coverage lists and gaps. It does not specify the exact response structure, but it conveys the semantic content well enough for an agent to understand the return. The addition of cost and terms further completes the operational context.

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 schema has 100% description coverage for the only parameter ('instruments'), fully documenting the comma-separated format and default behavior. The tool description itself adds no further parameter detail, but since the schema already handles it, the baseline of 3 is correct. The description does not need to repeat what the schema already provides.

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 verb-resource pair: 'Realised 30-day yields' for tokenized treasury funds, and names the specific universe (13 funds under the Open Treasury Yield Basis). It also details what measurements include (NAV, price, balances) and what is explicit (quoted/unavailable rows). This clearly distinguishes it from siblings like get_rwa_history or get_rwa_instrument, which pertain to historical or single-instrument data.

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 does not provide any explicit guidance on when to use this tool versus alternatives. It mentions a business/professional use restriction and terms, but nothing about selecting it over siblings. There is no statement like 'use this for current yields' or 'for historical data use get_rwa_history'. The only implied context is the tool's own name and content, but no exclusions or alternatives are mentioned.

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=true and openWorldHint=true, so the safe-read nature is covered. The description adds that the catalogue is free and limited to product/shared-service information, which is useful context. It does not contradict the annotations and provides a modest amount of additional behavioral scope.

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 two short sentences with no filler. The key identifier, 'capability and MCP tool catalogue for Rates by 402rates', is front-loaded, and the scope qualifier is a necessary clarification. Every word earns its place.

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 zero-parameter, read-only catalogue tool with annotations covering safety and open-world hints, the description is sufficient. It defines the resource, the scope, and the product context. It could mention what a returned catalogue contains, but the absence of an output schema and the simplicity of the tool keep the gap minor.

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 has no parameters, so the description does not need to explain parameter semantics. The empty schema fully covers the input surface, and the description's claims about containing product/shared service information are consistent with a zero-parameter catalogue tool.

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 identifies the tool as a 'capability and MCP tool catalogue' for 'Rates by 402rates', which makes the resource and scope clear. It lacks a strong verb, but the title's 'List' plus the catalogue wording convey the purpose. The phrase 'Contains this product and shared service information only' helps distinguish it from feature-specific tools.

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 this is the entry point for discovering available tools and capabilities. It does not explicitly state when to use it versus sibling tools or provide exclusions. The 'this product and shared service information only' qualifier gives some scope guidance but no direct routing.

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?

Beyond readOnlyHint/openWorldHint the description discloses cost (free, no paid market values), a 90-day retention limit subject to source permissions, the distinction between source dates/digests and retrieval times, and that no reconstruction is possible before the first baseline. That is meaningful behavioral context a caller could not get from the annotations.

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 short sentences with the core purpose front-loaded and no filler. Density is high (cryptic phrases like 'no paid market values or reconstruction before the first baseline'), but every sentence does carry distinct information.

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?

No output schema exists, so the description carries the burden of explaining the return shape; it names digests and source dates but never says a next_cursor and a list of change entries come back. The limit parameter and the baseline-recovery path are also left to the schema's partial hints.

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 67% schema coverage the schema already documents scope and cursor, and the description largely restates the scope versioning (instrument v1, market/access v2 with independent cursors). It adds the genuinely useful idea of per-scope independent cursors, but the limit parameter and its default remain undocumented everywhere.

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 states a concrete resource and mechanism: cursor-based Treasury change notices, i.e. a delta feed rather than a full history. It falls short of a 5 because it never contrasts itself with siblings like get_rwa_history or compare_rwa_snapshots, so the agent must infer which read tool this is.

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 explicit 'use this when…' guidance and no named alternatives, even though the sibling set contains several overlapping read tools. The only implicit usage cues are the 90-day retention note and the mention that reconstruction is impossible before a baseline, which hint at preconditions but do not route the agent.

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 that this is a read-only, closed-world operation. The description adds useful context beyond that: the data is 'Free' and 'source-backed,' unknown fund identity/investor access/liquidity remain explicit, and the tool does not provide live quotes or execution. It does not, however, describe return shape, pagination, or how version selection affects behavior, so it adds moderate rather than rich 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 four sentences are compact and each carries some meaning—scope, disambiguation, explicit unknowns, exclusions—but they are front-loaded with abstraction ('Free source-backed documentation of Treasury distribution and asset-settlement protocols') rather than an actionable statement of what the tool returns. The dense jargon makes the definition harder to parse than its length suggests.

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 zero-required-parameter read tool with 100% schema coverage and no output schema, so the description need not document every field. Still, it does not connect the parameters to behavior—e.g., what version 2 returns when no selection is supplied—and its abstract phrasing leaves an agent uncertain what the 'documentation' actually contains. Adequate but with clear gaps.

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 fully documents ticker, version, and record_id, including the enum for version and the version-2 only note on ticker. The description adds no parameter-level meaning—such as how record_id selection interacts with ticker—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 conveys a high-level purpose—source-backed documentation of Treasury distribution and settlement protocols—but never states a concrete verb-plus-resource like 'returns access evidence for a ticker.' Its abstract disambiguation language ('announced access path' vs 'identified fund') hints at scope without letting an agent tell it apart from siblings such as get_rwa_instrument or get_rwa_history.

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 only usage guidance is negative scope—'No live quote, execution or eligibility determination'—which implies when not to use it. There is no positive statement of when to choose this over the twelve sibling tools, no mention of prerequisites, and no alternative named for live quotes or eligibility checks.

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