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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real value by disclosing the shape of the returned records (code, display name, decimals, status), which is useful given there is no output schema; it does not mention ordering or refresh characteristics, but those are minor for a static reference list.

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 filler, with the resource identity and returned fields front-loaded before the optional filter hint. 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?

For a one-parameter, read-only reference lookup with full annotation coverage, the description supplies what the annotations and schema cannot: the contents of each returned record. Only a minor gap remains around ordering/completeness of the list, which is unlikely to affect correct 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?

Schema description coverage is 100% and the schema already documents the `assets` array, its format (["BTC", "ETH"]) and the omit-for-all behavior. The description only restates the filtering intent, adding no syntax or constraint detail beyond the schema, 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 names the resource (assets) and enumerates what is returned (code, display name, decimals, status), which clearly separates it from price-oriented siblings like get_ticker/get_book. It does not, however, explicitly state the verb or contrast itself with the adjacent get_instruments 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?

"Pass `assets` to look up specific ones" implies the omit-for-all default, but usage is only implied rather than stated as a when-to-use rule. No guidance distinguishes this from get_instruments, which an agent could plausibly confuse with an asset-listing call.

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, openWorldHint and destructiveHint, so the safety profile is fully covered. The description adds useful behavior not in the schema: result ordering (best prices first) and the 500-level cap. It still says nothing about rate limits, auth, or snapshot staleness, so this is solid-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 front-loaded sentence with no filler; every clause (snapshot, both sides, cap, ordering) carries information. It is a fragment rather than a full sentence, but that costs nothing here.

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 only 2 well-documented params, dense annotations, and no output schema, the description covers what the agent needs: what is returned (bids/asks), how much (up to 500/side), and in what order. The only real gap is the absence of any sibling-routing guidance.

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 (pair with its format rules, depth with default and bounds) are already documented by the schema. The description's 'up to 500 levels per side' only echoes the schema's depth maximum, adding no new meaning beyond 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+resource (order-book snapshot for a pair) and even specifies content (bids/asks) and scope (up to 500 levels per side). It does not distinguish itself from close siblings like get_spread or get_ticker, which also return current-market data, so an agent must infer the difference.

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 when-to-use guidance, no exclusions, and no alternatives named among the many sibling market-data tools. The purpose implies market-depth retrieval, but nothing tells the agent when get_book is preferred over get_spread, get_ticker, or get_trades.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: a per-call cap of 720 candles, most-recent-last ordering, and the fact that `since` enables backward paging. This is solid but not exhaustive about rate limits 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?

Three tight sentences with the purpose front-loaded, followed by the per-call cap and ordering, then pagination guidance. Every sentence adds value and there is 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 a 100% schema description coverage, rich annotations, and no output schema, the description supplies enough context to call the tool correctly. It covers what is returned, ordering, limits, and pagination, though it omits any mention of rate limits or authentication expectations.

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 adds practical meaning beyond the schema by explaining that `since` is used to page further back and that Kraken returns up to 720 candles per call, which contextualizes the `limit` maximum.

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, 'OHLCV candles for a pair,' which is distinct from siblings like get_ticker, get_book, and get_trades. It is clear without opening the schema, but it does not explicitly differentiate itself from sibling tools by naming alternatives or contrasting scope, which keeps it from 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?

It gives pagination guidance for the `since` parameter ('Use `since` (Unix seconds) to page further back'), which is useful implied usage. However, it never says when to choose this tool over get_ticker, get_trades, or other siblings, so explicit routing guidance is 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, idempotentHint, destructiveHint false, and openWorldHint, so the safety profile is covered. The description adds useful return-value context (precision, minimum order, tick size, fee schedule, leverage) in the absence of an output schema, though it does not discuss auth or rate limits.

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 single, front-loaded sentence that lists the key returned fields with no filler. Every element contributes to understanding what the tool returns.

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 read-only, single-parameter lookup with full schema coverage and rich annotations, the description provides enough context to invoke the tool correctly. It could be more complete by explicitly routing multi-pair needs to get_instruments, but no critical invocation detail 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%, and the 'pair' parameter is fully documented with examples and separator/case notes. The description does not add any parameter-level meaning beyond what the schema already provides, 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 the resource ('one pair') and enumerates the returned fields, so the agent knows it retrieves instrument details for a single pair. It implicitly contrasts with the sibling get_instruments by saying 'one pair', but does not name that alternative explicitly.

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 phrase 'for one pair' implies this tool is used when you need details for a single trading pair, which hints at the alternative get_instruments for multiple pairs. However, there is no explicit when-to-use guidance, no named alternatives, and no 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, openWorld, so the safety profile is covered. The description adds useful behavioral context beyond them: the result is "compact rows" that intentionally omit fees and full detail, which tells the agent what it will and won't get back.

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 filler, with the core scope statement front-loaded and the sibling routing placed after. Every clause 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 read-only list tool with no output schema, the description conveys scope, filterable dimensions, and the shape/nature of the returned rows. Missing only pagination/limit behavior and default-value context, which are minor given the schema's default and maximum.

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 75%, so the schema documents base, quote and search semantics (including case-insensitivity and examples). The description only restates which fields can be filtered and adds no syntax or combination rules, so baseline 3 applies. The limit parameter is not addressed in either place.

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 tradable spot pairs") and contrasts with its singular sibling get_instrument, which is exactly the pair an agent would confuse. The agent can distinguish this from get_instruments/get_instrument 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 detail-seeking callers to get_instrument for fees and full instrument data, which is clear usage context against the closest alternative. It stops short of stating when-not to use it or how the base/quote/search filters compose, so it is not a full when/when-not/alternatives statement.

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, non-destructive and open-world, so the safety profile is fully covered. The description adds the return-shape (time, bid, ask) but says nothing about how far back 'recent' reaches, rate limits, or pagination 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?

