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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful runtime behavior: assets missing from either venue yield an error on that row, and basis and funding are always reported together rather than folded into one score.

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, followed by a short interpretive guide and a compact parameter block. Every sentence contributes; none repeats schema or annotation data.

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 tool with rich annotations and an output schema, the description covers semantics, constraints, error behavior, and interpretation. Nothing needed to call it 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?

The only parameter, symbols, has no schema description, but the Args block fully compensates by defining base tickers, giving an example, and stating both-venue listing and per-row error behavior.

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 action and resources: compare Coinbase spot against Hyperliquid perp basis, plus funding and positioning. It is unambiguous and clearly distinct from price/candles/orderbook tools, but it never names or contrasts the nearest sibling market_pulse_funding_rate, so sibling differentiation is only 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 conveys the intended use case: agents needing spot-perp basis, funding, and the joint positioning read, with the 'disagreeing is interesting' line highlighting when the combined view matters. It gives input eligibility constraints but no explicit when-not-to-use or alternative tool routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description is consistent with these. The description adds the Coinbase source, granularity options, and max limit, but does not disclose ordering, pagination, latency, or other runtime behavior beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a one-line summary and followed by a tightly structured Args list. Every sentence adds useful information and there is no filler or repetition of schema defaults.

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 candle fetch, the description covers the key parameters and the output schema supplies return-structure information. It would be slightly more complete with a note on candle ordering or time range behavior, but nothing essential is missing for basic 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 0%, so the Args section in the description carries the full burden. It gives meaningful semantics for all three parameters: example symbols, valid granularity values, and the max candle limit. This fully compensates for the otherwise bare 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 first line states a clear verb and resource: 'Get OHLCV candles for a crypto asset from Coinbase.' It is specific enough to distinguish from price or orderbook tools, though it does not explicitly name or differentiate a sibling 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?

The description gives no guidance on when to use this tool versus siblings like market_pulse_price, market_pulse_indicators, or market_pulse_summary. The intended use is only implied by the word 'candles', leaving the agent to infer the right context.

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 the operation read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds that the tool returns funding rate plus mark price and open interest from Hyperliquid, but does not disclose rate limits, freshness, or units; this is acceptable given the strong annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the purpose and followed by an Args section. There is no filler, repetition, or wasted detail.

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

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

Given one required parameter, a read-only annotation set, and an existing output schema, the description is nearly complete: it states the input format and the returned data categories. It omits minor details such as supported asset discovery or funding-rate period, but these do not block 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 0%, so the description carries the burden. It defines symbol as a base ticker and gives concrete uppercase examples (BTC, ETH, SOL), fully compensating for the empty schema and telling the agent exactly how to populate the required parameter.

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

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

The description identifies a specific verb and resource: it gets the current perpetual futures funding rate from Hyperliquid, and explicitly names the additional returned data (mark price, open interest). This clearly distinguishes it from sibling tools such as price, candles, and orderbook.

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 explicit when-to-use or alternative routing, but the usage is implied: call this tool when you need current funding-rate data. It does not mention alternatives like market_pulse_basis or market_pulse_supported_assets, so the guidance is only implicit rather than explicit.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations, such as granularity determining the annualization factor, limit affecting EMA-50 stability, and the minimum 15 candles for RSI-14/ATR-14. This goes beyond a simple 'compute' statement.

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 well-organized with a clear summary followed by an Args section. It is slightly padded by the implementation note ('All math is implemented from scratch... see file'), which is not directly useful for tool selection or invocation, but the overall length is appropriate for three parameters.

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

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

Given that an output schema exists, the description correctly focuses on input semantics and behavior. It covers the data source (Coinbase candles), indicator timeframes, annualization, and parameter effects, providing everything an agent needs to call 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 coverage is 0%, but the description fully documents all three parameters: symbol with examples, granularity with allowed values and its effect on annualization, and limit with stability and minimum requirements. This completely compensates for the schema's missing descriptions.

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

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

The description opens with a specific verb ('Compute') and names the exact technical indicators (RSI-14, EMA-20/50, ATR-14, annualized realized volatility) and the asset class (crypto asset). This clearly distinguishes it from siblings like market_pulse_price or market_pulse_candles, which serve different purposes.

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 establishes clear context: this tool computes technical indicators from recent Coinbase candles, so an agent can infer when to use it (needing derived indicators). It does not explicitly name alternatives or exclusions, but the sibling names plus this context make the selection straightforward.

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, and destructiveHint=false, and the description does not contradict them. The description adds value beyond annotations by disclosing the data source (Coinbase), the per-side depth cap (max 50), and the size cost of include_levels ('the ladder is `depth` pairs per side'), so the agent understands the verbosity trade-off of the heavy option.

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 definition is front-loaded with a dense, informative summary sentence followed by a clean Args block. The include_levels rationale is the longest part but earns its place by preventing an unnecessary heavy call, and no sentence is wasted.

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

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

For a 3-parameter read-only tool with an output schema and full annotation coverage, nothing needed to select and invoke it correctly is missing: source, return fields, parameter semantics, defaults, and the cost trade-off of the optional ladder are all covered. The only minor blemish is the schema title reading 'get_orderbookArguments' instead of matching the tool name.

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 0%, and the description fully compensates: symbol is clarified as the base ticker with examples ('BTC', 'ETH', 'SOL'), depth is defined as levels 'per side' with a max of 50, and include_levels explains its default-false behavior and the ladder cost. Every parameter gains meaning beyond the bare schema property names.

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

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

