whale-insights

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the bar is lower. The description adds meaningful behavioral context by explaining the manual curation process, the meaning of updatedAt, and the ~1hr cache behavior, which helps the agent interpret data freshness and expect a stable, hand-maintained dataset.

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 short and front-loaded with the core purpose. There is some redundancy ('Curated list of active airdrop opportunities' restates the opening clause), but the additional freshness and cache details are valuable and concise.

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

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

For a parameterless, read-only tool with an output schema, the description is complete: it states content, scope, freshness semantics, and caching. An agent has everything needed to decide whether to call this tool and to interpret its results 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?

There are zero parameters and the schema is empty, so parameter ambiguity is not a concern. The description compensates by outlining what the response contains (chain, status, eligibility info), giving the agent useful context about the returned data without needing to inspect the output 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 opens with a specific verb ('Get') and a clearly scoped resource ('curated active and upcoming crypto airdrops'), and adds concrete detail about the content (35 hand-verified entries, chain, status, eligibility). This makes the tool's purpose and scope immediately distinct from the analytics-heavy 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 clearly implies when to use it: when the agent needs active or upcoming airdrop opportunities rather than history or analytics. It also sets freshness expectations ('updatedAt reflects the last manual content revision, not request time. Cached ~1hr.'), though it does not explicitly name 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context beyond annotations: it is 'public', MCP-compatible, paginated, capped at 1 year of history, and uses query params for direct agent invocation. No contradiction with annotations is 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 front-loaded with its purpose and well-organized, but it contains redundancy: 'paginated 1-year history' is repeated as 'Returns a paginated archive ... covering up to 1 year (365 days).' The filter list also largely duplicates what the input schema already documents. It is still readable, but not every word earns its place.

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

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

For a tool with 5 parameters, 3 enums, and an output schema, the description covers the essential operational details: required analystId, all valid analyst slugs, filter options and defaults, page semantics, the 1-year history cap, and the public MCP-compatible access mode. Annotations cover safety, and the output schema covers return shape, so no critical detail appears missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by providing human-readable analyst labels (e.g., chain_hawk as 'BTC & macro on-chain', whale_watch as 'multi-chain whale moves') and clarifies that period 365d maps to the full 1-year cap. These enrichments go beyond the raw enum names and schema descriptions.

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

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

The description clearly states the tool 'Returns a paginated archive of signals attributed to a single analyst, covering up to 1 year (365 days).' It names a specific verb, resource, and scope, and explicitly highlights the single-analyst limitation, which separates it from all-analyst siblings like analysts_signals_all. The MCP-compatible query-param variant framing further distinguishes it from path-param 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?

The description gives clear context on when to use this tool: to fetch a single analyst's signal history, and specifically calls out that it is the MCP-compatible variant AI agents should use to avoid resolving URL templates. However, it does not explicitly say when NOT to use it in favor of related siblings such as analysts_signals, analyst_daily_summary, or signal_history_monthly, so it stops short of full alternative guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, but the description goes well beyond that: generation time (9:00 UTC), model (gpt-4o-mini), no auth required, only shortSummary returned, caching (30 min), empty-array behavior before 9:00 UTC, and rate limit (60 req/min). This is rich behavioral disclosure with no contradiction.

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 key verb and scope, but it repeats itself: 'Get today's AI-generated commentary' is restated as 'Returns today's AI-generated daily commentary', and '9:00 UTC' appears three times. The extra details are useful, but the redundancy makes it longer than necessary.

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 output schema exists, so return values are covered. The description adds everything else needed: timing (generated 9:00 UTC, empty before), caching (30 min), rate limit, auth status, and the exact fields returned. Nothing an agent needs to call this tool correctly is missing.

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

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

The input schema has zero properties, so there are no parameters to document. Baseline 4 applies. The description appropriately spends its space on response fields and behavior instead of parameter semantics, which is exactly right for a no-input 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 opens with a specific verb and resource: 'Get today's AI-generated commentary for all 10 analysts'. It specifies the exact scope (today's, all 10 analysts, 2-sentence summaries) and clearly distinguishes this from sibling tools like analyst_archive or analyst_summary_history, which cover historical data.

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

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

The description provides clear context: use for today's generated commentary, public endpoint, no auth, and it notes the fallback for full commentary via the authenticated Pro endpoint. It also gives timing constraints (empty before 9:00 UTC, cached 30 min). However, it does not explicitly name sibling tools as alternatives or state when to prefer them over this one.

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 substantial behavior beyond the annotations: exact calendar-month boundary enforcement via DATE_TRUNC, the guarantee that all 10 analysts appear even with empty arrays, direct querying of signal_history, and null conditions for winRate and avgReturn. This is rich operational context that annotations alone do not provide.

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

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

The description is dense and front-loaded with the core purpose, and nearly every detail earns its place. It is slightly verbose due to the parenthetical DATE_TRUNC explanation, the repeated 'never more than 6 month buckets' guarantee, and the full analyst list, but it remains readable and well organized.

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

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

For a zero-parameter read-only tool with an output schema and complete annotations, the description covers invocation context, edge cases (few signals => null winRate; no resolved+priced signals => null avgReturn), the deterministic analyst set, and example user queries. Nothing needed to select or interpret this tool is missing.

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

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

The tool accepts zero parameters and schema description coverage is 100%, so there are no parameter semantics to document. The baseline for zero-parameter tools is 4; the description appropriately invests in return-value semantics instead.

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

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

The description states a specific verb ('Returns'), a specific resource ('performance summary for all analysts'), and a precise scope ('exactly the last 6 calendar months'). It also distinguishes itself from sibling tools like analyst_daily_summary by explicitly describing monthly granularity and enumerating the 10 canonical analysts covered.

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 concrete query examples ('How did WhaleWatch perform in May?' or 'Who was the best analyst last month?') and clearly defines the 6-month window, making when to use it clear. It does not explicitly name alternatives or state when not to use this tool, so it falls just short of full exclusion 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 well beyond the read-only annotations by explaining that analysts are algorithmic attribution identities rather than humans, that stats are computed from the live signalHistory PostgreSQL table with resolved-signal logic, and that winRate is a fraction while avgReturn is a percentage. This gives the agent a strong behavioral and data-integrity picture.

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

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

The description is front-loaded with its core purpose and every clause adds meaningful context, including domain areas and metric units. The list of ten personas is long but necessary for identification; the only structural defect is the unexplained trailing 'B', which appears to be a truncation artifact.

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 annotations and an output schema present, the description covers data provenance, non-human attribution, and metric semantics well. However, it does not address the mismatch between the 10 named personas and the 5 enum values, nor does it provide guidance for choosing this over sibling analyst tools, so the picture is not fully 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 schema fully documents the optional analyst slug filter, so the baseline is 3. The description adds useful persona context but does not map friendly names to schema slugs, and it claims all 10 personas while the enum only exposes 5 slugs, which creates ambiguity about whether the other five can be filtered.

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

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

The description uses a specific verb ('Returns') and resource ('all 10 pseudonymous CryptoWhaleInsights analyst personas') and then enumerates all ten with their domains. This clearly distinguishes the tool from signal-level siblings and makes the scope immediately obvious.

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 'live performance stats' and the reference to the Signal Performance Proof page imply this is for current analyst-level performance snapshots, but no alternative tools are named and no when-to-use/when-not-to-use conditions are given. Sibling names like analysts_top and analyst_daily_summary suggest alternatives, but the description itself does not route the agent.

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

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

Annotations already mark the tool as read-only/idempotent/non-destructive, and the description adds valuable behavioral context: free-tier depth, the 7-day window, the 200-signal cap per analyst, no authentication requirement, and the exact response shapes for both single- and multi-id calls. It clearly discloses limits and output behavior beyond the structured 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 long but organized around distinct pieces of information: usage, analyst IDs, limits, authentication, and response formats. The core purpose is front-loaded, and most sentences earn their place, though the inclusion of full response shapes and signal field listings makes it denser than strictly necessary.

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

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

For a one-parameter read-only tool with an output schema, the description is remarkably complete: it covers single vs multi behavior, the all-analysts alternative, data depth limits, auth expectations, and response structures. An agent has everything needed to invoke it correctly without opening the schema.

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

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

