Degenscan Intel

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the safety profile is covered. The description adds a genuinely useful non-annotation fact: the $0.1/call cost and the fact that it collapses ~6 calls into one. It stops short of stating auth needs, rate limits, or latency characteristics.

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 claim, but the payload list is a comma-choked run-on and the 'replaces ~6 calls' claim is stated twice, once mid-list and again in the final sentence. Trimming the duplication would make it materially tighter 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?

There is no output schema, so the description carries the full burden of explaining return contents, and it does so comprehensively (pressure/drivers, headlines, filings, exposure map, Polymarket odds, 7d catalysts, venue status/tradable_now). It also discloses cost, which is the other thing an agent needs before invoking a premium 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 coverage is 100% and both parameters are documented in the schema, so baseline 3 applies. The description only echoes the 24h scope and the single-asset constraint already implied by asset_id; it adds no format or edge-case semantics beyond that.

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 ('One-call briefing for ONE asset') and then enumerates exactly what the briefing contains (net pressure, headlines w/ sentiment, SEC filings, exposure map, Polymarket odds, catalysts, venue status). It also distinguishes itself from siblings by naming events_since and impact_for as the many-asset alternative.

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

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

Explicit cadence guidance ('ideal once per asset per session or pre-open') and an explicit routing rule: use this for everything about ONE asset, use events_since + impact_for for many assets. Both the when-to-use and the when-not-to-use alternative are named.

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 this as a safe, idempotent read. The description goes beyond them usefully by disclosing the data sources/venues (Mercado Bitcoin, BCB PTAX, Coinbase) and the per-call cost ($0.002/call), which affects invocation decisions. It stops short of describing latency or response shape.

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 dense sentences with zero filler; the core comparison is front-loaded and the cost and usage boundary are appended compactly. Every clause carries distinct 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 no-parameter, no-output-schema tool the description conveys the sources and the comparison basis well. It never says what the returned value looks like (premium in percent, bps, or a raw spread), which is the one remaining gap an agent might want before calling.

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 there is nothing to document, so the baseline is 4. The description correctly spends no space on parameter syntax and instead clarifies the comparison basis, which is the only input-like ambiguity.

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 scope: USDT/USDC-BRL on Mercado Bitcoin vs BCB PTAX, and BTC-BRL vs BTC-USD at both PTAX and the on-exchange USDT rate. This is specific enough that an agent can distinguish it from any sibling FX or pricing tool without opening a schema.

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

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

It states the use case explicitly ("Use for Brazil's crypto-dollar/BTC premium vs the official PTAX") and adds a negative boundary ("not for other FX"), which is genuine routing guidance. It does not name a specific sibling to use instead, so it falls short of a full 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 readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds pricing ($0.002/call) and the provenance of earnings dates ('seen in the feed'), which are real behavioral facts not in structured data. It stops short of output shape or rate-limit 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?

Three dense sentences with no filler: scope, use cases and price, then routing to the sibling. The most important routing constraint is front-loaded alongside the content list.

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

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

For a read-only, low-risk lookup with no output schema, the description conveys what the result contains (dated events with the assets they usually move), the cost, and where to go for a related need. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so all three parameters (days, types, universe) are already documented. The description restates the type categories and the earnings-scoping intent of universe, adding marginal clarity but nothing the schema lacks. 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 and resource (upcoming scheduled catalysts) and enumerates the covered categories: US macro prints, FOMC, Treasury auctions, and earnings dates. It also explicitly carves out the sibling treasury_auctions, so an agent can distinguish it without inspecting the schema.

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

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

Gives concrete use cases ('avoid holding through a print', 'schedule polling') and an explicit alternative with its condition: 'for Treasury auction details use treasury_auctions.' Both when-to-use and when-to-use-something-else are covered.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive. The description adds real context beyond them: an auth requirement (Carry Oracle key, US$100/month), the factual 'data, not a signal' framing, and the returned fields. Return format details (pagination, refresh cadence) remain unstated, keeping it from 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?

Three tight sentences, front-loaded with scope and contents, then the cost/auth caveat, then the routing rule. Every sentence earns its place.

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

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

With no output schema, the description compensates by naming the returned fields (funding, OI, 24h volume, spot mark) and the access requirement. An agent has enough to decide and call 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 both dex and min_vol are fully documented in the schema. The description implies dex filtering ('every dex', 'filter to one dex' lives in schema) but adds no syntax or default detail beyond it, so baseline 3 is correct.

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 (annualised funding) and scope (every perp on every Hyperliquid dex: main + HIP-3), with a clear verb-like framing. It separates itself from price_for and carry_history explicitly, so an agent can route 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?

Explicit when-to-use ('ALL perps on ALL Hyperliquid dexes at once') and names the alternatives for the narrower case ('for one coin use price_for or carry_history'). Nothing 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 already declare readOnly/IDEMPOTENT/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful non-annotation context: the authentication requirement (Carry Oracle key) and the retention property of the data source (beyond the 500 h window). It stops short of describing rate limits or pagination, hence a 4 rather than 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?

Three tight sentences, no filler, with the data scope and the 'beyond 500 h' constraint front-loaded ahead of the alternative-tool routing. 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?

For a two-parameter read tool with no output schema, the description covers what is needed to call it correctly: coin format, hourly granularity, retention window, auth requirement, and the sibling to use instead. Return-field specifics are implied by the enumerated metrics but never laid out, which is the only minor gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's mention of the HIP-3 prefix convention (xyz:NBIS) and the hourly granularity restates what the schema already documents for coin and hours, adding no new syntax or format detail.

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

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

