cryptofeed402

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 crucial context beyond this: the $0.05 cost, deterministic non-LLM behavior, and what is returned (x402 payment requirements and URL). It also points to get_audit_sample for the output format, which is excellent transparency for a paid tool.

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

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

Front-loaded with cost and purpose, followed by a compact enumeration of checks, then determinism and return info. No filler; every phrase provides actionable detail for an agent deciding whether and how to call it.

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

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

Given the tool's complexity, the definition covers cost, scope, checks performed, return values (payment requirements and URL), and explicitly directs to get_audit_sample for output format. With no output schema, this is sufficient for correct invocation.

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

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

Schema coverage is 100% and the sole parameter's description already specifies valid inputs (domain or http(s) URL, public hosts, ports 80/443). The tool description adds little beyond that, 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?

States a specific verb (audits) and resource (public website or x402 API) for AI-agent readiness, and enumerates the exact checks performed. This clearly distinguishes it from the market-data siblings and from get_audit_sample, which is explicitly named as a format reference.

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 clear context: use for auditing a public website or x402 API. The 'paid endpoint ($0.05)' note is a key usage consideration. It does not explicitly state exclusions or when to choose an alternative, but the scope ('public hosts, ports 80/443' in schema) implicitly excludes private/internal sites.

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 annotations by disclosing the paid x402 mechanism, exact price, error/no-charge behavior for missing/stale data or unknown symbols, and that the response includes payment requirements and a URL. Annotations only cover read-only/idempotent safety, so this extra operational context is valuable.

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

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

Front-loads the core purpose and follows with usage, error behavior, and payment details. It is dense but nearly every sentence adds operational value, though the pricing is repeated from the title and the sample URL is incidental.

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

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

With no output schema, the description compensates by explaining the ranked-table result, the single-coin variant, x402 payment requirements, and error/no-charge conditions. Nothing an agent needs to invoke it correctly 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 100% and the single optional symbol parameter is already documented with pattern and examples. The description restates that an optional symbol returns one coin, which is mildly useful but largely duplicates 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?

States a specific verb/resource (per-coin headline mention volume vs 7-day average from the latest 12h tagger run) and specifies the ranked-table shape. It explicitly distinguishes itself from get_sentiment, so an agent can separate the two without opening schemas.

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

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

Clearly explains the optional symbol path versus the full ranked table, and explicitly says 'Volume signal, not tone (use get_sentiment for bullish/bearish).' This names the alternative and the condition that selects 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds genuinely new facts: the result is free, cached (i.e., not freshly computed), and scoped to one fixed domain. It also sketches the return contents. It does not say how stale the cache is or whether the sample domain can be changed, but for a cached read that is minor.

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

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

A single front-loaded sentence that leads with 'Free' and the artifact type, with no padding. It is somewhat dense but every clause (cached, fixed domain, score range, pass/warn/fail, evidence and fixes) carries information.

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

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

For a parameterless read tool with no output schema, the description supplies the missing return-value context (score range, per-check statuses, evidence/fixes) and the fixed target domain, and annotations cover the safety profile. Nothing needed to invoke or interpret it is absent.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; the implicit 'no args, fixed domain' behavior is correctly conveyed. Baseline for a zero-parameter tool is 4.

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

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

States a specific verb+resource ('cached example agent-readiness audit'), pins the exact target (cryptofeed402.site), and describes the payload (score 0-100, pass/warn/fail per check). It explicitly positions itself as the sample output of audit_agent_ready, so it is distinguishable from that sibling and from lookalikes like get_sample_brief and get_teaser.

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?

'so you can see the output of audit_agent_ready before paying' gives a clear condition for using this tool and names the paid alternative. It stops short of an explicit 'do not use this if you need a live audit of your own domain' exclusion, which is the main residual gap.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the $0.02 cost, x402 payment requirements, error/no-charge behavior for missing or stale packs, content format, and the primary-plus-standby backup design. It also states what the response includes (x402 requirements + URL), which is important for a paid endpoint.

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 front-loaded and every sentence adds useful information: cost, pack contents, sibling differentiation, failure behavior, response shape, and a free sample link. There is no redundant or filler wording.

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

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

Given the tool's complexity as a paid, parameterless endpoint with no output schema, the description covers the essential context: what is returned, how payment works, what happens on failure, and where to find a free sample. An agent has enough information to invoke it correctly and understand the payment flow.

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 an empty schema, so there is no parameter meaning for the description to add. The baseline for a parameterless tool is 4, and the description does not need to compensate for any schema gaps.

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 resource and scope: a pre-built pack of the last ~7 days of twice-daily crypto digest briefs, with markdown bodies and sha256 hashes. It explicitly distinguishes itself from get_history by noting that get_history is date-range and per-day, so an agent can select between them without opening schemas.

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

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

