whale-data

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

Annotations already mark it read-only, idempotent, and non-destructive, so the bar is lower. The description adds valuable behavior beyond annotations: the access-tier difference (Keyless vs Starter and up), the exact fields returned at each tier, and the explicit 'Descriptive, not a forecast' caveat that prevents an agent from treating it as predictive.

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 dense but every sentence earns its place: what the tool returns, how to phrase queries, access-tier behavior, and a caveat. It front-loads the core resource and follows with usage and behavior details without any 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?

Given the output schema, annotations, and optional parameters, the description is complete. It explains the live-setup scope, field categories, access-level return differences, and the descriptive-only nature of the data, so an agent has enough context to select and invoke 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?

The input schema already documents all three parameters at 100% coverage, including defaults and the coin/pair alias. The description adds some contextual meaning by showing a natural-language coin-filter query ('is there a setup on SOL'), but it does not substantially go beyond the schema for actual parameter semantics.

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 identifies the tool as the engine's live whale-flow setups, with concrete fields (state, direction, catch type, severity, age, price move). The use phrases ('what setups are live', 'is there a setup on SOL') and 'not a forecast' distinguish it from the many sibling market-data tools.

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 explicit query patterns for when to use the tool: 'what setups are live', 'is there a setup on SOL', 'what is the engine watching'. It also warns the data is descriptive, not a forecast, which discourages misuse, though it does not name specific alternative tools or state when not to use it.

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, establishing a safe read-only operation. The description adds valuable context beyond these annotations: it clarifies these are executed liquidations (not projected levels), split by long/short, and characterizes the data as descriptive market data only. This enriches the agent's understanding of the tool's 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 description is compact and front-loaded with the core purpose, then supplies crucial sibling differentiation and a note about the tool being the plain-English name for liquidations. Each sentence adds distinct value—purpose, behavioral distinction, and routing—with no filler or redundant repetition of schema details.

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

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

Given that an output schema exists and annotations already cover safety and idempotency, the description addresses everything an agent needs to correctly select and invoke the tool: what it returns (recorded, split long/short), when to use it versus alternatives, and the nature of the data (descriptive, not projected). No critical context appears missing.

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

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

Schema description coverage is 100%, so the input schema fully documents all five parameters (coin, pair, hours, limit, since_ms) including their semantics and constraints. The description does not add any parameter-specific meaning beyond what the schema already provides, so it meets the baseline of 3 without exceeding 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?

The description states exactly what the tool does: returns already-recorded forced closes (liquidations) for one pair, split into long versus short. It distinguishes itself from sibling tools liq_zones (projected levels) and market_liquidations (whole market) explicitly, so an agent can tell them apart 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?

It names specific alternatives and the conditions for selecting them: use liq_zones for where liquidations could happen next, and market_liquidations for the whole market at once. It also clarifies it is for recorded data on a single pair, leaving no ambiguity about when to invoke this tool.

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 mark readOnly, idempotent, and non-destructive. The description adds meaningful context beyond that: it is 'Free to call, same on every plan', 'Descriptive market data only', and it explicitly reports streamed/free set status plus 'where recorded' for data availability. This gives the agent access, cost, and data-boundary information the annotations do not 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 compact and front-loaded: the first sentence packs the search action, input examples, and key output fields. The following sentences add usage timing, cost/access, and scope limitations. Every sentence earns its place 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?

An output schema exists, so return-value documentation is not the description's job. Given that, the description covers the essential selection context: when to use it, what makes it special (free, streamed/free-set flags, symbol resolution), and its limitation as descriptive market data only. Nothing needed to invoke 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?

Schema description coverage is 100%, with all four parameters documented including query, pair alias behavior, and limit defaults/ceiling. The description does not add parameter-level semantics beyond that, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: 'Search the coin catalog by symbol or part of a name'. It also distinguishes itself from siblings by naming what it returns: the canonical symbol other tools take, streaming/free-set status, and market data. This is much more precise than the generic title 'Find a coin'.

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?

Directs the agent to 'Use it first when a coin is unfamiliar or ambiguous, and for "which coins are ..." discovery.' This is a clear context for when the tool should be chosen. It does not explicitly name alternatives or when-not-to-use cases, 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 the tool as read-only, idempotent, and non-destructive. The description adds behavioral nuance: it notes that news is 'a candidate explanation for a move, never asserted as the reason' and that it provides 'descriptive market data only.' This adds interpretive context beyond the annotations, though it doesn't detail response shapes or error handling, which is partially covered by the output schema and parameter descriptions.

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-structured and front-loaded with the core purpose, followed by usage examples and alternatives. Every sentence adds value—the alternative routing, the caveat about news not being the reason, and the 'descriptive data' tag. No fluff, and it remains readable despite its length.

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?

The description covers the tool's purpose, typical queries, distinction from alternatives, and the interpretive stance on news. Combined with a rich input schema and existing output schema, nothing essential is missing for an agent to use this tool correctly. The only minor gap (what 'market-wide picture' entails) is not critical given the overall context.

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 schema has 100% description coverage for both parameters, including defaults, aliases, and edge-case behavior (covered:false). The tool description adds no additional parameter-specific meaning, so per the baseline rule for high schema coverage, a score of 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 clearly states the tool's function: 'The headline read for one coin: recent headlines, the written points behind them, a pre-computed mood score (-100 to +100) and the market-wide picture alongside.' It specifies a verb (read) and resource (headlines for a coin), and differentiates from siblings by naming market_brief as the alternative for 'why is X moving'. This makes it distinct from the many other tools.

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 states when to use this tool: 'Use it when the HEADLINES are what was asked for' with concrete examples, and when not to: 'For "why is X moving" call market_brief instead' with reasoning that market_brief already contains the news. This is clear guidance that routes the agent correctly among alternatives.

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. The description adds valuable behavioral context: keyless access, descriptive market data only, and clarifies that 'count' and 'total_usd' cover exactly the returned rows with a 'window' field, avoiding misinterpretation of fixed 24h figures. This exceeds the annotation baseline.

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, each dense with information: scope, event distinction, and metric semantics. No fluff, front-loaded with the most important purpose, and 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?

Given an output schema exists and annotations cover safety, the description covers scope, event type, chain availability, metric semantics, and alternative tool differentiation. It is complete for a read-only filtered tool with simple 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 description coverage is 100% for both parameters, providing full documentation. The description further clarifies the 'limit' parameter's behavior (defaults, hard ceiling) and the 'chain' parameter's refusal behavior, adding value beyond schema. Baseline 3 is elevated to 4 due to meaningful extra context.

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 ('repaid debt and seized collateral') and clearly names resources (Aave V3, Morpho Blue on Ethereum, Arbitrum, Base). It distinguishes from the sibling 'liquidations' tool by explicitly saying it's a different event and never summed with one.

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

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