A single tight sentence with the resource front-loaded and zero filler. It is efficient, though its brevity borders on under-specification rather than model conciseness.

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 market-data tool with no output schema, the enumeration of the tuple fields is useful, but 'recent' is undefined and limit semantics are absent. Annotations carry the safety burden, yet the temporal scope of the query remains unclear.

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 description adds no parameter meaning at all; pair and since are documented only by the schema (67% coverage), and limit has no description anywhere. Since the description neither compensates for the uncovered limit param nor clarifies range/ordering semantics of 'since', it falls below 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?

States a specific verb and resource ('recent best bid/ask spread samples') and enumerates the returned fields (time, bid, ask), so the agent knows this differs from a full orderbook or ticker read. However, it never explicitly differentiates against siblings like get_book or get_ticker, leaving the distinction implicit.

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 no when-to-use guidance, no alternatives, and no exclusions. An agent choosing between get_spread, get_book, and get_ticker gets no routing help beyond the surface wording.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by naming the possible system states and noting that server time is returned, but it does not address authentication, rate limits, or response structure.

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 single, front-loaded sentence that states the resource and the returned information without filler. Every element 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 status endpoint with rich annotations, the description gives enough information to call it correctly and understand the main return values. It could more explicitly explain when an agent should use it, 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?

The tool takes no parameters, so there is no parameter semantics to document; the baseline for a zero-parameter tool is 4. The description does not need to compensate for any schema gaps.

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 specifically identifies the resource as Kraken system status and server time, and enumerates the possible status values (online, maintenance, cancel_only, post_only). It is clearly distinct from the market-data siblings, though it does not explicitly frame itself as a pre-flight availability check.

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?

There is no guidance on when to call this tool, when not to call it, or how it relates to alternatives. The intended use—checking exchange availability before trading or issuing orders—must be inferred entirely from 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and freshness profile is largely covered. The description adds the useful behavioral framing that values are a "current snapshot" (point-in-time, not streaming/historical) and anchored "since the daily open," which the annotations cannot convey. It does not mention staleness, rate limits, or behavior for invalid/delisted pairs.

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 with no filler; the resource and its scope are front-loaded and every listed field earns its place by telling the agent what data comes back.

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-parameter, no-output-schema tool, the description is nearly complete: it enumerates the returned fields so the agent knows what it gets in lieu of an output schema, and annotations cover the safety profile. The main omission is disambiguation from overlapping siblings (get_tickers, get_spread, get_book).

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 "pair" parameter already documents format and separator/case flexibility, so the schema carries parameter meaning. The description constrains scope to "one pair" but adds no additional syntax or format guidance beyond the schema. 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 uses a specific verb+resource ("Current snapshot for one pair") and enumerates exactly which fields are returned (bid/ask, last trade, 24h volume, VWAP, high/low, trade count, percent change). It clearly reads as a market-data snapshot tool, but it does not name or distinguish itself from the closest sibling get_tickers (plural, presumably multi-pair), nor from get_spread/get_book which overlap with bid/ask 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 word "one pair" implies the single-pair scope versus the plural get_tickers sibling and the pair requirement, but usage is only implied. There is no explicit when-to-use/when-not statement and no guidance on choosing this over get_spread, get_book, or get_candlestick for overlapping data.

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, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: whole-market scope on omission, quote-asset filtering, and 24h-volume ordering of 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?

A single sentence with zero waste that front-loads the primary mode (list of pairs) before the fallback (whole market). Parenthetical qualifiers are compact and each carries 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?

For a read-only, 3-parameter, fully schema-documented tool with no output schema, the description covers scope, filtering and ordering adequately. It could say a bit more about what a 'snapshot' contains, but annotations and schema carry the rest.

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 all three parameters are already documented, including the 'only used without pairs' constraints. The description adds only the 24h-volume sort detail, which is marginal beyond the schema; 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 specific verb and resource (snapshots for a list of pairs) and clarifies batch scope via 'in one call,' which implicitly distinguishes it from the singular sibling get_ticker. It never names get_ticker or another alternative outright, 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?

It clearly explains the key usage condition: pass `pairs` for a specific list, omit it to get the whole market, optionally narrowed by quote asset. There is no explicit exclusion or named alternative for single-pair lookups, 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 declare readOnly/idempotent/openWorld, so safety is covered. The description adds real behavioral value beyond them: it explains the pagination mechanism and that `since` accepts either an opaque cursor from a prior call or a nanosecond Unix timestamp. It omits ordering guarantees and rate limits, keeping it below 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?

Two tight sentences with no filler; the primary scope statement leads and the non-obvious `since` semantics follow immediately. Every clause carries 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?

For a 3-parameter read tool with no output schema, the calling contract is nearly complete: pair, count ceiling, and cursor semantics are all covered. The trade record shape and ordering direction are unspecified, but that is a minor gap for a straightforward paginated list.

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 only 33% (pair is documented; count and since are bare), so the description must carry weight. It does: the dual meaning of `since` (cursor vs ns timestamp) and the `count` ceiling of 1000 are both clarified. It does not document the count default of 50, which the schema does supply.

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 ('most recent public trades for a pair') with a scope cap (up to 1000), which clearly separates it from sibling aggregation tools like get_candlestick or get_book. It stops short of explicitly naming any sibling, so it lands at 4 rather than 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?

Usage is implied by the resource itself — an agent needing raw recent prints for a pair will pick this. However, there is no explicit when-to-use vs get_candlestick/get_ticker guidance and no stated prerequisites, so it is only the minimum viable level.

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