The schema already describes id as an analyst slug and lists valid values, yielding 100% schema coverage, so the baseline is 3. The description adds extra meaning by explaining comma-separated multi-analyst usage, providing concrete URL examples, and mapping each slug to a human-readable analyst and focus area, which improves parameter understanding without redundancy.

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

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

The description opens with a specific object ('Analyst signal history') and a clear action ('Returns the last 7 days of signals'), then states both single- and multi-analyst modes. It also names the sibling endpoint for fetching all analysts at once, so an agent can distinguish it from analysts_signals_all without inferring.

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 tells the agent when to use a single id versus a comma-separated list, notes that multi-id avoids extra round-trips, and directs the agent to the /all endpoint for fetching all 10 analysts. This provides actionable selection criteria, including the key 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?

Beyond annotations, the description discloses free-tier depth, the 7-day window, up to 200 signals per analyst, lack of authentication, and the exact response envelope. This goes well beyond the readOnly/idempotent hints and gives an accurate model of runtime behavior.

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

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

The purpose is front-loaded and the description packs in meaningful details like response fields, auth, and alternatives. It is one long flowing paragraph with some redundancy (last 7 days repeated twice), but not wastefully long for the amount of context provided.

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?

Covers auth, scope, response format, signal fields, and the alternative subset endpoint. It is slightly incomplete because it claims to list analyst IDs but only enumerates 5 of the 10, and the final sentence is cut off; still, the core calling context is fully explained.

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 already reflects that, so the baseline is 4. The description adds useful confirmation that no query parameters are needed, which removes any ambiguity about optional 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?

Clearly states it returns all analysts' signal history in one request, covering the last 7 days for all 10 analysts grouped by analystId. It distinguishes itself from a subset endpoint and makes the resource and response shape explicit.

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

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

Explicitly says this tool is for getting all analyst signals in one response and gives the alternative endpoint for fetching a subset of analysts. It also notes no authentication and no query parameters, so an agent knows exactly when to call 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?

Goes well beyond the read-only, idempotent annotations by disclosing the null-return edge case, the 5-signal minimum, the 7-day window, the ~10-minute cache, and units for winRate and avgReturn. No contradiction with annotations exists.

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

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

Core behavior is front-loaded and most sentences contribute useful context such as caching, units, ID mapping, and null behavior. However, the second sentence largely repeats information already given in the first sentence, preventing a perfect score.

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

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

For a no-parameter read-only tool with an output schema, the description covers selection criteria, edge cases, units, analyst ID mappings, and freshness. Nothing material is missing for an agent to invoke and interpret 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?

The tool has zero parameters, so schema coverage is trivially high and there is no parameter syntax for the description to clarify. Under the rubric, a 0-parameter tool gets a baseline 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?

Description clearly states a specific function: return the single analyst with the highest win rate among those with 5+ resolved signals, including win rate, avg return, and last 3 signals. It also distinguishes its purpose from siblings by noting it exists to avoid iterating over all 10 analysts.

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 a clear use case: surface the best-performing signal source without iterating over all analysts. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion 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?

Even though annotations already declare readOnly, idempotent, and non-destructive behavior, the description adds substantial context: pagination, 90-day limit, Pro-only full commentary, returned field list, no-auth requirement, and 60 req/min rate limit. None of these contradict the annotations.

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

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

The description is long but information-dense, with the main purpose front-loaded and query patterns laid out clearly. There is minor redundancy between 'historical daily AI analyst summaries' and the closing 'Use this for daily historical data', but no wasted sentences.

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

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

Given the empty input schema and the need to differentiate among many siblings, the description is complete: it covers query modes, limits, auth, rate limits, response fields, access restrictions, and alternatives. An agent has everything needed to call it correctly.

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

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

The input schema has zero properties, so the description fully carries parameter semantics. It documents query parameters including ?date=YYYY-MM-DD, ?analystId=...&days=30, and the 90-day cap, and even lists the fields returned per record. This goes beyond what the schema provides.

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

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

The description opens with a specific verb-resource pair ('Get historical daily AI analyst summaries') and gives exact query modes. It explicitly distinguishes itself from analyst_daily_summary, the monthly tool, and live snapshot tools, so an agent can tell it apart 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 gives explicit when-to-use guidance: use for daily historical data, use analyst_daily_summary for today's data, the live snapshot tool for current conditions, and the monthly tool for long-term trends. It also states the 90-day maximum and the two query patterns.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description adds meaningful behavioral detail: only tokens with ≥3 resolved signals are included, the window is 90 days, and entries include total and resolved signal counts. This clarifies the filtering logic an agent can expect, although it does not address behavior when analystId is omitted.

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

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

The core behavior is front-loaded and the ordering is logical, but the description is padded with a long analyst list that largely duplicates the schema enum and a redundant opening phrase. The sentence describing return fields is truncated mid-phrase ('win/loss ou'), making the structure feel incomplete.

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?

Annotations and output schema carry much of the burden, and the description covers the main filtering behavior. However, the tool declares analystId as not required while the description says it is for 'a single analyst,' leaving a notable gap: what happens if analystId is omitted? This ambiguity prevents the definition from being fully self-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?

The schema already fully documents the enum and requiredness, so the baseline is 3. The description adds extra semantic value by pairing each analyst slug with a human-readable label and domain focus, which helps an agent choose the right analystId. The '?analystId=' phrasing is slightly inconsistent with the MCP input schema, but the intent is 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 a specific function: returning the top 5 tokens by win rate attributed to a single analyst over the last 90 days, with a statistical significance filter. It is specific enough to convey the resource and action, but it does not explicitly distinguish itself from sibling tools like analysts_top or analyst_daily_summary.

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 useful context such as the 90-day window, the 3-signal minimum, and the allowed analystId values with domain descriptions. However, it does not state when to prefer this tool over its siblings or when not to use it, leaving the routing decision largely implicit.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds substantial behavioral context beyond that: data is accumulated daily, older than 180 days is purged, no authentication is required, there is a 60 requests/min rate limit, and a 5-min in-process cache exists. 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 dense but every clause earns its place: purpose, data granularity, example use cases, retention policy, response shape, parameter semantics, operational limits, and routing guidance. It is front-loaded with the most important differentiator ('top 5 per day') and closes with explicit sibling routing.

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 parameter and an output schema, the description is complete. It covers what the tool returns, why an agent would call it, how to parameterize it, how long data is retained, rate and cache behavior, and when to prefer a sibling tool instead. Nothing an agent needs to invoke it correctly is missing.

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

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

The input schema already fully documents the `days` parameter with default, min, max, and description, so the baseline is 3. The description adds meaningful context by linking the 180-day max to the automatic data purge, and by restating the query parameter in a usage context. This is a modest but genuine increment over the schema.

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

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

States a specific verb and resource: 'Returns a daily history of the top 5 cross-exchange arbitrage opportunities detected by the platform.' The scope ('top 5 per day', 'daily historical data') clearly distinguishes it from the monthly arbitrage tool and the live snapshot tool mentioned.

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 says when to use it: for daily historical data and for AI-agent questions about frequency and average spreads. It also names alternatives: 'use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.' This gives the agent both inclusion and exclusion guidance.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior, and the description adds substantial behavioral context beyond that: data is aggregated from daily snapshots before purging, the archive is never deleted, it grows indefinitely, and records are excluded if they have fewer than 5 daily contributions. It also discloses the data source, authentication requirements, rate limit, and cache behavior.

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

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

The description is dense and well-organized, front-loading the core purpose before adding details about aggregation, exclusion rules, source, and usage guidance. Minor redundancy exists in repeating 'cross-exchange arbitrage permanent monthly archive' twice at the start, but every other 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 definition is complete for a parameterless tool: it describes the data granularity, listed output fields, exclusion rules, data source, authentication needs, rate limits, cache behavior, and explicit comparison to sibling tools. The presence of an output schema also relieves the description from needing to detail 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?

The input schema has zero parameters, so the baseline is 4. The description adds no parameter-level detail because none is needed; it instead describes the fixed output shape and filtering rules, 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?

The description explicitly states it 'Returns the permanent monthly archive of cross-exchange arbitrage opportunities' with one row per symbol per calendar month. It precisely differentiates itself from sibling tools by specifying monthly aggregation and permanent retention, 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?