It gives a clear use case (backtests) and names the alternative get_history with the condition that differentiates them. It also explains the paid nature and that missing/stale packs return an error with no charge, which is directly relevant to deciding whether 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes meaningfully beyond them: it discloses the $0.012 charge, that errors are not billed, that stale or missing components surface as 503, and that the response carries x402 payment requirements plus a URL. The only gap is that the payment handshake itself (what the agent must do with the returned requirements) is left implicit.

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

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

Two short sentences plus a sample URL, with the paid/price qualifier and the composite scope front-loaded before the error and billing semantics. Nothing is redundant and no sentence could be removed 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?

With no output schema, the description carries the return-value burden and does state that the response contains x402 requirements and a URL, along with the failure mode and billing guarantee. It is slightly thin on whether the actual brief/sentiment/perps payload comes back in this call or after payment, which is the one thing an agent could still misread.

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 single symbol parameter already carries its type, pattern, example and 'Ticker, e.g. BTC' description. The description only restates 'for one symbol', adding no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

Names a specific composite resource and enumerates its three components (brief, news sentiment, perps radar) scoped to one symbol, which lets an agent map it to the sibling tools get_latest_brief, get_sentiment and get_perps. It stops short of stating explicitly that it is the bundled alternative to those three calls, so the differentiation is inferred rather than declared.

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 '503 if any component is missing/stale' clause implies the tool should be used when all three datasets must be simultaneously fresh, and the price hints at a cost tradeoff against three separate calls. However, there is no explicit when-to-use/when-not-to-use statement nor any named alternative, leaving the agent to reason about the bundle-versus-individual decision itself.

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 read-only/idempotent annotations, the description discloses the $0.003 cost, x402 payment requirements, no-charge behavior on bad params or unknown symbols, and Hyperliquid's most-recent-5000-per-interval retention. These are material operational traits an agent needs before calling.

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 content is front-loaded and every detail is relevant, but it is delivered as one very dense sentence with nested parentheticals. It is informative yet not optimally scannable or structurally clean.

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

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

With no output schema, the description carries the return-value burden and does so: it states that the endpoint returns x402 payment requirements and a URL, and it links to a free sample response. Combined with venue and error behavior, this is complete enough for correct invocation.

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

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

With 80% schema coverage, the baseline is 3, but the description adds useful semantics: venue=hyperliquid is default, HIP-3 builder-dex symbols use dex:TICKER, end is Hyperliquid-only, and OKX is most-recent-only. It mostly complements rather than merely repeats the schema.

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

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

The description clearly states a specific resource and scope: OHLCV candles for Hyperliquid perps or OKX USDT spot pairs. It does not explicitly distinguish itself from siblings like get_price or get_spot, so it falls short of the top score for sibling differentiation.

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

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

It gives clear usage context: venue defaults, interval availability by venue, limit ranges, optional end time for older Hyperliquid candles, and error/no-charge behavior. It stops short of naming when to use this instead of sibling tools or when not to use it.

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

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

With no annotations, the description carries the full load and does well: it discloses the $0.002 price, that payment is x402-based, that the call returns x402 requirements plus a URL rather than data on the first pass, the ~12h data freshness, and that missing/stale data errors out with no charge. It does not spell out how to satisfy the x402 requirements or the payload shape beyond the field list, which keeps it short of 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?

A single dense paragraph that leads with the price and the data source, then lists returned fields, then the error/billing rule, then the free sample. Every clause carries a distinct fact and nothing is repeated.

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

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

No output schema exists, so the description must enumerate the return payload, and it does: event count, corroborated events, outlet names, up to three sample headlines, plus the x402 requirements envelope. Combined with the freshness and error semantics, an agent knows enough to call and interpret it, though the two-step payment handshake could be clearer.

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

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

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly does not waste words on inputs.

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

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

The description gives a concrete verb and resource: per-asset, multi-outlet news heat computed from the latest headline-tagger run, with named fields (event count, 2+ outlet corroboration, outlet names, sample headlines). It is specific enough to separate this from generic sentiment tools, though it never explicitly contrasts itself with the closest siblings get_attention or get_sentiment.

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

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

Usage is implied by the ~12h refresh cadence and the 'missing/stale data returns an error' clause, and the free sample URL gives the agent an alternative to paying for a trial look. There is no explicit statement of when to pick this over get_attention, get_sentiment, or get_teaser, so the agent must infer the route.

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 read-only, open-world, idempotent, and non-destructive behavior, but the description adds important context: the endpoint is paid ($0.0025), returns x402 payment requirements and a URL, and provides a free sample response. It does not detail rate limits or the full post-payment response shape, but it is substantially more transparent than the annotations alone.

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 cost and data scope, then gives usage guidance, return behavior, and a sample link. Every sentence earns its place, and the dense parenthetical details are relevant rather than wasteful.

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

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

