f1ow

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

ReadOnlyHint is provided, and description aligns. Adds time window (next 7 days) and optional filtering, which is fine but minimal behavior beyond 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 concise sentences, front-loaded with core function and an example. No wasted words.

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?

Simple list tool with one optional param and high schema coverage; description is adequate but does not mention return structure or any pagination/limits. However, with low complexity and no output schema, it is sufficient.

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 coins 100% with example. Description repeats the example, adding no new meaning beyond 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 it lists crypto catalyst events for the next 7 days. Clear verb and resource, but doesn't describe what a 'catalyst event' is or contrast with sibling tools like catalysts_economic_calendar.

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?

Implies usage for upcoming crypto catalysts, optional filter by coins. No explicit exclusions or when to use alternatives like economic calendar.

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 declare readOnlyHint=true, and the description adds useful context about the time range and the filter behavior without contradicting the annotation. It does not describe error conditions or response format, but for a read-only calendar tool this 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?

The description is a single, concise sentence that front-loads the core purpose and includes the optional parameter in a natural way. No wasted words or redundancy.

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

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

For a simple read-only tool with one optional parameter, the description covers the essential details: content type, time window, and filtering option. It does not specify the return fields, but that is not critical for such a tool and there is no output schema to hint at them.

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 description repeats the parameter info already present in the schema (min_importance values, default). It adds no new meaning beyond what the schema provides, 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 states 'Scheduled macroeconomic data releases' with specific examples (CPI, FOMC, jobs, GDP) and a defined time window, making it distinct from sibling tools like catalysts_calendar.

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

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

No guidance is provided on when to use this tool versus alternatives such as catalysts_calendar or other catalyst-specific tools. It only describes the tool's own behavior without mentioning exclusions or competing options.

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 description doesn't need to restate that. It adds valuable behavioral context beyond annotations: explains the meaning of positive flows, the reporting lag, and the pricing nuance. This enriches the agent's understanding of what the tool returns and potential caveats. It doesn't mention auth or rate limits, but those are less critical for a read-only data retrieval tool.

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

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

The description is a single paragraph that is well-structured: main purpose first, then key outputs, then important caveats (lag and price), and alias info. Every sentence earns its place; no redundant or filler content. It's concise yet comprehensive, covering all essential aspects without unnecessary length.

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

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

With no output schema, the description must convey what the tool returns, and it does: latest day total, per-fund breakdown, trailing daily trend. It also covers the critical behavioral details (age, price timestamp) and parameter semantics. Given the tool's simplicity (2 params, 0 required), the description is complete and self-sufficient, leaving no major gaps for an agent to operate correctly.

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

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

Schema description coverage is 100% (asset and symbol both described). The description adds the accepted asset list (BTC, ETH, SOL, XRP) and clarifies that 'symbol' is an alias, which is not explicitly in the schema but implied. It also reinforces the default behavior. This adds meaningful guidance beyond the schema, though it doesn't go into format details like case sensitivity. Given full schema coverage, a baseline of 3 is exceeded.

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

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

The description clearly specifies the tool's function: 'Recent daily spot-ETF net flows (USD) for an underlying asset (BTC, ETH, SOL, XRP; defaults to BTC)' with concrete outputs (latest day total, per-fund breakdown, trailing daily trend). It distinguishes itself from siblings like flow_orderbook and market_candles by focusing on ETF flows. The verb 'flow' is specific, and the resource (spot-ETF net flows) is unambiguous.

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

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

The description provides clear context on when to use the tool, highlighting data freshness ('Flows settle behind spot and skip weekends, so the latest row is routinely a day or more old') and the nuance that the price is from that date not spot. It also mentions the 'symbol' alias for asset, which aids usage. However, it does not explicitly name alternatives or state when not to use this tool compared to sibling tools, though the uniqueness is 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?

Beyond the readOnlyHint annotation, the description discloses fallback to a single-venue figure when the aggregate source is offline and describes the series structure (4h buckets, window low/high). This adds meaningful 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 front-loaded with the core purpose and includes dense, valuable information throughout. It is slightly verbose due to the interpretive narrative, but 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?

With no output schema, the description explains the return elements (summary stats, 4h series, low/high) and parameter effects. It covers the tool's complexity well, though it could specify exact output structure more precisely.

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 applies. The description repeats the points parameter behavior but adds little beyond the schema's already detailed explanation; symbol is self-explanatory.

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

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

The description clearly states it provides current market-wide open interest for one coin's perpetuals, including 24h/7d changes, 24h price change, and a 4h-bucket series. This specific verb+resource scope distinguishes it from related tools like market_candles.

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

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

