whale-insights

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

The description discloses that 'updatedAt' reflects manual revision time, not request time, and that the data is cached for approximately 1 hour. This provides important behavioral context beyond a simple read operation, especially with no annotations present.

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 extremely concise: two sentences that front-load the core purpose ('Airdrop tracker') and add key behavioral details. Every sentence earns its place with 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 low complexity (no parameters, no output schema), the description sufficiently explains what the tool returns and its caching behavior. However, the absence of an output schema leaves the exact format of the list undefined, which is a minor 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?

There are no parameters. The input schema is empty with 100% coverage. Per guidelines, a tool with zero parameters receives a baseline score of 4, and the description appropriately adds no redundant parameter information.

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

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

The description clearly identifies the tool as an 'Airdrop tracker' providing a 'curated list of active airdrop opportunities'. This distinguishes it from sibling tools like 'funding_rates' or 'liquidations', which serve different purposes.

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 fetching airdrop opportunities, but does not explicitly state when to use or avoid this tool, nor does it mention alternative tools. The context is clear enough given the variety of siblings, but lacks direct 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?

Discloses caching (~10min) and data source (LI.FI). No annotations, but description adequately covers behavioral traits for a read-only summary 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?

Two sentences, front-loaded with core purpose, followed by important limitations. 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?

Given no parameters and no output schema, description fully explains tool purpose and constraints (preview, caching). Sufficient for agent to understand what it does.

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?

No parameters; baseline 4. Description adds meaning by specifying output content (recent large transfers and per-bridge summaries), compensating for 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?

Clearly states it provides cross-chain bridge flows with specific verb (bridge flows) and resource (recent transfers and per-bridge volume summaries). Differentiates from sibling tools like stablecoin_flows and whale_activity.

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?

Describes free preview limitations and subscription requirement for full history, implying usage for quick overviews. Lacks explicit when-to-use vs alternatives but provides sufficient context.

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?

Without annotations, the description fully discloses behavior: caching (~5min refresh), subscription gating, and data sources. No contradictions or omissions.

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?

Succinct three-sentence description front-loaded with the tool's purpose, followed by key details (sources, preview limit, caching). No unnecessary 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 no output schema, the description adequately describes the return data (events with transaction links and volume history). It covers caching, sources, and access tiers, providing a complete picture.

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?

No parameters exist; schema coverage is 100%. The description adds value by explaining the data returned (events and volume history), which is appropriate for a parameterless 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?

Description clearly defines the tool as a token burn tracker providing recent on-chain events and 14-day burn volume history. It specifies data sources (Etherscan, Blockchair, Solana RPC), distinguishing it from sibling tools like 'airdrops' or 'whale_activity'.

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

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

Explicitly states the free preview limitation (top 3 events, full list requires subscription) and that data is cached with no per-request cost. Does not directly compare with alternatives but provides sufficient context for 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?

With no annotations, the description carries the full burden. It discloses a key behavioral trait: caching for approximately 5 minutes. This informs the agent about data freshness. However, it does not explicitly state that the tool is read-only or non-destructive.

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 front-loads the tool's purpose and includes all essential information (what it returns, cache time). Every word is necessary and earned.

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 zero parameters and no output schema, the description is fairly complete, covering output components and cache behavior. It could additionally describe label ranges or update frequency, but the current information is sufficient for basic use.

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, and schema coverage is 100%. The description adds significant meaning by detailing the output contents (score, label, factors, history) beyond the empty schema, which has a baseline score of 4.

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

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

The description clearly states the tool provides a 'Fear & Greed index' with specific components: current score, label, contributing factors, and recent history. It distinguishes from siblings by specifying 'crypto Fear & Greed' and a '7-factor' index, which is unique among the sibling tools.

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

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

The description implies usage for sentiment analysis but does not explicitly state when to use this tool versus alternatives like 'funding_rates' or 'market_heatmap'. No exclusions or context for when not to use 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?

Discloses caching (≈3min) and data sources, but lacks details on output format, possible rate limits, or whether data is historical or real-time. Without annotations, the description carries the burden but misses some behavioral aspects.

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

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

Two sentences, no redundancy, front-loaded with key information. Every sentence provides essential context (source, aggregation, caching, sentiment).

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?