With no output schema and no parameters, the description covers what the tool returns at a high level: funding-rate extremes, open interest, volume filter, watchlist, and x402 payment requirements. The sample link helps, though the exact response structure after payment is not fully spelled out.

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 minimal and the schema does not need compensation. The description also explains the implicit filtering constraints (top 10 extreme rates, >$1M 24h volume, fixed watchlist), which is useful context even though no parameters exist.

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

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

The description states a specific resource and scope: the 10 most extreme Hyperliquid funding rates right now, including annualized percentages, open interest in USD, and a volume threshold. It also names the watchlist assets and distinguishes itself from historical funding siblings through 'right now' and 'most extreme'.

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

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

It gives clear use cases: spotting crowded longs/shorts and squeeze risk before a trade, or running a funding-arbitrage scan. It does not explicitly name when not to use it or point to alternatives such as get_funding_history, so it stops short of full routing 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 mark this as read-only/idempotent/non-destructive, and the description adds important behavior beyond that: exact $0.005 pricing, x402 payment requirements, no charge on bad params, and a free sample URL. These are high-value operational details for a paid endpoint.

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 definition is dense but front-loaded with the paid endpoint, data returned, and key constraints. Every clause is relevant, though the semicolon-heavy single paragraph is slightly harder to scan than a more structured layout would be.

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

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

For a complex paid endpoint with no output schema, it explains the core returned data, x402 payment requirements, URL, error behavior, and provides a sample response link. It does not describe the exact funding-history response shape or field names, but the sample link materially offsets that gap.

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

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

Schema coverage is 100%, so a baseline of 3 is warranted, but the description adds some meaning beyond the schema by explaining interval bucket contents (mean rate, cumulative) and synthesizing the hours/from-to and interval-dependent maximum constraints. It still largely restates schema constraints rather than documenting new parameter behavior.

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 resource and scope: hourly funding settlements for one Hyperliquid perp, including the metrics returned and interval options. An agent can distinguish this from siblings such as get_extreme_funding because it is full funding history, not an extremes scan.

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

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

It gives clear invocation conditions: provide hours or from/to, choose interval with corresponding maximum windows, and expect an error with no charge on bad params or unknown symbols. It does not explicitly route the agent away from alternatives like get_extreme_funding or get_perps, so it stops short of full when-to-use-vs-alternatives 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 readOnly, idempotent, non-destructive and open-world, so the description does not need to repeat them. It adds genuinely new behavior: a $0.005 charge, x402 payment requirements in the response, the no-charge-on-error rule, and venue reachability caveats (Binance/Bybit 'when reachable'). It stops short of describing rate limits or latency.

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?

Densely front-loaded: price, scope, normalization, then edge cases, then sample link. Nearly every clause carries information, though the $0.005 price is stated twice (title and first clause) and the x402 mechanics could be tighter.

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 two parameters, no output schema and a pointer to a sample endpoint, the definition is mostly sufficient for correct invocation. However, it omits the shape of the actual returned data (only 'x402 requirements + URL' is mentioned), so an agent cannot tell what payload arrives after payment.

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 50%: symbols is documented ('Optional; default watchlist') while venues has no description. The description partly compensates by explaining venue reachability and the minimum-venue constraint, but it never says what the default watchlist contains or how the venues array defaults when omitted.

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

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

States a specific verb+resource: 'cross-venue funding carry for 1-20 symbols', naming the venues and defining the spread as max-min. It is distinguishable from sibling tools like get_funding_history or get_extreme_funding, though it never names them explicitly, so sibling differentiation is left implicit.

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

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

Gives useful context on the error path ('<2 venues or bad params return an error and no charge') and a free sample URL, but never states when to prefer this over get_extreme_funding, get_funding_history, or get_perps_context. The agent must infer selection from the purpose sentence alone.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real value by disclosing the paid x402 pricing model, the $0.50 per-call cap, and that the call returns payment requirements plus a URL. It does not say what an unpaid call looks like or how the 402 challenge must be satisfied.

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 price and resource, then use cases, then return shape and a sample link — a sensible ordering. The parenthetical pricing is slightly dense but every clause carries information.

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

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

With no output schema, the description carries the burden and does so: it names the fields each brief contains, states that the response is x402 payment requirements plus a URL, and points to a free sample. The only missing piece for a fully self-sufficient definition is the default for the optional `to` parameter.

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 0%, so the description must compensate; it supplies the YYYY-MM-DD format and the important 'up to 366 days' range constraint that the schema does not express. It leaves one gap: `to` is optional but the description never states the default behavior when it is omitted.

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

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

