whale-data

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 that results are live ('right now') and that detail can be brief or full, but it does not disclose clamping behavior or pagination details beyond what the schema already says. 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 a single, compact sentence that front-loads the core purpose and lists the key output fields. It is efficient and easy to scan, though it could be slightly more explicit about usage boundaries.

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 and annotations cover safety, the description is adequate for a read-only list tool. However, it does not clarify how this tool differs from whale_activity or whale_radar, and it leaves the agent to infer when to use it. For a tool with 4 optional parameters and a paging mechanism, a bit more context would help.

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 four parameters. The description adds minimal semantic value beyond the schema, only reinforcing that the tool is live and that detail controls row granularity. 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 ('tracked right now') and resource ('whale-flow setups'), and lists the key fields (state, direction, age, price move). It is clear what the tool returns, though it does not explicitly distinguish it from sibling tools like whale_activity or whale_radar.

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 real-time tracking ('right now') and mentions optional filtering by coin and pagination via cursor, but it does not explicitly state when to use this tool versus alternatives like whale_activity or whale_radar. The usage context is implied rather than spelled out.

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 readOnlyHint, idempotentHint, and destructiveHint, lowering the burden. The description adds meaningful behavioral context beyond those: the response is organized 'in causal order', the output is guaranteed to avoid a second call, view variants alter what is returned, and crowding is gated to Pro users. 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?

Two dense sentences with the core promise front-loaded ('one-call answer for ONE coin, in causal order') before the content list and view lanes. Every clause earns its place, and the view enumeration is necessary because the schema explicitly defers to the description for lane meanings.

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

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

An output schema exists, so return values need not be explained. The description covers the data categories, the single-call behavior, all view variants with their contents, and the Pro restriction. The only minor gap is not naming sibling alternatives for routing, but for a well-scoped read-only analysis tool this is near-complete.

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 genuinely expands on the view parameter: it defines what quick (price, funding, OI only), funding (rate per exchange), and crowding (0-100, Pro) each return, while the schema merely says 'Which lane; see the description.' This makes the description the canonical source for view 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?

States a specific verb/resource: 'one-call answer for ONE coin' that answers 'why is X moving', enumerating exact content (price, 24h move, news read, whale flow, forced closes, funding, open interest). The single-coin causal framing distinguishes it from market-wide siblings like market_screener, market_now, and watchlist_brief without them being named.

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

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

Gives clear context: use this when the question is 'why is X moving' for one coin and you want it without a second call. Scope is explicit with 'ONE coin', implying it is not for portfolio scans or multi-coin comparisons, but no alternative tool is named and there is no when-not-to-use 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful return-content context (covered status, free status, price, 24h change) and states 'Free', but it does not discuss pagination behavior, rate limits, or edge cases beyond what the parameter schema already mentions.

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 core action is front-loaded in a compact first sentence, and the description stays short overall. 'Free.' is slightly redundant with 'whether it is free', but the description earns its place by being efficiently scannable.

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 search tool with full schema coverage and an output schema, the description conveys the essential inputs and outputs: search by symbol/name, get canonical symbol, coverage, free status, price, and 24h change. It lacks explicit guidance about when to prefer a sibling like coin_brief, but the schema covers pagination and detail levels.

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 each parameter already having a meaningful description such as 'Next page: the cursor from the previous answer' and 'brief (default): the answer, key numbers and top rows.' The description mostly restates the query concept ('by symbol or name') rather than adding new parameter-level meaning, 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 opens with a specific verb and resource: 'Find a coin by symbol or name', and clearly states the lookup value: canonical symbol, coverage, free status, price, and 24h change. It does not explicitly name a sibling like coin_brief, so differentiation is conveyed functionally rather than by direct contrast.

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 for when to use this tool: when you need to resolve a coin by symbol or name and learn whether it is covered, free, and what price/change it has. It does not provide explicit exclusions or name alternative tools, so it stops short of full routing 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=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds useful behavioral context: the default series (price), the default interval (hourly or daily), ordering (oldest first), and the nature of each series (e.g., intraday funding/OI, daily archive, whale flows). 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?