States a specific verb (retrieves) and resource (hourly funding/premium/mark/OI/volume for one coin) with an explicit scope qualifier: history retained beyond Hyperliquid's 500 h window. It also names the sibling it is not, so an agent can distinguish it from carry_funding_matrix without 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 both the when-to-use condition ('one coin's hourly history beyond 500 h') and the alternative with its selecting condition ('for the current snapshot of all coins use carry_funding_matrix'). The key prerequisite ('Requires a Carry Oracle key') is stated up front, leaving nothing to inference.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful context beyond them: it requires a Carry Oracle key, and it is 'Raw data, not a call', which tells the agent not to treat the output as a recommendation. It does not describe return shape, but that gap is minor here.

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 dense sentences with no filler. The defining filter condition is front-loaded, and the routing rule comes last where an agent deciding between siblings will look for 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?

For a single-parameter, no-output-schema read tool the definition covers what is needed: the filter semantics, the auth prerequisite, the nature of the output ('raw data'), and sibling routing. Only a brief note on the returned data shape is absent, which is acceptable given there is no output schema.

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

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

Schema coverage is 100%, and the single parameter is documented in the schema with its default of 0.5. The description restates the default (50%) and the threshold semantics, but adds no syntax or nuance beyond the schema, so 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 resource (perps), a precise filter condition (|annualised funding| above a threshold, no hedge leg on Hyperliquid) and the mechanism (no spot, no same-ticker HIP-3 listing). It explicitly distinguishes itself from named siblings, so an agent can route correctly without opening a schema.

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

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

Gives an explicit when-to-use case ('funding extremes that cannot be hedged on Hyperliquid') and names the alternatives for the excluded case (carry_xdex, carry_spot_perp). Both the positive and negative routing conditions are stated.

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

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

Adds substantial context beyond the annotations: auth requirements (Carry key via X-API-KEY, free trial key, or x402 per-call payment), the sort order ('sorted by 14-day funding'), and a full enumeration of returned fields. With no output schema, this field disclosure is genuinely load-bearing. Rate limits or pagination behavior are not mentioned, keeping 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?

Front-loads the scope, then returns, then auth, then routing. The long field enumeration is verbose but justified because no output schema exists to document the response. Slightly dense but nothing 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?

Given two optional params fully documented by the schema and no output schema, the description compensates by listing the return fields, noting the sort order, stating access/auth modes, and naming the sibling alternative. An agent has everything needed to select and invoke 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 description coverage is 100% for both parameters, including their defaults (limit=50, min_vol=100000), so the schema carries the parameter documentation. The description adds no parameter-level detail, so 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 precise verb/resource scope: 'Hyperliquid main-dex perps that also have a Hyperliquid spot market,' with concrete examples (HYPE, PURR, BTC via UBTC). It immediately distinguishes itself from the sibling carry_xdex, which covers cross-dex HIP-3 pairs.

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

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

Explicitly routes the agent: 'Use for main-dex perp vs its spot market; for cross-dex HIP-3 pairs use carry_xdex.' It also sets expectations with 'Data, not a signal,' telling the agent this returns raw data rather than a trade recommendation.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond that: it names the authentication requirement (Carry Oracle key), scopes the output to every perp market and dex, and lists concrete return fields including 7-day changes and risk flags. It stops short of covering pagination, rate limits, or response format, so a 4 is appropriate.

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

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

The description is three tight sentences that are front-loaded with the returned data, then the auth requirement, then the usage guidance. Every sentence earns its place, and there is no redundant or vague language.

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

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

For a read-only listing tool with no input parameters and no output schema, the description provides a complete picture: what it returns, the required key, and exactly when to use it versus funding-related tools. Annotations already cover the safety profile, so 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 zero parameters, so the schema has no parameter semantics to document. Per the rules, zero parameters yields a baseline of 4; no additional meaning can be added beyond what the empty 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 states a specific resource (every Hyperliquid perp market and dex) and the exact data categories returned (status, OI and volume with 7-day change, growth mode, risk flags). It explicitly distinguishes from sibling tools by saying 'not for funding levels', which separates it from carry_funding_matrix and funding_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?

It gives a clear use case ('market and dex health (delistings, OI drops)'), a prerequisite ('Requires a Carry Oracle key'), and an explicit exclusion ('not for funding levels'). The agent has enough to decide when to call this versus the funding-focused siblings without inferring.

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. The description adds meaningful context beyond them: auth requirements, 'Data, not a signal' framing, the main-dex exclusion rule, and the sort order. Pagination/rate-limit behavior is not mentioned, keeping it short of 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?

Front-loads the core definition and example; the output-field enumeration is dense but informative given there's no output schema. Slightly long, but nearly every clause 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?

With no output schema, the description usefully enumerates the returned fields (legs, spread_apr_now/14d, basis_pct, min_leg_vol24_usd) and sort order. Auth and scope are covered; only edge-case behavior like empty results or rate limits 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?