Provides explicit interpretive guidance on when to use the data (reading OI against price) and suggests pairing with market_candles at 4h for the price leg. It does not explicitly state when not to use it, but the context is strong.

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 description doesn't need to reiterate safety. It adds value by specifying that it returns 'most active' markets and the exact data fields, which helps the agent understand output structure. It does not mention any other behaviors (e.g., sorting, limits), but the read-only nature plus output details are sufficient given the annotation coverage.

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

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

The description is two sentences, front-loaded with the core purpose, and includes examples and output details. Every sentence carries meaningful information with zero fluff, making it efficient for an agent to parse.

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 only one parameter (fully described in schema) and no output schema, the description adequately covers what the tool returns (most active markets with probabilities, volume, resolution date). This is sufficient for a simple query tool; the agent can infer behavior from the description and schema without additional gaps.

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

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

The schema provides 100% coverage with a descriptive parameter explanation and examples. The tool description repeats similar examples, adding no new semantic information. Per the rubric, when schema coverage is high, the baseline is 3, and the description does not elevate it further.

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

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

The description clearly states the tool returns market-implied prediction-market odds for a topic, with concrete examples ('Fed rate cut', 'bitcoin 100k') and specifies the output fields (per-outcome probabilities, volume, resolution date). This distinguishes it from sibling tools which cover general market data, news, or sentiment, not prediction markets.

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 for prediction-market topics and indicates it returns the most active matching markets. It does not explicitly exclude other tool categories or name alternatives, but the context of 'prediction-market odds' makes the intended use clear. It lacks explicit when-not-to-use guidance, but the purpose is specific enough.

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 bar is lower. The description adds useful behavioral context: it performs full-text search, returns the most recent matching filings, and specifies the output fields (form type, filer, direct link). 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 two sentences, front-loaded with the action and resource, and every word adds value. It includes an example and describes the return fields without unnecessary elaboration.

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, read-only tool with no output schema, the description covers what it returns and the search scope. It does not specify the time window for 'recent' or limit on results, but these are minor gaps given the tool's simplicity and the annotation coverage.

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

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

Schema coverage is 100% for the single 'query' parameter, and the schema description already includes the same examples (company name, ticker, theme) as the tool description. The description does not add meaning beyond what the schema provides, so a 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 states the tool searches recent regulatory filings full-text for a company, ticker, or theme, with an example. It distinguishes itself from siblings by focusing specifically on regulatory filings, a unique resource among the listed tools.

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

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

The description implies when to use this tool (when needing regulatory filings for a company or theme) by providing example queries. It does not explicitly mention alternatives or exclusions, but the use case is clear enough. A higher score would require an explicit 'use X instead for Y' note.

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 provide readOnlyHint=true, and the description reinforces that it's a snapshot, implying no state changes. It adds behavioral context by describing the measure of imbalance (positive means more bid depth), which is not in annotations or 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 concise, one sentence, and front-loaded with the key resource 'Order-book snapshot'. Every phrase adds value, and it avoids redundancy with the schema.

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

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

Given the tool's simplicity (one parameter) and presence of an output schema, the description sufficiently covers the tool's purpose and a key behavioral nuance (imbalance sign). It lacks some detail on how depth is computed or timeframes, but the output schema likely covers return structure.

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% (the only param is symbol with a clear example). The description adds context about what the symbol refers to (coin) and clarifies output fields, going beyond the schema's minimal description.

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

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

The description clearly states it provides an order-book snapshot for one coin's perpetuals, listing specific components (best bid/ask, spread, depth, imbalance). This distinguishes it from siblings like market_quotes and funding_current by focusing on order book depth and imbalance.

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 implicitly indicates when to use it (when order book data is needed) but does not explicitly contrast with alternatives like market_quotes or flow_whale_positions. No exclusions or context provided, just the tool's 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?

Beyond the readOnlyHint annotation, the description richly discloses behavior: cohort-level aggregation, exchange-specific reserve changes, substitution of USDT flows for native assets, and the interpretation of withdrawals/deposits as accumulation vs sell pressure. This adds significant context beyond annotations.

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

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

The description is dense but well-structured: states purpose, breaks down components, notes caveats, provides interpretation signals, and ends with a pointer to an alternative. Every sentence adds value with no filler.

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

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

With no output schema, the description does the work of explaining what will be returned (reserve changes, positioning, transfers) and how to interpret it. It lacks explicit response structure but is sufficiently complete for a cohort-level aggregation 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 already fully describes both parameters (100% coverage). The description adds contextual meaning by tying min_usd to the 'large on-chain transfers' threshold and clarifying 'one coin' for symbol, enhancing understanding of the parameters' purpose without duplicating schema 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 states the verb 'Aggregate' and the resource 'whale context for one coin', enumerating exact data included (reserve changes, positioning, transfers). It explicitly distinguishes from sibling flow_whale_positions by stating 'For specific whale wallets and their live positions use flow_whale_positions.'

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

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

