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

Annotations declare readOnlyHint=true and openWorldHint=true, and the description reinforces this by explicitly stating no order is placed. It also discloses what the simulation returns. It doesn't mention latency, rate limits, or book staleness, but with annotations covering the safety profile this is solid added context.

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, zero waste, with the core behavior and the safety guarantee front-loaded before the invocation hint.

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

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

No output schema exists, but the description enumerates the return fields, which is the key missing piece for an output-less tool. Parameter guidance is adequately covered given 75% schema coverage. Minor omissions like rate limits or book freshness keep it from 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?

Schema coverage is 75% and the description adds a meaningful constraint not encoded in the schema: 'Give size or notional_usd', clarifying these are alternative sizing inputs. The symbol description already routes to strike_list_markets, so the remaining gap is minor.

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 ('Simulates a market order against the live book') and enumerates the exact outputs: average fill price, worst price, slippage vs mid in bps, liquidity coverage. This clearly distinguishes it from the sibling read-only data tools like get_orderbook or market_snapshot, which do not simulate executions.

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 'without placing anything' clause establishes the safe, non-trading context and 'Give size or notional_usd' directs how to invoke. However, it offers no explicit when-to-use versus alternatives (e.g., use get_orderbook for raw depth vs this for a fill simulation), leaving some inference to the agent.

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?

readOnlyHint and openWorldHint already establish that this is a safe external read, so the bar is lower. The description adds the default-to-own-account resolution behavior, but omits caching/freshness of balances, rate limits, and parameter precedence when several identifiers are passed.

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, front-loaded with the resource and its scope, then the identifier behavior. The field enumeration is dense but earns its space by telling the agent what it will receive.

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 compensates by listing the returned metrics, which is the right call. Only the interaction between account_id, sub_account_id, and wallet_address remains underspecified for a tool with zero required parameters.

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

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

Schema coverage is 100%, so all three parameters are already documented, including the 'no keys needed' note for wallet_address. The description reinforces the default-own-account and public-lookup semantics but adds no precedence or conflict rules beyond the schema.

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

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

States a specific resource (account balances and margin) and enumerates exactly which figures are returned, which is unusually concrete. It does not distinguish itself from near-siblings like strike_get_positions or strike_get_portfolio, so an agent must still infer the boundary.

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 usage context: no argument defaults to your own account, and any public account is reachable via wallet address. It stops short of naming when to prefer this over strike_get_positions or strike_get_portfolio, and says nothing about what happens if multiple lookup parameters are supplied.

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 openWorldHint, so the safety profile is covered. The description adds useful behavioral context by enumerating the returned summary stats (change, range, close-to-close volatility, volume), which the annotations alone do not convey. It omits any pagination/limit caveats, keeping it shy 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?

Two tight sentences, front-loaded with what the tool returns, followed by a concrete use case. No filler; 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?

No output schema exists, but the description compensates by naming the summary stats returned, and the schema covers key params. Interval and price_type semantics are the only meaningful gap, so it is nearly complete for a read-only data 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 60% and documents symbol, limit, and include_candles well. The description largely restates the stats output and adds no meaning for the undocumented interval and price_type enum parameters. Baseline 3 is appropriate given the schema does most of the work.

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 (OHLCV candles for a market) plus what else is returned (summary stats: change, range, volatility, volume). Clear enough to distinguish from siblings like strike_get_orderbook or strike_get_recent_trades, though it does not explicitly name that distinction.

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 concrete usage example ('how has ADA moved this week') that anchors the tool to trend questions. It does not mention when to prefer strike_market_snapshot or other alternatives, so exclusions are 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?

Read-only safety is already covered by readOnlyHint, so the description only needs additive context. It does disclose the useful ranking-by-absolute-APR behavior when no symbol is supplied, but says nothing about pagination limits or the shape/size of the returned set.

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 tightly packed sentences with the capability stated first and the no-symbol behavior second. Every clause adds meaning with 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?

