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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds genuinely useful semantics by explaining the two binding-limit modes (liquidation vs manipulation) and by warning that 'unknown' is neither safe nor unsafe. It does not cover freshness of the published figures or error 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?

Front-loaded with the core comparison, then the two limit types, then the result vocabulary. Every sentence carries content, though the parenthetical explanation of manipulation/liquidation is slightly verbose for a description whose schema already carries the naming details.

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 correctly supplies the return vocabulary (within/exceeds/unknown) and interprets the ambiguous value. For a three-parameter read-only tool this covers everything an agent needs before calling.

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 fully documents assetId, amount, and quote, including the CODE:ISSUER format and string-for-precision rationale. The description adds no parameter-level detail beyond that, so the 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?

States a specific verb and resource ('compares a proposed collateral amount with Keel's recommended maximum safe collateral size') and explicitly scopes it as a comparison against published figures rather than a credit decision, which separates it from risk/underwriting siblings like get_asset_risk.

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 context for when the tool applies and draws a boundary ('not a credit decision'), and the schema points to find_asset when only a code is known. It does not, however, name sibling alternatives such as get_asset_risk or compare_assets and the conditions that would select them.

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, non-destructive behavior, so the description's job is lighter. It usefully adds that results span both sides of the book with separate ledgers and that all figures are denominated in USDC, which the annotations cannot convey.

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: the first front-loads the comparison scope and the returned metrics, the second adds the decision context and unit convention. 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?

With no output schema, the description carries the burden of describing returns and does so by listing every metric produced, plus the USDC unit. It stops short of noting pagination or whether unknown asset ids are rejected, which is a minor gap for a read-only batch 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% and the single assetIds parameter is fully documented there, including the CODE:ISSUER format. The description only restates the 2-10 cardinality already encoded as minItems/maxItems, adding no new parameter 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?

States a specific verb and resource ('side-by-side comparison of 2 to 10 assets') with the exact comparison dimensions enumerated, so an agent can distinguish it from get_asset_risk or estimate_trade_depth without opening the 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?

Offers implied usage ('useful for choosing between collateral candidates') but never states when not to use it or which sibling to prefer for single-asset or depth-only questions. The find_asset prerequisite is only mentioned in the schema, not the description.

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/idempotent/non-destructive, so the burden is lower, and the description adds real behavioral context: no interpolation exists between rungs, so results are coarse brackets, and depth aggregates SDEX order book plus AMM pools. It doesn't mention latency, rate limits, or staleness of the measured ladder.

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, front-loaded with purpose before the bracket/methodology caveat. Slightly dense but every sentence carries information; the parenthetical examples could arguably be trimmed.

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 helpfully sketches the return shape ('at most 2%/5%/10%' or 'exceeds measured depth') and the non-interpolated nature of the answer. It could go further by pointing agents to get_methodology for the ladder definition, but an agent has enough to call it 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 every parameter (side direction, quote default to USDC, string amount, asset id format). The description reinforces the quote-asset convention but adds no syntax or format detail beyond the schema, matching the 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?

States a specific operation: placing a trade size between measured rungs of the depth ladder and returning a price-impact bracket. The 'bracket, never a point estimate' framing and mention of SDEX + AMM depth make it unmistakable versus siblings like get_asset_risk or check_collateral_size.

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 audience framing ('for traders and market makers') implies when the tool matters, but no explicit when-to-use/when-not guidance or named alternatives are given. The dependency on find_asset appears only in the schema, not in the description.

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, so the safety profile is covered. The description adds genuine behavioral context beyond them: that no single match is selected and that multiple matches are a normal, expected outcome the agent must handle by asking the user.

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 zero filler. The lookup behavior is front-loaded and the multi-issuer caveat follows immediately, each sentence earning 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?

With no output schema, the description still conveys what comes back (full CODE:ISSUER ids, possibly several), which is exactly the information an agent needs. Nothing material for correct invocation 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 description coverage is 100%, so both the code and issuer parameters are already documented in the schema. The description reinforces the multi-issuer case but adds no syntax, format, or matching rules beyond what the schema 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 gives a specific verb (resolves) and resource (an asset code such as USDY or AQUA) and states the concrete output form (CODE:ISSUER ids Keel monitors). It is distinguishable in effect from siblings like list_assets, though it does not name an alternative tool explicitly, keeping it at a strong 4.

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 provides clear operational context: when one code has several issuers all are returned, and the agent is told to ask the user rather than pick one. That is real usage guidance, but there is no statement of when to prefer a sibling tool or when this lookup is unnecessary, so it stops 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 cover readOnly/idempotent/non-destructive, and the description adds real behavioral context: the LEDGER_NOT_AVAILABLE error for unreconstructed ledgers, the historical-vs-latest mode switch, and the mandatory provenance-quoting convention. It does not describe pagination or rate limits, but those are less relevant for a read.

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 is front-loaded and the return-value enumeration, while long, is the substance of an output-schema-less tool. The verbose field list is dense but each clause maps to a distinct returned metric; no filler sentences.

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 carries the return-value burden and does so by enumerating risk band, confidence, flags, depth tiers, collateral sizing, concentration, volume/supply and last trade, plus the ledger error. It could note the quote-asset scope in the return but is otherwise complete for calling 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% and the schema already documents assetId, quote (USDC default) and ledger thoroughly. The description only restates the ledger mode ('historical reconstruction') and adds no syntax or format detail beyond the schema, 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 ('The full Keel risk reading for one asset') and enumerates exactly what the reading contains, so an agent knows the scope of the result. It does not, however, explicitly distinguish itself from overlapping siblings such as estimate_trade_depth or check_collateral_size, which return some of the same sub-metrics.

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 conditional mode ('Pass ledger to read a historical reconstruction instead of the latest scan') and a routing pointer to find_asset when only a code is known. It stops short of saying when to prefer this tool over the depth/collateral 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?

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the thresholds are chosen rather than calibrated against incidents, and the agent should mention that when explaining an asset's band. This is useful domain context that affects how the tool's output should be interpreted.

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 the contents of the response and followed by an instruction on how to use the thresholds when explaining bands. Every sentence earns its place, though the second sentence is more usage guidance than tool description, keeping it from 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 and no parameters, the description carries the burden of explaining what is returned. It does so by naming the methodology version, every threshold, and the documentation link, and it adds interpretive context about thresholds being chosen. A slightly clearer enumeration of return structure would make it complete at a 5.

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 the baseline is 4. There are no parameter semantics to clarify, and schema coverage is 100% with an empty object 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?

The description clearly states the resource: the Keel methodology version, every threshold used to fire flags and size collateral, and a documentation link. It distinguishes itself from siblings like get_asset_risk and check_collateral_size by being the source of thresholds rather than an application of them, though it lacks an explicit verb like 'retrieve' or 'list'.

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 provides implied usage guidance by saying to mention the chosen-not-calibrated thresholds 'when explaining why an asset got its band,' which tells the agent one context for using the output. However, it does not explicitly say when to call this tool versus alternatives like get_asset_risk, nor does it state prerequisites or exclusions.

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/idempotent/non-destructive, so safety is covered. The description adds genuine behavioral context beyond that: the 90-day maximum window, the distinction between direct readings and reconstructions, that trades-implied is a lower bound, and that band changes are summarised rather than returned raw.

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 what the tool returns, then usage conditions, then source semantics. The named USTRY example costs a little space but illustrates the bounds-omitted rule.

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 and seven parameters, the description carries the burden well: it names the returned dimensions, the windowing rule, the source taxonomy, and the summarisation behavior. Return shape/pagination details are the only notable 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 baseline is 3. The description still adds value the schema lacks: the hard 'at most 90 days apart' constraint on from/to, and the operational consequence of the source enum (reconstructions only reachable without bounds).

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 ('a time series of band, flags, depth and max safe collateral for one asset') scoped to ONE data source. The 'time series' framing implicitly distinguishes it from the snapshot sibling get_asset_risk without ambiguity.

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?

Clearly states the two usage modes: supply from and to for a windowed request, or omit both to list every stored reading. It also names the non-obvious condition that reconstructions like the USTRY series are reachable only with bounds omitted. It does not explicitly name alternative tools, but the when-to-use conditions are concrete.

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, destructiveHint=false, and openWorldHint, so the safety and idempotency profile is fully covered by structured data. The description adds the content shape (what the status reports) but no traits annotations miss: no auth requirements, caching/TTL behavior, rate limits, or whether the ledger reference is live or stale. Given the annotation coverage, 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?

A single dense sentence, front-loaded with the most important question (is the engine healthy) followed by supporting detail, then the usage cue. Nothing is wasted, though the inline list is packed tightly enough that it reads as a run-on.

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 must carry the return-value burden, and it does by enumerating the four reported facts. Combined with annotations covering safety, an agent has enough to call and interpret the tool. Missing only detail on format/units of the returned values.

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 for the description to disambiguate; baseline 4 applies. No misleading parameter information is present.

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 specific resource (Keel service) and enumerates the four facts it reports: engine health, latest scan ledger, monitored asset count, and methodology version. This clearly distinguishes it from the asset-level siblings (list_assets, find_asset, get_asset_risk). It lacks an explicit verb, reading as a noun phrase rather than 'Returns status of...', but the resource is unmistakable.

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?

'Call this first when freshness matters' gives a concrete condition for invocation and positions the tool as an entry-point check. It does not name exclusions or alternatives, nor does it explain what 'freshness' means operationally, but the cue is actionable and 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the shape of returned data, but since there is no output schema this is mostly return-value context rather than behavioral disclosure; no auth, rate-limit, or ordering/pagination behavior is described.

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 dense sentences, front-loaded with the resource and its returned fields, followed immediately by the filtering behavior. No filler or redundant phrasing.

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 usefully enumerates the returned fields, and pagination/filter parameters are documented in the schema. Adequate overall, though it omits default ordering and any note on how limit/offset interact with result size.

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% with enums for band and hasFlag, so the schema fully documents all four parameters. The description's examples ('e.g. CRITICAL', 'e.g. MANIPULATION_CHEAP') restate enum values already present in the schema, adding only marginal value; baseline 3 is correct.

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 ('Lists the Stellar assets Keel monitors') and enumerates the returned fields (risk band, band confidence, max safe collateral size, fired flags). This clearly distinguishes it from siblings like find_asset or get_asset_risk, which operate on a single asset.

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 filtering sentence ('Filter by band... or by a single flag... to find risky collateral') gives an implied usage context, but there is no explicit when-to-use vs sibling guidance and no exclusions (e.g. when to prefer find_asset or compare_assets).

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