It explicitly instructs when to use this tool: 'Use this for long-term monthly archive data; use the corresponding live or daily-history tool for current or finer-grained data.' It further clarifies data exclusions, like months with fewer than 5 daily records, and provides practical constraints such as rate limits and cache duration.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structure. The description adds meaningful behavioral context beyond annotations: DB-backed with a 5-minute cache, 365-day retention with permanent monthly archive, and aggregation from LI.FI API. These details inform expectations about freshness and data availability without contradicting any 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 longer than strictly necessary but front-loads the core purpose and outputs before implementation details. The main redundancy is repeating the output fields in both the opening sentence and the 'One row per day' clause. However, every sentence contributes useful context, and the usage guidance is clearly positioned at the end.

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?

This is a simple single-parameter read tool, and the description covers the output row shape, data source, caching, retention, and when to choose an alternative. An output schema exists, so return-value details are already structured. Nothing essential is missing for an agent to select and invoke the tool correctly.

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

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

The single 'days' parameter is fully documented in the schema (1–90, default 30), so schema coverage is 100%. The description adds only marginal semantic value by saying 'over up to 90 days', which largely repeats the schema. This meets the baseline but does not elevate beyond it.

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

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

The description opens with a specific verb and resource: 'Get daily cross-chain bridge flow history', then enumerates exact output fields (volume USD, transaction count, protocol count, top protocol) and the data source. It clearly distinguishes this as the daily historical variant, implicitly separating it from the sibling 'bridge_flows' live snapshot 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 explicitly states when to use this tool: 'Use this for daily historical data; use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.' This directly routes an agent between alternatives and provides clear selection criteria.

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

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

Annotations already mark the call read-only/idempotent/non-destructive. The description adds genuinely useful behavioral details beyond that: free-tier truncation to 'top 3 flows + 2 bridge summaries', auth gating for full history via 'Weekly Alpha subscription', and data staleness via 'Cached ~10min'.

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 short and front-loaded, but it repeats 'recent large cross-chain bridge transfers' and buries 'top 3 free; capital-rotation signal' in an awkward em-dash aside. It could be tightened to one or two clear sentences without losing meaning.

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

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

Given zero parameters, an output schema, and annotations covering the safety profile, the description is mostly complete: it covers source, scope, subscription limits, and cache freshness. It is slightly incomplete in not naming the obvious sibling history tool and not explaining the 'capital-rotation signal' label.

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

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

The input schema has zero properties, so there are no parameters to clarify; this is the baseline-4 case. The 'top 3 free' note refers to output truncation, not an input parameter, so no additional parameter semantics 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?

States a concrete read operation: 'Get recent large cross-chain bridge transfers' and adds 'per-bridge volume summaries sourced from LI.FI.' It is clear in scope (recent, large, top-3 free) and implies it is a snapshot rather than full history, though it never explicitly names the sibling tool bridge_flow_history.

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 helpful context: 'Free preview: top 3 flows + 2 bridge summaries' and 'Cached ~10min' signal that this is a lightweight, limited snapshot. However, it does not explicitly state when to prefer bridge_flow_history or when this tool is insufficient beyond the subscription mention.

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?

Even with annotations marking the tool read-only and idempotent, the description adds valuable non-obvious behavior: only the top 3 events are available for free, the full list requires a Weekly Alpha subscription, responses are served from cache with no per-request AI cost, and the cache is refreshed every ~5 minutes. This goes well beyond what the annotations convey.

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 action and then introduces important caveats, which is effective. It loses some points for redundancy: the sources are listed twice ('from Etherscan + Blockchair + Solana RPC' and 'sourced from Etherscan, Blockchair, and Solana RPC'), and 'burn events' is repeated in both main clauses.

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

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

For a zero-parameter, read-only tool with an output schema and strong annotations, the description is complete. It specifies sources, the historical window, explorer-verifiable transactions, subscription limits, and cache behavior — an agent has everything needed to invoke it correctly.

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

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

The input schema has zero parameters, so the baseline of 4 applies. There are no parameter details to elaborate, though the description does clarify what a no-input call returns: recent burn events, a 14-day history, and the free/full preview boundary.

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

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

The description opens with a specific verb and resource — 'Get token burn events and 14-day burn history' — and clearly enumerates the assets (ETH, SOL, BNB), data sources, and the two output components (recent events and daily burn-volume history). This makes it easy for an agent to distinguish from the many analyst, whale, and market sibling tools.

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

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

The intended use is clear: call this when token burn events or 14-day burn history is needed. It does not explicitly name alternatives or state when not to use it, but no sibling tool appears to cover burns, so the description provides enough context for correct selection.

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, openWorldHint, idempotentHint, and non-destructive behavior, so the bar for added value is lower. The description adds the caching behavior (~5min), which is genuinely useful operational context beyond the annotations. No contradiction between description and 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 somewhat redundant: '7-factor breakdown' and 'contributing factors' are the same concept, and the second sentence repeats the score/label/history listing from the first sentence. The key usage hint is front-loaded, but the repetition costs it a higher score.

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

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

For a parameterless read-only tool with an output schema and annotations covering safety, the description covers the return contents, caching behavior, and points to a sibling for long-term trends. It is complete enough for correct invocation; it could mention what 'recent history' means but the output schema likely fills 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?

The tool has zero parameters, so there is nothing for the description to explain beyond the schema. Schema description coverage is trivially 100% and the description correctly spends no space on parameters, warranting the baseline 4 for parameter-free tools.

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

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

States a specific verb ('Get') and resource ('Crypto Fear & Greed index'), then enumerates the content: composite 0-100 score, label, 7-factor breakdown, and recent history. It also disambiguates from the sibling fear_greed_monthly by noting that one is for long-term trends, so an agent can tell this tool apart immediately.

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 tells the agent to use fear_greed_monthly for long-term trends, which is a clear usage condition. It does not mention the sibling fear_greed_history, so the routing guidance is good but not exhaustive. Overall, the description provides clear context on when to choose this tool over at least one 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful non-obvious behavior: DB-backed storage, 5-minute caching, and that data comes from a 7-factor composite index. No contradiction with annotations exists.

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

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

The description is front-loaded with the essential purpose, but it contains redundancy: 'daily historical' appears twice, and 'one row per day' and the label details are repeated. It earns its place overall, but tighter editing would improve clarity.

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 output schema covers return values, and the description provides data source, cache behavior, and use cases, which is mostly sufficient. However, the contradictory maximum-day value (180 in description vs 90 in schema) leaves the agent unable to determine the real boundary, creating a meaningful completeness 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 coverage is 100%, so the baseline is 3, and the description does add meaning by explaining the per-row output and default/max behavior. However, it introduces a harmful inconsistency: the description says 'max 180' and the schema's "days" property has "maximum": 90, while the schema description also says '1–180.' This directly confuses the parameter boundary and undermines reliable invocation.

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

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

The description names a specific verb ('Get'), a clear resource ('daily Fear & Greed score history'), and the return contents ('0-100 score + Extreme Fear/Greed label per day'). It also differentiates itself from nearby siblings by explicitly scoping to daily history over up to 180 days, distinguishing it from fear_greed_monthly and the live snapshot 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 explicitly states when to use this tool: 'Use this for daily historical data', and names alternatives: 'use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.' It also mentions usefulness for trend analysis, giving an agent clear selection criteria.

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 annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds meaningful behavioral details: 'Never deleted; grows indefinitely', 'Months with fewer than 20 daily records are excluded', 'No authentication required. 60 req/min. 5-min cache.' 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 definition, then covers row structure, exclusions, access limits, and use-case routing without fluff. Each sentence adds distinct 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 zero-parameter read-only tool with output schema and safe annotations, the description is complete: it explains aggregation source, purge timing, exclusions, rate limits, caching, and the appropriate sibling choice.

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

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

There are zero parameters, so the baseline of 4 applies. The description adds no parameter constraints (there are none), but it does explain the returned row composition (avgScore, minScore, etc.) which is helpful context even though it isn't parameter semantics.

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

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

Clearly identifies a specific verb ('returns') and resource ('permanent monthly archive of the Fear & Greed index'), with specifics like 'one row per calendar month, aggregated from daily snapshots'. It also distinguishes itself from live/daily-history counterparts, so an agent can differentiate it from siblings like fear_greed or fear_greed_history.

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 'Use this for long-term monthly archive data; use the corresponding live or daily-history tool for current or finer-grained data.' This provides both a positive use case and an alternative direction.

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

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