For a read-only funding query with no output schema, the description conveys what is returned (rate variants, payer side) and the default ranking logic. The only meaningful omission is how limit interacts with the ranked 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?

Coverage is 50%: the schema describes symbol well and even points to strike_list_markets, while limit is undocumented in both places. The description's 'one market or all' clarifies symbol optionality but gives no meaning to limit, so it only marginally compensates for the gap.

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 (get funding rates) and resource (markets), and adds the concrete output content: hourly/8h/APR rates and who pays. The 'one market or all' scope also lets an agent distinguish it from snapshot or orderbook 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?

The description explains the conditional behavior when no symbol is given (ranking by absolute APR to surface carry opportunities), which implies a good use case. However, it never states when to prefer this over siblings like strike_market_snapshot or strike_get_sentiment, nor any 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavior — result ordering (newest first) and backward-only pagination via cursor — but says nothing about limits' effect on payload size, rate limiting, or the auth difference between account_id, sub_account_id, and wallet_address, which matters for a history endpoint.

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 resource enumeration comes first, then ordering, then pagination. Every clause carries information an agent needs before calling.

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 9-parameter history tool with no output schema, the description does not indicate what a returned row contains or how records differ across the five kinds, which is the main gap an agent would hit when interpreting results. It is adequate to invoke the tool correctly, but not complete enough to use the output confidently.

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 already fairly high at 78%, so the baseline would be 3. The description earns the extra point by translating enum values into domain meaning — 'fills (trades)', 'positions (closed positions)', 'transactions (deposits, withdrawals, transfers)' — and by explaining that the cursor is an id taken from the last returned row.

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 ('Account history') and enumerates the five record kinds it returns, mapping each to plain language (fills = trades, positions = closed positions, transactions = deposits/withdrawals/transfers). This implicitly separates it from siblings like strike_get_open_orders and strike_get_positions, though it never names them 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?

It gives concrete paging guidance ('Use cursor (an id from the last row) to page back') and sort direction, which helps invocation. But there is no explicit when-to-use vs. alternatives — nothing says to prefer strike_get_open_orders for live orders or strike_get_positions for current positions over this historical view, leaving that inference to the agent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful scope by clarifying that only open and untriggered orders are returned and listing order types, but it does not cover pagination, filtering defaults, or authentication nuances beyond what the schema implies.

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 efficient sentence that front-loads the resource and scope. Nothing is wasted, and the order-type enumeration adds useful precision without bloating.

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 and full schema description coverage, the definition is minimally adequate. It does not explain return shape, pagination, or how it differs from history-oriented siblings, leaving some contextual gaps.

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 four optional parameters are already documented in the schema. The description only adds the general account context and does not explain how symbol, account_id, sub_account_id, or wallet_address interact, 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?

The description states a clear resource and scope: open and untriggered orders, including limits, stops, take-profits, and trailing stops, for an account. It is specific enough for an agent to know what is returned, though it does not explicitly distinguish itself from sibling tools such as strike_get_history.

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 phrase 'for an account' and the order-status scope, but there is no explicit guidance on when to use this tool versus alternatives like strike_get_history or account-level tools. It is adequate but leaves routing 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context by listing the returned order-book fields, but it does not mention rate limits, pagination, or other behavioral constraints beyond what annotations provide.

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 with no wasted text. It efficiently conveys the resource and the key returned metrics.

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 retrieval tool with rich schema coverage and annotations covering safety, the description is largely complete. It explains the returned order-book contents, though it does not describe pagination or return-structure details.

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 are already documented in the schema. The description mentions top price levels per side, which loosely maps to the levels parameter, but it does not add meaning beyond the schema.

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

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