States a specific resource and scope: archived twice-daily briefs retrieved over a date range. The word 'archived' implicitly distinguishes it from get_latest_brief, and the enumerated content (sentiment, funding, open interest, prices, news, macro calendar) makes the resource concrete.

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

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

Gives clear use cases ('backtesting, reviewing how the market narrative evolved, or filling a report gap'), which grounds when to reach for it. It stops short of explicitly naming get_latest_brief as the alternative for current data, so the sibling routing is left 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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds the crucial non-obvious behavior: this call is paid at $0.015 and returns x402 payment requirements plus a URL rather than the content directly. That payment-flow disclosure is exactly the kind of context annotations cannot 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 price and identity are front-loaded, and the content enumeration is dense but each item carries information. The single long sentence is slightly heavy, though the closing free-sample pointer is well placed.

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

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

With no output schema, the description still tells the agent the response format (JSON + markdown), the field coverage, the 7-day lookahead, and the payment-challenge behavior. An agent can decide and call correctly without further 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 tool takes zero parameters, so there is nothing to disambiguate; the baseline for a no-param tool applies. Nothing in the description is needed here beyond noting the absence of filters, which the schema already establishes.

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 ('the full latest twice-daily crypto research brief') and enumerates its contents (headline, sentiment, funding, watchlist, news, macro). It is clearly distinguishable from the free-sample sibling get_sample_brief and from narrower siblings like get_sentiment or get_outlook.

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

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

Gives an explicit use case ('for agents that need a ready market summary for a user or a daily report') and names the free alternative get_sample_brief with a URL. It does not, however, contrast with other paid research siblings such as get_outlook or get_narratives_weekly, so the routing guidance is only partial.

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/non-destructive, and the description goes well beyond them: exact price, the billing rule that unknown/empty/upstream errors are not charged, the upstream source limitation (OKX only, Bybit blocked), and the fact that the response contains x402 payment requirements plus a URL rather than the raw data. It even offers a free sample URL for pre-flight verification.

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?

Everything is packed into one dense, information-rich block with essentially no filler; pricing, purpose, window, billing rules, and sample URL each carry weight. The only structural weakness is that the price leads ahead of the actual purpose, so the core verb+resource arrives second.

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 paid x402 endpoint with no output schema, the description covers the essentials an agent needs before calling: cost, billing failure modes, upstream coverage, and the shape of the response. What's missing is result-level context — whether this is a flat list, an aggregate count, or whether there's a cap on returned liquidations — which matters for a time-window query.

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 50% — symbol is documented, hours is not. The description fills that gap by giving the hours range and, importantly, the default of 1, which the schema does not encode anywhere. It also clarifies that the symbol refers to an OKX USDT-SWAP ticker, adding meaning beyond the schema's bare pattern and 'Ticker, e.g. BTC'.

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 and scope: 'recent OKX USDT-SWAP public liquidations for one symbol.' Exchange (OKX), instrument class (USDT-SWAP), and granularity (per symbol) are all stated, so an agent can distinguish this from every sibling on the list at a glance.

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

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

The description implies usage through 'recent ... liquidations for one symbol' and supplies a time window with a default, but never states when to reach for this versus related market-data siblings such as get_perps, get_candles, or get_oi_history. The 'Bybit is geo-blocked from this host' note is an environmental constraint rather than routing guidance, so the agent must infer that this is the only liquidation source available.

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 safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely non-obvious behavior: an explicit price ($0.025), the fact that the call returns the x402 payment requirements and URL (i.e., a payment handshake before data), and that stale or absent data yields an error with no charge. That last point materially changes agent retry logic.

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

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

Two compact sentences, front-loaded with the price and the resource, followed by return content, error behavior, and the sample link — every element earns its place. It is slightly dense as a run-on chain of clauses, but there is no filler.

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

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

With zero parameters and no output schema, the description must carry the return shape and payment mechanics itself, and it does: content fields, error/no-charge rule, and the x402 challenge response. Minor gaps remain around payment completion flow and data freshness/cadence, but an agent has enough 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?

There are no parameters, so the baseline is 4; the description correctly implies the tool takes no input and describes the fixed window (seven days) rather than offering filters. Nothing about parameter semantics is left ambiguous.

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

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

The description names a specific resource and scope — weekly narratives pack, top multi-outlet story clusters from seven days of headline-tagger events, with titles, blurbs and links. That content profile (cross-outlet clustering over a 7-day window) is distinct enough from siblings like get_latest_brief or get_teaser that an agent can pick it without opening any schema.

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

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