The description is a single sentence that efficiently packs the core purpose and all four series definitions. It's front-loaded with 'History for one coin' and avoids filler. While dense, every phrase adds information, making it appropriately concise for the complexity.

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 tool with an output schema and fully documented parameters, the description covers the main decision point (which series to use) and default behavior. It doesn't mention pagination or detail modes, but those are described in the parameter fields. The description is sufficient for an agent to call the tool correctly without missing key information.

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 parameters like coin, days, limit, etc., are already documented. The description enriches the 'series' parameter by explaining what each enum value returns (e.g., 'near-live hourly or daily bars', 'intraday open interest and funding path'). This adds semantic value beyond the schema's simple 'Which lane; see the description.'

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 'History for one coin' and enumerates the available series (price, funding_oi, daily, whale_daily), each with a brief explanation. This is specific and goes beyond a mere tautology. It doesn't explicitly contrast with sibling tools, but as the only 'history' tool it's distinct enough.

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

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

No guidance is provided on when to use this tool versus alternatives. The description only explains what it does, not the conditions for selecting it over other tools like market_now or coin_brief. There's no mention of when to prefer this tool or 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 cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that: lending closes are on-chain and excluded from perp, projected levels are modelled rather than actual trades, and long closes are executed by selling. No contradiction with 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 dense and efficient: a two-word subject followed by a compact scope legend, with a final clarifying sentence about long liquidations. Every clause adds information, and there is no repetition of schema content or annotations.

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

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

For a read-only query tool with eight optional parameters and an output schema, the description covers the meaning of every scope lane and the relevant defaults. It does not discuss pagination or polling parameters, but those are fully documented in the schema, so the description is sufficiently complete.

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 real meaning for the scope parameter, which the schema explicitly defers to the description ('see the description'). It also explains default behavior per scope, going beyond the property names and enum values.

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 as forced closes/liquidations and enumerates the distinct scope lanes. It is unambiguous about what the tool exposes, though it does not explicitly contrast itself with sibling tools like history or market_now.

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 selection context within the tool: which scope is the default when a coin is named versus otherwise, and that lending liquidations are never added to perp. It does not mention alternative tools, but the internal scope guidance is concrete and actionable.

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 meaningful behavioral context beyond the annotations: stateful behavior ('since your last check', 'pass back next_since_ms on a timer'), result clamping ('more is clamped and said' in the limit param), unusualness ranking, and the brief/full detail split. Annotations already cover the read-only, idempotent safety profile, so no contradiction exists; the description enriches the operational picture.

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 opener 'The whole market in one call' front-loads the purpose well and every clause adds information rather than padding. But the body is a single run-on sentence with nested parentheticals and semicolons exceeding 80 words, making it notably hard to parse; per-view bullets or line breaks would drastically improve scannability.

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 5-view, 7-parameter tool with an output schema and safety annotations, the description covers all views, the stateful since-last-check behavior, pagination via cursor/next_since_ms, and the brief/full detail split. Minor gaps like explicit auth/rate-limit mentions and error behavior are not critical for a read-only aggregator.

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 carries real semantic weight for the central view parameter — the schema explicitly defers ('Which lane; see the description') and the description defines each lane's payload. It also adds the since_ms/next_since_ms timer protocol and cross-parameter behavior ('overview ... pass coin for one row') that the schema does not.

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 opener 'The whole market in one call' names the verb-resource pair and positions this as the market-wide aggregator tool, and each of the five view descriptions states exactly what that lane returns. This clearly distinguishes it from siblings like coin_brief (single coin), market_screener (screening), and news (news feed).

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 per-view breakdown gives clear implied context for when each lane is appropriate (changes for what moved since last check, movers for 24h gainers/losers, defi for DEX volume/TVL). However, no sibling alternatives are named and there are no explicit when-not-to-use or exclusion statements, so deciding between market_now, market_screener, and coin_brief is left to inference.

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

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