The description states a specific resource and enumerates the returned order-book contents, including top levels and summary metrics. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as strike_market_snapshot or strike_estimate_market_impact.

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 guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The resource name implies order-book retrieval, but the description does not help an agent choose between this and related market-data tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful detail about what portfolio data is returned, but it does not disclose permission or wallet requirements, selector behavior, or whether some fields require API-wallet context.

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 a single front-loaded sentence listing the key returned metrics, with no filler. It is somewhat dense but still readable and appropriately sized for a read-only portfolio summary.

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?

There is no output schema, so the description usefully enumerates the returned performance dimensions. However, it leaves gaps around selector behavior, the role of history_points, and how the three account lookup parameters interact, which matters for a tool with four parameters and multiple lookup modes.

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 high at 75%: account_id, sub_account_id, and wallet_address have descriptions, while history_points has bounds and a default but no textual schema description. The description mentions a recent account-value curve but does not explain that history_points controls its length, so it adds only marginal parameter meaning beyond the schema.

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

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

The description clearly states the resource and scope: long-run portfolio performance with realized PnL, volume, fees, deposits/withdrawals, fee tier, staking discount, and account-value curve. It does not explicitly distinguish itself from siblings like strike_get_account or strike_get_history, but the returned data set is specific enough for an agent to understand its purpose.

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 alternatives such as strike_get_account, strike_get_positions, or strike_get_history. It also does not explain when to prefer wallet_address, account_id, or sub_account_id lookups.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not burdened with safety disclosure. It goes beyond them by explaining what is computed and returned (risk flag derived from thresholds, funding per day, distance to liquidation), which is real added context. It still omits auth nuances for the account lookup modes and any rate-limit 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?

Two sentences, no filler: the first front-loads the return payload and the second front-loads the user intents. 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 no output schema, the description does the heavy lifting by naming the key returned fields and the flag semantics, which is what an agent needs to decide the tool fits. Remaining gaps are scope questions: whether positions span all accounts or only the identified one, and whether results are paginated or filtered by symbol.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above baseline by explaining that the ok/watch/danger flag is the output of watch_pct and danger_pct, connecting the threshold parameters to the return value. It says nothing about how symbol, account_id, sub_account_id, and wallet_address interact or which takes precedence.

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?

Specific verb+resource ('open positions') with an explicit enumeration of the enriched fields returned: mark price, notional, PnL as % of margin, liquidation distance, risk flag, and daily funding. It is clearly distinguishable from sibling strike_get_portfolio and strike_get_account because it describes position-level risk computation rather than balances or holdings.

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 concrete trigger phrasings ('how are my positions', 'am I close to liquidation', 'what is funding costing me') that map cleanly to invocation scenarios. It does not, however, explicitly exclude or route to overlapping siblings such as strike_get_portfolio or strike_get_account when the user asks broadly about their account.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuine context by disclosing that results include a derived taker-flow summary (buy vs sell volume, largest trade), which is not visible from the schema. It says nothing about recency window, pagination, or whether trades are real-time, so it stops short of rich behavioral disclosure.

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; the resource comes first and the distinguishing return-value detail follows. Nothing is redundant with the schema or annotations.

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 query with no output schema, the description covers purpose and the shape of the response summary, which is enough to call it. However, two of three parameters carry no explanation anywhere, and the recency/ordering semantics of 'most recent' are undefined, leaving meaningful gaps.

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 only 33% — symbol is documented in the schema (with a pointer to strike_list_markets), but limit (default 200, max 1000) and include_trades (default 20, max 100) are undocumented. The description mentions a trade summary but never explains how limit vs include_trades differ or what they control, so it fails to compensate for the coverage gap.

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 in a market") plus the added value of a taker-flow summary. An agent can tell it apart from strike_get_orderbook or strike_get_candles by the 'executed trades with buy/sell volume' framing, though no sibling is named 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?