Provides explicit when-not guidance ('no individual wallets') and names the alternative tool for individual whale data. It also explains the context for native assets vs ERC-20 tokens, which guides interpretation and appropriate usage.

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 reveals how accounts are discovered ('from the venue leaderboard'), the optional address cap of 10, and the precise return payload including equity, positions, side, notional, entry price, liquidation price, leverage, and unrealized PnL. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose and then packs useful usage details and field names into two sentences. Every clause contributes essential information 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?

Given the tool has a simple optional parameter, an output schema, and a readOnlyHint annotation, the description fully covers the invocation modes, data source, and return details. It is complete for an agent to select and call this tool correctly.

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

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

With 100% schema description coverage, the schema already documents the one optional parameter thoroughly. The description adds only a slight rewording ('to follow specific wallets') without materially enriching the parameter semantics beyond the schema.

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

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

The description clearly states the tool shows 'Live whale positions on Hyperliquid perps' and enumerates the exact output fields. It also distinguishes itself from the sibling tool flow_whale_context by noting that aggregate cohort signals belong there.

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

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

It explicitly explains both modes: default auto-discovery of the largest active whales and optional comma-separated addresses to follow specific wallets (max 10). It also directs users to flow_whale_context for aggregate cohort signals, providing a clear alternative.

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, the safety profile is already known. The description adds meaningful behavioral context: the interpretation of positive/negative rates ('Positive means longs pay shorts'), the significance of trajectory ('the same +6% annualized reads as post-flush relief...'), and the nature of the series (low/high, shape). This goes beyond the annotation and explains what the data means.

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

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

The description is front-loaded with the essential purpose, but the middle section is verbose with elaborate analogies like 'trailing delta flattens away' and 'opposite tapes'. While these add interpretive depth, the prose is denser than necessary for an agent; a more direct phrasing would improve conciseness.

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

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

No output schema exists, so the description bears the burden of explaining what is returned. It covers hourly rate, annualized estimate, 24h/7d trajectory, the 8h-bucket series, and the window's low/high—giving a complete picture of the response. It also explains the 'points' parameter's effect on output, which is sufficient for a simple two-parameter tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the 'points' parameter usage ('Set 'points' to trim the series...') but does not add meaning beyond what the schema already provides. The 'symbol' parameter is straightforward and not expanded upon.

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 immediately states the tool's core function: 'Current perpetual funding rate for one coin (hourly rate plus an annualized estimate), merged across providers, with its 24h and 7d trajectory AND the underlying 8h-bucket series.' This is a specific verb+resource, and it distinguishes this tool from siblings (none of which focus solely on funding rates for a single coin).

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

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

The description provides clear context on when to use the tool by emphasizing that 'The trajectory is the point' and explaining how to interpret the current rate against its recent history. It stops short of explicitly naming alternatives or exclusions, but no direct sibling exists, 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 state readOnlyHint=true. The description adds substantial behavioral detail beyond that: spot/perp are hard constraints and error rather than substitute, the response labels the market/interval/source actually delivered, includes USD volume when available, and flags a still-forming last candle. No contradictions with annotations.

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

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

The description is three sentences, front-loaded with the core purpose, then parameter semantics, then response behavior. Every sentence earns its place with no redundant or vague phrasing. It is tight 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?

Given the tool's complexity (5 params, enums, deprecated param), the output schema already defines the response shape. The description covers the behavioral nuances (market constraints, fallback, response labeling, volume, last-candle flag) and deprecation guidance. It is complete for an agent to invoke 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. The description adds significant extra semantics: deprecation of 'days' with guidance to use interval+limit, the hard-constraint behavior of spot/perp (error vs substitute), the auto fallback logic, and the response detail about labeling and volume. These go beyond the schema's parameter 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 states 'OHLC(V) candle history for a coin by symbol' with a specific verb and resource. It clearly distinguishes from siblings like market_quotes (live quotes) and market_coins (list). The mention of market types (spot/perp) and interval options adds specificity.

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

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

The description provides clear context on parameter usage (interval, limit, market) and explains the 'auto' fallback and hard constraints for spot/perp. It does not explicitly name alternative tools for when not to use it, but the purpose is obvious. It lacks an explicit 'use this when' statement, but the context is adequate without exclusions.

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

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

With readOnlyHint=true, the annotation already covers the safety profile. The description adds the specific data fields returned (price, market cap, ATH/ATL, description), which is useful behavioral context. However, it does not disclose potential edge cases (e.g., invalid coin ID behavior, data freshness, or response structure). This matches the baseline where annotations carry part of the burden, but the description adds some value.

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, well-structured sentence that front-loads the main action and lists the key returned data with a clarifying example. Every word contributes meaning, 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?

