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?

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 annotation already marks this as readOnlyHint=true, so the description doesn't need to cover safety. It adds valuable behavioral context by describing the returned items (tagged with kind and price move where measured) and the ordering. It stops short of disclosing potential pagination or result limits, but for a read-only search tool, the description goes beyond the annotation sufficiently.

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 fluff. The primary action and resource are stated up front, followed by specific details on content types, ordering, and output tagging. Every sentence contributes value, and it is well-structured for quick scanning by an agent.

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 search tool, the description covers the core functionality, output content, and ordering. It does not mention pagination, result limits, or date-range constraints, but given the simplicity and the presence of the readOnlyHint annotation, the description is reasonably complete for an agent to make a correct call.

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

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

Schema description coverage is 0% and there is only one parameter, 'query'. The description implies that 'query' is the search topic, but it does not explicitly define its format, requiredness (though it is required per schema), or any constraints. For a simple string parameter, the description's contextual implication is adequate, but it does not fully compensate for the lack of schema documentation.

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

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

The description states a specific verb ('searches'), a clear resource ('recent news on a topic'), and enumerates the content types (articles, market-moving posts, exchange announcements) and ordering (newest first). It distinguishes itself from sibling tools like sentiment_social or market_quotes by its focus on news retrieval with price-move tagging, leaving no ambiguity about its function.

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 conveys that this tool is for finding recent news on a given topic, which is a distinct use case among the siblings. However, it does not explicitly state when to use it instead of alternatives (e.g., sentiment_social for social sentiment, or filings_search for official filings), nor does it mention any exclusions or complementary tools. The context is clear but the guidance is implicit rather than explicit.

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

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

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?

The description is consistent with the readOnlyHint annotation and adds the scope 'each connected data provider.' However, it doesn't disclose details like what health metrics are reported, whether it pings endpoints, or how statuses are represented. Since annotations already cover the read-only safety profile, the description adds only modest behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. It immediately states the action and the target resource, making it easy for an agent 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?

For a parameterless read-only health-check tool, the description gives enough information to call it correctly and understand the general result. There is no output schema, but 'health of each connected data provider' sufficiently conveys what the agent should expect, even if exact field names are not specified.

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 covers 100% of the (empty) parameter surface. The description doesn't need to explain parameters because there are none, and the baseline for no-parameter tools is appropriately strong.

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 ('Reports') and resource ('health of each connected data provider'), making the tool's function unambiguous. None of the 28 sibling tools relate to provider health, so it is easily distinguished from them without needing to open 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 usage context is clear: an agent should call this tool when it needs the health status of connected data providers. It doesn't explicitly name alternatives or exclusions, but there are no sibling tools that overlap with this purpose, so the guidance is sufficient.

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 adds substantial behavioral context beyond that: zero per-symbol calls to the rate-limited derivatives provider (explaining why it is safe at scale), liquidity filtering before candle fetching, bounded shortlist, the six-signal construction with vote semantics, and the honest caveat that bands are disclosed constants with no backtest. It also discloses the tier/floor/symbol accounting contract so absence from the list is never ambiguous.

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

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