It gives useful routing context: this is a paid call, a failed/stale-data call costs nothing, and a free sample URL exists at cryptofeed402.site/samples/narratives-weekly, which effectively names a zero-cost alternative. It does not explicitly state when to prefer this over siblings such as get_latest_brief or get_sample_brief, so it stops short of full when/when-not 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 cover the safety profile (readOnly, idempotent), and the description adds genuinely non-obvious behavior: the tool returns x402 payment requirements and a URL rather than the data itself, costs $0.005, is backed by an 8-day-retention snapshot store, and fails without charging on bad input. That is exactly the kind of context annotations cannot 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?

Front-loaded with the paid-cost headline and the data scope, then constraints, then the sample link. Dense but every clause carries information; slightly packed with parentheticals that slow scanning.

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

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

With no output schema, the description usefully discloses cost, retention, error/no-charge semantics, payment-requirement return, and a free sample URL. What's missing is any hint of the response payload shape once payment is settled, which an agent planning a call would want to know.

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 only 50% — symbol is documented in-schema but hours is bare. The description compensates by stating the valid range and the default of 24, which the schema does not express (it only carries an example). It still doesn't say what hours means precisely (window ending now? aligned to snapshot cadence?), so not a 5.

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

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

States a specific verb+resource: 'about-hourly open-interest history (coins, USD, mark, hourly funding) for one Hyperliquid main-dex perp'. It also names the data source (cryptofeed402 snapshots) and scopes to a single symbol, which cleanly separates it from get_funding_history or get_candles without the agent opening either schema.

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

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

Gives useful preconditions (hours 1-192 default 24, paid $0.005, HIP-3 symbols and bad params error out with no charge) and explains why this exists ('Hyperliquid has no public OI history'). But it never routes the agent to or away from a sibling tool — there is no explicit 'use this instead of get_funding_history when...' guidance, leaving the choice 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 readOnly/idempotent annotations, the description discloses pricing ($0.01), that unknown symbols or unavailable data return an error with no charge, that OI-change components are null until snapshots cover the window, and that it returns x402 payment requirements. It also clarifies the output is factual checks only with no buy/sell recommendation.

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 price and purpose, then enumerates the return components — justified because there is no output schema. It is dense and run-on, but almost every clause contributes specific information rather than filler.

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

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

With no output schema, the description carries the burden of explaining return values and does so thoroughly: summary string, venue comparisons, funding detail and rank, OI deltas with null semantics, sentiment, as_of timestamps, and flag rules. It also covers payment and error behavior and links a free sample response.

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

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

There is only one parameter and the schema description already covers it fully (Hyperliquid perp ticker, including dex:TICKER format). The description adds no extra symbol syntax or edge-case guidance beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description clearly states a specific verb and resource: a pre-trade preflight for one Hyperliquid perp that returns a defined bundle of metrics in one call. It distinguishes itself by scope and aggregation, but never names sibling tools (e.g., get_perps_context or get_price) that an agent might otherwise choose, so sibling differentiation is only implicit.

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 'pre-trade preflight' framing gives a clear usage context, and 'in one call' implies this replaces multiple narrower lookups. However, it does not explicitly say when not to use it or name alternatives, so the guidance stops short of full when/when-not routing.

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 establish read-only, idempotent, open-world, non-destructive behavior, so the description correctly focuses on additional context: paid x402 endpoint at $0.002, no charge for unknown symbols, HIP-3 symbol support, and that payment requirements and a URL are returned. It still does not describe the full payment flow or rate limits, but it adds meaningful behavioral detail beyond annotations.

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

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

The description is dense but front-loads the payment cost and then enumerates the returned fields, symbol coverage, error behavior, x402 response, and sample URL. Every sentence contributes useful information, though the parenthetical funding breakdown is somewhat dense for a single-parameter tool.

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

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

There is no output schema, and the description compensates by listing the key returned metrics (funding intervals, annualized, next_funding_time, time_to_next_seconds, OI USD, 24h volume, mark/oracle, premium, top-10 flag). It also covers payment requirements and invalid-symbol behavior, leaving only minor gaps such as the exact error payload format.

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 useful meaning beyond the schema by noting that unknown symbols return an error and incur no charge, and that HIP-3 builder-dex symbols use the dex:TICKER form with rank null. The schema already documents the pattern and examples, so this is an incremental rather than essential addition.

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 clear verb and resource: retrieve current metrics for one Hyperliquid perp, including funding, OI, volume, prices, and premium. It scopes the tool to a single symbol and supports HIP-3 builder dexes, but it does not explicitly differentiate this from siblings such as get_perps_context, get_extreme_funding, or get_oi_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?