The tool is simple with one parameter, no output schema, and a read-only annotation. The description enumerates the data fields returned, which gives the agent a good understanding of what to expect. It lacks a mention of return format or error behavior, but given the simplicity and annotation coverage, the description is sufficiently complete for this context.

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

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

The input schema has 100% coverage for the single parameter coin_id, including a description and example. The description repeats the same example, adding no additional meaning beyond the schema. Since schema coverage is high, the baseline score of 3 is appropriate—no extra semantic value is provided.

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

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

The description clearly states the tool fetches price, market cap, ATH/ATL, and description for a coin by coin ID, with examples. This specific verb+resource combination differentiates it from siblings like market_quotes (which likely only offers current quotes) and market_coins (which likely lists coins). The purpose is unambiguous.

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

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

The description implies usage by listing the data fields returned, but it does not explicitly state when to use this tool versus alternatives like market_quotes or market_overview. There is no exclusion or explicit alternative mention, making the usage guidance only implied 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 description only restates 'Lists' which aligns with the readOnlyHint annotation but adds no extra behavioral context. There is no mention of return format, pagination, or any limitations.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose without unnecessary words. It earns its place perfectly.

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

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

The tool is simple with no parameters and a read-only annotation. The description sufficiently explains the return value (coin symbols) even without an output schema, though it could mention whether the list is exhaustive or sorted.

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

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

The tool has zero parameters, so the baseline is 4. The description adds minimal meaning by specifying what is listed (coin symbols), but no parameter details are needed.

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

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

The description clearly states the tool lists coin symbols from the market-data provider. It is specific and distinct from siblings like market_coin_details, though it doesn't explicitly name any alternatives.

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

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

No guidance is provided on when to use this tool versus alternative siblings such as market_quotes or market_overview. The usage is only implied as 'when you need coin symbols.'

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 declares readOnlyHint=true, and the description aligns with that (no mutation). The description adds useful detail about the tool's content (the four specific metrics) but does not disclose additional behavioral traits like response format, latency, or any special constraints. With the annotation already covering the read-only nature, this is adequate but not outstanding.

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 immediately identifies the tool's purpose and lists its key components. No fluff or redundant phrasing; every word adds 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?

Given there are no parameters and an output schema exists, the description is sufficient to understand what the tool returns. It names specific data points, which is complete for a snapshot tool, though it does not address usage relative to siblings (covered under usage guidelines).

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

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

There are zero parameters, and the description effectively communicates what the tool returns, which is the main semantic content. The baseline for 0-parameter tools is 4, and this description adds meaningful detail about the output contents beyond the mere existence of the tool.

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

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

The description clearly states that the tool provides a global market snapshot, listing specific components (total market cap, BTC/ETH dominance, Fear & Greed index, Altcoin Season index). This is specific and differentiates from purely single-metric siblings like sentiment_fear_greed, though it doesn't explicitly name an alternative 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?

No guidance on when to use this tool versus alternatives such as market_quotes or sentiment_fear_greed, which could overlap. The description lacks any 'when to use' or 'when not to use' context, leaving the agent to infer based on the tool name.

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 provide readOnlyHint, so the description carries the burden of transparency. It adds value by explaining the spot/perp price separation and basis difference, which is non-obvious and helps the agent interpret results. It does not detail rate limits or data freshness, but given the output schema exists, this 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?

The description is three sentences long, front-loaded with the core purpose, and includes only necessary details. Every sentence adds value: the metric list, the spot/perp distinction, and the parameter usage. Zero waste.

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

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

Given the tool's complexity (many metrics) and the presence of an output schema, the description covers the essential aspects: what fields are returned, the provider merging, and the filtering behavior. It could be more explicit about when to use it versus sibling tools, but for a snapshot tool with clear output schema, it is largely complete.

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

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

Schema description coverage is 100%, and the description for 'symbols' matches the schema exactly. The description does not add any additional meaning beyond the schema, so a 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 states the tool's function: a per-coin market snapshot with a specific list of metrics. It distinguishes itself from siblings by mentioning it is 'merged across providers' and includes both spot and perp prices, which is unique among the listed market tools.

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

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

The description gives usage context (filter by symbols or get all) but does not explicitly guide when to use this tool versus alternatives like funding_current or derivatives_open_interest. The implied use is for a comprehensive snapshot, but no exclusions or alternative recommendations 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?

The annotation readOnlyHint=true already establishes safety, so the description's burden is reduced. It adds useful behavioral details: the tool covers gainers, losers, and trend candidates, and uses a >+5% move threshold. However, it does not clarify ordering, result count, or whether the categories are combined or separate, but this is acceptable for a simple read-only ranking tool.

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

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