Annotations already mark this as read-only and idempotent.te, lowering the bar. The description adds meaningful behavioral context by stating that bands are evaluated 'against each pair's own recorded days' and by listing the exact band thresholds. This helps the agent understand that results are relative per pair, not global.

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

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

The description is a single, front-loaded sentence: 'Screen every recorded pair at once' followed by a compact list of criteria. No filler or redundant phrases. The band list is dense but necessary, and each element earns its place.

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

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

With an output schema present, the description doesn't need to cover return shapes. It fully explains the screening logic, the key parameter semantics, and the tool's scope. Pagination and output-detail parameters are already documented in the schema, so an agent has everything needed 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 schema coverage is 100%, the description adds crucial meaning beyond the schema: it explains that funding_band and oi_band are interpreted relative to each pair's own recorded days, and it clearly maps 'minimum whale-flow multiple' to whale_mult_min and 'unusual-only' to unusual_only. This resolves ambiguity that the bare schema leaves.

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

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

The description opens with a specific verb and resource: 'Screen every recorded pair at once.' It then enumerates the screening criteria (funding_band, oi_band, whale-flow multiple, unusual-only), making it unmistakable what the tool does. This distinguishes it clearly from siblings like coin_brief or watchlist_brief, which target narrower scopes.

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 'every recorded pair at once' makes the tool's use case explicit: whole-market screening rather than single-coin or watchlist inspection. It doesn't name alternative tools or list exclusion conditions, but the context is clear enough for an agent to decide when to invoke 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, so the safety profile is covered. The description adds valuable behavioral context: 'Free, never counted' clarifies that using this tool does not consume plan answers, which is a meaningful behavioral trait beyond the annotations. It also discloses the approximate nature of the answer count ('roughly').

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, compact sentence that front-loads the core purpose ('Your plan, what it includes, roughly how many answers are left, and the next plan up') and ends with a useful behavioral note ('Free, never counted'). Every word earns its place; no filler.

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

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

For a zero-parameter, read-only status tool with a rich output schema, the description is nearly complete. It explains what the user will see and the key behavioral caveat (not counted). The only minor gap is that it doesn't explicitly say 'use this to check your plan status,' but the purpose is obvious from the description and title.

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 schema provides no parameter semantics. The description compensates by explaining what the tool returns (plan details, answer count, next plan), which is the relevant semantic content. With 0 params, the baseline is 4, and the description meets 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 clearly states what the tool does: it shows the user's plan, what it includes, roughly how many answers are left, and the next plan up. It uses a specific verb ('Your plan...') and resource, and the title reinforces the purpose. It doesn't explicitly distinguish from siblings, but the resource ('my plan') is unique among the listed siblings.

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

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

The description implies usage context: it's a read-only status check for the user's plan and remaining answers. It doesn't explicitly state when to use it vs alternatives, but the sibling list contains no other plan-related tool, so the context is clear enough. No exclusions or alternatives are mentioned.

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 that a signed-in connection is needed and that it returns alerts that have 'fired' since a time, which is useful context. However, it does not elaborate on pagination behavior or response structure, but with annotations and an output schema present, the description adds sufficient supplementary 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 description is a single sentence, front-loaded with the main function, and includes the key prerequisite (signed-in connection). Every word earns its place; no fluff or 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?