Usage is implied by the description: call this for a single perp's current metrics, and invalid symbols will error without charge. However, it gives no explicit when-to-use/when-not-to-use guidance or direct alternatives, so the agent must infer its role relative to the many perps and funding siblings.

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

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

Despite annotations covering read-only and idempotent behavior, the description adds substantial context: it is a paid x402 endpoint costing $0.01, returns payment requirements and URL, and charges nothing on errors from unknown symbols, bad params, or stale data. It also discloses that the output is 'facts only, no recommendation' and lists the returned perp and news fields, giving agents a rich behavioral picture beyond structured hints.

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 front-loads the paid nature and purpose before details. Every element, including error semantics, field list, and sample URL, earns its place for a complex paid tool; though long, it avoids filler and is well organized as a single informational paragraph.

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

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

With no output schema, the description carries the burden of explaining returns and does so thoroughly: it lists perp fields (mark, oracle, funding, OI, etc.), news sentiment fields, attention vs 7-day average, and neutral flags. It also covers payment flow and error behavior, making the definition complete 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 coverage is 100%, so the single optional symbols parameter is already documented. The description still adds meaning by explaining the default behavior when omitted (watchlist plus coins in current news snapshots, up to 25) and by contrasting that with the 1-20 passed-symbol limit, supplementing the schema's min/max constraints.

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

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

The description uses a specific verb and resource: 'one-call market scan' that returns Hyperliquid perp state joined with news sentiment. It explicitly distinguishes its scope from siblings by covering watchlist plus news coins (up to 25) or passed symbols (1-20), making it clear this is a combined perps+news context tool rather than a pure perps or sentiment endpoint.

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 states when the tool is useful: 'for trading agents' and for scanning the watchlist plus every coin in current news snapshots, or user-supplied symbols. However, it does not explicitly name alternative sibling tools (e.g., get_perps or get_sentiment) or state when not to use it, leaving some routing 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 cover safety and idempotency, and the description adds meaningful behavioral context beyond them: the $0.0025 cost, the x402 payment flow, the fact that unknown symbols are not charged, and a sample response URL. This is exactly the extra operational detail an agent needs for a paid endpoint.

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

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

The description is a dense but front-loaded paragraph that covers cost, data fields, symbol scope, error behavior, and payment flow without filler. It could be split for readability, but every clause carries information.

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

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

With no output schema, the description lists the returned data categories and points to an external sample response URL, which is largely sufficient. It does not fully describe the response shape, but the sample link compensates for that gap.

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

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

Schema coverage is 100%, so the single symbol parameter is already documented with pattern and examples. The description still adds semantic value by clarifying that HIP-3 builder-dex perps use the dex:TICKER format and have no spot cross-check, which goes beyond the schema text.

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: it returns perp mark, funding, OI, and OKX spot for any listed Hyperliquid perp. It distinguishes its scope from siblings like get_spot and get_perps by naming HIP-3 builder-dex symbols and the no-spot-cross-check caveat.

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 explains the paid x402 context and that callers must pay with their own x402 client, plus that unknown symbols return an error and incur no charge. It does not explicitly route to alternatives such as get_spot or get_pricing, but the usage context is otherwise clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: the tool is free, prices are denominated in USDC on Base, settlement is via x402, and a payTo address is returned. It stops short of describing the response shape or caching/refresh 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?

A single front-loaded line beginning with 'Free:' puts the most decision-relevant fact first with no filler. It is a sentence fragment rather than a sentence, which slightly softens clarity, but nothing is wasted.

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

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

For a zero-parameter, read-only tool with strong annotations and no output schema, the description covers what the agent needs: cost of access, the currency/chain of the quoted prices, and the returned fields. Only the response format and the distinction from get_price are left unstated.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema already conveys. The listed contents (prices, network, payTo) are effectively return-value information, which is useful but not 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?

The description names the exact resource and its payload: current per-call prices, network, and payTo address, including the settlement rail (USDC on Base via x402). It is clear what you get, but it never distinguishes itself from the similarly named sibling 'get_price', which risks confusion between pricing metadata and an asset price.

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

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

Usage is only implied: labeling it 'Free' suggests it is the tool to call to learn what a paid call costs before spending, but there is no explicit when-to-use statement, no prerequisites, and no reference to alternatives such as get_price. An agent can infer the intent but gets no routing 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 readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds meaningful non-schema context: the content is delayed, from the previous edition, and omits OI, sentiment and markdown formatting — real limitations an agent needs to know. It does not address freshness lag magnitude or rate limits, so it is strong rather than exhaustive.

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

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

A single dense sentence: the free/tier framing leads, limitations follow in parentheses, and the routing instruction closes. Every clause carries information and nothing is padding.

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

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

