f1ow

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

The readOnlyHint annotation already tells the agent this is a safe read. The description adds useful scope context (next 7 days, crypto events), but discloses nothing about the return shape, result volume, or whether the window is fixed, which would help an agent decide how to consume it.

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, zero filler, with the core scope (7-day window) front-loaded before the optional filter detail.

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

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

For a single-optional-param read tool with no output schema, the description covers purpose, scope, and filtering adequately. The only meaningful gap is disambiguating this tool from the economic calendar and other catalysts siblings.

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 single parameter is fully documented there, including the comma-separated format and the omit-for-all default. The description repeats the same example and adds no syntax or matching semantics (e.g. case sensitivity, unknown symbols) 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 (Lists), resource (crypto catalyst events), and an explicit time scope (next 7 days), which goes beyond the title. However, it does not distinguish itself from the sibling catalysts_economic_calendar, leaving the agent to infer whether crypto catalysts and economic catalysts overlap.

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

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

Usage is implied by the 7-day forward-looking scope and the optional coin filter, but there is no explicit when-to-use guidance and no named alternative (e.g. catalysts_economic_calendar) for the case where the agent wants macro events rather than coin-specific ones.

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 readOnlyHint=true, so thedescription does not need to establish the read-only nature. The description adds useful behavioral context: the time range, the type of content, and how min_importance changes the result set. It does not disclose return structure or pagination, but for this simple read-only tool the added behavior is sufficient.

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 cover the core purpose, time window, and optional filter behavior with no wasted words. The most important information appears first, and every clause contributes to an agent's ability to invoke the tool correctly.

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 one optional parameter and no output schema, the description provides the essential content, schedule scope, and filtering option. It could be more complete by describing the returned fields or contrasting it with catalysts_calendar, but those are minor gaps relative o the tool's simplicity.

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?

There is only one parameter and the schema already documents it fully, including the 1-3 scale and default of 2. The description essentially restates the schema's meaning rather than adding new semantic or edge-case detail, 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 clearly identifies the resource as scheduled macroeconomic data releases with concrete examples (CPI, FOMC, jobs, GDP) and an explicit time window. It does not use a direct verb like 'list' or 'get,' and it does not explicitly differentiate itself from the sibling catalysts_calendar, so it falls just 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 context for when the tool is appropriate: macroeconomic releases within roughly the last 2 days to next 7 days. It also explains the optional min_importance filter. However, it does not state when to prefer an alternative tool like catalysts_calendar, so no exclusions 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?

Beyond the readOnlyHint annotation, the description discloses meaningful behavioral traits: data is delayed, weekends are skipped, the latest row's age is reported, and the attached price is from that date rather than current spot. This gives the agent critical expectations about data freshness and semantics.

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, well-ordered sentences: the core purpose and result shape come first, followed by essential caveats and the alias note. There is no filler or repetition of schema details that don't add 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?

Even without an output schema, the description gives a sufficient picture of what the tool returns: total, per-fund breakdown, trend, date with age, and associated price. The parameters are fully covered, behavior is explained, and no critical calling information 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 by enumerating accepted asset values (BTC, ETH, SOL, XRP), reinforcing the default, and explicitly documenting the 'symbol' alias. This goes beyond the schema's minimal 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 precisely identifies the resource (spot-ETF net flows in USD), the supported assets (BTC, ETH, SOL, XRP with BTC default), and the output shape (latest day total, per-fund breakdown, trailing daily trend). This clearly distinguishes it from other flow-related siblings like flow_orderbook or flow_whale_context.

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 clearly implies when to use it: whenever ETF flow data for a supported asset is needed. It provides important context about timing (flows settle behind spot, skip weekends) and interpretation (positive means net inflows), but does not explicitly name alternatives or state when not to use 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 only declare readOnlyHint=true, and the description adds real behavioral context: the data sources per venue, the default/max lookback window, and the important caveat that coin and time are parsed from notice text and 'a notice that does not name them says so.' It stops short of describing response shape or coverage gaps per venue beyond 'announcements when configured.'

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

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

Front-loaded with the core purpose and scoping, then filters. It is dense and somewhat run-on in the middle (venue parentheticals), but nearly every clause carries information an agent needs; little 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?