Usage is only implied: 'recent trades in a market' suggests a post-trade flow lookup, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as the orderbook (resting liquidity) or candles (aggregated OHLC). The agent must infer the distinction from the sibling names.

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 openWorldHint, so the safety profile is covered; the description adds real behavioral context by identifying the data source (the exchange's own 24h tape, not an external feed) and an explicit caveat that the value is display-only and unsuitable as a risk input. It does not mention refresh cadence or snapshot staleness, which would have pushed this to 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?

Two tight sentences with zero filler: the first front-loads what the index is, its range, its derivation, and its components; the second delivers the critical usage caveat. Nothing is redundant or buried.

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 parameters, no output schema, and annotations covering the safety profile, the description supplies nearly everything needed to call and interpret the tool. The only gap is the return shape — whether callers get a bare score or an object including the named momentum/breadth/volatility components — which is left ambiguous.

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 at the parameter level; baseline 4 applies. The description's scale note (0–100) usefully pre-frames how to interpret the parameterless result.

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 (Strike's Fear & Greed index) with its exact scale (0 extreme fear to 100 extreme greed), source (the exchange's own 24h tape), and sub-components (momentum/breadth/volatility). This clearly separates it from sibling market-data tools like strike_market_snapshot or strike_get_orderbook, which return prices/depth rather than a derived sentiment score.

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 'Display-only, not a risk input' gives a meaningful when-not-to-use boundary for risk/position-sizing decisions. However, it never names an alternative tool or states the positive condition that selects this one (e.g., 'use when gauging crowd positioning vs. strike_market_snapshot for current prices'), so the routing guidance is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-data characteristics are covered structurally. The description adds return-content detail (funding quoted as APR) which is genuinely useful, but says nothing about default page size (limit=50), pagination limits, or whether inactive markets are silently excluded.

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 what is returned, then the use case. No redundancy and nothing 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 read-only list tool with no output schema, the description adequately covers what comes back and why to call it. The notable gap is that the undocumented limit and include_inactive parameters affect result shape and pagination, which an agent would need to know.

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 50%: sort_by and category are documented, but limit and include_inactive are undocumented in both schema and description. The description's ranking hints ('top movers, highest funding') loosely map to sort_by values but never explain limit or include_inactive, so it fails to compensate for the coverage gap. 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 ('Lists') and resource ('every Strike perpetual market') and enumerates the returned data (price, 24h change, volume, open interest, funding as APR). The scope word 'every' implicitly contrasts with strike_market_snapshot, so an agent can distinguish them without opening schemas.

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 usage contexts: discovering symbols, ranking markets, top movers, most traded, highest funding. It never names an alternative tool or states when not to use this one, 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description's added value is the contents inventory, but it says nothing about data freshness/latency, whether values are point-in-time or rolling, failure behavior for unknown symbols, or rate limits — meaningful gaps for a market-data call.

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

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

A single front-loaded sentence that opens with the value proposition ('one-call brief for a single market') before the field list — no filler. It is dense with domain jargon (funding APR, mark vs index premium) that a newcomer would need to decode, which keeps 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, the description carries the burden of telling the agent what comes back, and it does so field by field. Given a one-parameter read tool, the remaining gaps (freshness, units, empty/error cases) are minor rather than disqualifying.

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?

Only one parameter, and the schema already fully documents it at 100% coverage, including examples and a pointer to strike_list_markets for discovery. The description adds nothing about the symbol parameter (e.g. case sensitivity, normalization, error on invalid symbol), 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 ('a single market') and enumerates exactly what is bundled: price, 24h range/change, volume, open interest, funding, mark vs index premium, spread and book depth/imbalance. This is clearly an aggregate snapshot rather than a single-metric call, which implicitly separates it from siblings like strike_get_orderbook and strike_get_funding. It stops short of naming those siblings explicitly, so it is not 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?

The phrase 'one-call brief' implies this is the shortcut instead of stitching together strike_get_candles, strike_get_funding and strike_get_orderbook, but that comparison is never stated. There is no explicit when-to-use, when-not-to-use, or named alternative, so usage must be inferred from the sibling list.

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