The description is a single, front-loaded sentence that conveys the essential information without any fluff or redundancy. Every word contributes 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?

For a tool with no parameters and no output schema, the description is sufficiently complete to convey the core functionality. It could be slightly more explicit about the exact return format (e.g., separate lists vs. combined), but given the simplicity of the tool, the current level of detail is adequate.

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

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

Since the input schema has zero parameters, the baseline is 4. The description correctly focuses on output semantics rather than parameters, and no additional parameter explanation 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 clearly states the tool's purpose: it ranks 24h gainers, losers, and trend candidates. The verb 'Ranked' and the specific categories distinguish it from sibling tools like market_trending or market_overview, which likely have different scopes.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or when to prefer a sibling tool, such as market_trending for trending coins or market_quotes for specific quotes. This lack of comparative context forces the agent to infer usage from the name alone.

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, but the description adds no extra behavioral context. It does not define what 'trending' means, how results are sorted, or whether the output is time-sensitive. Minimal disclosure 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 description is a single sentence with no wasted words. It is front-loaded with the action verb and clearly states the resource, achieving maximum efficiency.

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 list tool, the description provides the basic purpose. However, with no output schema, it lacks detail about what the returned list contains or how it differs from similar market tools. Adequate but not complete.

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

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

The tool has zero parameters and the schema is empty, so there is nothing for the description to add. The baseline is 4, and the description appropriately does not attempt to explain non-existent parameters.

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 the specific verb 'Lists' and identifies the resource as 'currently trending cryptocurrencies'. It clearly distinguishes from siblings like market_coins (all coins) and market_top_movers (by performance), though it does not explicitly mention these alternatives.

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

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

There is no guidance on when to use this tool versus alternatives such as market_coins or market_top_movers. The description is purely functional and provides no contextual cues or exclusions.

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

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

Annotations declare readOnlyHint=true, and the description adds that results are recency-filtered to 7 days and that crypto-native headlines are merged conditionally, which is useful beyond the read-only hint. No contradiction, but could clarify reliability of the merged feed.

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 packs essential information efficiently, front-loading the purpose and noting a conditional behavior. No extraneous 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?

Given the simplicity of a single-parameter tool with no output schema, the description covers the main need. It does not describe the output format, but that is less critical with no output schema. The conditional merging is a useful nuance.

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

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

The schema has only one parameter (query) with zero description coverage abstractly. The tool description implies the query is a topic, but does not provide format or examples beyond the schema's type. With a single parameter eliminated, the description adds minimal clarification.

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

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

The description clearly states that the tool searches the web for news and articles on a topic, with a specific time frame (last 7 days). It distinguishes itself from siblings by focusing on news search, though it doesn't explicitly compare to any sibling 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 gives context on when to use (searching recent news) but does not enumerate exclusions or alternatives. No guidance on when not to use this tool or which siblings might be better for specific use cases.

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

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

ReadOnlyHint is present, so the description only needs to add context beyond safety. It discloses that invalid tokens return a 'not a tracked chain' message ja that gas price is excluded. This is useful but could add more detail about response structure.

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 the key purpose and usage, with exclusions. Very concise and no fluff.

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

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

Description explains what it returns (TVL, fees/revenue), how to use (token symbol), and what happens for invalid input. It lacks detail on output format, but for a simple tool with one param, it's sufficient. Annotations cover read-only nature.

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 already documents the 'symbol' parameter fully (100% coverage). Description adds examples and a clarification that it must be L1/L2 token symbol, but that's marginal. Baseline 3 is fair.

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

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

The description clearly states the tool retrieves on-chain TVL and network fees/revenue for a specified chain, using a specific verb and resource. It distinguishes this from sibling tools (e.g., funding, market data) by its focus on on-chain metrics.

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

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

Provides explicit instructions to use the chain's token symbol and notes the exclusions (gas price not covered, non-L1/L2 tokens return a message). This is clear context for usage, though it doesn't name alternative tools for gas price data.

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 does not contradict the readOnlyHint annotation and describes a read-only operation ('reports'). However, it adds no additional behavioral detail beyond the annotation, such as the meaning of 'health' or any side effects. With annotations already covering safety, this minimal addition yields a 3.

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, clear sentence that is front-loaded with the action and object. There is no wasted text, and it efficiently communicates the tool's function.

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

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

Given the tool's simplicity—no parameters, a read-only hint, and no output schema—the description is nearly complete. It could optionally elaborate on what 'health' entails, but for a straightforward status check, the current wording suffices. It is adequate without being exhaustive.

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 no parameters (0 required, 0 total), and the schema coverage is 100% by default. Per the rubric, a baseline of 4 applies for zero-parameter tools, and the description provides no param info because there is nothing to explain. It adequately conveys that no inputs are needed.

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

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

