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 new context: free, no API key, nothing signed or spent, and the failure modes (unknown symbol, unreachable upstream). 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-loaded one-line summary followed by clearly labelled Use when / Not for / Returns / Example blocks. The embedded example response is long but earns its place since no output schema exists; minor verbosity otherwise.

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

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

With no output schema, the description carries the return contract itself (headlines[] with title, url, sentiment, score, published_at) and even a concrete example payload. Combined with the source, cost and failure behavior, 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 description coverage is 100%, so both parameters (filter enum, currencies) are already documented in the schema. The description only echoes 'for any token' and shows a currencies example; it adds no format or default semantics beyond the schema. 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 ('Latest crypto news and community sentiment from r/CryptoCurrency') plus scope ('for any token'). The source and content type are explicit, distinguishing it from generic search tools at a glance.

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

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

Provides an explicit 'Use when' trigger and a 'Not for' clause that names three alternatives (web_search, url_reader, fear_greed_index) with the condition that selects each. 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, and the description adds materially beyond them: cost ('free'), auth posture ('no API key, nothing signed or spent'), and explicit failure behavior ('Fails with an error message on an unknown symbol or an unreachable upstream source'). That failure-mode disclosure is exactly the kind of operational context an agent needs before calling.

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

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

Front-loaded with the core purpose, then cleanly sectioned into Use when / Not for / Returns / Example / Cost and failure. Every section earns its place, though the 'Example response' field list partially repeats the 'Returns:' enumeration, which is minor redundancy.

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

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

There is no output schema, so the description correctly compensates by enumerating return fields (tvl, change_1h/1d/7d, chains[], category) and giving a concrete example response. Combined with the cost/auth/failure notes, 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 description coverage is 100% and the single parameter already documents 'Leave empty for top 10'. The description restates that behavior ('Returns top 10 or a specific protocol') but adds no new syntax, format, or constraint detail. Baseline 3 applies when the schema carries the parameter semantics.

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

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

States a specific verb+resource ('DeFi protocol Total Value Locked from DeFiLlama') and immediately defines scope: top 10 or a single named protocol. This is distinguishable from every sibling (yield_scanner, dune_query, token_market_data) 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?

Explicit 'Use when' clause names the two valid scenarios (single protocol TVL, comparing top protocols), and the 'Not for' clause routes to named alternatives (yield_scanner for best yield, dune_query for revenue/custom metrics). When-to-use and when-not-to-use are both present with the alternatives spelled out.

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, openWorld, idempotent, non-destructive), yet the description adds real value beyond them: fast_only semantics ('returns cached result instantly or raises immediately, never blocks'), cost ('free, no API key, nothing signed or spent'), and failure modes ('fails with an error message on an unknown symbol or unreachable upstream source').

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, then cleanly sectioned into Use when / Not for / Returns. The example response is long but earns its place because there is no output schema to convey the return shape.

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

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

With no output schema, the description compensates by specifying the return fields (rows[], columns[], row_count, generated_at) and a full example response. Nested query_parameters and all four params are covered, and cost/auth/failure behavior is stated.

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

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

Schema coverage is 100%, so the schema documents all four parameters, giving a baseline of 3. The description still adds meaning beyond the schema by explaining the latency/blocking contract of fast_only and its intended audience ('for live bots').

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?

Specific verb (Run) plus resource (Dune Analytics query) scoped to a query ID, and it explicitly routes away from siblings ('the other tools cover prices, derivatives, TVL and security without one'). An agent can distinguish it from defi_tvl, token_price, etc. 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?

Explicit 'Use when' and 'Not for' sections name the exact preconditions (you need a Dune query ID) and the disqualifiers (no query ID, need sub-second answers). It even redirects to the correct fallback ('set fast_only=true or use a cached tool').

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered structurally. The description adds genuinely useful context beyond that: free, no API key, nothing signed or spent, and error behavior on unreachable upstream. It loses a point because the advertised failure mode 'unknown symbol' is inconsistent with a schema that only exposes a limit parameter and accepts no symbol.

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, then cleanly sectioned into Use when / Not for / Returns / Example / Cost. Every sentence carries distinct information; the labeled structure makes scanning fast.

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-value burden and does so explicitly: value, value_classification, optional history, plus a concrete example response. Combined with auth and failure-mode notes, 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?