The annotations already declare read-only, idempotent, non-destructive behavior, and the description adds substantial context beyond them: no credentials required, pageSize fixed at 20, 30-day maximum public window, case-insensitive q matching, and the response/item shape. There is no contradiction with the annotations.

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

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

The description is front-loaded with purpose and efficiently covers filters, pagination, and response details. It is slightly redundant at the opening ('News feed archive — paginated 30-day history... Returns a paginated archive...' repeats paginated/30-day/archive), and the final field explanation appears truncated, but overall each section earns its place.

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

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

For a four-parameter read-only feed tool with an output schema, the description covers every invocation concern: all parameters with defaults, max window, fixed page size, credential-free access, exclusions/alternatives, and response fields. No required call-time information appears to be missing.

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

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

Schema coverage is already 100%, but the description adds meaningful value by explaining q with an example and case-insensitivity, defining type values (news RSS, ai AI-generated, manual analyst notes), noting page is 1-indexed, and revealing that 30d is the maximum public window. This goes well beyond the schema baseline.

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

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

The description uses a specific verb ('Returns') and names the exact resource: a paginated archive of crypto news, analysis, and AI-generated summaries from the CryptoWhaleInsights feed. It also explicitly carves out whale-movement events and points to a different endpoint, which distinguishes it from the whale-related 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?

It clearly frames when to use the tool ('AI agents can use this to read the latest crypto news... without any credentials') and gives a direct alternative for whale-movement data ('use /api/public/whale-movements'). However, it does not distinguish this archive from the closely related analyst_archive sibling for analyst-note content, so the routing guidance is not fully complete.

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 indicate read-only, idempotent, and non-destructive behavior. The description adds substantial context beyond that: data is aggregated before purge, never deleted, limited to top 10 tokens by volume, months with fewer than 20 records are excluded, no authentication required, 60 req/min rate limit, and 5-min cache. These are exactly the behavioral traits an agent needs to invoke it safely and interpret results.

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

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

The description is dense and front-loaded with the core purpose, followed by row structure, coverage constraints, operational limits, and usage guidance. It is somewhat redundant with the phrase "permanent monthly archive" appearing twice early on, but every sentence otherwise carries useful information.

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

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

For a one-optional-parameter read-only tool with an output schema, this description is complete. It covers what data is returned, aggregation logic, exclusions, coverage scope, authentication, rate limits, caching, and the appropriate alternative tool. Nothing essential is missing for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents the optional symbol parameter. The description adds only a concrete example (?symbol=BTC) and confirms omission returns all top-10 tokens, which is useful but not a major semantic expansion 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 specifies a clear verb and resource: "Returns the permanent monthly archive of perpetual funding rates per token" with one row per token per month. It also distinguishes itself from siblings by explicitly positioning this as the long-term monthly archive versus the corresponding live or daily-history 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 explicitly directs usage: "Use this for long-term monthly archive data; use the corresponding live or daily-history tool for current or finer-grained data." This tells an agent exactly when to select this tool over alternatives.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds useful behavior beyond that: the 3-minute cache, the cacheAgeSeconds field for exact freshness, and exchangeCount for judging how many exchanges contributed data this cycle. 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 opening phrase is front-loaded and the cache/exchangeCount sentences carry valuable operational detail. However, the em-dash clause restates the following sentence: exchange sources and the sentiment label are both mentioned twice, which wastes 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 zero-parameter, read-only endpoint with an output schema, the description covers the essentials: what data is returned, from which exchanges, the sentiment label, and how to interpret freshness and exchange coverage. It does not explain sentiment derivation, but that is not required to invoke the tool correctly.

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

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

The tool has zero parameters, so the input schema fully covers the parameter space and the baseline of 4 applies. The description adds no parameter info, but none is needed; it usefully documents output metadata fields instead.

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

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

The description opens with a specific verb ('Get'), a precise object ('live perpetual futures funding rates'), and names the exchanges and the derived sentiment label. It is distinguishable from sibling history/monthly tools by the word 'live', though it does not explicitly contrast with them.

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

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

The description gives clear context: this is for current live funding rates rather than historical data, and the 3-minute cache tells agents not to expect instant updates. However, it never names alternatives like funding_rates_history or funding_rate_monthly, nor states when not to use this tool.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: data sources (Gate.io, MEXC, Kraken), daily snapshot method, cold-start omission, cache duration, and the sentiment-label thresholds. 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 dense and front-loaded with the core purpose, and nearly every sentence adds useful context. It is somewhat long and repeats default/max information, but the content is relevant and organized in a logical flow from result to semantics to usage.

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

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

With an output schema present, return-value documentation is not needed. The description covers token universe, data sources, sampling frequency, derived fields, sentiment meaning, caching, edge cases like cold-start days, and alternative tools, making it complete for an agent deciding to call it.

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

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

Schema coverage is high, so the baseline is 3, but the description adds meaningful usage details: case-insensitive symbols, example query, default values, and sentiment threshold interpretation. However, it introduces a discrepancy by saying max 180 while the schema maximum is 90, preventing a perfect score.

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

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

The description states a specific verb and resource: returns daily historical perpetual futures funding rates for a single token over N days. It also distinguishes itself from sibling tools by naming the live snapshot tool and monthly tool as covering different time horizons.

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 says 'Use this for daily historical data; use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.' It also gives defaults, ranges, and an example query, leaving no doubt about when to invoke this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavior beyond that: the 30-second cache, the meta.cacheAgeSeconds freshness check, and the meta.chainCount semantics. 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 chain list and 'USD estimates' are repeated almost verbatim: the first clause lists the 7 chains with USD fee estimates, and the following clause repeats the chains and USD estimates. This redundancy wastes a sentence, though the key cache and meta information is still 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?

For a parameterless, read-only tool with an output schema present, the description is complete: it lists the chains, explains freshness semantics, and documents the relevant meta fields. Nothing an agent needs to invoke this correctly is missing.

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

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

The input schema has zero parameters, so the baseline for this dimension is 4. The description reinforces that no input is required by describing exactly what the response covers.

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

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

The description uses a specific verb and resource ('Get real-time gas prices') and enumerates the seven supported chains, so an agent knows exactly what the tool returns. It does not contrast itself with the sibling gas_price_history, so it stops short of a 5.

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

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

The phrase 'real-time gas prices' plus the '30s cache' clearly establishes this tool as the current-state counterpart to historical tools. However, it never explicitly says 'use this instead of gas_price_history when you need current fees', so exclusion guidance is implicit rather than stated.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: DB-backed, 5-min cache, 365-day retention, permanent monthly archive, and one-row-per-day format.

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 expands into data details and usage guidance. It is somewhat dense with repeated mentions of 'gwei' and a long network list, but every sentence contributes value and the structure is logical.

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

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

With an output schema present, annotations covering safety, and a single fully documented parameter, the description supplies all needed context: data scope, retention, freshness, and routing to sibling tools. An agent can correctly invoke this tool with no missing information.

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

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

The input schema already documents the 'days' parameter with min, max, default, and a clear description, giving 100% schema coverage. The description mentions 'up to 90 days' but adds no new semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Get daily gas price history' and enumerates the exact networks and metrics (ETH/BNB/ARB/POLY/BASE fast gwei, SOL lamports). It clearly differentiates from siblings by explicitly contrasting with the live snapshot tool and monthly 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?

Explicit usage guidance is provided: 'Use this for daily historical data; use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.' This tells an agent exactly when to select this tool over alternatives.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's extra detail is genuinely additive: it discloses the 5-minute refresh cadence, 5-minute cache, omission of days with no data, severity thresholds based on confidence scores, and backfill provenance. No contradiction with annotations exists.

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

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

The main purpose is front-loaded and the structure is readable, but several details are not needed for correct invocation, such as '49,000+ on-chain signals' and the SQL-level 'ON CONFLICT DO UPDATE' implementation. These add bloat even though the overall shape is organized.

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 look-back control, data currency, empty-day behavior, severity derivation, and sibling routing, while the output schema handles return-value details. It is nearly complete, but the contradictory max-days value prevents a perfect score because it undermines safe autonomous usage.

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 adds context about default and range, but it introduces a critical inconsistency: the description says 'max 180' and '1–180, default 30,' while the input schema declares 'maximum': 90. An agent reasoning from the description could issue an invalid request, so the parameter guidance is actively misleading.

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

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