Reasonably complete for a param-less tool: covers data sources, aggregation, caching, and sentiment. Lacks output structure specification, but the tool is simple and the description is sufficient for an agent to understand its purpose and data 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?

No parameters exist, so the schema adds no meaning. The description adds value by explaining the aggregated nature and sentiment label, which goes beyond the empty schema. Baseline for 0 params is 4.

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

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

Clearly states the tool provides perpetual funding rates from specific exchanges (Gate.io, MEXC, Kraken) with a derived sentiment label. Distinguishes itself from sibling tools like gas, liquidations, etc., which cover different data types.

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 fetching aggregated funding rates and sentiment, but does not specify when to use this tool over alternatives like social_summary or liquidations. No explicit guidance on context or prerequisites.

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?

No annotations exist, so the description bears full burden. It discloses that data is cached for approximately 30 seconds, signaling potential staleness. No other behavioral traits (rate limits, authentication) are noted, but the tool is read-only and side-effect-free.

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: first sentence describes purpose and scope, second adds critical caching detail. No extraneous words. Information is front-loaded and every sentence 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?

For a parameterless tool with no output schema, the description covers the main purpose and a key behavioral detail (caching). It lists the chains and mentions USD estimates per speed tier. Missing output format details, but the tool is simple enough that this is sufficient for an agent.

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

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

Input schema has zero parameters and schema description coverage is 100% (trivially). Baseline score 4 applies per instructions because no parameters need elaboration. Description does not add parameter info, which 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 returns current gas/transaction fees across seven specific blockchains with USD estimates per speed tier. It uses a specific verb ('Gas prices') and distinguishes from diverse sibling tools covering airdrops, bridge flows, burn tracker, etc.

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 explicit when-to-use or when-not-to-use guidance is provided. Usage is implied by the tool's name and description, but no alternatives or exclusions are mentioned. For a simple read-only tool with no parameters, this is adequate but not exemplary.

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?

Discloses caching behavior (~5min) and scope (recent estimates by token), which are key behavioral traits. With no annotations, the description provides useful transparency beyond the schema, though it omits details like read-only nature or rate limits.

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 of 7 words, extremely concise yet informative. Every word serves a purpose, with no redundancy.

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

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

For a parameterless tool with no output schema, the description provides essential context: data type (liquidation map), recency (recent), granularity (by token), and caching behavior. No gaps for its 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?

Zero parameters and 100% schema coverage make further parameter description unnecessary. The description adds no param details as none exist, so baseline 4 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?

Description states it provides recent market liquidation estimates by token, clearly indicating the data source and granularity. While it distinguishes from siblings like funding_rates or gas, it lacks an explicit verb.

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 vs alternatives, nor any exclusions or prerequisites. The description merely states what the tool does without contextual usage hints.

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 transparency by noting the tool is 'cached ~10s' and assures 'no fabricated floors', which are useful behavioral traits. However, it lacks details on what specific metrics are included, how they are computed, or any rate 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 concise with two sentences, each adding value. It is front-loaded with the core purpose. Minor improvement could be restructuring for clarity, but overall efficient.

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 no output schema, the description should convey what the tool returns. It mentions 'real recent counts' but does not specify the structure or fields. For a snapshot tool, this is incomplete. Also, the relationship with similar sibling tools is unclear.

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 no parameters, so the description does not need to explain param semantics. Baseline of 4 is appropriate since no additional param info is required.

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 'live platform metrics' and 'real recent counts', which effectively communicates the core function. It distinguishes from siblings by emphasizing 'live' and 'real', but does not explicitly differentiate from similar tools like platform_stats.

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

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

No guidance is provided on when to use this tool versus alternatives. The description implies real-time data but does not explain when live_stats is preferred over sibling tools like platform_stats or trending.

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 no annotations, the description adds valuable context: caching (~5min) and non-gated access. It does not disclose rate limits or error conditions, but for a read-only, zero-parameter 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 concise (one sentence plus two short phrases) and front-loaded with key information. Minor lack of structure (run-on) but 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?

The description covers what the tool returns (metrics and sources), which is sufficient given no output schema. It does not mention limits or pagination, but as a single-view tool this 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?

There are no parameters, so the schema provides complete coverage. The description adds meaning by detailing the output fields and data blending, which enhances understanding beyond the empty schema.

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

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

