SBOR

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description layers on real behavioral detail the annotations cannot: exact venues read per chain (Aave, HyperLend, Kamino, Morpho), that DefiLlama selects the largest market per chain and reports its size, and that DefiLlama only substitutes when a direct contract read fails. That fallback/provenance disclosure is valuable and does not contradict the closed-world annotation (the venue set is fixed).

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 dense paragraph that front-loads what is compared before the caveat and then the data provenance. Every clause carries information, though the long parenthetical venue mapping makes it heavier to read than a short bulleted structure 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?

No output schema exists, yet the description conveys what the caller gets (a rate per chain plus market size) and where each number originates, including the degradation path. Only the exact response shape beyond that is left unspecified, which is a minor gap for a read-only comparison 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 coverage is 100% for the single index enum parameter, so the schema already documents it fully. The description adds only indirect meaning — that these markets are never index constituents, clarifying the filter means 'comparable to' rather than 'member of' — which is marginal beyond the schema wording.

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

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

The description names a concrete resource (lending-market rates on Ethereum, Base, Hyperliquid, Solana plus SOFR, US repo, and BTC-collateral dollar borrow cost) and frames it as a comparison against Stacks rates, so an agent knows what data comes back. It does not, however, explicitly distinguish itself from the sibling compare_rate, which an agent would have to disambiguate by other means.

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 a clear interpretive constraint — 'Context only: none of these is ever a constituent of an SBOR index' — which tells the agent these numbers must not be used for index composition and pairs naturally with the index filter. No named alternative or when-not-to-call rule for the sibling compare_rate, but the usage context is unambiguous.

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 safety is covered. The description adds genuinely new behavioral context the annotations cannot express: it refuses rather than guesses, and an error result means no trustworthy answer exists rather than a bad rate. That error-semantics disclosure is valuable for correct agent behavior.

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?

Purpose and the headline action threshold are front-loaded, and each sentence carries usable content. Slightly dense and the 'main reason SBOR exists' clause is mildly rhetorical, but nothing 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?

With no output schema, the description still conveys what a successful result means (direction and magnitude of deviation) and what an error means. For a 3-parameter read-only comparison tool, an agent has everything needed to call it and interpret the result.

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, but the description adds real meaning for the 'index' parameter by mapping scenarios to specific indexes (stablecoin rate for dollar-vs-bitcoin, else BTC-COLLATERAL-USD; currency index for Stacks lending). The 'rate' and 'side' semantics are already fully covered by 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 (compare), resource (a rate), and outcome (above/below market and by how much) in the first sentence. An agent can immediately distinguish this from get_rate or get_history, which only retrieve benchmarks rather than judging an offered rate.

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 explicit decision rules: 'if a borrow offer is more than 50 basis points above the benchmark, stop and ask a human' and 'Use SBOR to stop, never to start.' It also prescribes which index to choose for specific scenarios (dollar loan vs bitcoin, Stacks lending), removing inference from the caller.

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 safety is covered. The description adds genuinely useful semantics beyond that: means are computed per methodology version and never across a methodology change, which is non-obvious behavior an agent must respect when interpreting results.

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 tight sentences with the core resource stated first, then usage, then a critical caveat. No filler, though the third sentence's phrasing ('never across a change in how the number is built') is slightly abstract and could be plainer.

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 partially compensates by indicating the return shape (daily fixings, methodology-scoped means). For a two-parameter read-only history tool with full schema coverage and safety annotations, the picture is close to complete, though it says nothing about volume or pagination for a series that can span back to a rate's inception.

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 enum of indices is fully documented in the schema, including the BTC-COLLATERAL variants and their effective date. The description adds no parameter-level detail (e.g., what 'days' defaults to or interacts with), 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 states a concrete resource and scope: 'Daily fixings since each rate began,' which reads as a time-series of historical fixings distinct from a single-rate lookup. It does not explicitly name the sibling get_rate or clarify boundary cases, so it stops short of full sibling 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 a clear when-to-use signal ('to see whether a rate is unusual, or how the cost of capital has moved'), which tells the agent the analytical intent behind the call. However, it names no alternatives (get_rate, compare_rate) and offers no exclusions, so the agent must infer when not to use 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 mark readOnlyHint=true and openWorldHint=false. The description adds useful context by framing the tool as an informational reference covering exclusions and policy, reinforcing that it is non-mutating and safe to 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?

Two tight sentences with no filler. The core scope is front-loaded, and the usage directive is concise and actionable.

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 parameterless, read-only methodology resource, the description fully covers what the agent will learn and when to consult it. No output schema is necessary for safe invocation.

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 input schema has zero parameters, so there is nothing to document at the parameter level. The description compensates by explaining what content the tool provides, meeting the baseline for a parameterless 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 states a clear subject and scope: the full SBOR methodology and integration policy, including how the fixing is built, what is excluded, and what SBOR will/will not do. This differentiates it from siblings like get_rate (actual rate values) and compare_rate (comparisons).

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 final sentence gives explicit guidance: read this before quoting a rate in anything that matters. It does not name alternative tools, but the directive clearly signals the appropriate context for use.

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 readOnly and closed-world. The description adds real value beyond that: the data source (lending contract state), default behavior (returns every currency index unless one is named), the 14 October 2026 per-stablecoin rate change, and the 'read the freshness line first' warning about data staleness.

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 what the tool returns, then the usage rationale, then the default and freshness caveat. It's dense but every sentence carries information; the long enumerations of index families make it slightly less tight.

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, single-param tool with a 100% documented enum and annotations covering the safety profile, the description covers purpose, default behavior, data source, staleness warning, and interpretation guidance. Return shape isn't described, but no output schema exists, so a complete value-level description would be a plus rather than mandatory.

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 the enum plus its description already document the index parameter fully. The description reinforces the default (all indices) and the 14 Oct 2026 per-stablecoin distinction, but adds little syntax 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 (read) and resource (SBOR benchmark rates from lending contract state), enumerates the concrete index families (BTC-COLLATERAL-USD, per-stablecoin, Stacks currency indices), and is clearly distinguishable from siblings like get_history or compare_rate.

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

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

Gives a clear use case: judge whether a lending offer is good by comparing borrow/supply rates to the benchmark, with concrete conditions (borrowing above borrow rate = overpaying). It doesn't explicitly point to sibling tools like compare_rate for cross-rate comparison, so not 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 readOnlyHint=true and openWorldHint=false, covering the safety profile. Since no output schema exists, the description usefully carries the return-content burden by naming the five fields each market includes. It stops short of pagination, ordering, or per-field semantics.

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 tight sentences with the core payload (venues, assets, returned fields) front-loaded and an interpretive note trailing. No filler or restatement of the name, though the second sentence is more nice-to-have than essential.

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 single-optional-enum read-only tool with no output schema, the description supplies the returned fields and the interpretive purpose, which is enough for correct invocation. The only gap is the lack of explicit routing versus the sibling rate/market tools.

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 enum values are self-documenting, so the schema already fully explains the 'index' parameter. The description adds no syntax, default behavior, or format guidance beyond what the schema provides, which is the baseline 3 case.

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 resource (every venue and asset in an index) and enumerates the returned fields (borrow rate, supply rate, utilization, depth, weight), so the agent knows exactly what this returns. It does not, however, distinguish itself from siblings like get_rate or get_history, leaving the agent to infer the relationship.

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 only implied: 'Utilization explains why a rate sits where it does' hints this is a drill-down for explaining a rate, but no explicit when-to-use or when-not-to-use guidance is given. No alternative sibling is named, so the agent must infer that get_rate is the shallow lookup and this is the deep one.

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