The description clearly states the purpose: 'Reports the health of each connected data provider' with a specific verb ('reports') and resource ('health of each connected data provider'). It is distinct from sibling tools which focus on market data, so differentiation is inherent.

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 when one needs to check the health of data providers, and there are no similar sibling tools to compare. However, it does not explicitly state when not to use it or name alternatives, but given its unique function, the guidance is clear enough without explicit exclusions.

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

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

Annotations declare readOnlyHint=true, and the description adds substantial behavioral context: it is 'Deterministic — same inputs, same read', and it details output structure (nine axes, each with state, numbers, and a +1/0/-1 fragility vote) and important caveats like 'the axis degrades rather than substituting a single venue's OI' and 'house book ... measured as net over its own gross book'. This goes 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?

The description is long but densely structured: it begins with the core purpose, then systematically enumerates each of the nine axes, explains the vote rule, and lists additional outputs ('farmed' synthesis, focal points, thresholds). Every sentence adds value, though it could be condensed slightly without losing essential meaning, so it earns a 4 rather than 5.

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

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

The description is exceptionally complete for a tool with nine axes and multiple output components. It explains each axis in detail, the disclosed vote rule, the synthesis, focal points, and thresholds, and it clarifies the tool's deterministic nature and scope ('Reports the board, not a direction'). Given the complexity, no gaps remain for an agent to misinterpret.

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

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

Schema coverage is 100% with the only parameter 'symbol' fully described ('Coin symbol, e.g. "BTC" or "ETH"'). The description adds no further meaning about the parameter beyond the schema, so a baseline of 3 is appropriate; it neither hinders nor enriches parameter understanding.

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 it's a 'Deterministic positioning read for one coin' and explicitly names it as 'the game-state companion to research_regime', clearly distinguishing its purpose from siblings. It specifies the resource (one coin) and the verb (read), and elaborates on what it answers ('who is crowded, who is paying, who is trapped, and where').

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

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

The description gives explicit workflow guidance: 'Call research_regime first for market context, then this per coin before sizing or timing decisions.' It also clarifies the tool's scope ('Reports the board, not a direction') and its deterministic nature, which helps an agent know when and how to use it.

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

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

Despite already having readOnlyHint:true, the description goes well beyond annotations. It details each axis, the methodology (e.g., Mayer Multiple vs 200-day SMA), includes explicit 'would change the call' thresholds, and states the deterministic rule-based nature. This gives the agent deep insight into what the tool does, beyond the simple read-only annotation.

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

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

The description is organized logically, starting with the core purpose, then breaking down each axis, and ending with usage guidance. Every sentence contributes specific information (e.g., what each axis measures, how votes combine, when to use it). No fluff, fully front-loaded with the most important details.

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

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

Although an output schema exists, the description provides comprehensive context for a complex tool: it explains the seven axes, the underlying metrics, the voting mechanism, and the thresholds. It also clarifies the tool's role in the broader workflow, making it complete without the need for the user to consult external docs.

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 (schema coverage 100%), so baseline for parameter semantics is 4. The description compensates even further by thoroughly explaining the output structure: each axis reports state, underlying numbers, a vote, and the sum-of-votes rule. This richer explanation adds value beyond the empty schema.

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

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

The description specifies a clear action ('Deterministic market-regime classification') on a specific resource ('market regime'), and lists seven distinct axes (trend, volatility, cycle, etc.), distinguishing it from the many sibling tools like sentiment_fear_greed or ta_technicals. It's highly specific and informative.

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

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

The description explicitly states when to use it: 'Useful as a first call: most other signals... read differently depending on this regime.' This provides strong usage context and implies it should be run before other tools, effectively differentiating it from sibling tools that might deliver similar market metrics.

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 provide readOnlyHint=true, but the description goes far beyond that, disclosing behavioral traits: 'computed in-house', 'the same numbers as ta_technicals', 'grounded narrative synthesis with citations', 'per-section status list that distinguishes an empty section from a failed feed', and the conditional 'when the symbol is a tracked chain'. These add substantive context beyond annotations and the schema, informing the agent of data provenance and edge-case handling.

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

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

The description is long (about 80 words) but dense with valuable information, organized as a list of sections. It front-loads the core concept 'Aggregated single-coin dossier' and then details all components. While there is some redundancy (repeating examples from schema), the length is justified by the tool's complexity and the need to list all data categories. It is structured effectively for parsing.

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

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

Given the tool's high complexity (aggregates 15+ data categories), the presence of an output schema, and a readOnlyHint annotation, the description is exceptionally complete. It enumerates every data section, explicitly names the technical indicators, notes conditional behavior (tracked chains), and highlights the status list for feed reliability. This provides thorough context for an agent to decide invocation and interpret results.

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 single parameter 'symbol' is fully covered by the schema (100% coverage), including an example ('ETH'). The description only repeats the example ('e.g. 'ETH'') and adds no additional meaning such as format, case sensitivity, or allowed values beyond what the schema provides. Baseline 3 is appropriate because the schema fully documents the parameter.

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

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