Given the output schema exists, the annotations cover safety, and the schema documents all parameters, the description is fairly complete. It covers the core behavior, sorting, and the time constraint. The main gap is lack of usage guidance to differentiate from sibling tools, but that is addressed under usage_guidelines. Overall, an agent can call this tool correctly based on the information provided.

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% – every parameter has a description in the schema. The description itself only mentions 'since a time', which mirrors the since_ms parameter, but adds no new meaning beyond the schema. The baseline of 3 is appropriate because the schema handles 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 states a clear purpose: list fired alerts since a time, sorted newest first, with the move since each. It uses a specific verb ('fired') and resource (alerts), and is not a tautology. However, it does not explicitly distinguish itself from sibling alert-related tools like 'signals' or 'watchlist_brief', though the phrase 'fired alerts' gives some distinction.

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

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

No guidance on when to use this tool versus alternatives. It mentions the requirement for a signed-in connection, but does not state under what circumstances an agent should choose this over other alert/notification tools. No exclusions or alternative tool names are provided.

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 read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful output-composition context but no additional behavioral traits such as rate limits or side effects. 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?

Two sentences with no filler; the output highlights are front-loaded and the alternative routing is a short second sentence. 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?

An output schema exists, and the parameter schema covers clamping, paging, cursor use, and detail modes. Combined with the description's clear purpose and sibling routing, nothing an agent needs 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 parameters are already well documented with examples, defaults, and paging behavior. The description reinforces that the tool targets one coin but adds no new parameter-level 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 exact resource (news for one coin) and lists distinctive outputs: headline, mood score with range, written points, and market-wide read. It also distinguishes itself from coin_brief, so an agent can select it without opening the schema.

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

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

It explicitly says not to use this tool for 'why is X moving' and routes to coin_brief as the alternative. The tool's own use case—single-coin headlines with sentiment and market context—is clear from the first sentence.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description itself adds no behavioral context such as pagination behavior, defaults, or side effects; it only lists data content, which does not go 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, front-loaded sentence that packs the resource and the key delivered data fields with no filler or redundant wording. Every part 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?

The full input schema, output schema, and annotations cover the calling contract well, and the description supplies the domain content. The only notable gap is explicit usage routing versus sibling tools, but that is already captured under the usage-guidelines dimension.

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%: coin, cursor, and detail are all documented in the schema, including defaults and the brief/full enum. The description adds no parameter-specific meaning beyond that, so the baseline of 3 applies.

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

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

The description names the specific resource (BTC or ETH options) and enumerates exactly what data is provided: open interest by strike, put/call balance, max pain per expiry, implied volatility, and large trades. This clearly distinguishes it from sibling tools like orderbook or 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?

The description implies a clear use case for fetching BTC/ETH options data, but gives no explicit when-to-use versus when-not-to-use guidance and does not name any alternatives or exclusions. The context is clear but the routing guidance is only implicit.

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 context by disclosing that the data is merged across exchanges and showing exactly what is computed: bid/ask, spread, side dollar amounts, and holding exchanges. This goes beyond simply restating 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?

A single densely informative sentence that front-loads the core subject ('order book for one coin merged across exchanges') and then lists the returned quantities in a natural order. There is no redundant wording 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?

For a read-only tool with no required parameters and an output schema, the description plus schema covers the coin scope, aggregation behavior, and key returned items. The only real shortfall is explicit routing guidance among sibling tools, which was already penalized under usage guidelines.

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, cursor, detail, and levels. The description focuses on output content rather than parameter meaning, so it does not need to compensate for schema gaps; 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 clearly specifies the tool returns a consolidated per-coin order book and enumerates its key contents: best bid and ask, the gap, dollars resting on each side, and the exchanges at each level. It stops short of a 5 because it is a noun-phrase definition rather than a verb-led instruction and does not explicitly name sibling 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 intended use is easy to infer: call this when the user wants a single coin's aggregated order book. However, there is no explicit when/when-not guidance or comparison to related tools such as market_now or coin_brief.

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, covering the safety profile. The description adds that it provides net direction, share of flow, and coins, which is useful context about the data returned. However, it does not disclose any additional behavioral traits such as pagination limits or data freshness, but the annotations lower the burden.

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, concise sentence that front-loads the core purpose and key outputs. There is zero fluff or redundancy, and every word contributes to understanding the tool's 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?