There is a single optional parameter (limit) already fully documented in the schema at 100% coverage, including default and max. The description adds no syntax or semantics beyond that, so the baseline 3 for high schema coverage 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 (Crypto Fear & Greed Index) with its scale semantics (0=extreme fear, 100=extreme greed) and optional history. It explicitly distinguishes itself from token-specific siblings (crypto_news, funding_rates), so an agent can route correctly 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?

Provides an explicit 'Use when' condition (gauge overall market sentiment) and a 'Not for' clause naming two concrete alternative tools for token-specific sentiment. This is the when/when-not/alternatives pattern at full strength.

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 safety, and the description adds value beyond them: cost ('free'), auth requirements ('no API key, nothing signed or spent'), data provenance ('live public data'), and failure modes ('fails with an error message on an unknown symbol or an unreachable upstream source').

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?

Strongly front-loaded and sectioned (purpose, use when, not for, returns, example, cost). The 'Returns' field list and the JSON example overlap somewhat, costing a little efficiency, but both are defensible given no output schema.

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

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

With no output schema, the description supplies the return shape (funding_rate_pct, annualized_rate_pct, sentiment per exchange) plus a concrete example and error behavior, and its annotations carry the safety profile. Nothing needed for 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?

The single 'asset' parameter is already fully documented in the schema (100% coverage, including the empty-string-for-all-majors behavior). The description adds no format, casing, or lookup guidance beyond that, so it meets the baseline without extending 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 verb+resource ('Get perpetual futures funding rates') and scopes it to three named exchanges, which immediately separates it from single-venue or generic market tools in the sibling list.

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

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

Explicit 'Use when' clause names the decision context (gauging leveraged sentiment / cost of holding a perp), and the 'Not for' clause routes to two exact siblings (open_interest, pre_trade_check) with the conditions that select them.

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 new context: free pricing, no API key, nothing signed or spent, and the failure mode (error on unknown symbol or unreachable upstream). It stops short of stating rate limits or caching freshness, which for a 'current' price feed would be the one remaining useful 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?

Front-loaded with the core purpose, then labeled sections (Use when / Not for / Returns / Example / Price) that make it skimmable. Slightly long for a zero-parameter read tool, and the inline example response duplicates the field list above it, but no sentence 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?

There is no output schema, so the description carries the return burden and does it well: named fields (slow_gwei, standard_gwei, fast_gwei, base_fee_gwei, confirmation times) plus a concrete example payload. Combined with the failure-mode and cost notes, 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?

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The description correctly avoids inventing parameter semantics for a no-arg 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 ('Get current Ethereum gas prices') plus the three tiers (slow, standard, fast), and explicitly scopes it to Ethereum mainnet only. An agent can distinguish it from the 19 siblings, including the one that overlaps (market_snapshot).

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

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

Uses an explicit 'Use when' / 'Not for' structure and names the alternative route (market_snapshot already includes standard gwei) with the condition that selects it. Nothing is left to inference about when to pick this tool.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds material beyond annotations: free public data, no API key, nothing signed or spent, and failure behavior on unknown symbols or unreachable upstream sources.

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

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

The description is front-loaded and organized into purpose, use cases, exclusions, returns, and example. It is somewhat verbose, repeating 'one call' and including an example response that largely restates the return fields, but no section is misleading or 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?

With no input schema and no output schema, the description carries the full documentation burden. It lists returned fields and provides an example response, plus safety and failure context, so an agent has enough information to invoke and interpret the 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?

The tool takes zero input parameters, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, a 4 is appropriate; 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?

The description states a specific combined resource: macro and crypto market snapshot in one call. It clearly distinguishes itself from siblings such as token_price, gas_tracker, and funding_rates. However, it advertises 'Fed rate, inflation proxy' while the listed returns do not include those fields, creating a minor mismatch.

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

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

