DeskPulse

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

With no annotations, the description carries the full burden and does disclose two non-obvious behavioral traits: it is a paid call ($0.05 USDC / 50000 atomic) and requires no API keys. It omits rate limits, failure modes, and latency/refresh characteristics, so it is good but not complete.

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 terse telegraphic statements with no filler, and the return fields are listed compactly. Slight deduction because the pricing line is front-loaded ahead of the actual purpose, delaying the agent's answer to 'what does this do'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained (the description lists them anyway), and the schema fully documents the two parameters. Given no annotations, the description adequately covers cost and auth, though it could say more about paid-call failure handling or rate limits.

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 (spotPair, futuresSymbol) are already fully documented with defaults and mapping rules. The description adds the conceptual pairing of spot vs futures inputs but 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+resource: computes spot-vs-Kraken-Futures basis (futures mark/index/mid vs spot mid). This is clearly distinguishable from siblings like funding_snapshot and book_depth, though the differentiation is implied rather than called out.

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 or when-not-to-use guidance, and no alternatives named among the sibling tools. The only qualifying context is 'Public API only — no keys', which is an auth prerequisite rather than usage 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?

With no annotations, the description carries the full behavioral burden. It does add valuable context that the call costs $0.03 USDC (30000 atomic) and that the data is public, but it omits rate limits, failure modes, and whether payment failures are recoverable.

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 payment cost is front-loaded, which is arguably useful for gating decisions, though leading with purpose might read more naturally.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so listing return fields is slightly redundant but harmless. Payment cost, venue, and payload are covered; only the routing decision versus hl_book_depth is unstated, which is a minor gap for a two-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (pair, count) are already documented with examples and defaults. The description adds nothing beyond the schema about parameter semantics, 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 resource and venue ('Kraken public order book depth') plus the concrete payload (bids, asks, mid price, volume imbalance). This clearly distinguishes it from the sibling hl_book_depth, which an agent can infer covers a different venue.

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 'Kraken' qualifier implicitly tells the agent when to pick this over hl_book_depth, and the PAID tag flags a gating condition, but there is no explicit when-to-use or when-not-to-use statement. Usage is left to inference from the venue name.

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?

With no annotations, the description carries the full burden and does well: it discloses the paid cost ($0.05 USDC / 50000 atomic), that no API keys are required, and that fundingRatePrediction and relativeFundingRate come from historical data. It omits rate limits, latency, and failure behavior, which keeps it short of a 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?

The cost/payment fact is front-loaded, followed by source, return fields, and auth/parameter notes in a dense but well-ordered block. Every clause carries information, though the returned-field list is somewhat long for text that an output schema already covers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so enumerating return fields is not strictly necessary, but the description still covers the decision-critical facts an agent needs: price, data origin, no-key access, and parameter preference. Nothing essential to invoking the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are already documented in the input schema, including the alias relationship and accepted symbol aliases. The description's 'Prefer symbol; pair is accepted as alias' merely restates that schema content, 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 a specific resource and source — Kraken Futures perpetual funding for PF_XBTUSD/PF_ETHUSD — and enumerates the metrics returned, so an agent knows exactly what it gets. It does not explicitly contrast itself with hl_funding_snapshot, though the 'Kraken Futures' framing implicitly separates it from the Hyperliquid 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?

'Prefer symbol; pair is accepted as alias' gives concrete parameter guidance, and 'Public API only — no keys' tells the agent no auth setup is needed. However, there is no explicit when-to-use/when-not guidance relative to basis_snapshot or hl_funding_snapshot, so selection between siblings is 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?

With no annotations, the description carries the full disclosure burden. It does add one genuinely behavioral fact — the call is always free — which is real cost context an agent could use for planning. However it omits auth requirements, rate limits, and failure modes; and since an output schema exists, listing the returned fields duplicates structured data.

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?

Very short and front-loaded, but 'FREE' is asserted twice ('FREE.' and 'Always free'), which wastes one of only two sentences. The remaining sentence is efficient and delivers the useful content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not enumerate return values, and a parameterless health check is inherently simple. The description is sufficient to invoke it correctly; it only lacks failure/error semantics, which is a minor gap for this tool class.

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 is nothing for the description to clarify, and it correctly does not invent parameter details.

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 (health check) plus what it returns: server status, network, and payTo address. That is far more specific than the sibling snapshot tools and lets an agent classify it without opening the schema, though it never explicitly contrasts itself with those siblings.

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 — an agent can infer 'call this to verify the server is reachable,' but the description never says when to use it, what state it should precede, or what to do if it fails. The two mentions of 'free' are pricing, not usage 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?

No annotations are provided, so the description carries the full behavioral burden, and it does disclose two consequential traits: the $0.03 USDC cost with atomic units, and that no API keys are required. It omits rate limits, pagination, or whether depth is aggregated, which keeps it short of a 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?

Three sentences, zero waste, and the most decision-critical fact (paid, with exact price) is front-loaded before purpose and return shape. Every clause 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?

With an output schema present and 100% schema coverage, the description needn't describe return values, yet it usefully previews the payload fields anyway. It covers cost, auth, and scope, so nothing essential is missing for a low-complexity public market-data call, though sibling disambiguation is absent.

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 both parameters (coin with XBT→BTC/WETH→ETH normalization, nLevels max 100) are fully documented in the schema. The description adds no additional parameter meaning, 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+resource+scope: 'Hyperliquid public L2 order book depth', and the hl_ prefix plus the exchange qualifier distinguish it from the generic book_depth sibling. An agent can tell at a glance what data comes back (bids/asks with price, volume, n, mid, imbalance).

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 a useful precondition ('Public API only — no keys') and flags that the call is paid, which implicitly gates usage. However, it never says when to prefer hl_book_depth over the sibling book_depth or basis_snapshot, leaving the selection decision to inference from the name prefix.

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?

No annotations are provided, so the description carries the full burden. It does disclose two useful traits beyond the schema: the paid cost (50000 atomic USDC) and that it uses the public API without keys. It omits rate limits, read-only/reversibility framing, and latency or caching 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 dense sentence that front-loads the cost and then enumerates the payload. No filler, though the trailing field list duplicates what the output schema already conveys.

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?

One optional parameter with full schema coverage plus an output schema means return values need not be explained, and the tool is otherwise well-specified for its complexity. The only real gap is the undifferentiated overlap with the funding_snapshot sibling.

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 coin parameter, including the XBT→BTC / WETH→ETH normalization note, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond what the schema already documents, 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 verb+resource: a Hyperliquid perpetual funding snapshot with an enumerated payload. However, a sibling named funding_snapshot exists and the description never explains how hl_funding_snapshot differs from it, so sibling differentiation is missing.

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 price tag ($0.05 USDC) implies this is a paid alternative to a free sibling, but the description gives no explicit when-to-use-this-vs-funding_snapshot guidance. Nothing about when the paid call is warranted over the free path.

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