With no output schema, the description does the work of characterizing the returned payload (a trimmed, delayed brief lacking OI/sentiment/markdown), which is sufficient for an agent to call it correctly. Missing only peripheral details like delay duration or refresh timing.

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 per the baseline rule this scores 4. The description correctly implies a no-argument call by not describing 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?

The description names a specific resource (a delayed, trimmed sample of the twice-daily crypto brief) and explicitly distinguishes it from the sibling it is not: get_latest_brief. An agent can tell exactly what this returns and how it differs from paid siblings without opening any schema.

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

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

It gives a clear selection condition — 'Use to evaluate before paying for get_latest_brief' — which routes the agent between the two tools. It does not mention other plausible alternatives such as get_teaser or when this tool is the wrong choice, so it stops short of a full when/when-not statement.

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?

Well beyond the annotations: discloses the cost, the x402 payment-requirements return path, a ~15-minute refresh cadence, the LLM-labeling plus deterministic-math methodology, and the critical failure behavior (error and no charge for unknown or stale symbols). These are exactly the operational traits an agent needs before spending money on a call.

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 price and the core capability, then layered with output shape, methodology, and failure modes. It is dense and runs as one block, but no sentence is filler; a light break-out of the paid/error clauses would make it scan faster.

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

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

There is no output schema, and the description fully compensates by describing every returned field plus the payment-requirements payload. Error conditions, cost, and freshness are all covered, so an agent can call this correctly without further investigation.

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 ticker format and pattern are already documented. The description still adds value by stating the symbol must be present in the current snapshot or the call fails uncharged, which is a semantic constraint not expressible in 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-resource pair: 'crypto news sentiment for one asset', and enumerates the exact shape returned (-1..1 score, bearish/neutral/bullish label, pos/neg/neu counts, up to 5 headlines). This clearly separates it from price/candle/funding siblings, though it never names an adjacent analysis tool like get_narratives_weekly or get_latest_brief.

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

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

Gives a clear usage context: it is a paid ($0.002) call, and unsupported or stale symbols error out with no charge, with a free list endpoint offered as the way to check coverage first. What's missing is explicit routing versus sibling analysis tools — it doesn't say when sentiment is the right pick over a narrative or brief 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?

Goes well past the readOnly/idempotent annotations by disclosing the paid cost ($0.002), the x402 payment-requirements handshake, the no-charge-on-error guarantee, and the concrete shape of the returned ticker data. These are exactly the traits an agent needs before committing to a paid call.

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

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

Front-loads the most decision-relevant fact (paid, price) then the resource, then error semantics, then a sample link — no filler. The field enumeration is dense but each item is informative; only the payment-requirements sentence is slightly buried 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?

No output schema exists, yet the description fully covers the return payload fields, the error case, and the payment response, so an agent can call this correctly and know what to expect. Nothing material is missing for a one-parameter read tool.

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

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

Schema coverage is 100% and the schema already documents symbol as a base ticker with examples and a pattern. The description adds only the pairing convention ('<SYMBOL>-USDT'), confirming the parameter is the base asset without quote suffix, which is a marginal gain 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: 'OKX spot ticker for any live <SYMBOL>-USDT pair', and enumerates the returned fields (last, bid/ask, spread bps, 24h OHLC, volume). It is distinguishable from get_candles/get_perps by being a single-pair snapshot, but it never names the closest sibling (get_price), leaving that boundary for the agent to infer.

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

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

Usage is implied rather than prescribed: 'any live ... pair' plus 'Unknown pairs return an error and no charge' tells the agent what is and isn't valid input, and the free sample URL offers a safe preview. There is no explicit when-to-use versus get_price or get_candles, nor any statement of prerequisites for the x402 payment flow.

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, idempotentHint=true, destructiveHint=false, so the safety profile is covered structurally. The description's one behavioral addition is the 'Free' tier marker, which is genuinely useful for an agent reasoning about cost/auth. It says nothing about data freshness, staleness, or whether the teaser is truncated relative to the paid brief.

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

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

A single sentence with zero filler, front-loaded with the most decision-relevant token ('Free') followed by the payload contents. Nothing could be removed 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?

With no parameters and no output schema, the description carries the burden of describing what is returned, and it does list the three content groups. The remaining gap is relational: it never clarifies how the teaser relates to get_latest_brief or get_sample_brief, which an agent choosing among seven similar getters would need.

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

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

The tool takes zero parameters, so the baseline is 4; schema coverage is 100% and there is nothing for the description to disambiguate. The description instead spends its words on return content, which is the right allocation here.

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

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