With an output schema present, return values need not be explained, and the description covers sources, time window, filter semantics, and parsing caveats. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds meaning beyond the schema: it enumerates what 'all' actually includes (pair removals, margin/collateral changes, migrations, postponements) and clarifies comma-separated symbol usage. This is genuine added value over the enum labels.

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 ('Exchange listings and delistings from the venues' own notices') and immediately scopes it to scheduled vs. recent events. It names the exact venues covered (Binance, Bybit, OKX, Upbit), which distinguishes it from generic siblings like catalysts_calendar or news_search.

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 for when this matters ('delistings announced 2–7 days ahead; new listings... among the most price-moving events') and explains the filter dimensions. It does not explicitly name an alternative sibling tool 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?

Despite the readOnlyHint annotation, the description adds substantial behavioral context: the Bybit taker-split limitation (~1000 trades), the fallback to price-direction reading, and the explicit statement that every read declares its basis. This is rich disclosure well beyond the 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?

Front-loaded with the core purpose and venue scoping, and every sentence is informative. It is dense and long for a three-parameter tool, but little is pure 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?

With an output schema present and full param coverage, the description need not explain returns; it still supplies venue-selection logic, the basis caveat, and reading semantics, so an agent has everything needed to call and interpret it.

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 schema already documents hours, symbol, and interval including defaults. The description reinforces the grid/venue semantics but does not add syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource (USDT-margined perpetual flow for one coin on a 5m/15m/1h grid from one venue) and explicitly distinguishes itself from the market-wide aggregate, which separates it from siblings like derivatives_open_interest and derivatives_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?

Gives a clear use case ('to say whether a move was positions opening or closing, and which side pushed') and an implicit exclusion ('One venue, not the market-wide aggregate'), but never names an alternative sibling or state explicit when-not 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 only declare readOnlyHint, so the description carries the rest of the burden and does so well: it discloses that the sample is a share of the market, stated per bucket and 'never scaled up', and that cascades/largest orders come only from venues that publish them (OKX, Gate). It also explains the 1y baseline methodology (percentile, 'largest since' date, median day), which is behavioral context no annotation or schema conveys.

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

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

Front-loaded with the core resource and scope, and each sentence carries distinct content (contents, sample caveat, use rationale, baseline). It is a single dense paragraph of roughly 110 words, which is heavier than needed; light structuring would improve scanability without losing 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?

An output schema exists, so return values need not be spelled out; the description instead supplies the methodology, caveats, and use framing that an agent needs to interpret the numbers correctly. Nothing material for correct invocation or interpretation 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 both defaults and ranges are already documented; baseline is 3. The description adds some framing — the interval drives the timing sample, top_orders is the largest individual liquidations, and hours relates to the 'trailing ~24h' baseline — but it doesn't add format or unit detail beyond the schema, and 'minute-level timing sample' sits slightly oddly against a 5m/15m/1h enum.

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 — 'Liquidation history for one coin's perpetuals' — and enumerates the exact contents: market-wide long/short liquidations in 4h buckets, a 24h venue split, and a minute-level timing sample with detected cascades. It even positions itself against a related signal (inferring liquidations from price/OI), so an agent can distinguish it from derivatives_open_interest and derivatives_flow without opening a 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?

Gives a clear use condition — 'Use it to say WHEN and WHICH SIDE was forced out, instead of inferring liquidations from price and open interest' — and the rationale (flat OI can hide heavy liquidations). It stops short of naming sibling tools or stating exclusions (e.g., when derivatives_flow is the better pick), so it is strong context rather than a full routing rule.

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 safety, but the description adds substantive behavior: a fallback to a single-venue figure if the aggregate source is offline, and the points=0 suppression behavior. It also discloses that the series carries its own low/high window. It does not cover latency, caching, or rate limits, but for a read-only analytics call this is strong added context.

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

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

Front-loads the core purpose then layers interpretation, fallback, and the points knob. Nearly every sentence carries information, though the price/OI interpretation passage runs long and repeats the same idea (rising vs falling OI) more than strictly needed.

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

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

With no output schema, the description carries the full burden and does so: it explains the summary fields, the 4h series, the 1y percentile/range, and the fallback path. An agent can interpret the return value without guessing.

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

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

Schema description coverage is 100%, and both symbol and points are already fully documented in the schema, including the same omit/0 semantics the description repeats. The description adds only framing about why the series matters, not new parameter syntax. Baseline 3 is correct when the schema does 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?

States a specific verb and resource with scope: market-wide cross-exchange aggregate open interest in USD for one coin's perpetuals. It also enumerates the exact payload (24h/7d change, 24h price change, 4h-bucket series, 1y percentile rank), so an agent knows precisely what it is getting. This distinguishes it from pricing siblings like market_candles and market_quotes.

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 real interpretive context and an explicit pairing instruction ('pair it with market_candles at 4h for the price leg'). It also explains the price/OI read so the agent knows what question this tool answers. It stops short of naming when-not-to-use or contrasting with other derivatives siblings (derivatives_flow, derivatives_liquidations), so not 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, so the read-only nature is covered. The description adds meaningful behavioral context by stating it returns the most active matching markets and enumerating the returned fields, giving the agent a clear sense of behavior beyond 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?

The description is two sentences with no filler. It front-loads the core purpose, provides concrete examples, and immediately states the output content, making it efficient and well-structured.

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

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

For a single-parameter, read-only tool with no output schema, the description provides sufficient context: what the tool does, how the query is used, and what the response will contain. No missing information is critical for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents the query parameter thoroughly. The description adds illustrative topic examples, but does not materially extend 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 the tool as returning prediction-market odds for a topic, with specific output elements (per-outcome probabilities, volume, resolution date). It is easily distinguished from siblings like market_quotes or funding_current by its unique focus on prediction markets despite not naming 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 description implies usage: call it when you need market-implied probability odds for a given topic. However, it does not explicitly state when to prefer this over other market-data tools or mention any exclusions, so usage guidance is only implied.

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

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

Annotations already provide readOnlyHint=true, signaling a safe read operation. The description adds useful context about full-text search and the returned result fields, but it does not disclose limitations such as the exact date range for 'recent' or any pagination constraints. With annotations covering safety, a moderate score 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 two tight sentences. The first sentence front-loads the core action and scope; the second sentence states the return payload. Every clause earns its place with no 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?

For a simple one-parameter tool, the description is mostly complete: it explains both the query semantics and the output format (form type, filer, link), compensating for the missing output schema. The only minor gap is the ambiguity of 'recent' (no defined look-back period), which could affect expectations but is not blocking.

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%: the query parameter is fully documented with its own example ('a company name, ticker, or theme'). The description repeats the same examples without adding additional semantic detail beyond the schema, so it meets the baseline but does not exceed 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 uses a specific verb ('Searches') and resource ('recent regulatory filings'), specifies the search mode ('full-text'), and lists the exact output fields (form type, filer, direct document link). This clearly differentiates it from siblings like news_search and market_quotes, which cover different domains.

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 when to use the tool (when needing regulatory filings by company, ticker, or theme) but does not explicitly state when not to use it or contrast it with alternatives. No exclusions or routing guidance are provided, leaving the context to be inferred.

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 only readOnlyHint provided, the description carries the behavioral burden well: it discloses data provenance and gaps (OKX/Gate liquidation sample), the 2-second second-snapshot confirmation for walls, the evidence-grading hierarchy (traded > inferred > resting), and the caveat that resting orders can be pulled. This is rich, non-obvious context 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?

Content is front-loaded (purpose first, then sources, then grading, then usage), and every clause adds substantive information. It is dense and the sources are packed into one long run-on sentence, which slightly hurts scannability, but there is little dead weight.

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 explanation is unnecessary. The description still covers sources, limitations, grading, and usage intent, leaving nothing an agent needs to call it correctly 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 both parameters (hours with range/default, symbol with example) are fully documented in the schema. The description adds no syntax or format detail beyond that, 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?

States a specific resource ('Perp price levels for one coin') and immediately scopes it ('from what printed rather than from a chart'), then enumerates the exact content types: volume-at-price, value area/POC, HVNs, thin zones, OI changes by side, liquidations, and resting walls. An agent can distinguish this from derivatives_flow or flow_orderbook without opening schemas.

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

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

Gives explicit when-to-use context ('where price may stall, accelerate or meet forced flow') and an exclusion ('it is not a forecast'). However, it never names a sibling alternative such as derivatives_flow, derivatives_liquidations, or flow_orderbook, so the agent must infer routing against those tools.

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

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

With only readOnlyHint=true in annotations, the description carries most of the burden and delivers real value: it discloses venue selection and fallback (Hyperliquid then Bybit), that the response names the answering venue and how far its visible book reaches, and how to read imbalance (positive = more bid depth). It stops short of stating data staleness/refresh characteristics, which matter a great deal for an order-book tool.

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?

It is a single dense paragraph, but every clause earns its place: the return fields, the imbalance interpretation, and the venue/fallback note are all decision-relevant. It is slightly front-loaded with an enumeration rather than a purpose statement, but it wastes no sentences.

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

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

For a one-parameter tool with an output schema, the description covers the unusual behaviors an agent could not infer from structured data — venue fallback, venue naming, book depth reporting, and imbalance sign convention. Missing only operational details such as freshness/latency, which are not carried by any other structured field either.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents 'symbol' including a usage example ('BTC'). The description adds no format or coverage detail beyond that, which is exactly the baseline-3 case when structured fields do 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 names a specific resource (order-book snapshot for one coin's perpetuals) and enumerates exactly what it returns: best bid/ask, spread in bps, depth, imbalance, and $10k/$100k market-order cost. It is clearly distinct from market_quotes or fundraising tools. However, it never explicitly positions itself against the close sibling flow_levels, which also concerns order-book levels, so the differentiation is not fully nailed down.

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

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

There is no explicit when-to-use or when-not-to-use statement, and no alternative is named. Usage is only implied: the field list makes it obvious this is for measuring top-of-book liquidity and slippage. The one contextual remark ('Single-venue by nature', with a Hyperliquid-to-Bybit fallback) helps an agent understand what it is getting, but does not tell it when to reach for 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?

Beyond the readOnlyHint annotation, the description discloses important behavioral nuances: the transfer feed only covers ERC-20 tokens, native assets fall back to USDT exchange flows, and the tool interprets withdrawals as accumulation and deposits as potential sell pressure. This adds substantive context about data provenance and meaning that an agent needs to interpret results correctly.

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?

Four sentences, each with a distinct job: scope/components, asset-class caveat, interpretation, and alternative tool. The main purpose is front-loaded, and the prose is dense but not verbose. No filler or repeated schema content.

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

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

For a read-only aggregate tool with no output schema, the description covers data sources, scope, caveats, and interpretation. It does not specify the response shape or group/pagination behavior, but with only two simple parameters and a clear aggregation purpose, this is a minor gap rather than a blocking one.

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 both `symbol` and `min_usd` already clearly documented. The description reinforces the threshold concept ('above a USD threshold') and the coin scope, but it does not add new parameter-level detail beyond what the schema provides. 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 uses a specific verb ('Aggregate') and resource ('whale context for one coin'), then enumerates the concrete components: exchange reserve changes, Binance perps positioning, and large transfers. It also explicitly states the level of detail ('cohort-level, no individual wallets'), which distinguishes it from flow_whale_positions without needing to open that tool.

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

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

The description opens with the scope ('for one coin') and immediately contrasts with the sibling tool: 'For specific whale wallets and their live positions use flow_whale_positions.' It also provides interpretive guidance on when withdrawals/deposits matter, making the intended use case clear. This is explicit routing between 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?

With readOnlyHint=true already conveying the non-mutating nature, the description adds meaningful behavioral context: it auto-discovers accounts from the venue leaderboard, returns a detailed set of per-position fields, and supports following specific wallets. It could go further by noting edge cases like invalid addresses or data freshness, but it is transparent about the main 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 concise and front-loaded with the core purpose, followed by default behavior, optional parameter behavior, and a pointer to the relevant sibling tool. Every sentence earns its place with no redundant 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 single-optional-parameter read-only tool with an output schema, the description covers the default discovery mode, the optional address mode, the returned fields, and the natural alternative for cohort-level signals. Nothing essential is missing for correct 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?

The schema already covers the single parameter thoroughly with a 100% description coverage rate, including the comma-separated format, max 10 wallets, and omit-to-auto-discover behavior. The description adds only minor nuance like 'follow specific wallets instead,' 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 clearly identifies the tool's function: returning live whale positions on Hyperliquid perps, including specific fields like equity, side, notional, entry price, liquidation price, leverage, and unrealized PnL. It also explicitly distinguishes itself from flow_whale_context, which handles aggregate cohort signals.

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 the default behavior (auto-discover largest active whales), explains when to pass the 'addresses' parameter instead, and explicitly directs users to flow_whale_context for aggregate cohort signals. This gives clear when-to-use and when-not-to-use 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 only declare readOnlyHint=true, so the description carries the real burden here and delivers: it discloses that data is 'merged across providers', that the window is ~10 days by default, that points=0 suppresses the series, and that positive means longs pay shorts. Provider-merge and suppression semantics are genuine behavioral detail beyond the 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 first sentence front-loads the purpose well, but the middle is discursive, repeatedly re-explaining why trajectory beats a trailing delta and why a local low/high matters. The same idea ('the trajectory is the point', 'shape a trailing delta flattens away') is argued more than once and could be compressed without losing meaning.

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

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

With no output schema, the description must describe the return shape, and it does so thoroughly: summary metrics, trajectory windows, bucket series, and 1y percentile stats with dates. For a 2-param read tool this is nearly complete; only error/empty-data or provider-availability behavior is unaddressed.

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's points guidance ('omit for the full ~10-day window; 0 to suppress it') essentially restates what the schema already documents, adding no new format or constraint. Symbol gets no mention in the prose at all.

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 (current perpetual funding rate for one coin) with concrete outputs: hourly rate, annualized estimate, 24h/7d trajectory, 8h-bucket series, and 1y percentile line. That unambiguously separates it from derivatives_open_interest, derivatives_liquidations, and derivatives_flow. It never names a sibling to contrast against, which is why it falls 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?

It gives strong guidance on how to interpret the output ('judge the rate against where it has actually been rather than an absolute threshold'), but no guidance on when to select this tool over the derivatives_* siblings, nor any stated prerequisites. Usage is implied by the analytical framing rather than explicit.

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

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

Annotations only declare readOnlyHint=true; the description carries the rest and does so richly — provider fallback chains per market, the auto-fallback heuristic, hard-constraint error behavior for spot/perp, and that the response labels the market/interval/source actually delivered and flags a still-forming last candle. This is exactly the behavioral context annotations cannot express.

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

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

A single dense paragraph that front-loads purpose before parameters, with no filler sentences. It is long and unsegmented, so the nested auto-fallback rule is harder to scan than it could be, 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?

An output schema exists, so return format need not be explained, yet the description still notes response labeling, USD volume presence, and the forming-candle flag. Combined with the parameter semantics, an agent has everything needed 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 the baseline is 3, but the description adds real meaning beyond the schema: the provider chain behind each 'market' value, the auto-fallback condition, and the error-not-substitute contract. Some redundancy exists (it restates the interval enum list, limit default/max, and days deprecation already in the schema), which keeps it from 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?

Opens with a specific verb+resource ('OHLC(V) candle history for a coin by symbol') and immediately scopes it with the key identifying parameters. An agent can distinguish this from siblings like market_history, market_quotes, or ta_technicals 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?

Gives strong in-tool selection guidance: 'market' spot/perp/auto with an explicit preference order and the exact condition under which auto falls back to perp (spot history shorter than the request and than 210 candles), plus the fact that spot/perp are hard constraints that error rather than substitute. It does not, however, say when to reach for this tool instead of sibling tools such as ta_technicals or market_history.

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 annotation, the description discloses non-obvious behavior: IDs are case-sensitive, symbols or wrong-case IDs are resolved via search, and the response names the actually fetched ID so a resolution is never silent. This is exactly the kind of behavioral context 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?

Two sentences contain zero filler: the first front-loads the action and data returned, the second adds the resolution caveat essential for correct invocation. Every clause earns its place.

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

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

For a one-parameter, read-only tool with no output schema, the description is complete: it names the input forms, examples, case-sensitivity behavior, and the high-level return fields. An agent has enough to call it correctly and interpret the response.

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 goes beyond the schema by adding multiple examples and, crucially, the wrong-case resolution guarantee ('a resolution is never silent'), which clarifies what happens with non-exact inputs.

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 ('Fetches'), a clear resource ('a coin by its CoinGecko coin ID or ticker symbol'), and the exact fields returned (price, market cap, ATH/ATL, description). This distinguishes it from sibling list/quotes tools like market_coins or market_quotes without needing to open their 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 intended use is clearly implied: use this tool when you need detailed single-coin data by ID or symbol. However, it never explicitly names sibling alternatives or states when-not-to-use it, so the agent must infer routing based on the tool name and description.

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 readOnlyHint annotation already covers the read-only nature. The description adds only the source/scope ('from the market-data provider') and does not disclose return format, ordering, or whether the list is exhaustive. This is acceptable but minimal.

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

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

The description is a single, front-loaded sentence with no filler. It delivers the key action and resource immediately and earns its place without 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?

For a no-parameter, read-only enumeration tool, the description is nearly complete: it explains what is returned (coin symbols). It would be slightly stronger if it noted that the returned symbols can be used as inputs to market_* tools, but nothing critical is missing for correct invocation.

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

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

The tool has zero parameters and the schema has 100% coverage, so there are no parameter semantics for the description to add. The baseline for a no-parameter tool is 4, as nothing is missing here.

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 ('Lists') and a specific resource ('coin symbols available from the market-data provider'). It clearly distinguishes this tool from siblings like market_coin_details, which provide details about individual coins rather than enumerating supported symbols.

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 the tool is used when you need the list of supported coin symbols, but it gives no explicit guidance about when to choose this tool over alternatives. It does not mention exclusions or point to related market tools such as market_quotes or market_candles.

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 only supply readOnlyHint=true; the description adds pagination mechanics (pass nextEndMs back as 'end'), a 'start' stop condition, the fact that the newest row may still be forming (newestForming), and precise data provenance/retention windows per source. This is rich behavior beyond the 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?

Front-loaded with purpose, then paging, then reach, then routing; every section earns its place. Slightly redundant in restating limit/interval defaults already present in the schema, but the density is justified for a complex paginated tool.

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 need not be described, and the description still covers pagination flow, coverage limits, defaults, and sibling routing. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is high (86%) and carries most parameter docs, but the description adds real value the schema lacks: the meaning of each 'metric' enum value (OHLCV candles, market-wide OI aggregate, OI-weighted %/8h funding, long/short liquidation buckets) and the paging contract for 'end'/'start'.

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 ('Bulk history for one coin, one metric per call, in pages') and enumerates the exact metric modes with their semantics. It is clearly distinct from siblings such as market_candles and the derivatives_* 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?

Explicitly routes the agent: 'Use this to pull history; for a read of what is happening now, use the derivatives_* and research_* tools.' It also gives selection rules, e.g. 'use 1d for anything older than six months' and interval availability by metric.

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, so the read-only nature is covered. The description's word 'snapshot' adds a point-in-time behavioral context, but it does not disclose data freshness, latency, or any limitations. With annotations handling the safety profile, this is adequate but not rich.

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

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

A single, front-loaded sentence that names the deliverable and enumerates the key metrics with no filler. Every phrase earns its place, and the structure is easy to parse quickly.

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, high schema coverage, and an output schema present, the description gives an agent everything needed to understand what will be returned. The metric list is sufficiently complete for a no-argument market snapshot 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 tool takes zero parameters, so there is nothing for the description to clarify about input semantics. The baseline for zero-parameter tools is 4, and the description appropriately focuses on what the returned snapshot contains rather than 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 clearly identifies the tool as a 'Global market snapshot' and names the exact metrics it returns: total market cap, BTC/ETH dominance, Fear & Greed index, and Altcoin Season index. This differentiates it from most siblings by content, though it does not explicitly contrast it with closely related tools like sentiment_fear_greed or market_quotes.

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

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

The description explains what the tool provides but gives no guidance on when to choose it over the many sibling market and sentiment tools. No alternatives, exclusions, or conditions are stated, so the agent is left to infer usage from the phrase 'Global market snapshot.'

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 annotation, the description explains that prices come from different sources, that spot and perp fields are intentionally separate, and that the difference is the basis. This prevents an agent from misreading the combined snapshot as a single unified price.

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 carrying distinct information: scope/fields, price-source semantics, and filtering. There is no filler or duplicated annotation content.

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

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

With an output schema present and readOnlyHint set, the description covers the tool's purpose, data semantics, provider merge behavior, and parameter usage. No critical calling context 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 already fully documents 'symbols' with an example and omit behavior at 100% coverage. The description restates that but adds no new semantic detail beyond 'covered coin'.

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 concrete noun phrase ('Per-coin market snapshot') and enumerates specific data fields, making the tool's scope clear. The per-coin scope and merged-provider wording differentiate it from market_overview and funding_current, even without naming 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?

The symbol parameter usage is explicit ('Pass symbols to filter... omit for every covered coin'), but there is no guidance about when to prefer this tool over funding_current, derivatives_open_interest, or market_candles. Usage context is implied by the snapshot wording rather than explicit.

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

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

The readOnlyHint annotation already establishes safety, and the description adds useful context about the data scope and threshold. It does not disclose output size, sorting behavior, or whether gainers and losers are returned separately, but for a parameterless read-only list this is a mild gap rather than a serious one.

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 phrase that front-loads the key concepts: 24h gainers, losers, and trend candidates. The parenthetical threshold adds precision without extra words, and every component earns its place.

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

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

For a parameterless read-only tool, the description provides enough context to understand what results will represent and to choose the tool correctly. Minor missing details such as the number of entries returned or quote currency do not affect the ability to invoke it, since there are no parameters and the read-only annotation covers the safety profile.

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 input schema is empty, so there are no parameter semantics for the description to clarify. The baseline score of 4 applies because schema coverage is trivially complete and no invocation arguments 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 identifies the resource: ranked 24h gainers, losers, and trend candidates with a >+5% move threshold. It does not use an explicit action verb like 'returns' or 'lists,' and it does not explicitly distinguish itself from sibling tools such as market_trending, though the 24h movers framing implies a different purpose.

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

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

The intended usage is implied: an agent should use this for recent price movers over 24 hours with significant percentage changes. However, there is no explicit guidance about when to prefer this over alternatives like market_trending or market_overview, and no exclusion criteria are 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?

The readOnlyHint annotation already covers safety, and the description adds the temporal 'currently' scope plus that a list is returned. It does not explain what 'trending' means, the ranking basis, or additional behavior, but for a read-only, zero-parameter tool this is a reasonable 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?

The description is a single sentence that is front-loaded with the verb and resource, containing no filler or repetition. It is appropriately sized for a zero-parameter, read-only tool.

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 zero-parameter tool, the description adequately conveys that the output is a list of currently trending cryptocurrencies. Without an output schema, it could go further by defining 'trending' criteria, but the missing detail is minor given the tool's simplicity.

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 no schema ambiguity for the description to clarify. The baseline for parameterless tools is 4 because no additional meaning is 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 uses a specific verb and resource: 'Lists the currently trending cryptocurrencies.' It clearly states what the tool does, but it does not explicitly distinguish it from siblings like market_top_movers or market_coins, which could overlap conceptually.

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 'currently trending' implies this is the tool to use when a user asks about trending cryptocurrencies. However, no explicit when-not-to-use guidance or alternative routing is provided, leaving the agent to infer boundaries versus similar market tools.

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

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

The readOnlyHint annotation already covers safety. The description adds useful behavioral detail: unsupported symbols return a plain message, time ranges are 24h/7d/30d, and gas price is not covered. 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 sentences with no fluff. The main data scope is front-loaded, followed by input guidance and caveats. Every sentence earns its place.

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

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

For a single-parameter read-only tool with no output schema, the description is complete: what metrics are returned, what input format to use, what unsupported inputs do, and what is excluded.

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 schema already documents the symbol parameter. The description adds meaning by specifying 'own token symbol', giving L1/L2 context, and adding examples like 'BNB'. This goes beyond the schema's brief 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 states a specific verb and resource: returns on-chain TVL and network fees/revenue for one chain. It clearly distinguishes this from market-data siblings by focusing on on-chain metrics and a single-chain 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?

Clear usage context: use a chain's own token symbol, and non-L1/L2 tokens produce a plain 'not a tracked chain' message. It also excludes gas price. It does not explicitly name alternative tools, but the guidance is still 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?

Annotations only declare readOnlyHint=true, so the description carries the rest of the burden and does: it names the data source (Deribit), the exact metrics returned including USD vs native denomination, and the liquidity profile per underlying. That liquidity-depth warning is exactly the kind of behavioral context annotations cannot express.

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, each with a distinct job: what is returned, which expiries exist, which underlyings and how liquid. No filler and the resource definition 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?

With no output schema, the description compensates by enumerating the returned fields and their denominations, and it flags underlying coverage limits. For a read-only, seven-parameter chain fetch, an agent has everything needed to call it correctly and interpret the result.

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 schema already documents all seven parameters including the enum and the 'next'/date/exchange-code expiry formats. The description's defaults (next expiry, ±10% spot, both types) largely restate what the schema already declares, adding little beyond 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?

States a specific verb and resource: a Deribit crypto options chain for one underlying and expiry, calls/puts by strike. The enumerated return fields (bid/ask/mark, mark IV, Black-76 delta, OI, 24h volume) make it unmistakably the raw-chain tool rather than the sibling analytics tools (options_gamma, options_volatility, options_positioning).

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 operational context: which underlyings exist, that BTC/ETH books are deep while SOL/XRP/HYPE/AVAX/TRX are thin, and what the defaults are when the caller omits filters. It never names a sibling or an explicit when-not condition, 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?

Goes well beyond the readOnlyHint annotation by disclosing that signed output depends on an explicit dealer-positioning scenario and that the numbers are modeled, not observed orders. It also explains what the what-if path actually does (reprices the same frozen contracts, drops expired contracts via horizon_hours), which is exactly the kind of caveat an agent needs before trusting the output.

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?

Purpose is front-loaded, but the body is one very dense run-on sentence cramming output enumeration, what-if mechanics, and disclaimers together. Much of the output listing duplicates what a reader would infer from parameter names, and the dense packing makes skimming harder than a short bulleted structure would.

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

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

With no output schema and 8 parameters, the description carries the return-value burden and does enumerate the output blocks (GEX, walls, flips, regime, funding/OI block), so an agent knows what comes back. Remaining gaps are minor: no indication of result size, timing, or freshness for a computation this heavy.

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 additionally clarifies parameter interactions not obvious from the schema, such as any what-if parameter implying hedging and horizon_hours dropping contracts that expire in the interval. It still leaves details like price_change_pct's relationship to the built-in ±0.5–5% ladder slightly ambiguous.

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

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

States a specific resource and computation: crypto options gamma exposure (gross and dealer-signed GEX) by strike/expiry, plus walls, flip levels, and a rule-based options regime. This clearly separates it from siblings like options_chain (raw chain) or options_volatility, though it never names those siblings explicitly.

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

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

Usage is implied through the what-if and hedging mechanics ('hedging=true adds theoretical dealer hedge ladders', 'target_price / horizon_hours / iv_change reprice the same frozen contracts'), but there is no statement of when to reach for this tool versus options_positioning, options_volatility, or flow_levels, and 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 declare readOnlyHint=true, so the safety profile is covered. The description adds genuine context beyond that: the data source (Deribit), the derivation method for OI change (hourly snapshots), and the interpretive limit (descriptive, not a direction signal). It does not cover latency, pagination, or whether an underlying with no listed options returns empty versus errors.

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 capability list is front-loaded and every clause names a distinct metric, so little is wasted. It is one very long run-on sentence, which makes it slightly harder to scan than a bulleted enumeration, but nothing is redundant.

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

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

There is no output schema, and the description compensates by enumerating nearly every returned field, so an agent knows what to expect. The main residual gaps are source coverage (Deribit only — no mention of fallbacks) and the empty/error case, which matter for a read-only analytics call of this breadth.

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 currency, expiries, and trades_hours are already documented including defaults and maxes. The description only reinforces that the tool operates on one underlying and implies a recent trade-flow window; it adds no format or edge-case detail (e.g. case sensitivity of the symbol, behavior when trades_hours=0). 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?

States a specific resource (crypto options positioning for one underlying on Deribit) and enumerates the concrete outputs: OI in coins/USD, put/call ratios, strike concentrations, expirations, max pain, OI change, trade flow. This is clearly distinguishable from siblings like options_chain or options_gamma, which cover different slices of options data.

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 closing caveat "Descriptive positioning — not a direction signal" gives useful framing on intent, but no sibling is named and there is no explicit when-to-use/when-not-to-use guidance versus options_chain, options_gamma, derivatives_flow, or research_positioning. Usage is implied by the content list rather than 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 establish readOnlyHint=true, so the safety profile is covered; the description adds real value by disclosing the derivation method (lognormal at that expiry's ATM IV and forward) and the important limitation that the smile-adjusted figure only applies within quoted strikes. It does not describe output shape or behavior when price/range params are omitted, which keeps it off a 5.

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

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

Two sentences, no filler, with the core identification front-loaded and the caveat placed last where it belongs. The first sentence is heavily compressed with jargon stacking (lognormal/ATM IV/forward/smile), which costs a little readability.

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

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

With no output schema, the description carries the burden of describing return values, and it does so adequately (above/below probabilities, range probability, 68%/90% bands, smile-adjusted value). It stops short of covering default behavior when price or range bounds are omitted, a realistic agent question for a 5-parameter tool.

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

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

Schema coverage is 100%, so a 3 is the baseline; the description earns an extra point by framing that all parameters apply to a single expiry and by clarifying that the model is anchored to that expiry's forward and ATM IV, which shapes how price and range inputs should be interpreted.

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 quantity (risk-neutral probabilities from Deribit crypto options), the unit of analysis (one expiry), and the concrete outputs (P(above)/P(below), in-range probability, 68%/90% ranges, plus a smile-adjusted value). This is functionally distinct from the sibling vol/chain/gamma tools even without naming 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?

Usage is only implied via the closing caveat 'Market-implied odds, not calibrated forecasts', which usefully tells the agent what the numbers are not, but there is no explicit when-to-use rule or pointer to alternatives such as options_volatility or options_chain for other option-derived questions.

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 tool clarifies its fundamental nature: measuring 'how fast a move options price, not its direction.' It provides rich behavioral context by listing specific calculated timeframes and statistical measures like '1y percentile' and '25-delta risk reversal'.

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 technically overloaded, making it hard to read, but it prioritizes information density. Every clause provides a high-value piece of information regarding the tool's content.

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

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

While the input scope is meticulously covered, the definition lacks any mention of the output structure or how the return data for different underlyings should be interpreted, which is a gap given the complexity.

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?

Since schema coverage is 100%, the schema handles the technical requirements (string input). The description adds semantic value by demonstrating how the input should be structured (comma-separated list) and used (for comparison).

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 is extremely clear and functions almost as a technical specification, detailing exactly what kind of implied volatility metrics are provided (e.g., DVOL index, IV term structure, skew). It specifically states the data source (Deribit).

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 suggests a primary use case for the input parameter: 'Pass several underlyings ("BTC,ETH") to compare.' While it doesn't explicitly list alternatives, it clearly defines the specific financial context of the 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?

Beyond the readOnlyHint annotation, the description discloses the core aggregation rule (sum of votes), a specific exception (Trend vote withheld when 30d realized vol is at/below its 5th percentile), that compression is flagged structurally, that the asymmetry lean is informational and never votes, and that thresholds for changing the call are included. That is unusually rich behavioral disclosure for a read-only tool and directly informs how the agent should interpret output.

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 purpose is front-loaded in the first clause, and the dense enumeration that follows is information-bearing rather than filler. It is a long single paragraph, though, and the seven-axis catalog could be tightened; a bulleted structure would aid scanning, so it falls short of a 5.

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

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

With an output schema present, return values needn't be explained, and there are no parameters to document. What remains — what the tool computes, how votes combine, the volatility-compression exception, and the deterministic guarantee — is fully covered, leaving no gap an agent would need to guess at.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate — baseline 4 applies. No parameter-related content is missing or misleading.

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 verb and resource — 'deterministic market-regime classification' — and then enumerates the seven axes it covers, including the exact indicators used per axis. This is clearly distinct from siblings like research_opportunities, research_trade_plan, or market_overview, so an agent can select it without opening any 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 gives explicit usage context: 'Useful as a first call: most other signals (funding, sentiment, flows) read differently depending on this regime,' which tells the agent where this sits in a call sequence. It stops short of naming specific alternatives or stating when NOT to use it, keeping it at a 4 rather than 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?

Despite only carrying readOnlyHint=true, the description goes well beyond annotations by disclosing extensive behavior: output metrics, named checks, cost modeling, replay statuses, and that nothing is stored. This is exactly the kind of behavioral context an agent needs for a complex read/analysis tool.

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 purpose and justified by the tool's complexity, 13 parameters, and lack of an output schema. It is dense with semicolon-chained details, so it is not maximally clean, but most content earns its place.

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

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

For a complex tool with no output schema, the description explains the return values, named checks, cost breakdown, replay statuses, and storage behavior. An agent has enough context to invoke and interpret the tool correctly.

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

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

Schema coverage is already 100%, so the schema does most parameter documentation. The description still adds operational meaning, such as account_size and risk_percent being both-or-neither, how placed_at toggles replay, and how order_type affects fills and fee treatment.

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: check, review or replay a perp trade setup before or after placement. It distinguishes itself from sibling tools explicitly by naming research_opportunities and flow_levels and stating it is a check, not a signal.

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 when-to-use guidance: after research_opportunities or flow_levels suggests a setup, and before or after placement. It also clarifies it is not a signal, which directly separates it from signal-producing 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, and the description adds useful behavioral context: the index updates roughly every 15 minutes and returns a value plus label. It also clarifies the market-wide scope. This goes beyond the annotation without contradicting it.

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 pack the essential information: what the tool returns, how fresh it is, and which sibling to use for a broader view. There is no filler or redundant repetition of the tool name or title.

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, parameterless, read-only tool, the description fully covers what an agent needs: the metric, its range, update frequency, scope, and a pointer to an alternative. No output schema exists, but the return shape is adequately described as an index value plus label.

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 for this dimension is 4. There is no parameter detail to add, and the description's mention of the 0-100 range plus label is sufficient for a parameterless call.

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 a market-wide Fear & Greed index with a 0-100 range and label, and positions it as a macro sentiment gauge. It distinguishes itself from market_overview by naming that sibling as the full-market alternative. A specific verb is missing, but the intent is 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 states that this is a macro sentiment gauge and explicitly directs the agent to market_overview when a full market snapshot is needed. It does not mention sentiment_social or sentiment_twitter, but the alternative guidance is clear enough for most selection decisions.

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 readOnlyHint annotation already signals safe read-only behavior, and the term 'snapshot' aligns with it. The description adds metric-level detail but no additional behavioral context such as rate limits, data freshness, or source scope.

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?

Single sentence, front-loaded with the core purpose and then a compact metric list; no filler or repeated schema content.

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

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

For a single-parameter read-only snapshot, the description lists all returned metrics with relevant units and scales (0-100, %, lower-is-stronger), so an agent can call it and interpret the result without an 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?

Schema covers the only parameter 100% with a clear example ('Coin symbol, e.g. BTC'), so the baseline applies. The description adds no further parameter semantics beyond implying the coin symbol is the required lookup key.

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?

Clearly identifies a social-sentiment snapshot for a single coin and enumerates the specific metrics returned (galaxy score, alt rank, bullish sentiment, volume, dominance, interactions). It does not explicitly contrast with sentiment_twitter or sentiment_fear_greed, but the 'one coin' scope and metric list distinguish it from broader sentiment 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?

No when-to-use guidance is given. The description never states when to prefer this over sentiment_twitter, sentiment_fear_greed, or other sibling tools, and it offers no exclusion criteria; only the implicit 'for one coin' scope.

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=true already covering the safety profile, the description adds real behavioral context: a hard 7-day recency window, a 10-Post cap, and the default relevance sort order. It does not mention rate limits or auth requirements, but the operational constraints it does give are the ones an agent needs.

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

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

Two sentences, front-loaded with what the tool searches and immediately followed by the return contents and sorting constraint. Every clause carries information; no filler or restatement of the name.

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

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

An output schema exists, so the brief mention of engagement/views/links is a bonus rather than a requirement. Recency window, cap, and sort default are all covered, leaving only auth/rate-limit specifics unaddressed for a low-complexity read tool.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description reinforces latest=true, the 10-Post cap, and the query syntax but adds no format or syntax detail beyond what the schema fields state, matching the baseline 3.

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

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

Names a specific verb and resource ('Searches public X Posts') plus the scope ('last 7 days'), and lists the supported query syntax. The X/Twitter resource implicitly separates it from sentiment_social and sentiment_fear_greed, but no sibling is named explicitly, 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?

Usage is implied by the syntax and window description, and one behavioral alternative is noted (latest=true switches to newest instead of top relevance). There is no statement of when to prefer this over the sibling sentiment tools (sentiment_social, sentiment_fear_greed), so guidance is only implied.

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

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

Annotations only supply readOnlyHint=true, so the description carries the burden and does so richly: local computation provenance, the transparent EMA-alignment-qualified-by-ADX trend rule, routing/fallback behavior for the candle series, the max-4-interval constraint, and the daily-ATR clustering logic for support/resistance. This is substantial behavioral context well beyond what the single annotation provides.

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

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

Front-loads the core purpose and indicator inventory before the routing and S/R details, so an agent gets the gist immediately. It is dense and long, but nearly every clause conveys distinct capability information rather than filler, so the density is justified.

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 need not explain return values, and combined with the schema and annotations it covers provenance, routing, constraints, and indicator coverage completely. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents symbol, intervals (with the default and enum list), and market (with the spot-preferred/perp-fallback semantics), establishing the baseline of 3. The description largely restates these, adding only the 'max 4' emphasis and the rationale for the fallback rather than new syntax or format 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?

States a specific verb+resource ('multi-timeframe technical-analysis snapshot for one coin'), enumerates exactly which indicators are computed (RSI, EMA/SMA, MACD, ATR, Bollinger, ADX, volume, trend rule), and explicitly distinguishes itself as computed locally from real candles rather than a vendor black box. An agent can separate it from flow_levels, market_candles, and research_trade_plan without opening a 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?

Explicitly routes the agent: 'For levels from executed perp flow... use flow_levels' and notes ATR stop suggestions feed research_trade_plan. It also explains the market=auto fallback logic so the agent knows when spot vs perp applies. It does not enumerate when NOT to use it against the many other market_* siblings, but the named alternative 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?

The readOnlyHint annotation already covers safety, and the description adds the key behavioral detail: the output is the current UTC time in ISO 8601 format. For a stateless time-returning utility, nothing more is needed.

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 primary behavior comes first, and the use-case motivation follows in one compact example.

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 tool with no output schema, this description is complete: it states what is returned, the format, and a concrete use case. 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?

There are zero parameters, so the schema carries no semantic burden. The description still adds value by specifying the output format (ISO 8601), which is the only relevant interface 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?

States a specific verb ('Returns') and resource ('current UTC time') with an explicit format (ISO 8601). Its purpose is immediately distinguishable from the sibling data tools, which all return market or news data rather than a time anchor.

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

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

Gives a clear context of when to use it: anchoring 'now' and judging staleness of timestamps. There are no competing sibling time tools, so not naming alternatives is acceptable; only explicit exclusions are absent.

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