The 'Use when' and 'Not for' sections explicitly define the intended context and name alternatives for single-asset depth and historical/time-series queries. An agent can route between this tool and token_price, gas_tracker, funding_rates, or dune_query without inference.

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

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

Annotations cover the safety profile (readOnly, non-destructive, idempotent, openWorld), and the description adds genuinely new context: cost ('free'), no API key, nothing signed or spent, and the specific failure mode (error on unknown symbol or unreachable upstream). That is real disclosure beyond structured fields.

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

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

Front-loaded with the core purpose and structured with clear labeled sections (Use when / Not for / Returns), which is efficient. However the example response is lengthy and the opening sentence's phrasing is partially repeated in the 'Use when' block, so it is slightly padded rather than maximally tight.

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

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

With no output schema, the description compensates by enumerating return fields (total_oi_usd, oi_change_1h_pct, oi_change_24h_pct, long_short_ratio, per-exchange breakdown) and giving a concrete example response. Combined with usage routing and failure modes, 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 there is a single optional parameter with a default of 'BTC', already fully documented in the schema. The description adds no syntax or format detail for the asset parameter, 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?

States a specific verb and resource (get total open interest in perpetual futures) plus supplementary fields (1h/24h change rates). It explicitly distinguishes itself from siblings funding_rates and pre_trade_check by naming what each is for, so an agent can separate 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?

Provides explicit 'Use when' and 'Not for' sections that name the alternative tools (funding_rates, pre_trade_check) and the conditions selecting each. It even articulates the combination pattern (rising OI + high funding = overcrowded), 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 readOnly/idempotent/openWorld, but the description adds substantive context beyond them: free pricing, no API key, nothing signed or spent, CEX-only constraint (not DEX), and explicit error behavior on unknown symbols or unreachable upstreams. This is well above the 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 purpose followed by clearly labelled 'Use when', 'Not for', 'Returns', and example blocks. Every section earns its place; length is justified by the coverage it provides.

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 fully specifies return fields, a concrete example response, cost/auth profile, and failure modes. An agent has everything needed to invoke and interpret this tool correctly.

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

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

Schema coverage is 100% and only one parameter exists, so the schema already documents 'asset'. The description only reinforces this via the example ('ETH'), adding no syntax or format detail beyond what the schema provides. 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 (Get) with precise resource and scope: real bid/ask depth and slippage at $10k/$50k/$250k notional from Binance and Bybit. Explicitly differentiates from siblings token_market_data (market cap/24h volume) and pre_trade_check (full pre-trade verdict).

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

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

Provides explicit when-to-use ('before sizing a position', 'before executing a large trade') and when-not-to-use clauses that name the correct alternative tools for each excluded case. 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?

Despite annotations already flagging non-read-only/open-world, the description discloses what annotations cannot: the $0.01 on-chain settlement, the required funded mainnet Stellar account in STELLAR_SECRET_KEY, no API key needed, and the fallback semantics (native assets report security n/a; unrecognized tokens read 'unknown' and cap the verdict at caution). These are real operational constraints, not restated hints.

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

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

Front-loaded with the one-line purpose, then clearly separated Use when / Not for / Returns / Example blocks. It is long and mildly repetitive (the $0.01 price is stated twice), but nearly every sentence carries routing, constraint, or output-shape 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 a complex multi-factor, paid, non-idempotent tool without an output schema by listing the return fields plus a full worked example response showing verdict, per-factor levels, and embedded raw components. An agent has enough to size inputs and interpret outputs 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 baseline is 3. The description goes further by explaining the token_address resolution behavior — auto-resolution for named major tokens, security 'n/a' for native assets, and the caution cap for unknown tokens — which materially affects how an agent should populate that field.

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 concrete verb+resource and a quoted user intent ('I want to long $X of SYMBOL — is now sane?'), then enumerates the four factors it fuses. It explicitly positions itself against siblings by naming funding_rates, open_interest, orderbook_depth and token_security as the raw components it replaces.

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?