The description opens with a specific verb and resource: 'Returns a daily summary of Golden Alerts for the last N days.' It also clearly distinguishes this tool from siblings by positioning it against 'the corresponding live snapshot tool' and 'the monthly tool,' so the agent understands exactly what this history variant provides.

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 final sentence gives explicit routing guidance: 'Use this for daily historical data; use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.' It also explains the ?days=N look-back control, so when to call this tool versus alternatives is directly stated.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, and the description adds substantial behavior beyond that: the archive never gets deleted, data is aggregated from daily snapshots before purging, no auth required, 60 req/min rate limit, 5-min cache, and a statistical-minimum exclusion threshold. No contradiction exists.

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

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

The description is long but every sentence carries distinct information: purpose, aggregation behavior, field list, exclusion rule, data source, auth/rate/cache constraints, and sibling routing. The most important identity information is front-loaded before contextual details.

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

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

For a zero-parameter read-only tool with an output schema, the description is complete: it covers what the resource is, how it is computed, what fields it returns, when not to use it, rate limits, caching, authentication, and data provenance. Nothing an agent needs to select or invoke the tool correctly is missing.

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

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

There are zero parameters, so the baseline is 4. The description goes beyond this by enumerating every output field (totalCount, severity counts, topTokens, daysInMonth, avgPerDay), explaining the monthly aggregation semantics, and stating the minimum-record threshold. This fully compensates for the empty input 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?

Description starts with a specific verb and resource: 'Returns the permanent monthly archive of Golden Alert activity.' It explicitly distinguishes itself from live/daily-history tools and clarifies the monthly aggregation granularity, making it unmistakable among siblings like golden_alerts_history and golden_alerts_snapshot.

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 when to use this tool: 'Use this for long-term monthly archive data; use the corresponding live or daily-history tool for current or finer-grained data.' It also documents the 20-record exclusion rule, which is a concrete selection criterion for using the 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?

Richly discloses behavior beyond the readOnly/idempotent annotations: reads from cache with no AI query, omits pro-only fields, maps severity thresholds, and defines alert types. It also outlines the response shape and field meanings, all without contradicting the annotations.

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

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

The description is dense but mostly efficient, packing cache behavior, alert types, severity mapping, and response schema into a compact block. Minor redundancy exists in repeating "snapshot" and "latest" early on, and the final sentence is truncated at "No authentic," which is a structural blemish.

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 thorough for a zero-param read-only endpoint: refresh cadence, cache semantics, field omissions, alert taxonomy, and severity thresholds are all covered. The only gap is the unfinished sentence about authentication, which may leave an agent uncertain about access requirements.

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 adds all necessary semantic context and the baseline of 4 applies. No parameter documentation is needed beyond what the empty schema states.

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

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

The description opens with "Returns the latest snapshot of CryptoWhaleInsights Golden Alerts," giving a specific verb, resource, and scope. It further differentiates from siblings like golden_alerts_history and golden_alerts_monthly by emphasizing "latest," "refreshed every 5 minutes," and "up to 27 high-signal market alerts."

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

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

The description clearly establishes this tool is for the current snapshot by stating it reads from an in-process cache and refreshes every 5 minutes, implying use when current state is needed. It does not explicitly name alternative tools for historical data, but the "latest snapshot" framing gives sufficient situational 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?

Annotations already mark the tool read-only and idempotent, and the description adds substantial context: DB-backed storage, a 30-minute cache, one row per day, 30 tracked assets, the critical-zone threshold (≥76), and Pro-only per-asset detail exclusion. No contradiction with annotations exists.

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

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

Front-loaded with a clear summary and structured with concrete details, but slightly redundant: 'Daily historical Leverage Radar market aggregates' repeats the opening, and the aggregate list appears twice (once as a preview, once with specific values and threshold). Still compact and functional.

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

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

For a one-parameter tool with no required params and a full output schema, the description covers data frequency, cache behavior, metric semantics, critical-zone threshold, scope limitations, and routing guidance. Nothing essential is missing.

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

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

The single `days` parameter already has complete schema coverage with range and default in the input schema. The description only lightly restates 'up to 90 days' and daily scope, adding no meaningful parameter semantics beyond the schema, 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?

Names a specific verb and resource ('Get daily Leverage Radar market-level history') and enumerates the exact aggregates returned, including pressure scores, setup score, critical-zone count, regime, and Fear & Greed. It is clearly distinguishable from live-snapshot and monthly trend 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 closing sentence explicitly directs the agent to use this tool for daily historical data, a live snapshot tool for current conditions, and a monthly tool for long-term trends. However, it refers to those alternatives generically rather than naming the exact sibling tools, so the guidance is strong but slightly less precise.

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 (readOnlyHint, idempotentHint, destructiveHint false) cover safety, and the description adds substantial behavioral detail: picks auto-save every 5 minutes, selection requires score ≥ 60 across 1h/4h/12h windows, win is defined as ±1.5%, records are permanent, full list is Pro-only, and data is cached for 30 minutes. This goes far beyond structured fields.

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 and information-dense, but the first two sentences are largely redundant: 'Get Leverage Radar pick accuracy summary ... across all recorded Best Trade Now picks' is repeated by 'Aggregate accuracy statistics for all Best Trade Now picks recorded by the Leverage Radar tool.' The rest is valuable, but the repetition keeps it from being maximally tight.

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

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

For a zero-parameter read-only tool with an output schema, the description covers data provenance, sampling cadence, win/loss criteria, persistence guarantees, access restrictions, and cache behavior. There is nothing an agent needs to call or interpret this tool that is missing.

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

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

There are zero input parameters and schema coverage is 100%, so the baseline is 4. The description adds meaning by explaining exactly what data is aggregated (win rate, avg return, counts) and its selection criteria, helping the agent match the tool to user intent even without any params to document.

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

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

The description opens with 'Get Leverage Radar pick accuracy summary' — a specific verb and resource — and immediately enumerates the exact outputs: 'historical win rate, avg return, and total pick counts'. It clearly differentiates from siblings like leverage_history and leverage_radar by focusing on aggregated accuracy statistics rather than raw signals or history.

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 very clear context: this is for aggregate accuracy stats on 'Best Trade Now' picks, resolved against live price data. However, it never explicitly names alternatives or states when not to use it, so the agent must infer routing from the sibling list rather than being told.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond that: the 5-minute cache, that this is the public tier with pro-only fields stripped, and that content is restricted to 50 assets. The only minor tension is calling it 'real-time' while noting a 5-min cache, but the cache is disclosed clearly.

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

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

The description is dense but every sentence adds information: asset coverage, score meanings, market summary contents, stripped fields, cache duration, and window flexibility. It is slightly long but well-organized and free of 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?

Given an output schema exists and only one optional param is present, the description covers everything an agent needs: what the snapshot contains, its asset universe, its limitations (pro fields stripped), freshness (5-min cache), and the window parameter. There are no critical gaps for invoking it correctly.

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

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

Schema coverage is 100% and the only parameter, window, already has enum values, a default, and per-window descriptions. The description merely repeats 'Supports ?window=1h|4h|12h (default 4h)', adding no semantic value 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 names a specific resource ('Leverage Radar snapshot'), uses a clear verb ('Get'), and enumerates the exact output: pressure scores, setup scores, top long/short setups, and a market summary for 50 assets. The emphasis on 'current' and 'real-time snapshot' distinguishes it from historical sibling tools such as leverage_history.

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 provides clear context: a public, current snapshot with a 5-minute cache, stripped pro-only fields, and a selectable window. However, it never explicitly names an alternative tool or states when NOT to use this tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral detail: a ~5-minute cache, estimates rather than exact exchange data, geo-restrictions for Binance Futures and Bybit, and derivation from price action and open interest. This goes well beyond the structured 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, but it contains redundancy: the 5-minute cache is mentioned twice ('(5-min cache)' and 'Cached ~5min'), and the first two sentences both restate 'long and short liquidation amounts in USD per token'. Trimming would improve precision.

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 an output schema and a read-only annotation profile, the description covers everything needed to invoke it correctly: what is returned, token-level granularity, recency, cache behavior, estimate caveat, and geo-restrictions. Nothing essential is missing.

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

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