The description clearly states it's an 'Aggregated single-coin dossier' and enumerates all contained data sections (market data, global context, technicals, on-chain, news, narrative synthesis, catalysts, social sentiment, ETF flows, prediction odds, provider coverage, status list). It explicitly references sibling tools (market_quotes, ta_technicals) to differentiate the aggregated nature, making its purpose distinct and unambiguous.

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

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

The description implies use for comprehensive single-coin research by enumerating what it aggregates, and references sibling tools for comparison. However, it does not explicitly state when NOT to use this tool (e.g., for a quick real-time quote, use market_quotes directly) or provide clear alternative selection guidance. The extensive list of included data points strongly implies a 'use when you need everything' context, but lacks explicit exclusions.

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

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

The description adds meaningful behavioral context beyond the readOnlyHint annotation: it emphasizes determinism ('same inputs always give the same result'), notes that direction is inferred from stop placement, and explains that target only affects the reward:risk output. This goes beyond the schema and annotations without contradicting them.

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

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

The description is three sentences, front-loaded with the core purpose, and each sentence contributes useful information: what it is, what it returns, and its deterministic behavior. There is no fluff, redundancy, or irrelevant 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?

Given the presence of a full output schema and comprehensive input schema, the description covers the essential behavioral aspects: local calculation, deterministic results, direction inference, and the optional target role. It does not cover edge cases like stop equals entry or error handling, but that is not critical for tool selection or 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 description coverage is 100%, so the baseline is 3. The description does add context by explaining that target is optional and only used for reward:risk, and that direction comes from the stop's side of entry, but most parameter-level meaning is already present in the schema. It does not deepen individual parameter semantics substantially.

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 starts with a specific verb+resource: 'Fixed-fractional position sizing' and clearly states it is 'a local calculation, not a data-provider lookup,' which distinguishes it from the sibling data-fetching tools. It enumerates exactly what the tool returns and how direction is inferred, making the purpose unmistakable.

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

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

The phrase 'a local calculation, not a data-provider lookup' provides clear context for when to use this tool versus sibling market/data tools. It does not explicitly name an alternative tool or state when not to use it, but the 'local calculation' framing sufficiently implies its usage niche.

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 no safety contradiction. The description adds that the index is 'updated roughly every 15 minutes' (useful frequency context) and defines the output range, but doesn't disclose any other behaviors (e.g., JSON shape, latency), so it's 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?

Two sentences, highly efficient: states purpose, scale, frequency, and suggests a sibling. Zero filler words.

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

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

Given the tool's simplicity (no params, no output schema, read-only), the description fully covers what an agent needs: what it is, what it returns, how fresh it is, and where to go for more context. Complete for its scope.

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 has 0 parameters and coverage is 100% (vacuously), so there is nothing to describe. The description provides the output semantics (0-100 plus label), which is valuable given no output schema. Baseline 4 for zero params is justified.

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?

Clear verb 'sentiment' + resource 'Fear & Greed index' and explicitly defines the 0-100 scale and label. However, it doesn't explicitly distinguish from other sentiment siblings (sentiment_social, sentiment_twitter) beyond the market-wide macro scope, so it's not fully differentiated.

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

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

Provides context ('A macro sentiment gauge') and suggests using market_overview for a full snapshot, which is a weak alternative. But it does not say when not to use it or compare with other sentiment tools, so guidance is minimal.

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 indicates this is a read-only operation. The description adds context by listing the returned metrics and their nature (e.g., 0-100 composite). However, it doesn't explain any dependencies or data freshness details beyond what the annotation provides. The description does not contradict annotations.

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

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

The description is a single concise sentence that front-loads the purpose and lists the exact output metrics. Every word adds value; there is no redundancy.

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

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

Given the tool's simplicity (one parameter, clear output list) and the readOnlyHint annotation, the description covers the essential functionality. However, it doesn't explain how the 'galaxy score' is computed or whether any special considerations apply (e.g., data latency). The output metrics are listed, but the return format is not detailed, and there's no output schema to fill that gap.

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

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

Schema description coverage is 100%, so the single symbol parameter is fully documented. The description adds context that the tool expects one coin symbol and the example 'BTC' reinforces the format. Since the schema already covers the parameter, the description adds marginal but useful context.

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

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