Has explicit 'Use when' and 'Not for' sections: use when about to enter a position and want one combined verdict; not for a single raw factor (naming the four free alternatives) or when not sizing a position. This is the strongest form of routing guidance.

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

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

Annotations cover the safety profile (readOnlyHint false, openWorldHint true, non-idempotent, non-destructive), and the description still adds substantial context: the $0.01 on-chain settlement, the funded mainnet Stellar account requirement via STELLAR_SECRET_KEY, the hard max_spend enforcement across all downstream calls, and that no other API key is needed.

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?

Well front-loaded with labeled Use when / Not for / Returns sections, but the price-and-network information is stated twice (in the opening and the closing paragraph) and the inline example response is long. Efficient overall, with a small amount of redundancy.

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

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

With no output schema, the description carries the return contract itself, enumerating every returned field (session_id, max_spend, agent_address, gateway_url, tools_endpoint, created_at, receipt) plus a concrete example. An agent has everything needed to invoke and consume 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 coverage is 100%, so baseline is 3, but the description adds enforcement meaning to max_spend ('hard max_spend cap across all subsequent tool calls') and clarifies that the call returns the budget config and session_id. It modestly exceeds the schema's own wording.

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 ('Open a budget-capped agent session on AgentPay') and immediately scopes it with the entry-point role. No sibling among the data tools (token_price, gas_tracker, etc.) overlaps this session-management function, so the agent can discriminate it easily.

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 'Use when' and 'Not for' sections, and the exclusion names the concrete alternative (SDK quickstart() opening a free session) plus the selecting condition (spend cap / on-chain settlement). This is textbook routing guidance.

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

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

Despite annotations already declaring readOnlyHint/idempotentHint, the description adds substantial value beyond them: 'free', 'no API key', 'nothing signed or spent', and explicit failure behavior on unknown symbols or unreachable upstreams. This exceeds the annotation baseline by disclosing cost, auth, and error semantics.

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 capability, then structured with 'Use when' / 'Not for' / 'Returns' / 'Example response' / 'Price'. Every sentence earns its place; no repetition or filler.

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

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

For a read-only data tool with no output schema, the description provides return fields, an example response, cost/auth information, and failure modes—everything an agent needs to call it correctly and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by implying a token pair (token_a/token_b) and demonstrating the pair in the example response (ETH/USDC), which clarifies that both tokens are required and how they interact—beyond the schema's terse field descriptions.

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

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

The description states a specific verb+resource ('Get market cap, 24h volume, ATH, and price change for any token') and explicitly distinguishes itself from the sibling orderbook_depth and token_price. An agent can tell exactly what this tool returns 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?

Explicit 'Use when' and 'Not for' clauses name the alternative tools (token_price for spot price, orderbook_depth for pool liquidity) and the exact conditions that select them. 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 readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: it is free, needs no API key, nothing is signed or spent, and it fails with an error on an unknown symbol or unreachable upstream. It does not state rate limits or caching, which keeps it short of a 5.

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

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

Front-loaded with purpose, then structured 'Use when / Not for / Returns / Example' blocks. Every sentence earns its place; the example response and failure notes are compact and non-redundant.

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 enumerates return fields (price_usd, change_24h_pct, market_cap_usd, coin_id) and gives a concrete example response, plus error behavior. 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?

Only one parameter (symbol) at 100% schema description coverage, so the schema already documents it with an example (BTC, ETH, SOL). The description adds nothing about symbol format or case-sensitivity, matching the baseline 3 when the schema does the work.

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 ('Get the current USD price of any cryptocurrency token') and immediately names the sibling it is not, routing volume/ATH/pair quotes to token_market_data. An agent can distinguish it from token_market_data, market_snapshot and orderbook_depth 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?

Explicit 'Use when' (needs price, 24h change, market cap) and 'Not for' clauses that name the three alternative tools and the exact conditions selecting each. 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 read-only/idempotent/openWorld, and the description adds genuinely new context: cost ('free'), auth ('no API key, nothing signed or spent'), data provenance ('live public data'), and failure behavior ('errors on unknown symbol or unreachable upstream'). This goes well beyond the structured hints.

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

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