Schema coverage is 100% with only two optional params, both documented in the schema (limit, min_vol). The description doesn't add syntax or semantics beyond defaults, 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 resource (assets listed on 2+ Hyperliquid HIP-3 dexes) with a concrete example, and explicitly excludes main-dex tickers. The sibling differentiation is explicit: 'for perp vs spot use carry_spot_perp'.

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 names when to use it ('the same ticker priced on 2+ HIP-3 dexes') and the alternative for the adjacent case ('for perp vs spot use carry_spot_perp'). It also states access prerequisites (Carry key, trial key, or x402 per call).

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/non-destructive, so the safety profile is covered. The description adds genuinely new context: the $0.003 per-call cost, that results include a DefiLlama outlier flag, and an explicit caveat that this is not a risk rating. That is meaningful interpretation and cost context beyond the 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 return contents are front-loaded, which is good, but the phrase "Not a risk rating" appears twice, the second time redundantly redundantly tacked onto the usage sentence. That repetition wastes space and slightly muddies an otherwise tight definition.

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 five zero-coverage parameters, the description should carry more weight than it does; chain, limit, and the boolean flag semantics are unaddressed. It does describe returned fields and cost, which helps, but an agent still lacks enough to fully configure the call.

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

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

Schema description coverage is 0% across five parameters, so the description must compensate. It implicitly covers stable_only ("stablecoin or all") and min_tvl ("TVL floor") and touches the outlier flag, but chain and limit are undocumented anywhere, leaving half the parameters unexplained.

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 picture: it returns DeFi pools filtered to a TVL floor, with APY, 30-day mean APY, reward-token share, and an outlier flag. That is far more than a restatement of the name. It stops short of explicitly differentiating from siblings such as stablecoin_supply or the carry_* family, so it is clear but not fully self-routing.

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?

"Use for stablecoin pool APYs; not a risk rating" gives a positive usage cue and a boundary (not a risk assessment), which is useful. However, no alternative or sibling tool is named for when this is the wrong choice, so the guidance is 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on behavior they cannot express: no API key required, $0.003/call cost, data freshness/join semantics ('joined with our primary-source event pressure when covered'), and an explicit exclusion ('Liquidations are not included').

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 and the data inventory are front-loaded in a single dense sentence, and the routing/alternatives follow. It is long and field-heavy, but the enumeration is justified because there is no output schema; only minor tightening is possible.

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 2-param read tool with no output schema, the description enumerates the returned fields (funding, OI, mark/oracle/mid, premium, volume, flags), notes the event-pressure join, and states what is excluded — everything an agent needs to decide and 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 100%, so symbol and since are already fully documented in the schema, including case-insensitivity and the 24h default. The description adds only an example ticker list and the notion of hourly funding resolution, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb+resource: perpetual-futures microstructure for ONE coin from Hyperliquid's public API. It explicitly distinguishes itself from price_for (price only) and carry_funding_matrix (every perp), so an agent can route without opening sibling schemas.

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

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

Gives concrete trigger scenarios ('before sizing a perp position', 'detect crowded funding', 'market-structure leg next to events_since') and names two alternatives with the condition that selects each: price_for for price only, carry_funding_matrix for all perps.

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 safety (readOnly, idempotent, openWorld), and the description adds genuinely non-structured context: cost ($0.005/call), a free quota (100 calls/day), the scoring model (direction −1/0/+1, confidence 0..1, horizon), and the tradable_now / next_open fields. That is real behavioral disclosure 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?

Front-loaded with purpose and use cases, then filters, then pricing; minimal waste. The dense parenthetical enumerations of event kinds and impact fields make it long, but each clause carries information an agent needs.

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

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