The description names a concrete content bundle (brief teaser text, Hyperliquid extreme funding at 8h-equivalent rates, BTC/ETH/SOL prices with 24h change), so an agent knows exactly what comes back. It does not, however, say how this differs from the near-identical siblings get_latest_brief or get_sample_brief, leaving the 'teaser' distinction implicit.

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 leading 'Free:' implies this is the unauthenticated/preview entry point, which is useful routing context. But there is no explicit statement of when to prefer this over get_latest_brief, get_sample_brief, or get_extreme_funding, so usage must be inferred.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description's job is to add context — and it does: a fixed 20-item cap, a 30-day lookback window, and 'aggregate counts only' signaling that no per-agent data is exposed. It stops short of saying whether results are ranked by count or what the payload looks like, but the value-add is real.

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

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

A single sentence with zero filler; the 'Free:' qualifier and the result cardinality are front-loaded so an agent scanning it immediately knows cost model and output size.

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, no-output-schema aggregate read, the description supplies the essentials: what is counted, over what window, how many items, and that only aggregates are returned. Only the ordering/sort semantics of 'top' remain slightly underspecified.

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

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

The tool takes zero parameters, so the baseline is 4. No parameter semantics are needed, and the description correctly spends no words on inputs.

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

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

The description states a concrete resource (top 20 coins requested for monitoring) with explicit scope (last 30 days, aggregate counts only), which is far more specific than the title. It implicitly contrasts with the sibling request_asset (which submits a single request) but never names that relationship, so an agent must infer it.

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 leading 'Free:' token hints at a paid tier among siblings like get_pricing/get_teaser, and 'top requested' implies a discovery/popularity use case, but no sentence says when to call this versus request_asset or the brief tools. Usage is implied rather than instructed.

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

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

Annotations only declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false with no explanation. The description supplies the missing behavior context: the request is non-destructive but has no immediate effect, is reviewed by a human, carries a 10/hour/IP limit, and counts repeat asks within 24h once — which is exactly the meaning behind the idempotency hint.

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 'Free: ask ...' and every subsequent clause earns its place (covered list, outcome, caveat, rate limit). It is dense and somewhat run-on, but no sentence is filler.

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

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

With no output schema, the description carries the return expectation by explaining the request is merely logged for review and not guaranteed. Combined with the covered-asset allowlist and rate/dedup limits, an agent has everything needed to call this correctly and set user expectations.

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

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

Schema description coverage is 100%, so all three parameters (symbol, agent, reason) and their length constraints are already documented in the schema. The description adds no syntax, format, or usage nuance for the optional agent/reason fields, so the baseline 3 applies.

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

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

States a specific verb+resource ('ask cryptofeed402 to consider monitoring a coin it does not cover yet') and immediately scopes it with the currently covered set (BTC, ETH, SOL, HYPE, NEAR, AAVE). This distinguishes it cleanly from every sibling, which are all read-only 'get_*' retrieval tools.

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

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

Explicitly defines when to use it (a coin not yet covered), what the outcome is (logged for human review, high-demand assets may be added later), and the exclusion ('Not a guarantee'). Rate limit and dedup rules are stated as concrete operating conditions rather than left 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?

With readOnlyHint=false the description does real work beyond annotations: it discloses that submissions are logged as aggregate demand, that only counts are visible via GET /feedback/schedule, that notes and agent names are never published, that no IPs are stored, and that there is a 10/hour/IP limit. The one meaningful gap is whether repeat calls accumulate new entries or replace the prior schedule, which matters given idempotentHint=false.

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

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

Three short clauses, front-loaded with the cost signal and the core request, then the data-handling caveats, then the rate limit. Every sentence carries information; the parenthetical is dense but worth its space.

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?

A six-parameter write tool with no output schema needs to explain what a submission means and what happens next. The description covers storage, visibility, and throttling well, but leaves symbols/routes_of_interest semantics and repeat-submission behavior unexplained, so an agent cannot fully predict the effect of its call.

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

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

Schema description coverage is only 33%, so the description must compensate, and it partly does: 'how often' maps to frequency and 'best UTC hours' to preferred_utc_hours, and the privacy sentence implicitly flags that note and agent_name are collected. It says nothing about the symbols or routes_of_interest parameters, and adds no format or intent detail for preferred_utc_hours beyond the schema's own note.

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 concrete action: tell cryptofeed402 how often you want briefs/reports and which UTC hours you prefer. That is a specific verb plus resource, not a restatement of the name. It does not, however, distinguish this from the sibling demand-signal tool request_asset (nor explain how it relates to get_top_requested_assets).

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 leading 'Free:' and 'so we can schedule to match' imply this is an optional, no-cost demand-signal submission rather than a data fetch. There is no explicit when-not guidance and no named alternative for cases where the agent wants a one-off asset request (request_asset) instead of a recurring cadence, so routing between the two siblings is left to inference.

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