With zero parameters, the baseline is 4, and the description correctly avoids inventing parameter details. No parameter explanation is required, so this dimension is satisfied by the design rather than the prose.

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 gives a specific verb and resource ('Get leveraged-position liquidation estimates') and concretely defines the output as long and short liquidation amounts in USD per token. It is clear even without naming siblings, but it does not explicitly distinguish itself from related leverage tools like leverage_radar, so it earns a 4 rather than a 5.

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

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

The phrase 'Useful for identifying tokens with high leverage risk and likely volatility triggers' gives a clear, actionable context for when to call this tool. It doesn't state when not to use it or point to alternatives, so it falls short of the explicit routing standard.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description adds meaningful behavioral detail: a ~10s cache, a claim of 'real recent counts, no fabricated floors,' and explanation of returned meta fields, including cacheAgeSeconds. This goes well beyond what annotations already declare and helps the agent understand freshness and trustworthiness.

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

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

The description is compact and front-loaded: the core purpose appears first, followed by caching and response metadata. Each sentence adds distinct information without padding or redundancy, and the internal details are relevant to an agent's decision-making.

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

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

For a zero-parameter, read-only, cached snapshot tool with an output schema, the description covers key operational traits: cache behavior, response freshness fields, and data authenticity. No additional guidance is necessary for a correct call, since no parameters or prerequisites exist.

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 has no parameter semantics to explain. The baseline for 0-parameter tools is 4, and the description's focus on output metadata is appropriate and sufficient.

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

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

The description uses a specific verb ('Get') and names concrete resources ('whale moves today, smart-money wallets active, golden alerts'), making the tool's scope immediately clear. It also frames the tool as a 'live activity snapshot for the platform,' which distinguishes it from historical or summary tools in the sibling list.

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

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

Usage context is implied through 'Live activity snapshot' and 'real recent counts,' suggesting this is the real-time counter tool rather than a historical or aggregated view. However, it does not explicitly name alternatives or state when-not-to-use it, which matters given many nearby siblings like whale_activity, golden_alerts_snapshot, and platform_stats.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds substantial behavioral context beyond them: queries 8 sources in parallel, falls back to monthly archive tables for old dates, and exposes metadata.resolution and metadata.dataCompleteness. It also notes caching for today. This is a rich behavioral disclosure with no contradiction.

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 information-dense but structurally redundant: the opening sentence and the following em-dash phrase both announce 'single-call aggregated snapshot', and the 8-source list appears twice. The ending appears truncated ('Today is cached 5 minutes; hi'), suggesting incomplete cleanup. The content is organized logically thereafter, so it earns a mid-range score rather than lower.

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 one optional parameter and an existing output schema, the description covers all operational essentials: date format, default, time range, fallback behavior, response metadata fields, data completeness semantics, and caching. The only visible flaw is the truncated last phrase, which does not materially affect completeness for the agent's decision.

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

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

The schema already covers the single optional date parameter at 100%, so baseline is 3. The description adds value beyond the schema by explaining the default (today), the max lookback (730 days), and the automatic fallback to monthly averages for dates older than 365 days. That extra guidance justifies a 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 specifies a clear verb-resource pair: 'Get aggregated market context for a date in one call' and enumerates the exact set of data sources queried. It differentiates itself from the many sibling endpoints (fear_greed, funding_rates) by emphasizing the single-call aggregation of 8 sources. Repeated phrasing, e.g. 'Single-call aggregated market snapshot', reinforces purpose without ambiguity.

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

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

The description provides concrete invocation guidance: use ?date=YYYY-MM-DD, default is today, max 730 days back, and behavior for dates older than 365 days. It clearly implies use this when an aggregated snapshot across multiple market dimensions is wanted rather than calling individual endpoints. It does not explicitly name alternative tools or state 'when not to use', so it falls short of a 5.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description adds meaningful behavioral context: results are cached for ~5 minutes, access is non-gated, and data is blended from CoinGecko top markets plus emerging/hidden-gem tokens. This helps an agent set expectations about freshness and 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 repeats itself: the opening phrase and the following clause both say the same thing about a market-wide heatmap with tokens, volume, market cap, and chain. It also creates ambiguity by saying 'ranked by 24h performance' first and then 'top tokens by 24h volume,' which are not clearly the same ranking.

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 required parameters and an output schema present, the description covers most of what an agent needs: data fields, geo/access status, cache cadence, and source. However, the conflicting ranking phrasing ('24h performance' vs '24h volume') leaves the agent uncertain about how results are ordered.

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 parameter semantics are inherently non-issue. The description enriches the call by describing what the heatmap contains without needing to explain any 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?

Uses a specific verb and resource ('Get token market heatmap') and clearly states the returned data: top tokens, 24h performance, volume, market cap, chain. It distinguishes itself from sibling tools reasonably well, though it does not explicitly contrast with overlapping tools like market_context or trending.

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 useful context such as 'Market-wide token heatmap' and 'Non-gated', implying this is a general-purpose broad market snapshot with no authentication requirement. However, it never explicitly states when to use this tool instead of alternatives or when it should not be used.

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

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

Beyond the readOnly/idempotent annotations, the description adds useful behavioral context: DB-backed storage, a 5-minute cache, 365-day retention with monthly archive, and one row per day. It does not contradict the annotations.

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

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

The description is repetitive: the first sentence already lists the returned fields, and the second sentence largely repeats BUY/SELL/NEUTRAL verdict and confidence. While the extra detail about cache/retention is useful, a more compact structure would serve the agent better.

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 data is returned, the daily granularity, data source, caching, retention, and when to use alternatives. With an output schema present, this is substantially complete; only exact sibling tool names are missing.

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

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

The only parameter, days, is already described in the schema with default, minimum, and maximum. The description only reiterates 'up to 90 days' and adds no additional semantic meaning, so the high schema coverage carries the weight.

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 begins with a specific verb-resource pair: 'Get daily Market Pulse history'. It enumerates the fields returned and explicitly differentiates this history tool from live/momentary and long-term trend siblings, leaving no ambiguity about what it does.

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 says to use this tool for daily historical data, the live snapshot tool for current conditions, and the monthly tool for long-term trends. It gives clear selection criteria but does not name the exact sibling tool(s), leaving minor routing effort to the agent.

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

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

Annotations already mark the tool as read-only, idempotent, and open-world, and the description adds meaningful operational context beyond those hints: DB-backed storage, 5-minute cache, 365-day retention, permanent monthly archive, and row-level output structure. Nothing in the description contradicts the annotations, and the data freshness/retention details help agents reason about temporal 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 front-loaded with the core purpose and ends with clear alternative routing. It is slightly repetitive ('daily narrative/sector history' and 'Daily historical narrative strength') and uses several em-dashed asides, but every sentence contributes useful information such as cache behavior, retention, and output shape.

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 an output schema, no required parameters, and strong annotations, the description covers everything an agent needs to invoke it correctly: time range, row semantics, sector filtering, data source, cache freshness, retention, and which sibling tool to use for other time horizons. There are no significant contextual 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 already documents both parameters with descriptions: `days` (1–90, default 30) and `sector` (optional filter, returns all sectors when omitted). The description mostly repeats these ideas, adding only a usage nuance ('single sector trend') and an example. With 100% schema coverage, the baseline of 3 applies because the description does not substantially expand parameter meaning 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 opens with a specific verb-resource pairing ('Get daily narrative/sector history') and then enumerates the exact output dimensions: market cap change %, strength score, token count, daily rank, and top tokens. It also explicitly contrasts itself with live snapshot and monthly trend tools, so an agent can distinguish it from sibling tools like 'narratives' without inspecting schemas.

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

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

The description gives a direct usage directive: 'Use this for daily historical data; use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.' It also explains that filtering by sector produces a single-sector trend, which gives the agent actionable context for when to include or omit the sector parameter.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile, so the description adds meaningful behavioral context beyond that: results are cached ~30 minutes, the full data set requires a Weekly Alpha subscription, and the free preview is limited to 3 narratives with 3 tokens each. There is 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 front-loads the main purpose, but it repeats the same example categories (AI, RWA, DePIN, memecoins) and essentially says 'top tokens' and 'leading tokens' twice. The content is not excessive, but some redundancy could be trimmed without losing meaning.

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

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

For a zero-parameter, read-only snapshot tool with an output schema and strong annotations, the description is complete enough. It covers the data source, freshness, access tiers, and what the agent can expect in the free response, so no critical calling context is missing.

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

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