The description clearly states that the tool returns a market-wide token heatmap with specific metrics (volume, price change, market cap, chain) and data sources (CoinGecko top markets plus hidden-gems). This is precise and distinguishes it from sibling tools like fear_greed or funding_rates.

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 mentions it is non-gated and cached, implying general availability, but provides no explicit guidance on when to use this tool over alternatives. No exclusions or comparisons are given, leaving the agent to infer from the tool's purpose 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?

Discloses caching (~30 min), free preview limitation, and subscription requirement for full data. No annotations exist, so description provides good behavioral context despite missing rate limits or error 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?

Two sentences with no fluff. Key information (purpose, examples, subscription, caching) is front-loaded and efficient.

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 no parameters or output schema, the description covers what the tool returns, caching, and access limitations. Additional details like update frequency or data source granularity could improve, but current 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?

No parameters present; schema coverage is trivially 100%. Description adds value by explaining output structure (narratives with leading tokens) and access tiers, which is more than baseline requires.

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 states it provides trending crypto narratives (e.g., AI, RWA) with leading tokens, derived from CoinGecko Categories. Differentiates from sibling tools by focusing on narrative/theme-based data.

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

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

Implies use for narrative-based market insights, but no explicit comparison to alternative tools or when-not-to-use. Mentions free preview vs. full set, but lacks direct guidance on selection among siblings.

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

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

The description discloses that the data is 'Cached ~60s', which is a useful behavioral trait indicating staleness. No annotations are provided, so the description carries the burden for safety and destructiveness, but it does not state that the tool is read-only or non-destructive, which is important for an agent to know. The caching info adds transparency, but other aspects are missing.

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 extremely concise, consisting of two short sentences that clearly convey the purpose and a key behavioral detail (caching). No unnecessary words, and the essential information is front-loaded.

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

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

Given that the tool has no parameters and no output schema, the description provides a reasonable list of the data categories returned. It is mostly complete for a simple stat tool, though it could add more about the structure or format of the response. It adequately sets expectations.

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 no parameters, so the schema coverage is 100% by default. The description does not need to add parameter information, and it doesn't. According to the guidelines, with 0 parameters, a baseline score of 4 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 that the tool returns 'Platform statistics' with specific metrics like tracked wallets, chains, tokens, tools, languages, supported chain list, and a performance subset. It distinguishes itself from siblings (e.g., airdrops, bridge_flows) by being an aggregate of canonical platform metrics rather than a specific data point.

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

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

The description implies usage for obtaining a broad overview of platform metrics, and the sibling list suggests it should be used when other specific tools (e.g., airdrops) are not needed. However, it lacks explicit when-to-use or when-not-to-use guidance, and does not mention 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 no annotations, the description carries full burden. It discloses it returns 'most recent' data and 'explorer-verifiable references', but does not mention any side effects, rate limits, or data freshness guarantees. Minimal transparency.

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 key information. Efficient but could be more structured (e.g., bullet points) to enhance 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?

No output schema, so description must explain return value. It mentions 'whale movements' and 'explorer-verifiable reference' but lacks details on chains, time range, or data fields. Adequate for a simple tool but not comprehensive.

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?

No parameters in schema, so baseline is 4. Description does not need to add parameter info; it communicates the tool is a simple fetch without 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 it returns 'recent whale movements' with 'explorer-verifiable reference', clearly indicating the data source and verification property. It lacks explicit differentiation from sibling 'whale_activity', but the specificity is high.

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 like 'whale_activity' or other on-chain tools. The description only states what it does, not when it's appropriate.

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

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

Without annotations, the description covers key behaviors: non-gated access, caching (~5min), no per-request AI cost, and tiering for full insights. It discloses that AI insight text is excluded, which is important. Could be improved by mentioning rate limits or update frequency, but current details are 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 sentences, front-loaded with the tool's purpose and contents. Every sentence adds value: first explains output, second adds caching and subscription context. No redundant or vague phrasing.

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 no parameters and no output schema, the description covers the tool's purpose, cached nature, and tiering. It distinguishes from siblings by focusing on social sentiment. Could mention typical score range or label interpretation, but overall sufficient for a parameterless 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?