The tool has an output schema, so return values are already documented. The description states the key data points (net direction, share of flow, coins) and the scope (sectors). It is complete for an agent to decide when to call it, though it lacks explicit mention of pagination (handled by cursor) or usage conditions, which is minor given the simplicity and existing 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?

Schema coverage is 100%, with all three parameters (cursor, detail, window) having descriptions in the schema. The description does not add any additional meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema handles the 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 states the tool's function: tracking where whale money moves between sectors, with specific outputs like net direction, share of flow, and coins. It uses a specific verb ('moving') and resource ('sectors'), making the purpose unambiguous and distinct from siblings like whale_activity which focus on individual whales rather than sector-level flow.

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 no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or comparisons to sibling tools. The only implied usage is that it answers sector rotation queries, but no explicit when-to-use or when-not-to-use information is given.

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

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

With readOnlyHint and openWorldHint already in annotations, the description adds valuable context: signals are logged live when fired and never backfilled, each entry includes the price after, record shows how many rose and median move, and scorecard returns totals only. This goes beyond annotations, though it does not mention rate limits or pagination behavior.

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

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

The description is two sentences with no filler. The first covers the core data provenance (live, never backfilled, price after), and the second lists the three views with their distinguishing outputs. Every clause earns its place and 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?

Given the tool's complexity (7 optional parameters, 3 views, paginated detail mode), the description combined with full schema coverage and output schema gives an agent enough to call it correctly. The main missing piece is explicit when-to-use versus siblings, which is already reflected in the usage-guidelines score.

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 meaning for the view parameter by explaining each enum value (recent, record, scorecard) in terms of returned data, and implicitly clarifies the roles of type and coin for the record view. Other parameters are adequately described in the schema.

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

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

The description clearly states the tool exposes signals with their outcomes and enumerates three distinct views (recent, record, scorecard) with their specific outputs. This identifies the resource and operation well, though it does not explicitly name sibling tools for differentiation.

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 internal guidance by explaining what each view is for, which helps choose among the view parameter values. However, it does not state when to use this tool instead of related siblings like history or market_now, so cross-tool usage guidance is only implicit.

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 context about the output structure (stages, evidence, price move) which is useful behavioral detail. However, it doesn't disclose any additional behaviors like pagination limits, rate limits, or specific handling of edge cases. Given the annotations, a 3 is appropriate.

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

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

The description is a single, front-loaded sentence that efficiently conveys the purpose and key output elements. It includes the stages, the 'one coin, one story' format, evidence, and price move without redundancy. It could arguably be slightly more structured (e.g., listing the parameters) but is concise and to the point.

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 core purpose and output format. An output schema exists, so return values are documented there. The parameter schema is complete. The description does not explicitly mention pagination, but the 'detail' and 'cursor' parameters imply it. Overall, it is sufficient for an agent to understand what the tool does and how to invoke it, though it could add a note on when to use 'full' vs 'brief'.

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%, meaning all five parameters are documented in the input schema. The description does not add any parameter-specific meaning beyond what the schema already provides. It mentions the stages but not how parameters like 'coin' or 'limit' map to the output. This matches the baseline of 3 when the schema handles the heavy lifting.

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 does: it provides a snapshot of current situations categorized by stages (emerging, confirmed, escalating, cooling, contested), with one coin and story each, including evidence and price move. This is specific about the resource and output format, though it lacks an explicit verb like 'list' or 'get'. It is distinct from siblings like 'market_now' or 'signals' in that it focuses on stage-based situation tracking, but it doesn't explicitly differentiate itself.

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 its use case (monitoring current developments) but provides no explicit guidance on when to use it versus alternatives, nor any exclusions. There is no mention of alternative tools or conditions that would favor another tool. The context is clear enough that an agent could infer usage, but it lacks direct routing information.

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/destructive annotations, the description discloses data provenance and trust levels ('verified by their own fills', screened is 'a weaker claim') and temporal behavior ('moves... just now', dex wallets moving the most). It doesn't discuss auth or rate limits, but annotations already cover the safety profile, so the added semantics are meaningful.

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-loads the defining cohort before the view list. It is dense but not padded; a more structured bullet list would aid scanability, but every clause carries information.

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

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