The opening sentence names a specific verb and resource — 'Get an order book snapshot for a crypto asset from Coinbase' — and enumerates the exact return fields (best bid/ask, spread in basis points, bid/ask volume imbalance over depth levels). This makes it easy to distinguish from siblings like market_pulse_price or market_pulse_summary, which cover single quotes and aggregate views rather than ladder depth.

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

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

The description gives clear context on what the tool returns and says the summary fields 'answer most questions', with include_levels to be enabled 'only to walk the book or size an order against real resting liquidity'. It provides clear context without explicit exclusions, but it never names an alternative sibling or states exactly when to pick this over market_pulse_price or market_pulse_summary.

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, and destructiveHint=false, so the safety profile is handled. The description adds useful behavioral context beyond that: the data source is Coinbase, and symbol normalization behavior is disclosed ('A trailing -USD or /USD is tolerated and stripped'). This is valuable operating detail without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely compact: one sentence for the tool purpose and a short Args block for the parameter. No repeated schema information, no filler, and the most important semantic detail is front-loaded. Every sentence 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 single-parameter, read-only spot price lookup, the description is complete. Annotations carry the read-only/idempotence guarantees, the output schema handles return-value documentation, and the description covers source, price type, and symbol formatting. The sibling `market_pulse_supported_assets` even covers the complementary concern of which symbols are valid.

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 0%, so the description must carry the full explanatory burden for the single parameter. It does this well by defining `symbol` as a base ticker, providing concrete examples ('BTC', 'ETH', 'SOL'), and documenting accepted suffix forms. An agent can confidently construct valid inputs from this description alone.

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

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

The description opens with a specific verb and resource: 'Get the current spot price for a crypto asset from Coinbase.' The word 'spot' plus 'current' clearly distinguishes it from sibling tools like market_pulse_candles or market_pulse_orderbook. It is immediately obvious what the tool does and where it fits.

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 establishes clear context for when to use it: whenever the agent needs the current spot price. It does not explicitly name alternatives or when-not-to-use cases, but the phrase 'current spot price' implicitly excludes historical candles, order books, funding rates, and derived indicators. A short explicit pointer to a sibling for historical data would make this 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?

The annotations already cover safety (readOnly, idempotent, non-destructive). The description adds useful behavioral context by explaining that the tool returns one aggregated table containing specific metrics for all requested symbols, which goes beyond what the annotations state. No contradiction.

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 compact and well-structured: one sentence for purpose and use case, followed by a concise Args block. There is no filler or redundant restatement of the schema, and the key aggregation behavior is front-loaded.

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 summary tool with one parameter, an output schema, and sibling tools, the description covers why to call it, what it returns, and how to specify symbols. Minor gaps such as exact ticker formatting rules or behavior for unsupported symbols are non-critical.

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 no property descriptions, so the 'Args: symbols' documentation carries the burden. It clarifies that symbols are base tickers and provides a concrete list example. It could be more specific about accepted formats or unsupported symbols, but it is sufficient for a single array parameter.

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

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

The description opens with a specific verb+resource: a compact multi-asset summary table combining price, spread, funding rate, and RSI/trend for each symbol. This clearly differentiates it from the individual market_pulse_* siblings such as price, orderbook, funding_rate, and indicators.

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 states a clear use context: a quick market scan, avoiding calls to individual per-asset tools. It does not explicitly enumerate when NOT to use it or name an alternative tool, but the 'without calling individual tools' phrasing establishes the main routing decision.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral detail beyond those annotations: coverage is non-uniform across venues, spot-only and perp-only assets have different capabilities, and symbol counts are always exact even when the returned list is truncated. This gives the agent an accurate mental model of expected behavior without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence delivers the core purpose, followed by a concise but necessary caveat about coverage variance, then a structured Args block. Every sentence adds information: venue semantics, search behavior, limit behavior, and exact-count guarantee. There is no filler or redundant restating of schema defaults.

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, the description does not need to enumerate return fields. It covers all invocation-relevant context: what the tool lists, why to call it first, venue-specific capabilities, parameter options, and exact-count behavior. The explanation of basis requiring both venues also ties into the sibling market_pulse_basis tool, making the broader tool landscape coherent. Nothing necessary 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 0%, so the description carries the full burden for all three parameters. It fully explains 'venue' with every accepted value and their meaning, 'search' as a case-insensitive substring filter with an example, and 'limit' with the note that counts remain exact regardless of truncation. This is exemplary parameter documentation in the absence of schema-level descriptions.

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

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

The description opens with a clear verb and resource: 'List which crypto assets this server can actually answer for, and on which venue.' It immediately differentiates this tool from the market_pulse_* data tools by framing it as a coverage-discovery tool, not a market data tool. The phrase 'Call this before a scan rather than discovering coverage by watching individual symbols fail' further clarifies its distinct role.

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 explicitly states when to use it: 'Call this before a scan', and what to avoid: 'rather than discovering coverage by watching individual symbols fail'. It also provides actionable guidance on venue selection by explaining the semantics of 'both', 'spot', 'perp', 'spot_only', and 'perp_only', so an agent can choose the correct slice. This goes beyond vague context and gives a clear decision rule.

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