It provides clear context on what the tool covers (lending liquidations vs perp liquidations) and names the alternative 'liquidations' tool for perp liquidations. It does not explicitly say 'when not to use' beyond the differentiation, but the guidance is specific enough to select correctly.

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. The description adds valuable behavioral context beyond that: keyless access returns totals and a short token list with swap USD withheld, while a paid plan returns the full table. It also notes 'Descriptive market data only,' clarifying the nature of the data. No contradiction with 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 compact yet information-dense: first sentence defines the resource and outputs, second sentence provides usage context with example questions, third sentence covers access limitations and alternatives. Every sentence earns its place, and no filler exists.

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 the tool has no parameters, annotations already cover safety and idempotency, and an output schema exists, the description supplies all extra context an agent needs: content, usage intent, alternative routing, and access-tier behavior. Nothing material 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 tool has zero parameters, so there is nothing for the description to document. The baseline for a parameterless tool is 4, and the description correctly focuses on behavior and output rather than inventing parameter guidance.

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 identifies the tool as a one-call on-chain DEX state summary across Ethereum, Base, and Arbitrum, listing concrete outputs like 24h volume, TVL, top tokens, and whale swap activity. It also explicitly distinguishes itself from sibling tools by naming onchain_whales and whale_profile as alternatives, making purpose unambiguous.

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 this tool ('Use this for the DeFi / on-chain picture') with concrete example queries, and gives clear routing guidance: for individual wallets use onchain_whales, for CEX whale flow use whale_profile. This is explicit when/when-not guidance with named alternatives.

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 mark read-only/idempotent; the description adds useful behavior beyond that: Keyless results withhold wallet addresses, Starter+ names wallets, and the data is 'descriptive market data only'. This clarifies access-tier behavior and non-actionable nature without overclaiming.

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 dense sentences, all front-loaded with the core resource first, then usage examples and access caveats. No filler or repetition of schema fields.

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 tool with an output schema and safety annotations, the description covers the two modes, chains, time window, returned fields, access tiers, and next-step routing. Nothing essential is missing for tool selection and 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 coverage is 100%, so the baseline is 3. The description adds value by explaining the token mode ('24h whale-swap snapshot') and board mode, but it does not add new meaning for chain or limit beyond the schema 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?

Description names a specific resource (DEX whale board), scope (Ethereum, Base, Arbitrum, last 48h), content (ranked wallets with buy/sell dollars, chains, token count, behavior classification) and the per-token mode. This gives enough specificity to distinguish it from CEX whale boards and the dex_wallet 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?

Provides explicit example queries ('who is moving size on chain', 'who is trading PEPE on chain') and explains the token mode vs wallet-board mode. It also routes wallet-level detail to dex_wallet, but does not explicitly state when not to use this tool versus other whale/DEX siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable context beyond annotations: the 7% coverage limit, the meaning of tracked:false, and the 'descriptive market data only' caveat. No contradiction with 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?

Three sentences, each purposeful: the first states the tool's function, the second disambiguates from a sibling, and the third discloses the critical coverage limitation. No wasted words; information is front-loaded and directly relevant.

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 the output schema exists (so return values are documented) and annotations cover safety, the description provides the essential remaining context: the tool's scope (Ethereum/Base/Arbitrum), the sibling distinction, and a realistic coverage limitation that affects interpretation. This is complete for an agent to use the tool correctly.

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

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

Schema description coverage is 100%, so the schema already fully describes both parameters, including address format and limit defaults/cap. The tool description reinforces the address/vs Hyperliquid distinction but does not add new parameter-specific meaning beyond what is in the schema, so 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 opens with 'One Ethereum, Base or Arbitrum address: its recorded DEX swaps, net flow per token and activity pattern,' clearly identifying the resource (wallet address) and specific actions (DEX swaps, net flow, activity pattern). It also explicitly distinguishes from hl_wallet, ensuring no confusion among 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?

It gives explicit direction to use hl_wallet for Hyperliquid accounts ('For a Hyperliquid ACCOUNT use hl_wallet instead') and warns about the 7% coverage limit with the instruction to 'state it once when the answer turns on it,' which guides when and how to interpret results. This is strong 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description only needs to add non-obvious data behavior. It discloses that records are 'logged live and never backfilled' and that the tool returns 'descriptive market data only', both useful contextual traits. No contradiction with 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?