For an 11-parameter tool with a rich output schema and full schema parameter descriptions, the description covers the key conceptual dimension (view meanings and cohort definition) that would otherwise be opaque. It leaves cross-tool comparison to siblings out, but the read-only, non-destructive profile is already annotated, so the agent has enough to call 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%, so baseline is 3, but the description adds real semantics to the view parameter by explaining each enum value and marking smart_money as the default, which the schema does not do. Other parameters are sufficiently covered by 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 defines the tool's core subject precisely ('PROVEN cohort: Hyperliquid accounts screened for real profit and verified by their own fills') and enumerates six views with their specific outputs (e.g., moves: opens/adds/trims/closes/flips just now). This clearly differentiates traders from generic whale/screener siblings by establishing the unique cohort definition, even without naming alternatives.

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 per-view usage guidance: smart_money is default cohort holdings/trades, proven identifies accounts by trader number, screened is explicitly a 'weaker claim', moves covers live position changes, dex covers on-chain movers. What's missing is explicit routing against sibling tools such as whale_radar or big_catch, so it is strong on context but not on exclusions/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 establish readOnly, idempotent, non-destructive behavior. The description adds genuine behavioral context by explaining what each chain type returns and how auto mode falls back from Hyperliquid to on-chain. It does not contradict annotations and covers the main behavioral variation an agent must know.

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

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

Two sentences carry substantial meaning: scope ('One address'), per-chain output differences, and the chain parameter's behavior and values. It is front-loaded and free of filler, though the fragment 'One address.' is slightly cryptic and could be more explicit.

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 a rich output schema and detailed parameter descriptions, the description covers the key invocation decision: which chain to use and what to expect. Pagination, limits, and address format are already handled by the schema and output schema, so 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?

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the chain parameter's auto behavior ('tries Hyperliquid, then on-chain') and by mapping chain values to the kinds of data returned. It does not over-explain fields already well described in 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 that a single address yields account or wallet data, and clearly differentiates Hyperliquid accounts (positions, leverage, liquidation prices, fills) from EVM wallets (DEX swaps, net flow). The verb 'returns' and resource are present, though the opening 'One address' is terse and relies on the title for full framing.

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 usage: pass one address, optionally choose a chain, and get account/wallet data. It explains the chain auto-resolution order, which is useful, but it never explicitly says when to prefer this tool over alternatives like whale_activity, traders, or watch, and gives no exclusions.

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

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

Annotations already provide destructiveHint=true and idempotentHint=false, so the bar is lower; the description adds genuinely useful context about continuous monitoring, webhook delivery, and the creation plan requirement. It doesn't elaborate on delete effects, but that side is already signaled by the destructive annotation.

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 dense sentences with the core behavior front-loaded and a compact action grammar. Every clause earns its place, and there is no filler 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?

For a multi-action tool it covers the behavioral model, action routes, conditional parameter requirements, and the plan limitation, with an output schema available to explain returns. It doesn't address edge cases like duplicate alert creation, but annotations and the output schema absorb most of that burden.

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 encoding cross-parameter contracts: create needs coin + trigger + webhook_url, funding_band needs band, and delete takes id. This is more meaningful than the flat per-field 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?

The opening sentence states a clear behavior: alerts are continuously checked and posted to a webhook, and the action list defines list/create/delete. However, it does not explicitly distinguish itself from nearby alert-related siblings such as my_alerts or signals, so it stops short of a 5.

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

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