The tool has zero parameters, so the schema documents everything and the baseline is 4. The description compensates well by explaining the data scope, source, and subscription split, even though there are no parameters to elaborate on.

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

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

The description names a concrete resource ('top trending market narrative sectors') with specific examples (AI, RWA, DePIN, memecoins) and a clear derivation source (CoinGecko Categories). It also specifies the deliverable ('leading tokens') and the free-preview limitation, so an agent can distinguish it from unrelated siblings like airdrops or tax_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 gives useful context: this is a current snapshot, cached ~30 minutes, with a free preview and a subscription-gated full set. However, it does not explicitly state when to prefer this over narrative_history or trending, nor does it name an alternative, so usage guidance remains 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?

Annotations already mark it read-only, idempotent, open-world, and non-destructive. The description adds meaningful context about caching ('Cached ~60s') and the response's `meta.updatedAt` timestamp, going beyond the structured fields. No contradiction found.

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

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

Front-loaded with the core action and metric categories; the cache and timestamp details are relevant and placed at the end. Minor redundancy—'Canonical platform metrics' appears twice—keeps it from being perfectly concise.

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

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

With no parameters, rich annotations, and an output schema, the description covers the remaining needed context: caching behavior, response freshness, and metric scope. It doesn't explain how to interpret win rate or BTC benchmark, but the output schema and 'safe aggregate performance subset' wording make that 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?

The tool has zero parameters and schema coverage is 100%, so there is no parameter burden on the description. The description's enumeration of returned metric categories still adds useful semantic context by clarifying what the no-argument call returns.

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

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

Opens with a specific verb-resource pair, 'Get canonical platform metrics', and enumerates the exact metric categories (tracked wallets, chains, win rate, BTC benchmark). This makes it clear this is the platform-wide aggregate metrics tool and distinguishes it from sibling analytics tools by scope.

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

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

The word 'canonical' and the explicit metric list imply this is the go-to for platform-level aggregate stats, and 'safe aggregate performance subset' hints at a cautious choice. However, it never names alternative siblings like live_stats or status, nor does it state when not to use this tool.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context beyond that: a 10-minute cache, the exact meta fields to check for cache age, chain count, and signal count, and the claim that each movement has an explorer-verifiable reference. This is rich and useful, though it does not detail every edge case, so not a 5.

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

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

The description is front-loaded with the core purpose and includes all essential guidance in two sentences. It is slightly dense and has minor redundancy ('Get the latest 3 whale transfers' vs 'The most recent on-chain whale movements'), but every segment adds either scoping, alternatives, or meta-field explanation. It is well-structured and compact.

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

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

For a zero-parameter read-only tool with an output schema present, the description is complete: it states the exact result count, chain scope, cache behavior, key meta fields, and sibling alternatives. An agent has everything needed to invoke this tool correctly without inspecting schemas further.

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 input schema is empty and the baseline is 4. The description does not need to explain parameter semantics, but it still adds meaning by documenting the meta return fields. No deduction is warranted for lack of parameter detail.

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

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

The description opens with a specific verb and resource: 'Get the latest 3 whale transfers right now — live snapshot across 14 chains'. It clearly distinguishes itself from siblings by naming whale_activity and whale_movements as alternatives for different needs. An agent can immediately identify what this tool returns and how it differs from nearby 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 explicitly tells the agent when to use alternatives: 'use whale_activity for counts, whale_movements for paginated archive'. This provides clear routing guidance and prevents misuse. It also characterizes this tool as a live, bounded snapshot, making the usage context unambiguous.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds critical behavioral details: no authentication required, caching for 1 hour, 60 requests/min rate limit, and that reports are generated weekly. These go beyond the annotations and fully inform the agent of operational constraints.

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 yet well-organized. It front-loads the core purpose, then lists fields, access constraints, caching, rate limits, and response schema. Every sentence adds value with no fluff, achieving high information density without being rambling.

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 no input parameters and an output schema is described inline (response structure). The description covers the purpose, content, access, caching, rate limiting, and response format. Nothing an agent needs to correctly invoke and interpret the response is missing.

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

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