The description clearly states the tool provides a social-sentiment snapshot for a single coin, listing specific metrics (galaxy score, alt rank, bullish sentiment %, etc.). However, it could more explicitly distinguish itself from sibling sentiment tools like sentiment_twitter and sentiment_fear_greed, which likely serve different sentiment aspects.

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 via 'for one coin' and the symbol parameter, but it does not explicitly state when to use this tool over alternatives like sentiment_twitter or sentiment_fear_greed. It provides a clear context (social sentiment snapshot) but lacks explicit guidance on alternatives or exclusions.

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

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

The annotations include readOnlyHint=true, which aligns with the description's read-only nature (search operation). The description goes beyond annotations by specifying the data returned (engagement metrics, author reach) and the sorting behavior (relevance with latest option). However, it doesn't disclose potential side effects like rate limiting or that it only returns public tweets. With only readOnlyHint as the annotation, the description covers essential behavioral aspects adequately, though not exhaustively.

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, tight paragraph that front-loads the core purpose and data returned. Every sentence adds value: purpose, what's returned, and a usage hint. No filler or repetition. It's concise yet informative, covering the essential information an agent needs.

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

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

The tool has 4 parameters with 100% schema coverage, an output schema, and annotations. The description is complete for a search tool: it explains what it returns, how results are ordered, and hints at parameter interplay (minLikes with latest). It could mention potential empty results if no tweets match, but given the schema and output schema, the description is sufficiently complete for effective tool selection and invocation.

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

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

Schema description coverage is 100%, so the schema already describes all four parameters. The description adds value by framing the 'latest' parameter as a sorting switch ('set latest=true for the newest tweets instead') and hints at the usage of 'minLikes' for spam cutting. However, the description doesn't add much beyond the schema's explicit definitions, so a 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 states the tool's purpose: 'Searches Twitter/X and returns matching tweets with engagement metrics and author reach' for social sentiment assessment. It distinguishes itself from the sibling 'sentiment_social' tool by specifying the raw tweet-level output with engagement/author reach, which is entirely about twitter/x data. The verb 'searches' plus the specific resource and context for judging social sentiment on a coin or topic is specific and actionable.

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

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

The description provides clear context on when to use this tool (for judging social sentiment) and mentions the sorting option (relevance vs latest via latest=true). While it doesn't explicitly name alternatives like 'sentiment_social', it implicitly sets itself apart by focusing on raw tweets rather than aggregated sentiment, which is a useful differentiator. However, it lacks explicit 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?

The description goes beyond the readOnlyHint annotation by disclosing the data source ('computed locally from real candles'), the optional AltFINS vendor feed appendage, and the transparent trend rule. It also notes the 'auto' market routing behavior. These details add significant behavioral clarity without contradicting annotations.

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

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

The description is a single, dense paragraph that is well-structured: it starts with overall purpose, then lists indicators, then explains parameters, then mentions vendor feed. Every sentence adds value, though it is lengthy. It is not overly verbose given the complexity, and the structure aids readability.

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

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

The tool is complex with many indicators and multiple timeframes, but the description covers all essential input details, defaults, and constraints. With an output schema present and the readOnlyHint annotation, the description provides sufficient context for a user to understand what the tool returns and how to use it. No significant gaps are apparent.

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 parameters are already documented. However, the description adds contextual meaning: it explains 'intervals' with defaults and max count, and clarifies that 'market' routes candles (spot/perp/auto). This enriches the schema by linking parameters to the tool's internal behavior and constraints.

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

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

The description clearly states the tool's purpose: a 'Multi-timeframe technical-analysis snapshot for one coin' with a detailed list of indicators computed (RSI, EMA, MACD, ATR, Bollinger, ADX, volume ratio, trend rule). This is specific and distinguishes it from sibling tools like market_candles or market_quotes which focus on raw data or 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?

While the description thoroughly explains what the tool does and its parameters, it does not explicitly mention when to use it instead of alternatives. The context of sibling tools and the mention of 'not a vendor black box' imply reliability, but no direct 'use when' or 'when not to' guidance is given. However, the detailed scope makes usage clear enough for most cases.

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 is present, and the description adds context about the output format (ISO 8601) and its purpose. It doesn't contradict annotations and provides useful behavioral context 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 description is two sentences, front-loaded with the core function, and every word earns its place. It's concise 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 zero-parameter tool with no output schema, the description is complete. It explains what it returns and why you'd use it. It could mention timezone specifics, but ISO 8601 implies UTC, which is already stated.

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 description doesn't need to explain parameters. The schema coverage is 100% (empty schema), and the description adds value by explaining the output format and use case.

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

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

The description clearly states the tool returns the current UTC time in ISO 8601 format, which is a specific verb and resource. It distinguishes itself from siblings by being a simple time utility, not a data-fetching 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 provides a clear use case: anchoring 'now' to judge staleness of timestamps. It doesn't explicitly mention when not to use it, but the context is clear enough for a simple utility.

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