Two short sentences with no filler; the first is front-loaded with the tool's core payload, and the second adds routing and scope. Every clause earns its place despite a minor formatting issue around 'signal_record.Descriptive'.

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 no required parameters, the description does not need to enumerate return fields. It covers freshness, backfill behavior, scope, and the key alternative, leaving only minor domain nuance around 'signal-ledger flags' unexplained.

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 schema covers all five parameters at 100%, including defaults, caps, and the 'capped' notice in the payload. The description does not add parameter-level detail beyond what the schema already provides, so the baseline score 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 ('signal-ledger flags with fire-time price and later price outcomes') and explicitly distinguishes it from signal_record. It lacks a direct retrieval verb like 'list' or 'return', but the title and noun-phrase style still make the operation unambiguous.

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 explicitly routes the single-signal/single-coin case away: 'For one signal type on one coin (how the last N played out) use signal_record.' The first sentence also constrains scope to recently fired, live, non-backfilled data, which tells the agent when this tool is relevant.

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 description discloses that predicted rates are only returned 'where the venue provides it', notes free-plan limitations ('On the free plans BTC in full and any other pair as a headline'), and states 'Descriptive market data only'. This aligns with readOnlyHint=true and adds context (e.g., predictive nature, plan-based 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 a single paragraph but packs purpose, usage scenarios, alternatives, and a free-plan caveat. It is well-structured and front-loaded with the core purpose, though slightly long; every sentence earns its place, so it is appropriately concise.

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 the presence of a detailed input schema, an output schema, and annotations, the description covers purpose, usage, alternatives, behavioral caveats, and plan-based limitations. Nothing an agent needs to decide whether to call this tool or how to invoke 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 schema description already covers 100% of parameter meaning, including default behavior, bare-symbol interpretation, and free-plan effects. The tool description only refers to 'one pair' without adding any parameter-specific semantics, thus meeting the baseline for high schema coverage but not enriching it further.

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 ('Per-venue funding rates for one pair, side by side') and the output nature (predicted next rate and payout time where available). It provides concrete usage examples ('compare BTC funding across venues') that clearly distinguish it from market_brief and market_history, making the tool's purpose unambiguous.

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 says 'Use this when the user asks about funding across exchanges, where funding is most extreme, or where perp longs vs shorts are paying'. It names alternatives (market_brief for single average funding, market_history/market_extremes for historical comparisons) and explains what they cover, so the agent knows exactly when to choose this tool over others.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds meaningful behavioral context: the keyless vs. paid access difference, that keyless returns only top rows and states withheld counts, and that this is 'descriptive market data only.' No contradiction exists.

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 yet information-dense: it leads with the core data content, gives concrete usage examples, then routing to alternatives, and closes with access-tier behavior. Every sentence earns its place and there is no fluff.

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 tool with an output schema, the description is fully complete: it defines the data, gives usage context, differentiates from relevant siblings, and explains access limitations. Nothing an agent needs to correctly select and invoke this tool 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 tool has zero parameters and the schema already covers everything, so the baseline is 4. The description compensates by explaining what the returned board contains and the kinds of questions it answers, which adds semantic value beyond the empty 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 identifies the tool as an aggregated view of tracked Hyperliquid whale accounts, listing the exact data dimensions (equity, open notional, leverage, net bias, per-coin crowding). It also distinguishes itself from sibling tools like hl_wallet and hl_whales, so an agent can confidently select it for positioning questions.

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 this tool ('how the tracked HL whales are positioned right now') with concrete example queries, and also names alternatives for different intents: hl_wallet for a specific wallet, smart_money or hl_traders for profitable traders, and hl_whales for recent fills. This is explicit when/when-not 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?

The annotations already declare read-only and idempotent behavior, but the description adds important context beyond that: keyless returns only the proven-trader cohort, a plan returns every tracked account up to the row cap, since_ms is a polling cursor, and this is 'descriptive market data only'. None of this contradicts 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 compact and front-loaded with the most important identifying information, followed by concrete usage examples and behavioral caveats. Every sentence earns its place; there is no filler or restatement of the schema.

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 the annotations, the complete 100% schema coverage, and the presence of an output schema, the description covers what an agent needs to select and invoke the tool: the event type, returned fields, filters, polling cursor semantics, and access-tier behavior. There is no obvious missing context that would cause a wrong call.

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, but the description adds useful meaning by summarizing the filter dimensions ('Filter by coin, wallet or kind') and tying since_ms to a polling cursor and next_since_ms. It also gives limit-related context through the plan row-cap behavior, going slightly beyond the raw field 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-resource pair: 'What named Hyperliquid accounts just DID', then enumerates the concrete move kinds (open, add, trim, close, flip) and the returned fields (coin, side, size, standing position, leverage, liquidation price). This distinguishes it from sibling tools like hl_traders or hl_wallet, which focus on profiles or balances rather than position-change events.

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 explicit use examples ('what did the big accounts just do', 'did anyone flip short on BTC', 'what is Trader 7 doing') and explains the keyless vs. plan behavior, which tells an agent when it can get the cohort view versus all tracked accounts. It does not explicitly name sibling alternatives or state when not to use this tool, 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?

Beyond the read-only and idempotent annotations, the description discloses significant behavioral traits: only closing fills are used, equity/ROI/MM ratio are deliberately not verified, net PnL is shown beside gross and fees, profitableCloses counts distinct actions not partial fills, and keyless access returns truncated rows with a withheld count. No contradiction with 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 dense and front-loaded with the core purpose, then moves through caveats, field semantics, and access tiers. It is somewhat long and the first sentence packs many concepts, but every sentence contributes necessary distinction from sibling trader tools.

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 no-parameter read-only dataset with an output schema, the description is complete: it explains data provenance, what is and isn't verified, how the data differs from sibling tools, what fields mean, and what access tiers receive. Nothing critical 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 tool has zero parameters, so the 0-param baseline of 4 applies. The description goes further by clarifying output field semantics such as net realizedPnl and profitableCloses, which is useful even though it is not parameter documentation.

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 identifies the tool's purpose: returning Hyperliquid wallets with closed trades that meet realized-profit and human-pacing screens, so profitable traders outside ranked boards are captured. It also explicitly distinguishes the claim from smart_money and the proven-trader board, helping an agent differentiate at a glance.

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 clear context: use this when you need a broader set of verified traders based on closing fills rather than ranked leaderboards, and it warns that this is a weaker, different claim than smart_money or the proven-trader board. It does not provide an explicit 'when not to use' list, but the alternatives are named and the distinction is sharp.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses meaningful behavior: the live book is public and available on free plans, while win rates, cadence, realized PnL, and the full fill trail are plan-gated. The closing 'Descriptive market data only' also sets expectations about scope. This adds real value beyond the annotations and does not contradict them.

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 front-loaded: the first sentence states what the tool returns, and the second adds the plan nuance. Every sentence earns its place, though the final 'Descriptive market data only' clause is somewhat generic and could be trimmed or folded in without losing much.

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?

The tool has an output schema, so return-value documentation is already handled. The description covers scope, plan gating, and public-data availability, while the schema covers address and limit semantics. A qualified agent has everything needed to invoke it correctly.

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

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

Both parameters are fully documented in the input schema, including the address format, the tracked/untracked account distinction, and the limit behavior with defaults, free-plan caps, and ceilings. The description itself adds little parameter-level detail, so the schema carries the semantic weight, which is the expected 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?

The description opens with 'One Hyperliquid account' and enumerates the exact contents: live positions, equity, leverage, net bias, unrealized PnL, and recent whale-sized fills. This makes the resource and scope unmistakable, even without an explicit verb, and clearly distinguishes it from aggregate siblings like hl_whales or hl_traders.

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 communicates a clear use case: retrieve a single Hyperliquid account's live book and recent fills. It also gives plan-based guidance by saying the live public book stays on free plans, while computed history and the full fill trail require a paid plan. It does not name an alternative sibling for paid-only data, so it stops short of full exclusion 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?

Annotations already declare readOnly, idempotent, and non-destructive, so the description doesn't need to restate safety. It adds behavior beyond annotations: every fill row is 'followable to a live book', the data is 'descriptive market data only', and the venue uniquely names both sides of fills. It could add more about time window or rate limits, but the schema and output schema cover much of that.

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 the core capability, then gives a use example, sibling routing, and access note in compact sentences. No filler or tautology; each sentence adds decision-relevant 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 zero-required-parameter read query with fully covered schema and an output schema present, the description covers the tool's purpose, differentiation, use cases, and access posture. Nothing necessary for an agent to select and invoke 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?

Schema description coverage is 100%, and the input schema already documents coin, pair, limit, and since_ms with domain-specific detail (e.g., kPEPE matching, polling cursor semantics). The description itself adds no parameter-level meaning beyond the general use case, 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 opens with a precise verb+resource statement: 'Recent whale-sized Hyperliquid fills WITH THE WALLET ADDRESS attached.' It gives an explicit query example ('which HL whales just bought BTC') and differentiates itself from sibling tools by naming the venue's unique named-feed property.

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 tells the agent exactly when to use this tool ('Use this to see which named accounts just traded a coin') and routes to specific alternatives: hl_wallet for per-wallet book/leverage, hl_board for ranked board/net bias, and smart_money for the profitable cohort. 'Keyless' also clarifies access expectations.

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

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

Annotations already establish read-only and non-destructive behavior. The description adds valuable context about data scope and plan limitations: keyless access gives free pairs for the last 3 hours, Starter covers every streamed pair, and Pro adds 12-hour and projected grids. It also notes the data is descriptive market data only.

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 front-loaded with the core concept, then moves to usage scenarios, plan tiers, and alternative tools. Every sentence adds useful information without redundancy or 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?

Given the output schema exists, the description does not need to explain return values. It covers what the tool does, when to use it, how it differs from related tools, data availability by plan, and the fact that it is read-only descriptive data. This is complete for an agent to select and 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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description only adds that the grid is for 'one pair,' which aligns with the pair/coin parameters but does not meaningfully extend the schema's documentation.

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 tool's function: a realized liquidation heat grid for one pair, broken down by price band in 5-minute columns, with the hottest cell named. It also distinguishes itself from sibling tools by explicitly contrasting with liq_zones and liquidations.

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 explicit use cases: 'where did the liquidations cluster today' and 'which price band got hit hardest'. It also provides clear routing guidance, directing the agent to liq_zones for projected levels and to liquidations for individual events.

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?

Beyond the readOnly/idempotent annotations, the description reveals meaningful behavior: history survives restarts, sell-side events are always long liquidations, counts are event counts rather than dollars, and truncated results affect only returned rows. None of this is available from annotations or the input schema, and it does not contradict 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 dense but every sentence earns its place: purpose, methodology, field semantics, parameter default, truncation caveat, and a final scope guard. It is front-loaded with the core behavior and avoids repeating the schema verbatim.

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 pair-scoped read-only data tool with an output schema, this is complete: it covers the default window, the truncation semantics, and clarifies the long vs short dollar split ahead of the output schema. The annotations already cover safety, and the schema covers parameter formats, so nothing needed 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 coverage is 100% and the schema already documents coin/pair, hours, limit, and since_ms. The description adds useful semantics beyond that, especially the hours default ('hours: 24 for today'), what happens when hours is omitted, and the meaning of window_minutes and truncation; it does not deeply expand every parameter, so a 4 rather than a 5.

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 by naming the resource and scope ('Liquidation trades for a pair with the long and short breakdown'), so an agent can tell it is pair-scoped rather than market-wide. It is not a tautology and conveys the live-plus-recorded merge, but it never names sibling tools such as market_liquidations or coin_liquidations to differentiate them.

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 explains parameter-driven behavior ('Pass hours... without it...') and adds the caveat 'Descriptive market data only', but it gives no guidance on when to choose this tool over any of the many liquidation/market sibling tools. No alternative is named and no exclusion condition is stated.

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, so the description does not need to repeat those. The description adds valuable context about the projection nature ('not executed trades'), plan-specific behavior (free gets BTC without cascade chains; paid gets full snapshot), and 'Descriptive market data only'. This goes beyond the annotations and helps the agent understand expected behavior and limitations.

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 three sentences with no waste. It front-loads the core purpose and adds plan constraints in the final sentence. Every sentence earns its place, and it is highly efficient for the information conveyed.

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?

The tool is simple with two optional parameters and an output schema, so the description need not explain return values. It adequately covers the purpose, scope, and plan limitations. For a read-only, idempotent tool, nothing critical is missing; an agent can call it correctly with the given description.

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 fully documented in the schema, including the default behavior and alias handling. The description repeats some of this (e.g., plan differences) but does not add new meaning beyond the schema. Baseline 3 is correct because the schema already carries the parameter semantics effectively.

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 tool provides a 'projected liquidation level book for one pair', specifically distinguishes it as a projection rather than executed trades, and notes it is 'Descriptive market data only'. This is a specific verb+resource with clear scope, and it differentiates from other liquidation tools by emphasizing projection and single-pair focus.

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 about when this tool is appropriate: for projected levels on one pair, with plan-based limitations (free vs paid). It does not explicitly name alternatives or state when not to use it, but the 'projection' and 'one pair' nature implies when it should be used relative to other tools. This is clear context without explicit exclusions, so a 4 is appropriate.

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 destructiveHint=false, and the description adds context by stating 'Descriptive market data only'. It also discloses the free-plan limitation (full BTC answers vs. headline-only for other coins) and the identical data/credit cost to trade_context, which are valuable beyond the annotations. No contradictions.

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 long but front-loaded with the core purpose and example queries. Each sentence adds meaningful information—scope, components, usage examples, exclusions, and additional behavioral notes. Slightly verbose but earned, not padded.

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?

Despite having an output schema, the description explains the causal order and typical use cases, names alternatives, provides exclusions, and covers parameter nuances (free plan, compact mode). It leaves nothing an agent needs to call it correctly, and the output schema handles return 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 the schema already fully documents all four parameters. The description does not add semantic details beyond the schema, though it does restate that 'coin' is an alias for 'pair' and mentions the compact option. Baseline 3 is appropriate since the schema carries the weight.

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 it provides the complete current answer for ONE coin, listing specific components (price, news, whale flow, funding, etc.) and explicitly names the sibling tool trade_context as identical. It also gives concrete example queries ('why is BTC pumping'), making its purpose unmistakable and distinguishable from other tools.

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 explicit when-to-use guidance with example questions, and explicitly instructs the agent not to follow up with crypto_news or separate whale/funding/liquidation tools unless the user drills in. It also names the alternative trade_context, providing clear selection criteria.

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. The description adds 'Descriptive market data only,' reinforces the read-only nature, and mentions that perp and lending forced-close data are kept separate. This adds useful behavioral context beyond the annotations without 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 first sentence is long but well-structured with a clear list. The second sentence is grammatically awkward and repeats the 'one-call brief' idea without adding crisp clarity. It could be tightened to directly state the usage distinction between market_changes and market_digest.

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 and an output schema, the description covers the returned content and read-only nature. However, the ambiguous relationship with market_digest leaves an agent uncertain about which tool to pick for a given timing scenario, making the contextual guidance incomplete.

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 and the schema description coverage is 100%, so the schema requires no additional explanation. Baseline for zero parameters is 4, and the description adds no parameter-specific details that are needed.

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 what the tool returns with a specific enumeration: risk regime, news read, whale net flows, unusual coins, biggest movers, and forced-close picture. It also names the sibling market_digest, providing a distinction between the two, even if the sentence structure is ambiguous.

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 implies a usage distinction by mentioning that market_digest serves on a timer and referencing an on-demand 'what changed since this morning / overnight' question. However, the grammar is confusing and does not explicitly say when to choose market_changes over market_digest or other market siblings, leaving the guidance 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, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that it returns 'descriptive market data only' and 'returns everything in one payload,' which clarifies the scope and output shape beyond the annotations. 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?

One tight paragraph that front-loads the purpose, then lists the data contents, and ends with practical notes (no arguments, automation-friendly, descriptive only). Every sentence earns its place; there is zero fluff.

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 tool with an output schema, the description is fully sufficient. It tells the agent what the payload contains, that it's one call, and that it's for recurring use. The output schema handles return-value details, so nothing else is needed.

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 has zero parameters and an empty schema, so the description has no parameters to explain. Baseline for zero-parameter tools is 4, and the description correctly notes 'No arguments' without adding unnecessary detail.

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 'One-call market brief' and enumerates exactly what it returns (BTC risk regime, news, whale buys/sells, Smart Money Radar, largest movers, liquidation picture). This is a specific verb+resource that clearly distinguishes it from the many targeted market tools in the sibling list, which are narrower. The agent knows this is the aggregate snapshot.

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 explicitly states 'for a scheduled or recurring run' and notes that it can be called on a timer, making the intended use case unmistakable. It doesn't name alternative tools for when a narrower brief would suffice, but the 'one-call' framing implies it's the comprehensive option, and the sibling list offers plenty of more granular counterparts.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds that data may be stale, pointing to as_of_day and stale fields, and notes that next-day outcome stats exist only where enough events are available. This is useful context beyond annotations, though it does not fully explain how to interpret staleness.

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 sentences, front-loaded with the core purpose, followed by a clear caveat about data staleness. Every sentence earns its place with no redundancy.

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 input parameters and an output schema available, the description need not explain return values. It covers the key elements: what the tool reveals, the staleness caveat, and the descriptive-only nature. It could clarify what 'pairs' refers to, but that is domain-specific context rather than a critical gap.

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

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

The tool has zero parameters, so the baseline is 4. The description mentions as_of_day and stale but these are response fields, not inputs. No additional parameter semantics are needed.

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 it identifies pairs at record highs/lows or in the top/bottom 5% for funding, open interest, or liquidations relative to their own history, and provides next-day outcome stats. This is a specific, resource-focused purpose that distinguishes it from siblings like market_overview or market_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?

It provides context that the tool covers the latest recorded day, not necessarily today, and instructs to check as_of_day and stale before treating data as current. However, it does not explicitly name alternative tools or state when not to use it, so it falls 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, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: data is archived since specific dates, free plans cap to last day, paid plans reach full archive, and it is descriptive only. The schema further discloses that both lanes settle several days behind live and that `capped` indicates truncation. This goes beyond annotations without contradicting them.

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, each earning its place: the first defines the two lanes and archive dates, the second explains plan-based access, the third clarifies the descriptive nature. The most decision-relevant information (what data, for what scope) is front-loaded. No fluff or repetition of schema details.

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

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

Given the tool has an output schema and 100% schema coverage, the description need not explain return values. It covers the two modes, archive depth, plan limits, and descriptive nature. The only minor gap is that it doesn't explicitly state the 'settles several days behind live' caveat, but that is disclosed in the schema's days parameter, so the description is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning by framing the two lanes and the archive dates, which helps an agent understand the relationship between coin and pair. The schema itself is unusually rich (explains coin vs pair, defaults, caps, as_of/data_age_days), so the description's added value is moderate but real. It does not repeat the schema verbatim, and it clarifies the 'one pair' vs 'one coin' distinction.

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 (daily market history) and two distinct lanes (pair market data vs coin whale flow), with explicit date ranges. It distinguishes itself from siblings by stating it is 'Descriptive market data only' and by naming the two modes. The verb 'read' is implied but the resource and scope are precise.

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 when to use the tool (for daily history of funding, open interest, price, liquidations, or whale flow) and gives plan-based access guidance (free vs paid). It does not explicitly name alternatives among the many siblings, but the two-lane structure and 'Descriptive market data only' hint at when not to use it. The schema descriptions add more usage detail (e.g., coin vs pair selection), but the main description lacks explicit 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 mark it as read-only and idempotent. The description adds valuable behavioral context: totals are a floor (not exact), the Hyperliquid share is a sampled read from tracked wallets, and long dollars represent sell-side pressure. These go beyond the safety hints and inform interpretation 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?

The description is dense but every sentence carries necessary information. It leads with the core purpose, then layers in limitations and interpretation. Slightly longer than minimal, but justified given the nuance required to prevent misuse.

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 tool with no parameters and an output schema available, the description covers all essential context: scope, data sources, limitations, separate lanes, and interpretational guidance. Nothing an agent needs to invoke 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 tool has zero parameters, so the baseline is 4. The description adds substantial context about the output structure (hourly split, ranking, named_liquidations, lending lane) which helps the agent understand what the tool returns, though it does not need to explain parameter syntax.

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 explicitly states the tool retrieves market-wide forced closes, contrasting with per-pair calls. It names specific resources (whole market, perp dollars, Hyperliquid sample) and distinguishes it from sibling tools like coin_liquidations by scope.

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?

Provides clear guidance: use for a market-wide view rather than per pair, and explicitly warns that lending_liquidations is a separate lane that must never be added to perp numbers. This gives both when-to-use and when-not-to-mix instructions.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds valuable context: it is 'Descriptive market state, never a prediction', includes volume so thin-volume moves are visible, and scopes to the streamed top-~300 board. No contradiction with 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 densely functional and front-loads the core definition, then provides routing and caveats. The final two clauses ('Descriptive market state, never a prediction. Descriptive market data only.') are slightly redundant, but overall the length is justified by the amount of guidance.

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 the presence of an output schema, full parameter documentation, and annotations, the description covers all critical aspects: scope, content, use cases, alternatives, and non-predictive nature. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

Schema coverage is 100% and both parameters (only, limit) are fully described there, including enum values, defaults, and cap. The description does not add meaning beyond the schema, so the baseline score of 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 names a specific resource ('biggest 24h gainers and losers across the streamed top-~300 board') and a concrete purpose (momentum discovery). It clearly distinguishes itself from siblings by naming market_brief, market_screener, and whale_radar for other use cases.

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 explicit 'Use this for' scenarios with example queries, and explicitly states which alternative tool to use for WHY, cross-filtering, and whale flow. This leaves little ambiguity about when to select this tool.

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 covered. The description adds a useful behavioral note with 'Descriptive market data only' and implies no side effects, but it does not disclose pagination nuances or the available:false fallback, which are only in the schema.

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 cover the tool's data scope, the single-row mode, and the non-mutating nature. Every clause earns its place, and the most important information 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 overview tool with no required parameters and a full output schema, the description is nearly sufficient: it explains the purpose, the optional coin shortcut, and that data is descriptive. The only notable gap is lack of explicit guidance on when to prefer this tool over sibling overview-style tools.

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

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

Schema description coverage is 100%, so the schema already documents coin, pair, and limit thoroughly. The description reinforces the coin behavior and 'no paging needed,' but adds little meaning beyond what the input schema provides.

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 action ('One-call market scan') and enumerates distinct resources: totals, whale net flow, BTC risk regime, and top rows by volume. This makes the tool's purpose clear, though it does not explicitly contrast itself with close siblings like market_snapshot or market_digest.

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 clear context for the default board and a direct instruction for the coin parameter ('Pass coin to get one symbol's row directly'). It does not, however, say when to choose this tool over its many siblings or when not to use it.

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, so the safety profile is established. The description adds the key behavioral nuance that band comparisons are 'vs each pair's OWN recorded days' and that the whale-flow multiple is relative to the coin's own average, which is useful context beyond the annotations. However, it doesn't describe pagination, rate limits, or exact output behavior beyond what schema/output schema already 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 dense two-sentence structure that front-loads the core action ('Screen every recorded pair') and then lists filters. It earns its length by conveying the discovery call scope and relative-band logic, though the parenthetical enumeration of band values (record high, top 5%, etc.) duplicates schema content and could be shortened without losing value.

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?

The tool has 6 parameters, no required ones, full schema coverage, an output schema, and clear read-only annotations. The description supplies the missing high-level context: this is the cross-market discovery screen ('every recorded pair in one call') and filters are self-relative. It is complete enough for an agent to decide when to invoke and what to expect, without needing to explain return values due to the output schema.

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?

All 6 parameters have complete, detailed descriptions in the schema (100% coverage), so the description does not need to compensate. The description reiterates filter concepts like 'funding_band / oi_band' and 'whale_mult_min' but adds no new parameter-level meaning beyond summarizing what the schema already documents. 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 opens with 'Screen every recorded pair in one call', giving a specific verb, resource, and scope. It then enumerates the filtering dimensions (funding/oi bands, whale-flow multiple, radar-unusual) and ends with 'The discovery call. Descriptive market data only.', which distinguishes it from other market tools like market_snapshot or whale_trades.

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 'The discovery call' clearly signals when to use this tool: when exploring across all recorded pairs. It also notes 'Descriptive market data only', excluding trade execution or data modification. However, it stops short of explicitly naming alternatives for different use cases (e.g., 'for pair-specific data use market_snapshot'), so it lacks formal exclusion 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat safety. It adds valuable behavioral context about free vs. paid plan differences (BTC full vs. headline for others, and paid covers all streamed pairs) and the 'descriptive data only' nature. This goes 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 two sentences plus a short clause, tightly packed with relevant facts. The core purpose is front-loaded, and every sentence earns its place without 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?

Given the presence of an output schema and low complexity (2 optional params), the description adequately covers the operation, plan limitations, and scope. It omits explicit usage scenarios, but those are handled under usage guidance; other essentials like error behavior are not needed due to schema coverage.

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%, with detailed descriptions for 'coin' as alias and 'pair' including default behavior, bare-symbol handling, and plan/covered semantics. The tool description does not add additional parameter meaning beyond the schema, so a baseline of 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 clearly states the tool provides a market snapshot for a trading pair, enumerating the specific data points (last price, 24h stats, funding rate, open interest, liquidation totals). This is a specific verb+resource with listed fields. However, it does not explicitly differentiate from sibling tools like market_brief or market_overview, so it loses a point.

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 the many sibling market tools (market_brief, market_overview, market_digest, etc.). It mentions plan limitations but does not state scenarios for selection, exclusions, or alternatives. Usage context is only implied through 'one-call market state'.

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 classify the call as read-only and idempotent; the description adds that it is free and never metered, and clarifies that plan status is shared across website, AI, and REST API. No contradiction with annotations; the description supplements them with account-specific 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 opening sentence front-loads the capability list, followed by trigger conditions and the nuanced free-API-key clarification. Although the description is lengthy, each clause conveys distinct decision-relevant information and 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 an output schema present, return values do not need to be described. The description covers what the tool reveals, when to call it, cost behavior, and the subscription/API-key model, leaving no gap for a zero-parameter introspection 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?

The input schema has zero parameters, so there is no parameter-level description required. Per rubric, zero-parameter tools get a baseline 4; the description sensibly omits parameter detail and instead discusses plan semantics.

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 ('this connection') and states exactly what the tool exposes: plan status, credits, tier, caps, locked features, and what lifts each limit. It reads distinctly from market-data siblings and the title reinforces the scope.

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?

Provides explicit trigger scenarios: when a user asks what they get, how many credits remain, why a result was capped, or how/where to upgrade. It also clarifies a common misconception about free API keys, effectively giving when-not 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?

The description goes well beyond the annotations by disclosing plan-dependent behavior (free returns counts, Starter and up returns every row), keyless auth refusal, newest-first ordering, and the move since each alert fired. It also notes that only descriptive market data is returned. No contradiction with the readOnly/idempotent annotations exists.

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 the core purpose, followed by practical example queries and essential plan/auth details. The final sentence 'Descriptive market data only' is slightly vague but not wasteful. Overall, the prose is compact and well organized.

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?

The description covers auth expectations, keyless refusal, plan-tier output differences, ordering, and the notion of since-time filtering. Since an output schema exists, return structure does not need to be spelled out. Minor missing details like explicit sibling routing do not meaningfully hurt completeness.

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 schema already describes all parameters with 100% coverage, including since_ms defaults and the next_since_ms pagination hint. The description reinforces the time-based nature of the query but does not add meaningful parameter semantics beyond what the schema provides, so the baseline of 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 clearly identifies the resource: alerts that fired on the user's own CoinLobster account, with ordering and move data. It distinguishes itself from market-wide sibling tools by emphasizing 'YOUR alerts' and the account-specific history. The title 'What fired for you' aligns well with the described behavior.

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?

Explicit use cases are provided ('what fired for me overnight', 'did my BTC alert go off'), and the signed-in connection requirement is stated clearly. It doesn't name specific alternative tools, but the account-specific scope and auth condition make when-to-use clear without extra 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 establish readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral details beyond that: aggregation across venues, chronological ordering, resolution by plan tier, and the 'Descriptive market data only' boundary.

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 front-loaded with the core behavior before moving to usage examples and plan limitations. A little dense in the plan-tier sentence, but 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 simple read-only query tool with three optional parameters and an output schema, the description covers what it is, when to use it, when not to use it, ordering, resolution, and access limits. Nothing essential 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 input schema already covers all three parameters completely (100% coverage), so the baseline applies. The description adds plan-tier context like 'last 24h at 1-hour resolution' but does not need to add schema-level meaning.

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 exactly what the tool returns: 'the intraday path of open interest and funding for one pair, aggregated across venues, oldest first.' It also gives concrete example queries and separates it from market_history, so an agent can tell it apart from its closest 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?

It provides explicit use cases ('Use it for ...') and an explicit alternate for a different need ('For the daily archive use market_history'). This is clear when-to-use guidance with an exclusion.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: it is keyless, it returns descriptive market data only, and the min_usd schema note clarifies the feed records a size floor rather than every swap. This is useful behavioral context 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?

Every sentence earns its place: purpose, data contents, usage examples, sibling routing, and access constraints. It is front-loaded with what the tool returns and remains compact despite covering a lot of guidance.

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 a rich input schema and an output schema, the description covers the essential context: what the data is, who it is for, how to filter, which sibling to choose instead, and that no key is needed. There are no critical gaps an agent would need to infer.

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

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

Schema description coverage is 100%, so the schema already documents every parameter in detail, including the pair alias, chain refusal behavior, limit cap, min_usd floor, and since_ms polling cursor. The description adds only a high-level grouping ('Filter by chain, coin or minimum size'), which is correct but not substantial on top of 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 action ('Executed DEX whale swaps') with the resource scope ('on Ethereum, Base and Arbitrum') and the key data each result carries (wallet, DEX, token, USD size). It distinguishes itself from siblings by naming use cases and alternatives, so an agent can tell it apart before inspecting 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 explicit when-to-use guidance with natural-language examples ('which wallets are buying PEPE', 'large DEX swaps today') and names three alternatives with their specific conditions: defi_summary for chain-level totals, dex_wallet for one address history, and whale_trades for CEX flow. Also notes keyless access, which sets expectations for invocation.

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=true, idempotent=true, and destructve=false. The description adds worthwhile behavioral context: it is keyless, it is 'Descriptive market data only', and the large-trade feed deepens on a paid plan. No contradiction with the annotations exists.

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, front-loaded with the resource and data contents, then adds auth and safety caveats in short declarative sentences. The parenthetical 'which act as magnets into expiry' is a little extra but still informative; overall no sentence is waste.

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 a rich output schema, full parameter schema coverage, and safety annotations, the description covers coins, exchange, data fields, auth model, paid-plan limitation, and descriptive nature. It is complete enough for an agent to invoke correctly, though it could have briefly noted when not to choose it among the many sibling market tools.

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 schema already documents coin and pair, including that BTC/ETH are the only supported coins and that BTC is default. The tool description repeats 'BTC or ETH' but does not add new parameter-level semantics 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 identifies the resource (Deribit BTC/ETH options) and the exact data points returned: open interest, strike walls, put/call balance, max pain, DVOL, and large trades. It uses a noun phrase ('The options picture') rather than a direct verb, but the scope and contents are unmistakable. It distinguishes itself from siblings by focusing on options-specific intelligence rather than general market data, though it does not name an alternative.

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 descriptionmakes the use case clear by enumerating options-relevant fields and saying it is aggregate market structure, so an agent can infer to use it for options sentiment/positioning questions. However, it does not explicitly state when to prefer it over siblings like market_snapshot or market_overview, nor mention exclusions or conditions.

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 covered. The description adds valuable behavioral context: it explains the aggregation logic (merged across venues, aggregated by exact price), the plan-based level limits (free=5, Starter=10, Pro=25), and explicitly states 'Descriptive market data only' to prevent misuse. This goes 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 compact and front-loaded: it states the core function in the first sentence, gives example queries, then covers plan limits and the read-only nature. Every sentence earns its place, and the structure flows logically from what → when → constraints.

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?

The tool has an output schema, so return values are already documented. The description covers the key contextual gaps: aggregation behavior, plan-based level limits, and the read-only nature. It could mention pagination or the exact structure of the top levels, but the output schema likely covers that, and the description is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (coin, pair, levels) with their defaults and constraints. The description adds the plan-based level ceiling context, which complements the schema's 'hard' ceiling note, but does not substantially add meaning 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 states a specific verb ('merged', 'aggregated') and resource ('order book for one pair'), and distinguishes it from siblings by emphasizing the merged/aggregated nature across streamed venues. It also gives concrete example queries ('where are the walls on BTC', 'how deep is the bid', 'what is the spread'), making the tool's purpose unmistakable.

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

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

The description provides clear context for when to use the tool via example questions, and implicitly distinguishes it from other market data tools by focusing on order book depth and spread. It does not explicitly name alternative tools or state when not to use it, but the examples and 'Descriptive market data only' caveat give adequate 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?

Beyond the read-only/idempotent annotations, the description discloses meaningful runtime behavior: NEAR-LIVE data, newest_candle_age_min and stale fields, newest bar still forming, free/paid bar caps, and the capped field. This is exactly the kind of context annotations alone do not 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 dense but every sentence earns its place: purpose and shape, intended use case, differentiation from the archive, live-vs-stale signals, plan limits, and final caveats. The key identity is front-loaded in the first sentence.

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 the output schema, annotations, and 100% schema coverage, the description covers almost everything an agent needs: what the endpoint returns, why to choose it, how it differs from market_history, availability limits, and reliability signals. There are no material 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 the baseline is 3; the schema already fully documents coin, pair, limit, and interval. The description reinforces the interval default and cap behavior but does not add significant new parameter-level semantics 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 verb and resource: near-live OHLCV price bars for a pair, with interval, ordering, and bar shape. It explicitly contrasts itself with market_history, so an agent can distinguish it from sibling tools 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?

It says this is the lane a bot reads to compute its own indicators, and that it is deliberately separate from market_history, which settles days behind. This gives an agent an explicit 'when to use this vs that' rule and also signals that this is descriptive data, not an action tool.

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, and non-destructive behavior, so the description's additional context about leaderboard-derived screening, verification by fills, inclusion of open positions, and plan-specific headline behavior adds genuine value beyond the schema. The final note 'Descriptive market data only' reinforces the read-only nature 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 information-dense but somewhat run-on, packing multiple distinct ideas into a long first sentence before moving to examples, plan behavior, and alternatives. Every sentence earns its place, yet the structure could be clearer with more separation between purpose, usage, and alternatives.

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 lookup tool with an output schema, the description covers what the data is, how it is verified, example intents, plan-specific constraints, and sibling alternatives. 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 100%, so the schema already documents coin, pair, and limit well. The description adds context for the coin filter in examples and mentions plan-specific behavior, but does not materially expand parameter meaning beyond what the schema provides.

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 identifies what the tool returns: a screened list of profitable Hyperliquid accounts with trader numbers, performance figures, and coins traded. It gives concrete example queries and explicitly distinguishes itself from sibling tools like hl_wallet, hl_moves, and smart_money.

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 explains when to use the tool ('who are the best traders', 'who is Trader 12', 'which proven traders trade SOL') and names specific alternatives for other needs: hl_wallet for a live book, hl_moves for recent actions, and smart_money for collective per-coin books. It also discloses plan-dependent behavior around coin filtering.

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, and non-destructive behavior. The description adds meaningful context beyond that: signals are logged live and never backfilled, the data is identical to flag_outcomes, and it is descriptive only. This is more than the annotation baseline, though it does not detail response behavior, which the output schema covers.

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 sentences with no filler. It front-loads the core concept, then adds the alias and safety framing efficiently.

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 the rich parameter schemas, output schema, and safety annotations, the description is complete for invocation. It covers what the tool returns conceptually, the key data limitation (never backfilled), and the relationship to flag_outcomes.

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

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

Schema description coverage is 100%, so the schema already fully documents all five parameters. The description does not need to add parameter-level guidance, and it does not meaningfully do so; the baseline score of 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 specific resource: recorded signals with the price at trigger and afterward, which is clearly a historical outcome analysis tool. It also names flag_outcomes as the identical sibling, so an agent can distinguish signal_outcomes from related tools without inspecting 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?

The description explicitly points to flag_outcomes as the identical alternative and frames the tool as 'descriptive market data only,' which gives clear selection context. It does not spell out when to prefer this over other signal-related siblings, but the alias relationship largely covers the main ambiguity.

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 non-destructive behavior, so the description does not need to restate those. It adds valuable nuances: rates are only claimed when enough clean samples exist, otherwise only rows are listed, results are the same on every plan, and it is descriptive market data only. These details go beyond the structured annotations and meaningfully shape expectations.

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 information-dense with no filler. Each sentence adds a necessary aspect: output contents, use-case examples, sample-threshold behavior, plan consistency, differentiation from the sibling tool, and data nature. It is front-loaded with the core function.

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 query tool with an output schema and rich annotations, the description covers purpose, usage context, edge-case behavior (insufficient clean samples), plan consistency, and sibling distinction. Nothing an agent needs to correctly select and invoke this tool 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?

Input schema covers 100% of parameters with descriptions, including allowed signal types, coin examples, and limit bounds. The description adds context about 'last N firings' which maps to the limit parameter, but does not need to compensate for any schema gaps. Baseline 3 is appropriate given full schema coverage.

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 specific operation: showing how the last N firings of one signal type on one coin played out over 24h, with counts, median move, and underlying rows. It explicitly differentiates from flag_outcomes as the market-wide ledger, so an agent can distinguish it from a sibling with no ambiguity.

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

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

Provides concrete example queries ('how have funding-extreme flags on ETH worked out') and explicitly contrasts with flag_outcomes ('this is one type on one coin'). This gives clear when-to-use and when-not-to-use guidance without needing to infer from parameter 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 indicate this is read-only and idempotent. The description adds meaningful behavioral detail beyond that: tier-dependent behavior (Keyless returns top situations with trimmed evidence, Starter returns all with full evidence), the three-stage lifecycle, and the include_resolved Pro capability. This is valuable context not present in 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 dense but efficient: three sentences cover what a situation is, when to use the tool, and how access tiers change behavior. It is front-loaded with the core concept and each sentence contributes useful 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, the return structure is already documented. The description fills the remaining gaps: stage semantics, evidence/headline/price-move composition, tier-specific output differences, and the resolved-inclusion behavior. An agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds some context for include_resolved and implies coin filtering through the use-case examples, but it does not significantly enhance the 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 defines what the tool reports: live market situations organized by coin, lane, and stage with evidence, headline, and price move. The use-case examples like 'what is going on with SOL' and 'anything building on my coins' make its purpose concrete and distinguish it from generic market snapshot tools.

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 explicit use cases: checking what is happening with a coin, seeing developing situations, and monitoring coins the user cares about. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to select it appropriately.

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 description adds substantial behavioral detail beyond the annotations: positions_held and flow_traded are never added despite different units, unprofitable/unreadable wallets are never counted as flat, and rosterAgeHours is distinct from updated_at. These edge-case disclosures are valuable and consistent with the readOnly/idempotent 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 dense and front-loaded with the core purpose, and every sentence carries useful information. It is somewhat long and includes detailed methodology that could be trimmed, but it remains well-structured and free of 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?

Given the tool has an output schema, the description does not need to explain return values, and it covers the essential behavioral nuances: cohort definition, data units, wallet counts, flags, roster freshness, and unreadable-wallet handling. Nothing critical is missing for an agent to call this 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?

Although the schema already covers the window parameter at 100%, the description enriches it by clarifying what window affects (flow_traded, not positions_held), the unit semantics, and that windows_available in the reply reflects what was actually published. This goes well beyond the bare enum definition.

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 verb and resource: it reports what the PROVEN trader cohort is holding and trading, coin by coin. It also distinguishes itself from other tools by defining the cohort as Hyperliquid leaderboard accounts screened for provable profit rather than a guess.

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 provides clear context for when this tool is relevant — accessing proven-cohort holdings and traded flow — and notes it is keyless and descriptive. It does not explicitly name alternative tools or state when not to use it, so it falls 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.