There are zero parameters, so the baseline is 4. The description compensates by detailing the response structure (reports, total, updatedAt and each report's fields), which is valuable even though there are no inputs to explain.

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 specific verb 'Returns' and the resource 'a public index of the last 12 weekly Alpha reports', listing the exact fields (title, summary, publish date, week covered). It also distinguishes itself from Pro-only content, which differentiates it from potential sibling archive 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 clear context: it is public, requires no authentication, and is intended for agents to inform users about recent report topics and dates. It explicitly notes that full report content is Pro-only, implying this endpoint is for summaries. However, it does not explicitly name alternatives or state when not to use it, but the context is sufficient for most agents.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context beyond those: the data source (Stocktwits + CoinGecko + price-momentum, no Twitter API), the once-per-day recording from a 5-min cycle, omission of cold-start days, score thresholds (≥60 bullish, ≤40 bearish), and 5-minute caching. This is rich, non-redundant 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 dense but every sentence earns its place: core behavior, data source, recording cadence, cold-start handling, usage example, supported symbols, score interpretation, cache info, and routing to alternatives. The supported-symbols list is long but useful. It is slightly overstuffed, but the structure front-loads the main purpose and ends with practical guidance.

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

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

Given the output schema exists and annotations are rich, the description covers the essential runtime behavior: cadence, source, caching, cold-start omissions, score interpretation, and alternatives. The main gaps are the days-range contradiction with the schema and the unnamed live-snapshot sibling, which slightly reduces 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?

Schema coverage is 100%, so the baseline is 3. The description does add meaning by listing supported symbols, providing an example, and repeating that symbol is required. However, it claims 'max 180' and 'days is optional 1–180' while the schema's numeric maximum is 90. This direct contradiction could cause an agent to pass invalid values (e.g., days=180) and fail invocation.

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

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

The description opens with a specific verb and resource: 'Returns the daily historical social-sentiment score for a single token over the last N days.' It clearly distinguishes itself from siblings by stating it is for daily historical data, while live conditions and long-term trends belong to other tools. The scope (single token, daily snapshots) 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 gives a concrete invocation example ('?symbol=BTC&days=30'), states that symbol is required and days is optional, and explicitly says to use the live snapshot tool for current conditions and the monthly tool for long-term trends. However, it refers to 'the corresponding live snapshot tool' generically rather than naming the exact sibling, leaving some mapping to inference.

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

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

Beyond the annotations' safety hints, the description discloses data lineage ('aggregated from daily snapshots before purge', 'Never deleted'), coverage ('35 tracked tokens'), an exclusion threshold ('fewer than 20 daily records'), and operational constraints ('No authentication required. 60 req/min. 5-min cache'). This is substantial added context.

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

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

The description is dense yet each sentence adds distinct value: core function, aggregation source, retention, coverage, filter, output columns, exclusion rule, auth/rate/cache, and usage routing. The main purpose is front-loaded before the technical 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?

With one optional parameter, an output schema, and safety annotations already present, the description covers the only remaining contextual decisions an agent needs: long-term vs live/daily use, output row shape, coverage, and operational limits. Nothing essential is missing.

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

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

Schema description coverage is 100%: the schema already documents the optional symbol filter, examples, and the 'omit to return all 35 tokens' behavior. The description repeats the optional ?symbol=BTC example but adds little new parameter-level meaning 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 opens with 'Returns the permanent monthly archive of social sentiment per token' and specifies the row granularity ('one row per token per calendar month'), making the verb, resource, and scope unambiguous. It also distinguishes itself from sibling tools by labeling this the permanent monthly archive versus live or daily-history alternatives.

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

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

It explicitly states when to choose this tool: 'Use this for long-term monthly archive data; use the corresponding live or daily-history tool for current or finer-grained data.' This gives clear use cases, but it does not name specific sibling tool IDs, leaving some identification to the agent.

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

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

Annotations already cover the read-only, open-world, idempotent, and non-destructive profile. The description adds substantial non-obvious behavior: aggregation before months age out, never-deleted retention, exclusion of months with fewer than 5 signals, no authentication, 60 req/min rate limit, and 5-min cache. This goes well beyond what annotations provide.

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

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

The description is long but information-dense, with purpose front-loaded and usage routing at the end. It loses a point for redundancy: 'permanent monthly archive' appears twice in the opening, and the full field list and analyst ID list duplicate structured schema/output schema information.

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

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

With an output schema present, field enumeration is not strictly required, yet the description adds valuable interpretation (winRate as 0–1 fraction, avgReturn as % wins only), the <5 signal exclusion, archive retention semantics, coverage of all 10 analysts, and rate/cache limits. An agent has everything needed to invoke this 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% and the schema already documents analystId, including the allowed IDs and omit-for-all behavior. The description repeats this with the example '?analystId=chain_hawk' but adds no genuinely new parameter semantics, so the baseline 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 opens with 'Returns the permanent monthly archive of analyst signal performance', naming a specific resource and aggregation level ('one row per analyst per calendar month'). The 'permanent' and 'Never deleted' framing distinguishes this from live or daily-history tools, and the final sentence explicitly routes to those 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?

Provides explicit when-to-use guidance: 'Use this for long-term monthly archive data' and explicit when-not-to-use guidance: 'use the corresponding live or daily-history tool for current or finer-grained data.' This clearly selects between this tool and its siblings without leaving the decision to inference.

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

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

Annotations already provide readOnly/openWorld/idempotent/destructive hints, and the description adds meaningful behavior beyond that: data is served from cache, cached ~5 minutes, no per-request AI cost, AI insight text is excluded, and stronger insights are gated behind a Max Alpha subscription.

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 useful routing, but it is redundant: the aggregate score/label plus top 5 tokens is stated twice, and caching is mentioned twice ('Served from cache' and 'Cached ~5min'). It could be tightened without losing information.

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

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

For a zero-parameter, read-only tool with an output schema, the description covers everything needed to invoke it correctly: what it returns, auth requirements, caching behavior, subscription limitations, and the relevant sibling alternative.

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

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

The tool has zero parameters and schema coverage is 100%, so the description has no parameter semantics to add. The baseline for zero-parameter tools is 4; the description stays there by focusing on output and access behavior instead.

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

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

The description opens with a specific verb and resource ('Get aggregate market mood') and defines the exact output: overall sentiment score/label plus top 5 tokens. It also distinguishes itself from the sibling sentiment_history by explicitly naming it, so an agent can tell which tool to use.

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

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

It explicitly says 'use sentiment_history for per-token time-series', providing a clear alternative and the condition that selects the other tool. It also states 'no auth', 'non-gated', and that full AI insights require a subscription, giving clear when-to-use 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?

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add non-obvious context. It adds the 24h net-change sign semantics (positive = expansion/inflow, negative = contraction/outflow), the DefiLlama source, and a ~30-minute cache indicator, all valuable beyond the annotations.

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

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

The description is front-loaded with the core action and data scope, then routes to sibling tools and ends with cache freshness. There is minor redundancy in mentioning USDT/USDC/DAI twice and DefiLlama twice, but the structure remains efficient and scannable.

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

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

Given that the tool has zero parameters, an output schema exists to describe the return shape, and annotations handle the safety profile, the description fully covers what an agent needs: data scope, source, snapshot semantics, sibling routing, and cache behavior. Nothing essential is missing.

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

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

There are no parameters, so the input schema already covers 100% and there is nothing parameter-specific to document. The baseline of 4 for zero-parameter tools applies; the description still adds useful scope by naming the stablecoin set included.

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 a specific verb ('Get'), a concrete resource ('current stablecoin supply & 24h net flows'), and the covered stablecoins (USDT, USDC, DAI). It also names the sibling alternatives, stablecoin_history and stablecoin_monthly, making the current-snapshot 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?

Explicitly says 'Use this endpoint for the current snapshot' and routes the agent to /api/public/stablecoin-history for daily time-series and stablecoin_monthly for monthly trends. This gives clear when-to-use versus alternative guidance with no ambiguity.

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

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

Annotations already indicate a safe read-only, idempotent operation. The description adds meaningful behavior: cold-start days are omitted, data is cached for 5 minutes, the signal is based on 7-day net flow, and totalFlow24h/totalNow semantics are defined. This far exceeds what annotations alone provide.

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

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

The description is longer than strictly necessary, with some repetition between the opening sentence and the later 'Returns...' sentence. However, it is logically organized and every substantive detail — data omission, signal rules, caching, sibling routing — earns its place. It is not bloated enough to warrant a 3.

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

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

For a single-parameter, read-only tool with a rich output schema and extensive annotations, the description is nearly complete. It explains return semantics, missing-data behavior, caching, and alternatives. The only completeness gap is the inconsistent max days value, which prevents a perfect score.

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

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

The schema already covers the days parameter 100%, so the baseline is 3. However, the description introduces a harmful inconsistency: it says 'max 180' and 'up to 180 days', while the input schema sets maximum to 90. This conflicting guidance could cause an agent to request an invalid window, making the description misleading rather than helpful.

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 clear verb and resource: 'Get daily historical stablecoin supply changes.' It explicitly distinguishes itself from stablecoin_flows (current snapshot) and stablecoin_monthly (long-term trends), so an agent can identify which sibling tool to choose.

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

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

Usage guidance is explicit: 'use stablecoin_flows for the current snapshot', 'Use this for daily historical data', and 'use the corresponding live snapshot tool for current conditions and the monthly tool for long-term trends.' It tells the agent exactly when to choose this tool over named 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?

The annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds meaningful beyond-annotation context: no authentication required, 60 req/min rate limit, 5-minute cache, never-deleted archive, and aggregation before purge. No contradiction exists.

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

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

The description is well structured and front-loaded with purpose, followed by field details, operational constraints, and usage guidance. It has minor redundancy in the opening sentence where the tool name and archive concept are repeated, but otherwise 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 covers purpose, granularity, retention, authentication, rate limits, cache behavior, and output fields. With an output schema present and zero parameters, nothing critical is missing for an agent to select and invoke the tool correctly.

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

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

The tool has zero parameters and the schema coverage is 100%, so the baseline of 4 applies. The description adds useful semantics about the returned monthly fields but has no parameters to document.

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 the permanent monthly archive of stablecoin flow data, with one row per calendar month aggregated from daily snapshots. It also specifies the included fields and distinguishes itself from live or daily-history tools by emphasizing long-term monthly granularity.

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 says to use this tool for long-term monthly archive data and to use the corresponding live or daily-history tool for current or finer-grained data. It does not name the exact sibling tools, but the guidance is clear enough for an agent to route correctly.

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 readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: cached ~30s, per-source age in seconds, 24-hour error counts, and the specific output categories. This fully discloses the tool's observable behavior 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 front-loaded with the core verdict and includes the key output fields, use case, and caching detail in a compact form. There is minor redundancy between the opening summary, the 'Public health status' sentence, and the detailed return list, but nothing is extraneous or bloated.

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

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

For a parameterless, read-only health check with an output schema present, the description covers all an agent needs: what it returns, why to call it, and its caching behavior. The output schema handles return structure details, so the description does not need to repeat 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?

With zero parameters and 100% schema coverage, there are no parameter semantics to explain. The baseline for zero params is 4, and the description appropriately focuses on output and usage instead of inventing parameter details.

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

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

The description uses a specific verb ('Check live API & system health') and names the exact resources: all CryptoWhaleInsights data sources, MCP server, and OpenAPI spec. It clearly differentiates this health-status tool from metric-focused siblings like live_stats or platform_stats by emphasizing verdict and freshness rather than data values.

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 when to use the tool: 'verify the platform is live before making requests.' This gives an agent a clear decision rule. It does not name alternatives or say when not to use it, but for a zero-parameter health check this context 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 already establish read-only, idempotent, non-destructive behavior. The description adds useful context beyond those annotations: the data is cached for about an hour and is educational-only, which helps an agent set expectations about freshness and appropriate use. No contradiction exists between the description and 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 short and front-loaded, with the core purpose stated first and limitations/caching at the end. However, the jurisdiction list appears twice in slightly different forms, creating minor redundancy that could be tightened without losing information.

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

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

For a zero-parameter read-only tool with an output schema and rich annotations, the description covers everything needed: what data is returned, which jurisdictions are supported, the educational limitation, and the caching behavior. Nothing essential is missing 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?

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description still adds value by enumerating the supported jurisdictions (US, UK, DE, AU, CA, IN, AE, SG, OTHER), which is the most relevant semantic information an agent would need.

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