Front-loads the one-line purpose, then organizes guidelines, return fields, an example response, and cost/failure notes into scannable labeled blocks. No filler sentences; the example payload is high-value.

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

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

With no output schema, the description compensates by enumerating every returned field and giving a concrete example response, plus cost and error behavior. An agent has everything needed to decide and invoke correctly.

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

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

Schema description coverage is 100%, so both parameters (contract_address, chain with enum and default) are fully documented by the schema. The description only restates the chain restriction ('Ethereum and BSC contracts only'), adding little format or syntax 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 specific verb ('scan') and resource ('token contract') with the exact risk classes covered (honeypot, rug pull, security risks). It is immediately distinguishable from siblings like token_price and orderbook_depth, which it explicitly disclaims.

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

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

Provides explicit 'Use when' (checking a contract before trading/investing) and 'Not for' conditions, naming the alternative tools (orderbook_depth / token_price) for the excluded liquidity/price case, plus a native-coin exclusion and a chain limitation.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds value beyond them: no API key, cost is free, boilerplate-stripping behavior, and failure on unreachable upstream. The only blemish is a likely copy-paste artifact ('unknown symbol') that doesn't fit a URL reader.

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?

Well front-loaded with the core action first, then labeled Use when / Not for / Returns blocks. Mostly earns its place, though the 'Price: free' line and the stray 'unknown symbol' phrase add noise to an otherwise tight structure.

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 compensates by listing return fields (content, url, length, truncated) and giving a concrete example response. Combined with failure behavior 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?

Schema coverage is 100% and there is a single required URL parameter already documented in the schema. The description adds no URL format, scheme, or validation detail beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Convert any URL to clean, LLM-ready markdown') with concrete scope, and explicitly differentiates from the sibling web_search in the 'Not for' clause. An agent can distinguish this from web_search 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?

Provides explicit 'Use when' and 'Not for' sections, naming the alternative (web_search) and the conditions that select it (no URL yet, login-walled, JS-only rendering). This is textbook when/when-not/alternative guidance.

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

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

Goes well beyond annotations: settles $0.01 on-chain from STELLAR_SECRET_KEY, requires a funded mainnet Stellar account, is not read-only, uses live public data with no other API key, and explains the sybil-collapse behavior and return shape. Annotations only cover safety hints, so this description carries the real behavioral load and does so richly.

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 the use-when/not-for routing, which is good structure. However, it is dense and includes a full example response JSON inline, which is longer than needed for a 3-param tool and slightly buries the essential routing under illustrative bulk.

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 pricing, auth/wallet requirements, sybil behavior, return fields, and an example response despite no output schema. For a paid, non-read-only, open-world tool, this is complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions need/budget and chain filtering contextually but adds no syntax or enumeration details beyond the schema (e.g., no examples of chain values beyond what the schema already lists).

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, unusual verb+resource: a paid buyer-side trust oracle that sweeps the x402 marketplace, collapses sybil clusters, and returns one vetted recommendation. The quoted user-intent framing ('I need X, budget $Y — which x402 tool is real?') makes it immediately distinguishable from siblings like pre_trade_check or token_security.

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 'Use when' and 'Not for' sections name the alternatives: call the known AgentPay tool directly, or use the free keyless verified_route preview. The condition that selects this tool (about to pay an unknown x402 tool and want the real, used, non-sybil one under budget) is unambiguous.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description nonetheless adds real context the annotations cannot: it is free, requires no API key, nothing is signed or spent, and it fails with an error on unknown symbols or unreachable upstreams. It stops short of describing pagination or rate limits, but for a read-only public lookup this is strong.

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 purpose, then blocks for usage, return shape, example and cost. Every section earns its place, though the literal example response is somewhat verbose for a two-parameter lookup.

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 compensates by describing the return shape ('list of token balances (symbol, amount)') and giving a concrete example response. Combined with the explicit chain restriction and error behavior, 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 description coverage is 100%, so both parameters are already documented with the 0x…/G… format hints in the schema itself. The description usefully reinforces that no chains other than Ethereum and Stellar are supported, but adds little syntax beyond the schema, 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?