With zero parameters, baseline is 4. The description adds meaning beyond the empty schema by specifying the output structure (aggregate score/label + top 5 tokens) and caching behavior. It does not detail the format of score/label, but the core semantics are clear.

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 a social sentiment summary with aggregate market-mood score/label and top 5 tokens by sentiment. It distinguishes from full per-token insights by noting exclusion of AI insight text, ensuring the agent understands exactly what the tool returns.

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 quick social sentiment without AI cost, and mentions that full insights require a subscription. However, it does not explicitly state when to use this tool versus siblings like fear_greed or narratives, nor does it provide alternative tools for different needs.

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?

No annotations exist, so description carries the full burden. It discloses a ~30-minute cache, which is a useful behavioral trait. However, it does not mention other traits like rate limits, authentication needs, or whether it is read-only (though implied).

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?

Extremely concise: one sentence plus a cache note. No wasted words, front-loaded with the main purpose. 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?

The description provides basic information (data type and source, cache time) but does not describe the output format or structure. Since there is no output schema, more details on the returned data would improve completeness.

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

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

There are zero parameters, so schema description coverage is 100%. The description adds no information about parameters, which is appropriate since none exist.

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 stablecoin supply, mint, and burn data from DefiLlama. The resource and type of data are specific, and it implicitly distinguishes from sibling tools like bridge_flows or burn_tracker. The verb is implied but not explicit (e.g., 'retrieves').

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

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

No guidance on when to use this tool versus alternatives. It simply describes what it does without specifying context or exclusions. Sibling tools exist but no comparison is 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?

No annotations are provided, so the description carries full burden. It clearly states the tool is a read-only reference ('Reference'), non-advice, and cached, which sufficiently discloses behavior for a simple lookup 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?

Two short sentences with no fluff. Each part adds value: purpose, jurisdictions, educational note, cache duration.

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 zero parameters and no output schema, the description covers purpose, scope, and caching. It lacks return format details, but for a simple reference tool this is acceptable.

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, so baseline is 4. The description adds no parameter info, which is expected and acceptable.

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 crypto tax rates for reference, lists supported jurisdictions, and distinguishes it from sibling tools by specifying its purpose for the tax calculator.

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 notes the tool is educational only and not tax advice, and mentions a 1-hour cache, giving context for appropriate use. It does not explicitly contrast with siblings but the context makes it clear.

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?

Discloses caching interval (~5min) but no other behavioral traits like rate limits or data freshness beyond cache. Without annotations, description carries full burden; however, the caching detail is helpful.

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?

Extremely concise—two lines with front-loaded purpose, 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?

For a parameterless tool returning trending tokens, the description fully covers what, source, and caching behavior. No output schema needed for this simple use case.

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?

No parameters exist, so schema coverage is 100%. Description adds value by specifying data source and caching, earning a baseline 4.

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

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

Clearly states the tool returns trending tokens from DexScreener with caching behavior, distinguishing it from siblings like 'narratives' or 'whale_activity'.

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 explicit when-to-use or when-not-to-use guidance, but the simple purpose and lack of parameters make usage obvious. Could mention alternatives like 'market_heatmap' for broader trends.

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?

No annotations are provided, so the description fully carries the burden. It discloses caching behavior (served from cache, ~5min refresh), data sourcing (internal signal-history archive), and limitations (no USD volume, no wallet addresses, no per-transaction detail). This is highly transparent.

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, but it is front-loaded with the main purpose and covers all key aspects (output, limitations, parameter usage, caching). It is concise and informative, though slightly more structure could improve scanability.

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 one parameter and no output schema. The description explains the output format (counts grouped by chain, direction, day) and explicitly states what is not returned. Given the tool's simplicity, this is complete and sufficient for an agent to understand 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% for the single parameter 'window'. The description adds minimal extra info (clamping behavior) beyond the schema's documented range and default. Baseline 3 is appropriate as 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?

The description clearly states the tool returns aggregated historical whale activity counts across 14 chains, grouped by chain, direction, and day. It explicitly distinguishes what is included and what is not (no per-transaction detail, no wallet addresses, no USD volume). This is specific and differentiates from siblings.

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

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

The description explains when to use this tool for aggregated counts and notes that detailed data is subscriber-gated elsewhere. It provides guidance on the window parameter and its range. While it does not explicitly compare to all siblings, it gives sufficient context for appropriate use.

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