For an 8-parameter, zero-required read tool with no output schema, the description supplies the return shape, filtering defaults, cost/rate limits, and sibling routing. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds usage-level semantics by framing universe=["NVDA","BTC"] with min_confidence≥0.4 as the configuration for acting, and by tying `since` to backtesting. Some of this (past `since`) restates the schema, so it falls short of full compensation.

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 ('List market-moving events since a point in time'), enumerates the event kinds covered, and describes the per-asset scored output shape. It explicitly differentiates itself from siblings impact_for (one asset's scored impacts) and brief (one-call asset 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?

Gives concrete when-to-use scenarios ('what happened in the last N hours that affects my book'), a backtesting case with a past `since`, and explicit alternatives with their selecting conditions (impact_for, brief). It also names the default filter that makes results actionable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful non-annotation context: a cost of $0.02/call and a detailed preview of the returned reasoning (why each asset got its direction/confidence, the exposure-graph path, source links, corroborating sources). It does not mention auth or rate limits beyond cost, but the added transparency is meaningful.

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 output details, then usage guidance, then cost and a sourcing constraint. It is efficient overall, but the two sentences 'Takes the event id from those tools' and 'Use only with an event_id returned by events_since or impact_for' are partially redundant, slightly hurting conciseness.

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

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

For a simple read-only tool with one required string parameter, no output schema, and annotations that fully cover safety semantics, the description is complete: it says what the tool returns, when to use it, how it relates to sibling tools, the required input source, and the cost. Nothing an agent needs in order 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?

Schema description coverage is 0% for the single event_id parameter, so the description must carry the burden. It specifies where the event_id must come from ('returned by events_since or impact_for') and uses it to scope the tool to exactly one event. This adds essential semantic meaning beyond the bare string type in the schema, though it does not describe the id format itself.

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 ('Plain-language explanation') and resource ('ONE event's impacts'), and details exactly what the explanation contains (direction/confidence reasoning, exposure-graph path, source document link, corroborating sources). It also distinguishes this from sibling tools impact_for and events_since by framing itself as the 'reasoning' layer rather than the raw impact 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?

It gives explicit when-to-use criteria: 'when an impact from events_since/impact_for is surprising and you need the reasoning before acting, or to log a rationale.' It also states a hard prerequisite and restriction: 'Use only with an event_id returned by events_since or impact_for.' No ambiguity remains about the appropriate context or the required input source.

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, openWorld, and non-destructive, so the safety profile is covered. The description adds real value beyond that with per-call cost ($0.002/call) and the scope of what the graph returns, though it says nothing about response size or traversal limits beyond depth.

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?

Efficient and front-loaded: it leads with the resource, then use cases, then cost, then exclusions. The opening is a fragment and the enumeration is dense, but every sentence carries information and none 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 two-parameter read tool with a complete schema, the description adequately conveys what the graph contains so the agent doesn't need an output schema. It could go slightly further on result shape or breadth, but nothing essential to correct invocation 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%, with both asset_id and depth fully documented in the schema (including hop semantics and the `universe` cross-reference). The description adds no parameter-level meaning beyond that, so the baseline of 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?

The description states a specific resource (an asset's exposure graph) and enumerates its contents: suppliers, customers, countries, input commodities, regulators, indices, correlated assets, and facilities with coordinates. It clearly distinguishes itself from siblings like price_for, news_for, and events_since, which it explicitly rules out.

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 concrete when-to-use cases (finding second-order trades like TSM → NVDA/AAPL, or knowing which regulators/countries to watch) and an explicit when-not-to-use clause ('not for prices or events'). This routes the agent away from wrong 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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds value beyond that: it discloses the cost ($0.002/call), the public-domain source, and the shape of the returned content (summary, impact direction, link). It stops short of describing pagination or per-call rate behavior, keeping it at a strong 4.

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 resource and scope, then triggers, then the cost, then the sibling disambiguation. Every sentence carries information. The '$0.002/call' clause sits mid-description and momentarily interrupts the flow, a minor 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?

No output schema exists, but the description explains what comes back (summary, impact direction, link), and covers the forms, window and issuer dimensions. For a filtered, read-only lookup tool this is nearly complete, with only limit/pagination behavior 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?

Schema coverage is 75% (forms, since, ticker documented; limit is not). The description still adds meaning by spelling out the form categories (8-K items, Form 4, 13D/G, S-1/424B, bankruptcy) and the notion of a time window, reinforcing how 'forms' and 'since' behave. It adds context over the schema rather than merely restating 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?

States a specific resource (SEC EDGAR filings) with explicit scope ('touch ONE US issuer in the window') and enumerates the covered form types (8-K by item, Form 4, 13D/G, S-1/424B, bankruptcy). It also names the sibling it is not (news_for), so an agent can distinguish it without 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 concrete when-to-use triggers ('before earnings', 'when a stock moves without news') and states the routing rule explicitly ('Use for SEC filings of one issuer; for headlines use news_for'). Both the use case and the alternative are named, leaving nothing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely useful context the annotations don't: a $0.001/call cost and the 5–15 min refresh cadence, plus what is returned (annualized %, which side pays, OI, predicted next funding per venue).

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?

Dense but front-loaded: purpose, then cadence, then the routing alternative. Every clause carries information, though the single long sentence would read better split. 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?

No output schema exists, so the description appropriately enumerates the return fields (hourly/annualized rate, paying side, OI, predicted next funding across venue). Combined with the alternative-tool routing, an agent has almost everything needed, with only the limit parameter left unexplained.

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%: min_abs_rate_1h is documented in the schema (threshold semantics and default), but limit has no description anywhere. The description's mention of sorting by |hourly rate| implies a threshold notion but never explains limit, so it only partially compensates for the gap. 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?

Opens with a specific verb+resource+scope: which perps have extreme funding right now on Hyperliquid, sorted by |hourly rate|. It explicitly distinguishes itself from carry_funding_matrix for every Hyperliquid dex incl. HIP-3, so an agent can route without 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 an explicit cadence and purpose ('Use every 5–15 min to detect crowded positioning or to pick a side to receive funding') and names the alternative tool plus the condition that selects it (carry_funding_matrix for every dex incl. HIP-3). Nothing 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 already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the per-call price ($0.003/call) and the exact shape of what is returned. It stops short of noting rate limits or auth requirements, so it is not fully 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?

Front-loads the core definition, then usage, then cost, then sibling routing, in four compact sentences with no filler. Every clause carries distinct 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?

There is no output schema, and the description compensates by enumerating the returned fields (bias, event count, drivers, rationale, graph path). Combined with 100% schema coverage on inputs and full annotation coverage, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so asset_id, since, and limit are already documented with formats, defaults, and bounds. The description adds only the notion of a 'window' and reinforces single-asset scope, which is marginal beyond the schema — the baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource with scope: 'Net directional pressure on ONE asset over a window', then enumerates the payload (bias −1..+1, event count, strongest drivers, source events with rationale and graph path). It is unmistakably distinct from sibling tools like events_since, brief, and price_for.

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

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

Gives explicit when-to-use ('before entering or sizing a position in that asset, or to explain a move ("why is MSTR down today?")') and names the two alternatives with their selecting conditions: events_since for raw events, brief for a full asset briefing. Nothing 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 disclose readOnlyHint=false, idempotentHint=false and openWorldHint=true, and the description reinforces the non-idempotent nature via 'One per e-mail', plus adds quota (200 calls/7 days), no-card requirement, coverage boundaries, and the X-API-KEY delivery convention. It does not say what the response payload contains or how a duplicate-email request fails.

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 final clause 'Use once to get a free trial key (200 calls, 7 days); then send it as X-API-KEY' restates the opening sentence's facts with no new information, making the description noticeably redundant rather than front-loaded and 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 single-parameter, no-output-schema issuance tool the description covers the essential quota, scope, and delivery mechanism, so it is broadly adequate. It still omits what the call actually returns (the key itself? a confirmation?) and any failure/rate behavior, which an agent issuing this credential would benefit from knowing.

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% and the sole parameter ('email') is undocumented in the schema, so the description must carry it. 'One per e-mail' does convey that the e-mail is the uniqueness key for issuance, but it never states format expectations or that the key is delivered to that address, leaving a real gap for a 1-required-param 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?

States a specific verb and resource ('free trial API key for Degenscan Intel') and quantifies the deliverable (200 calls, 7 days, no card). It also delineates scope against siblings by naming which tool families it covers (carry_*, event feed) and which it does not (oracle). Slightly muddled by repetition, but an agent can tell what it returns.

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

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

It implies context – constrain usage, one per e-mail, and the resulting key's coverage – but never states when an agent should call this versus using an existing key or another tool. The 'Use once' phrasing hints at a single-shot precondition without spelling out what happens on repeat calls.

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 the description adds substantial context beyond them: the exact payload fields (source tier, corroboration count, −1..1 sentiment, impact direction, average sentiment label), the 'links only, no article bodies' limit, and a per-call price of $0.002. That is meaningful operational disclosure an agent cannot get from 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?

Front-loaded with purpose and payload, then usage, cost, and routing in a compact block. It is dense rather than padded, though the parenthetical field list is long enough that the sentence strains slightly.

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 describing return contents and does so thoroughly, including the sentiment scale and the 'no article bodies' caveat. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 67%, and the description mentions the 'window' concept that maps to the since parameter, but it adds no format or syntax detail for limit or since beyond what the schema already documents. With the schema doing most of the work, this lands at the 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: 'Headlines that touch ONE asset in the window', scoped to a single ticker. It also explicitly distinguishes itself from the sibling filings_for ('for SEC filings use filings_for'), so an agent can separate news flow from filings without opening a schema.

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

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

Gives concrete usage contexts ('what is the news flow on X today', 'feed a sentiment gate') and an explicit exclusion routing to filings_for. The 'one ticker' constraint is stated up front, so when-to-use and when-not-to-use are both covered.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds cost ($0.002/call), latency/effort profile (cached, no waiting, no LLM call), and freshness semantics (recomputed daily). These are exactly the behavioral traits an agent needs for a polling tool and are not derivable from the 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?

Front-loaded with the resource and contents, then usage, then the sibling alternative. Despite being dense, every clause carries distinct information (coverage, fields returned, slug behavior, cost, routing) with no filler or repetition.

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, so the description must describe returns, and it does: probability, 80% interval, base rate, market odds, edge, commitment hash, plus drivers/failure modes/history when a slug is given. Cost, caching, and routing are all present, so 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?

Schema coverage is 100%, so the baseline is 3, and the description goes further by explaining the semantic difference between passing a slug (one forecast with full drivers, failure modes, and history) versus omitting it (the whole board). This adds outcome-level meaning beyond the schema's terse 'Omit for the whole board'.

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 oracle's standing questions, recomputed daily) and enumerates exactly what the board covers: BTC/ETH/SOL price targets, FOMC, Polymarket markets, CPI/NFP. It distinguishes itself from the sibling oracle_forecast by naming the differentiator (standing questions vs. your own question).

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 when to use it ('today's standing forecasts without waiting') and names the alternative with the selecting condition ('to ask your own question use oracle_forecast'). Adds a polling pattern ('poll in a loop for cheap calibrated priors'), which is direct usage guidance.

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

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

Annotations only declare the safety profile (readOnly=false, openWorld=true, idempotent=false); the description goes far beyond, disclosing the async contract (returns forecast_id/queued/eta_s in under a second, 1-3 min to done), cost ($0.25/call, ~70 LLM calls), the require_verified HTTP 422 no-charge behavior, and the commitment_hash committed before resolution. This is unusually rich behavioral context.

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

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

Dense but nearly every sentence carries load (examples, pipeline, async contract, cost, result fields, alternative). It is somewhat long and the async mechanics sit mid-paragraph rather than front-loaded, which is the only real cost.

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 enumerating the return fields (probability, ci80, base_rate, edge, drivers, panel, commitment_hash, etc.), and it covers cost, timing, polling, and the failure path. An agent has everything needed to call and interpret this 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 already high (89%), but the description adds real meaning: it explains that interventions inject a shock into the simulated society and demonstrates the {round, news, audience} shape, clarifies method routing vs. forcing, and describes require_verified's refusal semantics 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?

States a specific verb+resource ('get a calibrated probability for a yes/no market question') with concrete examples, and explicitly distinguishes itself from siblings by naming oracle_get for polling and oracle_board for standing forecasts. An agent can route correctly without opening any schema.

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

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

Gives explicit when-to-use ('ask a NEW binary question'), the follow-up workflow (poll oracle_get every ~20s until status=done), and the alternative for a different use case ('For today's standing forecasts use oracle_board'). Nothing 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 already declare readOnly/idempotent/destructive=false, and the description adds the behavior those hints cannot express: the tool is a polling endpoint with distinct queued/running states, a retry_after_s field to honor, and a 'full Forecast' payload once complete. It also notes the result is free and verifiable via commitment_hash, which is real context beyond the 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?

Purpose and polling behavior are front-loaded and the Forecast field enumeration is informative, but the trailing sentence 'Use only to poll a forecast_id returned by oracle_forecast (free).' repeats content already stated in the first and second sentences and earns no 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?

There is no output schema, and the description compensates well by enumerating the returned Forecast fields and the interim status shape with retry_after_s. It stops short of stating what happens on an unknown/expired id or how aggressively to re-poll, so it is strong but not fully closed.

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 one parameter at 100% schema description coverage, the schema already defines forecast_id and its provenance. The description restates the same origin (returned by oracle_forecast, listed by oracle_board / oracle_track_record) without adding format, constraint or validation detail, 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 ('Poll or retrieve an oracle forecast') and immediately contrasts with the sibling that creates forecasts ('Use after oracle_forecast'). An agent can distinguish this from oracle_forecast, oracle_board and oracle_track_record 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?

Explicitly names the entry points (oracle_forecast, oracle_board, oracle_track_record) and the ordering ('Use after oracle_forecast'), so the agent knows when this tool is the right call. Minor deduction: the closing sentence 'Use only to poll a forecast_id returned by oracle_forecast' narrows the source of the id in a way that mildly conflicts with the earlier mention of oracle_board / oracle_track_record as id sources.

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, so the safety profile is covered. The description adds that the record is public and free and enumerates the returned fields, which helps an agent judge the trustworthiness of other oracle calls; it does not describe update cadence or how the 20 commitments are ordered beyond 'most recent'.

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 metric list and the interpretability scale, which is exactly what an agent needs first. The trailing audit sentence duplicates the earlier guidance and the title already says 'free', so there is minor wasted verbiage.

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 carries the burden of explaining return values, and it does so by naming the metrics and the commitment fields (id, probability, hash, outcome). It is complete enough to call and interpret, with only minor gaps such as aggregation windows or freshness.

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, which is the baseline-4 case. The description correctly implies a no-argument call ('How good the oracle has been'), so nothing is missing here.

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

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

Names the specific resource (the oracle's public track record) and enumerates the exact metrics returned: Brier overall and by domain, oracle vs. market Brier, beat_market_rate, mean absolute edge, and the 20 most recent commitments. It also anchors the scoring scale (0.25 coin flip, 0.15 good human, 0.10 superforecaster), so an agent knows precisely what it is reading.

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 it 'to decide how much to trust oracle_forecast / oracle_board' and to 'audit the oracle's public accuracy', which names the sibling tools and the decision context. The closing '(free)' audit sentence largely restates the opening guidance, so it is clear but slightly redundant rather than a crisp when/when-not split.

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, open-world, so the safety profile is covered. The description adds useful behavioral context: what the evidence pack contains (relevance, source tier, corroboration, per-asset impacts), the $0.01/call cost, and the 'information, not a forecast' caveat. It could say more about rate limits or result staleness, but it goes well 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?

Front-loaded with the core operation and evidence contents, then usage, then alternative routing. It is slightly dense with parenthetical examples, but every sentence carries routing or behavior 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?

Covers purpose, evidence composition, cost, and sibling routing for a read-only lookup with a fully documented schema. It does not explain return shape or freshness limits, but no output schema exists and the description is otherwise 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?

Schema description coverage is 100%, so the schema already documents all three parameters in detail. The description adds only the resolution behavior (id/slug via Gamma API, text searched), which is marginal beyond the schema. 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 states a specific verb (resolves, returns) and resource (a Polymarket market's odds plus primary-source events), and differentiates from the sibling polymarket_top for discovery. An agent can tell exactly what the tool produces without opening the schema.

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

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

It gives explicit when-to-use ('before trading or quoting a probability', 'to detect a fresh primary event') and sensitive exclusions ('to discover markets use polymarket_top'). The alternative is named with 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond that: cached from the daily board with no LLM and instant latency, pollable in a loop, $0.002/call, and a link to the Brier track record. Cost, freshness and latency disclosure are exactly the kind of behavior annotations cannot express.

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

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

Purpose and routing are front-loaded before the output-field enumeration, and no sentence is pure filler. However, the middle clause is a long comma-spliced list of output fields that would read better structured, making it denser 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?

There is no output schema, so the description carries the full burden of describing return values, and it does so comprehensively (oracle probability, 80% interval, market YES price, edge, cheap side, base rate, resolution date, sha256 commitment hash, sort order). Cost, caching and the sibling alternative are all covered, leaving nothing an agent needs 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 only 50% (limit has no description), so the description must compensate. It defines edge as (p − odds), which gives min_abs its meaning ('Minimum |p − odds|'), and limit is a conventional result cap. The added context on min_abs is useful, though limit semantics remain unstated.

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 opening clause states a specific verb and resource: it surfaces open daily-board questions where a calibrated forecaster disagrees most with Polymarket. It is distinguishable from polymarket_top and polymarket_context, and it explicitly contrasts itself with oracle_forecast for single-question 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 states the condition for use ('list markets where the oracle and market odds disagree most') and names the alternative with its selecting condition ('for one new question use oracle_forecast'). It also tells the agent to poll it in a loop, so the invocation pattern is 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, open-world behavior, so the safety profile is covered. The description adds genuinely useful non-annotation context: a per-call price ($0.002/call) and the fact that each row links to a primary-source evidence pack. It still says nothing about pagination, rate limits, or freshness of 'right now', so it is only modestly above the annotation bar.

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

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

Front-loaded with the core purpose and output fields, and reasonably tight overall. The usage sentence is partly redundant, restating 'most active prediction markets' after already saying it in the first sentence, which is minor waste rather than bloat.

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 enumerating the returned fields (question, YES odds, 24h change, volume, liquidity, end date, link), and it covers cost and tool routing. The main residual gap is the undocumented limit parameter and unstated result-count/default behavior.

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%: tag is documented in the schema, sort relies on an enum, and limit is undocumented beyond bounds/defaults. The description names the three sort options and gives tag examples (crypto/fed/politics), partially compensating, but it never explains what limit does, its 1-50 ceiling, or what 'tag slug' means beyond the examples.

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 ('the most active Polymarket markets right now') with the ranking basis (24h volume, liquidity, or 24h change) and enumerates the returned fields. It explicitly names the sibling tools it is not (polymarket_context, polymarket_edge), so an agent can distinguish 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?

Gives explicit routing: use this to find where prediction-market money is moving, use polymarket_context for a single market's evidence, and polymarket_edge for oracle disagreement. The when-to-use and the alternatives are both stated outright.

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 annotations (which only cover read-only/idempotent safety) by disclosing no-key access, payload size (~1 KB), 30 s caching, cost ($0.001/call), and the polling-loop use case — operational facts an agent cannot derive from 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?

Dense but front-loaded: capability, data sources, cost/latency, then routing to alternatives. Every clause earns its place with no filler.

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

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

With no output schema, the description compensates by enumerating the return payload fields and the pricing/caching model. For a single-param, read-only probe, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and the single 'symbol' param is fully documented with examples (BTC, ETH, SOL, HYPE) and source notes; the description adds nothing 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?

States a specific verb+resource (cheapest price check for ONE coin) and enumerates the returned data (Hyperliquid perp mark/mid/oracle, Coinbase spot, 24h change, basis, funding, event links), making it instantly distinguishable from siblings like carry_funding_matrix and carry_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 gives the when: 'Use for one coin's price/basis/funding now', and names two alternatives with their selecting conditions — carry_history for funding history, carry_funding_matrix for all perps at once. No inference required.

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 the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real context: the $0.001/call price, the hourly cadence, and the exact shape of what comes back. It stops short of latency or sourcing/refresh details, which is the only remaining gap.

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 cost/positioning hook is front-loaded and the routing sentence is tight, but "health/probe call" and "cheap heartbeat" restate the same idea, and the parenthetical class list is long for the value it adds.

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, so the description must carry the return contract — and it does, naming the by-class counts, the top-three severe events with impacts, and open venues. Combined with usage and cost, 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?

With zero parameters and 100% schema coverage, there is nothing to disambiguate; baseline 4 applies. The description correctly does not invent parameter guidance.

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?

It states a specific verb and resource — counts of events in the feed over the last hour, broken out by class — and enumerates the other payloads (top 3 severe with impacts, venues open). It also names the exact siblings it is not (events_since, brief), so an agent can route correctly without 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?

"Use it every hour to decide whether anything needs a deeper look, or as a health/probe call" gives an explicit cadence and trigger, and the closing clause names the alternatives and the condition that selects them (events_since for the events themselves, brief for one asset). Nothing 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 already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds cost ($0.01/call) and the recency/scope semantics ('for right now'), which are genuine extra signals not present in the structured fields. It stops short of describing freshness guarantees or result size.

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 payload contents before cadence advice and the sibling routing hint. The parenthetical enumerations are informative rather than filler, though the sentence is long and packs four distinct content categories plus pricing into one block.

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 carries the whole burden, and it compensates by enumerating exactly what the response contains (venues, next opens, ranked pressure, top events, prediction markets). An agent has enough to decide whether the returned payload matches its 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 per the rubric the baseline is 4. The description correctly implies a call with no arguments by framing the output as an unconditional snapshot of 'right now'.

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 deliverable (a one-call situational picture) and enumerates its contents: venue open/closed state, 24h event pressure by asset, highest-severity events, and prediction-market probabilities. It explicitly distinguishes itself from the sibling 'brief' by scope (market-wide vs single asset).

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

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

Gives explicit cadence guidance ('call it first in a session, or every few hours, to decide whether to look deeper') and a routing rule against a named alternative ('for one asset use brief'). When-to-use and when-to-use-something-else are both 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 the read-only, idempotent, non-destructive profile, so the bar is lower. The description adds real behavioral context beyond that: the report surfaces last errors and distinguishes primary from best-effort sources, which is exactly the transparency an agent needs to distrust stale data.

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 well, but the closing sentences are redundant: 'Free' appears twice and 'check the health of each primary source' restates the report's tier/health framing already given. Trimming would sharpen it 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 and no parameters, the description carries the burden of describing the return value, and it does so by listing the reported fields. It stops short of return format or ordering details, which keeps it from a 5.

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, which is the baseline-4 case. Nothing in the description needs to compensate, and the schema is complete for a no-arg call.

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

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

States a specific deliverable (transparency report) on a defined resource (~40 data connectors) and enumerates what it contains: tier, cadence, last successful run, items ingested, last error. That is enough for an agent to identify it, though it never contrasts itself with a specific sibling.

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 when-to-use contexts: judging freshness before trusting a quiet feed, or spotting best-effort sources. However it names no alternative tools and states no exclusions, so the routing is 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 declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds meaningful non-schema context: a per-call price ($0.002/call) and an interpretive note that net new supply proxies fresh on-chain dollar liquidity. It does not discuss freshness or rate limits, keeping 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?

Information-dense and front-loaded with the source and return shape; the long field enumeration is justified because there is no output schema. It is slightly heavy but every clause carries signal (fields, cost, interpretation, alternative).

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

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

With no output schema, the description carries the full return contract (all three top-level keys and their sub-fields), plus cost and the sibling alternative. Nothing an agent needs to call it correctly is missing.

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

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

The schema has 100% description coverage for the single 'limit' parameter, so the baseline is 3. The description adds no syntax, default, or interaction detail beyond what the schema already documents.

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 the specific resource ('Stablecoin supply from DefiLlama') and enumerates exactly what it returns (totals_usd_pegged, depegged_over_50bps[], items[] per stablecoin). It also names the sibling it is not (whale_moves), so an agent can route 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?

Explicitly states when to use it ('total stablecoin supply and net change') and when to use the alternative ('for individual large transfers use whale_moves'). This is the full when/when-not/alternative pattern.

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 extra operational context the annotations cannot: data sources (GoPlus + DexScreener), a 5-minute cache, deterministic output, and a $0.01/call cost. It stops short of stating failure modes (e.g. unsupported chain, unindexed token) or latency, so not a full 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?

Front-loaded with the decision moment and the required input before any detail; a single dense sentence. The long flag enumeration earns its place by telling the agent what the verdict actually contains, but it is the reason this is not a 5.

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

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

There is no output schema, yet the description documents the return shape thoroughly (verdict tiers, score range, named flags, sources, cache TTL). Coverage of the calling contract is strong; only edge-case behavior on bad or unsupported addresses is unaddressed.

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

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

Schema description coverage is 100%, so both parameters are already documented, including base-as-default-for-0x and base58 auto-detection for Solana. The description's chain enumeration and EVM-default note largely restate 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?

States a specific verb and resource (submit a token contract address, receive a risk verdict) plus the exact output vocabulary (DANGER/HIGH_RISK/CAUTION/LOW_RISK, 0-100 score, named flags). No sibling tool covers token contract risk, and the description makes that scope explicit rather than generic.

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?

Opens with the trigger context ('Before buying, sniping or routing a swap') and closes with an explicit exclusion ('Use for one token contract's risk checks; not a price or a recommendation'), which routes the agent away from price_for and any advisory use. When-to-use and when-not-to-use are both present.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond annotations: the data provenance (public-domain Fiscal Data) and a per-call cost ($0.003/call) that lets an agent budget. It does not, however, disclose the default time window or the shape of the response.

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

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

Two sentences, front-loaded with the resource and returned fields, then routing guidance. The cost note is compact and earns its place for an agent tracking spend. Slightly dense with parenthetical field lists 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?

For a two-parameter, no-output-schema tool, the description covers what data comes back at a field level and where it routes, which is the minimum viable. It still leaves the optional 'days' semantics, defaults, and the overall response structure undocumented, so an agent cannot confidently predict the window of results it will receive.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it largely fails. 'days' is never explained (lookback window? forward calendar horizon? default value when omitted?), and the 'type' enum (Bill/Note/Bond/TIPS/FRN/CMB) is left to the raw schema tokens. The mention of 'size' does not map to any actual parameter.

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

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

States a specific resource (U.S. Treasury auctions) and enumerates the concrete fields returned — high yield, bid-to-cover, indirect/direct/primary-dealer share — plus the upcoming calendar. It also explicitly differentiates itself from the sibling 'calendar' tool, so an agent can distinguish the two without 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 a direct when-to-use ('Use for U.S. Treasury auction results and the upcoming calendar') and names the alternative with its own routing condition ('for all macro releases use calendar'). The boundary between this tool and the sibling is stated, not 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered; the description adds the return payload (class, name, exposure tags, universe version) and the 'stamped on every response' versioning behavior, which is useful. It omits any note on result size or pagination, but for a static reference list 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?

The list of covered classes is front-loaded effectively, but the trailing 'Free. Use to list valid asset ids for other tools (free).' restates both the zero-cost point and the usage note already made earlier, adding redundancy that dilutes the definition.

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 describing returns and does so adequately (class, name, exposure tags, universe version). It is complete for a no-arg reference tool, though it does not state approximate universe size or response format for downstream parsing.

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

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

Zero parameters and 100% schema coverage, so the baseline is 4 and there is nothing for the description to compensate for. It correctly implies no arguments are needed.

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

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

States a specific verb (List) and resource (every asset id the service scores) and enumerates the covered classes, so an agent can distinguish it from data-retrieval siblings like price_for or exposure_graph. The scope and output payload are 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?

Explicitly instructs the agent to 'Call it once to map your tickers to asset ids before using the other tools', which is a clear prerequisite workflow and distinguishes it from all siblings. No exclusions are given, but for a free lookup tool none are plausibly needed.

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), and the description adds real context beyond them: no API key needed, labels are 'best-effort' (so they may be wrong), flow tags are decoded (to_exchange = sell pressure, mint/burn = supply change), default threshold $1M, and $0.002/call pricing. This is unusually rich behavioral disclosure.

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?

Dense but front-loaded: purpose, data source, payload fields and pricing all land in the first two sentences. The flow-tag glossary is long but each entry carries semantic meaning an agent needs, so the length is defensible rather than 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?

No output schema exists, so the description carries the return-shape burden and does it: USD size, labels, flow tags, totals by flow, tx links. Combined with cost, default threshold and the alternative-tool pointer, nothing needed 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?

Schema coverage is 67%, and the description compensates by explaining the $1M default threshold and the chain scope ('Base and Ethereum'), which map to min_usd and chains. Only limit (default 25, max 100) is left unexplained by either source.

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 exactly what the tool returns: large USDC/USDT transfers on Base and Ethereum sourced from public explorers, with USD size, exchange labels and flow tags. It also names the sibling it is not (stablecoin_supply), so an agent can distinguish the two without opening a schema.

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

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

Gives an explicit use condition ('individual large stablecoin transfers') plus the routing rule for the alternative ('for total supply change use stablecoin_supply'). Coupled with the default threshold and per-call price, an agent knows both when to call it and what it costs.

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