The description gives clear action routing (list default, create with coin+trigger+webhook_url, delete by id) and the plan gate 'Starter and up to create', so usage context is implied. But it never explicitly says when NOT to use this tool or names an alternative for simpler alert viewing, leaving the agent to infer the decision boundary.

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 repeat those. It adds useful context beyond annotations: an authentication requirement and the kind of analytical output provided. 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?

Two concise sentences with no filler. The primary purpose and output are front-loaded, and the auth note is brief but 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?

The description is complete for a zero-parameter read-only tool: it states what data is returned, the auth requirement, and the scope. The output schema covers return structure, and annotations cover the behavior profile, so nothing important 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 schema description coverage is 100%, so the schema fully documents the input surface. The description adds no parameter-specific meaning, but none is needed; the baseline for zero-parameter tools is 4.

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 returns every coin on the user's watchlist with specific metrics: flow against normal, buy/sell lean, and unusualness. It names the resource (watchlist) and differentiates itself from sibling tools like 'watch' by focusing on a per-coin brief in one call.

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 a clear context: use this to get watchlist coins with whale-flow analysis in a single call. It also states the prerequisite of a signed-in connection. It does not explicitly name alternatives or when-not-to-use, but the context is strong enough for an agent to know when it applies.

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?

Despite readOnlyHint and idempotentHint already covering safety, the description discloses substantial behavior: default summary contents, timeframes, flow splits, trade ordering, chain coverage, and context/unusualness semantics. This goes well beyond what annotations alone provide and makes the tool's behavior predictable.

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: one leading statement plus a compressed view-by-view enumeration. It earns its length by covering seven distinct modes, though a little more structural formatting would improve skimmability.

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 12-parameter surface and seven view variants, the description covers the semantic heart of each mode while leaving mechanical details like pagination and clamping to the schema. With an output schema present, this is reasonably complete, though it does not explain how the many filters interact.

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%, but the description adds meaning beyond the schema by specifying what each view mode computes (e.g., 'net flow over 1h/4h/24h/7d', 'fills with both wallets named', 'DEX swaps ... with the signer'). It clarifies that context accepts a list and which parameter modes are exclusive, improving selection confidence.

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

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

The description states the tool's core purpose concretely: 'What whales are doing, per coin,' and enumerates all seven views with the data each returns. It is clearly scoped to per-coin whale activity, though it does not explicitly contrast with sibling tools like whale_radar.

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 view list maps to sub-modes, but there is no guidance on when to choose this tool versus sibling tools or which view fits a user's question. No exclusions or alternatives are mentioned, so an agent must infer usage from the view names.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it explains that results are 'ranked by how far above normal (not by dollar size)' and that each coin is compared 'against its own normal'. This clarifies the output ordering and normalization logic 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?

Two sentences, no filler. The first sentence front-loads the core query and key qualifiers (unusual, own normal, timeframes, ranking), while the second sentence gives the use case. Every word 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?

The description is complete for a read-only discovery tool: it states the purpose, ranking logic, timeframes, and use case. The output schema covers return structure, and the input schema fully documents parameters. The only minor omission is a more explicit explanation of how 'unusual' is statistically measured, but 'against its own normal' is sufficient for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions the time windows (1h, 4h, 24h) which map to the window parameter, but it does not add anything beyond what the schema already states (e.g., 'Omit for all three'). No extra semantics are provided for limit, cursor, or detail, so the parameter meaning comes almost entirely from 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 uses a specific verb and resource: 'Which coins have UNUSUAL whale flow right now'. It clearly defines the scope (unusual relative to each coin's own normal), the timeframes (1h, 4h, 24h), and the ranking criterion (by how far above normal, not dollar size). The closing phrase 'For discovery when no coin is named' distinguishes it from sibling tools like whale_activity, which likely requires a coin name.

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 the primary use case: 'For discovery when no coin is named.' This gives clear context for when to choose this tool over others. However, it does not explicitly name an alternative or state a when-not condition, leaving the distinction from whale_activity implicit rather than direct.

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