States a specific verb and resource ('Get the token balances for any Ethereum or Stellar wallet address') with the scope of chains bounded. It explicitly distinguishes itself from token_price/token_market_data and whale_activity, so an agent can select 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?

Provides a 'Use when' line and a 'Not for' line that names the specific alternative tools (token_price, token_market_data, whale_activity) and the condition that routes to each. Nothing about when-not-to-use 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 cover the safety profile (readOnlyHint, openWorldHint, idempotentHint), and the description adds real operational context: free, no API key, nothing signed or spent, and a stated failure mode. It also discloses that results include page content, not just links, which is behaviorally 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?

Well front-loaded and organized into Use when / Not for / Returns / Example sections. The example response and the 'Better than DIY' framing are mildly verbose but each section carries useful routing or format 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 correctly compensates by documenting the return fields (url, title, description, content; query; count) and giving a concrete example response. 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?

With a single parameter at 100% schema coverage, the schema already documents 'query'. The description implies the result count (top 5) but adds no syntax or format guidance for the query itself. 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?

States a specific verb (search) and resource (the web) with the exact result shape ('top 5 results with their full content as clean markdown'). It distinguishes itself from siblings by naming url_reader and crypto_news as the wrong choices for adjacent needs.

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 'Use when' and 'Not for' sections name the conditions that select this tool and route the agent to specific alternatives (url_reader when the URL is known, crypto_news for sentiment headlines). 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 real value beyond that: 'Ethereum ERC-20 transfers only' scopes the data source, and 'no API key, nothing signed or spent. Fails with an error message on an unknown symbol or an unreachable upstream source' discloses auth and failure behavior. Only the lack of rate-limit or freshness-window detail keeps 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?

Front-loaded purpose followed by scannable Use when / Not for / Returns / Example / Price blocks — every section is labeled and easy to parse. The full JSON example response is somewhat long, but it demonstrates the shape of large_transfers[] and is defensible for a tool with no output schema.

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

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

With no output schema, the description compensates by enumerating return fields (from, to, amount, usd_value, minutes_ago, total_volume_usd) and giving a concrete example. Combined with the Ethereum-only scope and documented failure modes, 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 description coverage is 100%, so both parameters are already documented in the schema, establishing a baseline of 3. The description's 'large wallet movements' hints at the min_usd threshold but never explains its default or units, so it adds essentially nothing over the schema.

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

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

States a specific verb and resource — 'Detect recent large wallet movements for a token' — with the parenthetical 'whale tracking' anchoring the concept. An agent can distinguish this from token_price, wallet_balance, or orderbook_depth 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?

Explicit 'Use when' and 'Not for' clauses name two concrete alternatives (wallet_balance for address holdings, orderbook_depth for exchange book size) and give the discriminating condition for each. This is exactly the when/when-not/alternatives structure that earns the top score.

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/non-destructive/open-world, and the description adds substantive context on top: cost ('free'), auth ('no API key, nothing signed or spent'), and failure behavior (error on unknown symbol or unreachable upstream). It also discloses the risk_level heuristic caveat, which is not visible in the schema.

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

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

Front-loaded with the core purpose, then cleanly labeled Use when/Not for/Returns/Example sections. The embedded example response is somewhat long, but it substitutes for the missing output schema, so it 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?

No output schema exists, so the description compensates by describing the return shape ('list of pools with protocol, apy, tvl_usd, chain, risk_level sorted by APY descending') and giving a concrete example. Failure modes and constraints are also covered, leaving nothing essential 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 (token, chain, min_tvl) are already documented in the schema. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource+scope ('Find best DeFi yield opportunities across protocols for a given token') and explicitly contrasts with the sibling defi_tvl, which handles TVL rather than pool APYs. An agent can distinguish it from related siblings without opening any schema.

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

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

Provides explicit 'Use when' and 'Not for' clauses naming the alternative tool (defi_tvl), plus a proactive prerequisite suggesting token_security before depositing. When-to-use, when-not-to-use, and the alternative are all covered.

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