The core differentiation is front-loaded in the first sentence and the operational cautions are placed well. It is dense and long — the per-signal enumeration is heavy and a few clauses (e.g. restating research_regime's BTC-only scope) could be trimmed — but nearly every sentence carries a distinct constraint or routing cue, so it stays 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, return values need not be explained; the description instead covers everything else an agent needs — universe construction, signal definitions and vote polarity, geometry conventions, parameter effects, and failure-mode semantics. Given the tool's complexity, nothing material is left unspecified.

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

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

Schema coverage is 100% and the schema itself is unusually rich (the 'intervals' description explains candle-cost, confirmation-slower rule, and timeframe scaling). The description still adds meaning on top: it clarifies that 'tier' filters major/medium/all, that 'limit' caps the ranked list, and that each symbol in 'symbols' is individually accounted for under five possible dispositions. That is real added semantics rather than repetition.

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 cross-sectional screener over the whole major/medium-cap universe — and immediately distinguishes it from the per-coin tools ('the screener the per-coin tools cannot be looped into safely'). It names the sibling tools it complements (research_positioning, research_regime, research_trade_plan, ta_technicals), so an agent can place it in the toolset without ambiguity.

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

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

Gives explicit workflow direction: 'Use it to pick what to look at, then research_positioning and ta_technicals on the two or three that stand out,' and notes geometry feeds research_trade_plan directly. It also states when the tool legitimately returns nothing ('NO CANDIDATES' is a real and frequent answer), which prevents the agent from treating an empty board as a failure.

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 give readOnlyHint=true, so safety is already covered; the description usefully adds determinism ('same inputs, same read'), the explicit stance rule (sum-of-votes), the degradation behavior of the fragility axis, and the critical framing 'Reports the board, not a direction — crowding says who is paying, not where price goes.' Much of the remaining text enumerates return content rather than behavior, which blunts it slightly.

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 a strong orienting sentence, but the axis catalogue runs to roughly 350 words for a one-parameter tool, and a large share of that detail restates return values already carried by the output schema. Dense and hard to scan; a good chunk does not earn 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?

Nothing an agent needs to select or invoke the tool is missing: scope, sequencing, stance semantics, and determinism are all present. It undershoots on conciseness rather than completeness, over-explaining return values that the output schema already provides.

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?

Single parameter with 100% schema description coverage, so the schema already documents 'symbol' fully. The description adds no syntax, format, or edge-case guidance for the parameter. Baseline 3 applies 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?

Opens with a specific verb+resource and scope ('Deterministic positioning read for one coin'), then frames it as 'the game-state companion to research_regime' and enumerates the exact question it answers ('who is crowded, who is paying, who is trapped, and where'). An agent can distinguish it from research_regime, funding_current, and flow_whale_positions 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?

Gives explicit sequencing and context: 'Call research_regime first for market context, then this per coin before sizing or timing decisions.' It names the sibling to chain from and the decision point at which this tool belongs, leaving nothing to inference.

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

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

Annotations only declare readOnlyHint=true, but the description goes well beyond that by disclosing the sum-of-votes rule, the compression exception that withholds the Trend axis vote, the informational non-voting asymmetry lean, the explicit thresholds, and the deterministic behavior. This is far richer than the annotations alone and gives the agent a clear model of the tool's 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 dense but every sentence earns its place: the core classification is front-loaded, and the vote rule, exception, lean, thresholds, determinism, and usage positioning are all operationally relevant. The detail is justified by the complexity of the regime logic.

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 already covering the return shape and zero input parameters, the description supplies exactly the contextual information an agent needs: the composite nature, the exception behavior, the asymmetry lean, and when to use the tool. Nothing essential is missing.

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

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

The tool has zero parameters, so there is no parameter ambiguity and the empty input schema is fully self-contained. The description uses this opportunity to clarify output semantics and behavioral rules, which is more valuable than restating empty parameter details.

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

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

The description clearly defines the tool as a deterministic market-regime classifier across seven explicit axes and states exactly what it produces: per-axis state, supporting numbers, votes, and an overall posture. It effectively distinguishes itself from raw-data sibling tools by positioning it as a composite first-call regime read.

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

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

The description explicitly frames the tool as a first call and explains that funding, sentiment, and flows should be interpreted differently depending on this regime. This gives an agent strong context for when to invoke it, though it does not list explicit when-not-to-use cases or name specific sibling tools as alternatives.

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

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

Annotations already mark it read-only, and the description adds meaningful behavioral context: it is an aggregate assembled from multiple feeds, on-chain data is conditional on the symbol being tracked, and it includes a per-section status list that distinguishes empty sections from failed feeds. 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?

The description is one dense front-loaded sentence that starts with the core purpose before listing sections. It is long, but almost every clause names a distinct output category or caveat, so the length is justified by the tool's breadth; breaking it into bullets would improve scannability.

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

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

Given a simple input schema, a read-only annotation, and an output schema that covers return structure, the description covers the relevant behaviors and conditional cases (tracked chains, per-section failures, live provider coverage). An agent has enough information to call this tool and interpret its aggregated 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?

With 100% schema description coverage for the sole symbol parameter, the schema already documents the meaning and example. The description repeats the one-symbol scope and ETH example but does not add constraints like case-sensitivity, accepted symbol formats, or validation behavior, so it stays at baseline.

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

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

The description opens with 'Aggregated single-coin dossier' and enumerates the full set of data categories for one symbol, so an agent immediately knows what the tool returns. It also distinguishes itself from siblings by noting equivalent content to market_quotes and ta_technicals, making its aggregation role explicit.

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 strongly implies this is the broad overview tool and points out where its data overlaps with market_quotes and ta_technicals, but it never explicitly says when to prefer this over a specialized sibling. There is no when-not guidance or alternative routing, so an agent must infer the usage boundary.

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

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

Annotations only declare readOnlyHint=true, but the description adds substantial behavioral context: nothing is persisted ('the numbers come in, the replay goes out'), planLine is the round-trip handle, liquidation is priced with first-tier 0.5% maintenance margin (flagged as the optimistic case), and the full status set (PENDING/MISSED/OPEN/STOPPED/TARGET/AMBIGUOUS) is enumerated. No contradiction with readOnlyHint.

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 in the first sentence, and every subsequent clause maps to a real behavior (returns, statuses, sizing coupling, replay rules). It is dense as a single block — the return inventory could be broken out — but little of it is filler for a tool of this complexity.

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

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

With no output schema, the description carries the return burden itself and does so thoroughly: reward:risk, stop distance in % and 4h ATR, liquidation price, funding per day, perp levels, and the named checks. Edge cases (AMBIGUOUS candle, MISSED target-first) and the stateless model are covered, 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 baseline is 3, but the description genuinely adds semantics: the both-or-neither coupling of account_size and risk_percent, the leverage default logic, and the order_type fill rules (limit fills on approach or immediately if already marketable). It stops short of 5 because most field-level detail is still carried by the schema.

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

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

States a specific verb set and resource: 'Check, review or replay a perp trade setup (entry, stop, optional target)', and names the sibling tools it follows (research_opportunities, flow_levels). It also explicitly disclaims being a signal, which separates it from adjacent research tools 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?

Explicit routing: use after research_opportunities or flow_levels has suggested a setup. It gives conditional guidance for placed_at ('pass it whenever the user says when the trade was placed') and instructs to ask the user rather than re-call when order_type is ambiguous — when/when-not/alternatives are all covered.

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.