SiteCheck Agent Intel & Dev

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

Goes far beyond the read-only/open-world annotations by disclosing the return contract (valid yes/no, error paths, sanitized value), unsupported keyword behavior (returns error instead of silently passing), and payment semantics including that failed calls are not charged.

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 operation, then packs supported keywords, return behavior, unsupported-feature behavior, and pricing into a compact block. The keyword list is long but earns its place by defining the validation boundary.

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?

Complete enough for an agent to call correctly: purpose, supported keyword set, return shape, limitations, and payment model are covered. The output schema exists, so return-value detail is supplemental rather than required, and no major gap remains.

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 input schema already documents that 'value' is any JSON and 'schema' is the JSON Schema. The description reinforces the schema context but adds no syntax, formatting, or parameter-specific meaning beyond the structured fields.

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: checks an agent's JSON output against a JSON Schema. It also names the supported draft and keyword set, distinguishing clearly what the tool validates.

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

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

Implies use for JSON Schema validation and explicitly lists which schema keywords are supported and which unsupported features will return an error. It does not name alternative sibling tools or when-not-to-use cases, but the supported/unsupported boundary 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?

Goes well beyond the readOnly/openWorld annotations: discloses the data source (Blockscout), that unverified contracts are reported rather than guessed, the epistemic caveat that a hit is not proof, and the exact pricing model ($0.002 USDC via x402, failed calls free). The cost/payment-auth disclosure is especially valuable for an agent deciding to call.

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

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

Front-loads what it does, then layers scope, exclusions, caveat and price in an order that mirrors the agent's decision process. Every clause (source, verified-only, no-guess, not-proof, pricing) carries distinct information with no waste.

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

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

An output schema exists, so return format is covered elsewhere; the description fully supplies scope, limitations, epistemic caveat and payment terms. Nothing an agent needs to call this correctly is missing for a one-param read tool.

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

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

Schema description coverage is 100% and the single 'address' param is fully documented in the schema. The description reinforces the Ethereum/verified constraint but adds no syntax or format detail beyond the structured field, so the 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 verb and narrow resource: static search of a VERIFIED contract's Solidity source for max-wallet, max-transaction and cooldown rules. The scope is precise enough to distinguish it from broad safety scorers, but it names no sibling (e.g., honeypot_trap_detector or token_composite_safety_score) directly.

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-not conditions: unverified contracts, bytecode-only and non-Ethereum chains are out of scope, and hits are 'a clue, not proof of a trap.' It stops short of naming which sibling to use instead for bytecode or cross-chain cases.

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

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

Beyond the readOnly/openWorld annotations, the description discloses the measurement protocol (three GET requests), the returned level semantics, a clear coverage limitation (single vantage point, no standalone TLS handshake timing), and the billing model ($0.001 USDC via x402, failed calls free). This is exactly the operational context an agent needs before spending money.

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 compact sentences, front-loaded with what is measured and what comes back, then limitations, then cost. Every clause carries decision-relevant information 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?

The tool is simple (one param, output schema present), and the description still covers measurement method, output shape, scope limits, and pricing. An agent has everything needed to call it and interpret the cost.

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, and the schema already documents it at 100% coverage ('Public https:// endpoint address'). The description adds no further constraints on the URL (e.g., scheme restrictions, redirect handling, private-address rejection), so it does not improve on the schema.

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

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

The description names a precise verb and resource (measure liveness and latency of one public HTTPS endpoint) and specifies the method: three GET requests returning statuses, response-header times, median/worst, and an UP/DEGRADED/DOWN level. It is highly specific, but it does not explicitly contrast itself with the closest sibling, agent_intel_x402_endpoint_health_vetting, so an agent must infer the boundary.

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

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

Usage is implied by the stated scope ('one location only', 'does not test other regions', 'does not measure the TLS handshake on its own'), which tells the agent what the tool will not do. However, there is no explicit when-to-use framing or named alternative (e.g., a TLS/cert tool or a multi-region check), so selection guidance is only partial.

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

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

Beyond the readOnly/openWorld annotations, it discloses pricing ($0.003 USDC via x402, failed calls not charged), a concrete failure mode (HISTORY_TOO_LONG), and a hard blind spot (cannot see Jito bundle metadata). These are exactly the operational traits an annotation 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?

The mechanism is front-loaded in the first sentence, followed by the interpretation, limitations, and pricing in a tight sequence with no filler. It is on the longer side but every clause carries decision-relevant 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 complex, paid, open-world on-chain analysis tool, the description covers mechanism, interpretation caveats, failure conditions, and cost. With an output schema present, return-value detail is not required, and nothing an agent needs to decide whether to call it 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 is a single parameter with 100% schema coverage that already documents the mint as a base58 address of 32–44 chars. The description only reconfirms that it operates on a token mint and adds no format or edge-case detail 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?

The description states a specific mechanism: inspecting the first Solana slot where a token mint appears and counting distinct fee payers. The resource (token mint), the data source (public RPC), and the output signal (bundle-sniping risk) are all concrete, so an agent can distinguish this from the many token-safety siblings 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 clear interpretive guidance ('a signal, not proof') and states the operating limits up front (HISTORY_TOO_LONG for long histories, no Jito bundle metadata visibility). It stops short of naming an explicit alternative sibling or a 'use this instead of X when' rule, so it is clear context rather than full when/when-not routing.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the cost model ($0.003 USDC per successful call), the payment rails (x402 on Base, Solana or Arc), and that failed calls are not charged — critical context for a paid tool. It also proactively discloses the analytical limitation (no scam/exploit template database), preventing over-reliance on the result.

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 what is computed and the output scale, then scope limit, then price. Four sentences, all earning their place, though the metric parentheticals make it denser than typical; minor tightening possible without losing the pricing detail.

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?

An output schema exists and return values are not over-explained, yet the description still names the score range and label set. For a read-only, two-parameter, paid tool it covers computation, scope limits, and billing — everything 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 100% and both parameters are self-documented as 40-hex addresses, so baseline is 3. The description adds real semantics the schema lacks: the inputs must be Ethereum contracts' runtime bytecode targets, i.e. deployed contract addresses rather than arbitrary hex or EOAs, which is a meaningful constraint.

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 (compares) plus the exact resource (runtime bytecode of two named Ethereum contracts) and enumerates both metrics used (Jaccard on PUSH4 selectors, cosine on opcode frequencies) and the output shape (0-1 score with SIMILAR/PARTIAL/DIFFERENT). This is clearly distinguishable from nearby siblings such as smart_contract_linter_audit or token_composite_safety_score, which do not do pairwise bytecode comparison.

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 a firm usage boundary — 'compares two addresses only' and 'cannot say a contract is a known clone' — which tells the agent when to route elsewhere (e.g. known_scams_blacklist_db) for template matching. It does not name that alternative explicitly, so the exclusion is clear but the redirect 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=true and openWorldHint=true, so safety is covered. The description supplies real added context: the label source (brianleect/etherscan-labels on GitHub), that labels are community-made and may be stale, the 10-wallet cap, and x402 pricing of $0.002 USDC per successful call with failures not charged. That is meaningful disclosure beyond annotations, though it says nothing about latency or freshness of the balance snapshot itself.

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 its scope limits before the commercial terms. Dense and nearly waste-free, though the GitHub owner/repo path is more detail than an agent needs to select or call the tool.

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

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

An output schema exists, so return-format explanation is unnecessary; the description still covers data source, sampling limits, label reliability, and cost model. Nothing an agent needs in order to decide whether and how to call it 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 sole `exchange` parameter is already documented; the baseline would be 3. The description earns above baseline by naming the three accepted values and tying them to the labeling source, confirming what "exchange" filters on and warning that matching is label-dependent rather than exhaustive.

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 concretely what is returned: a native-ETH balance snapshot for up to 10 wallets labeled Binance/Coinbase/OKX. It also carves out scope against lookalikes (no token balances, no inflow/outflow history, not total reserves), which distinguishes it from siblings like agent_intel_whale_transaction_monitor and agent_intel_smart_money_inflow_tracker, though those tools are not named.

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 negative scoping ("snapshot of a sample, not total exchange reserves: no token balances, no inflow or outflow history") implies when the tool fits, but there is no explicit "use when" statement or named alternative for full reserve or flow data. Usage must be inferred from the limitations.

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 say readOnly and openWorld; the description adds substantial operational context beyond them: the $0.001 USDC per successful call price via x402 across Base/Solana/Arc, that failed calls are not charged, and that unresolvable identifiers return not_found rather than erroring. It also discloses an asymmetry in the output (authors only for DOI and arXiv) and that ISBNs are checksum-validated first.

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 what it does and which registries it hits; pricing and payment detail are trailed at the end where they belong. It is a single dense paragraph using semicolons, so it stays compact but is slightly harder to scan than a bulleted or multi-sentence layout.

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

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

For a paid, multi-registry verification tool this covers everything an agent needs before calling: input formats and cap, per-type registry routing, what a success and a not_found look like, output artifacts (BibTeX, APA string, title/year/venue) and the billing model. An output schema exists, so the return-value detail is bonus rather than obligation.

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 already documented, so the baseline is 3. The description still earns credit by sharpening the accepted formats (ISBN-10/13 explicitly, the arXiv:1706.03762 form) and noting checksum pre-validation, which tells the agent malformed ISBNs are rejected before any registry 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 verb (checks/verifies) and resource (references) plus the exact external registries used per identifier type: Crossref for DOI, arXiv API, Open Library for ISBN. The scope ('up to 5 references') and the verification target make it unmistakable against any sibling, none of which do bibliographic identifier resolution.

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

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

Usage context is clear: pass DOIs, arXiv ids or ISBNs and get verified metadata back, which implies the when-to-use case (validating citations in a bibliography). The batch bound of 5 is stated, giving a practical constraint. It stops short of naming alternatives or exclusions (e.g. when to prefer a claim-checking sibling), so no 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 only declare readOnly/openWorld, which is a low bar; the description goes well beyond by disclosing the paid-metering model: $0.002 in USDC per successful call, payable via x402 on Base, Solana or Arc, with failed calls not charged. That billing-on-failure detail is exactly the kind of behavioral trait an agent needs before calling, and it is not derivable from any structured field.

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: purpose first, scope exclusions second, cost model last. Every clause carries information an agent would otherwise have to guess, and there is no padding or restatement of the tool name.

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

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

With an output schema present and 100% parameter coverage, the description only needs to carry scope, exclusions and cost — all three are covered. 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?

Schema coverage is already 100%, so the baseline is 3, but the description earns more by clarifying that matching runs against recall date and description text and, for FDA, the reason-for-recall field. It still doesn't clarify whether `days` applies to both sources or only CPSC, which the schema hints at but leaves ambiguous.

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

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

The description states a specific verb and resource ('Recent US recalls matching a keyword') and then itemizes the exact data sources it draws from: CPSC consumer-product recalls and FDA food enforcement reports. It explicitly names what is out of scope (NHTSA vehicle, FDA drug/device), so an agent can tell at a glance whether this tool covers its need.

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 exclusion list ('Vehicle (NHTSA) and FDA drug/device recalls are not included') gives clear negative routing guidance, and the keyword-driven scope is stated up front. It does not name an alternative tool to use for the excluded recall classes, so it stops short of full when/when-not routing.

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

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

Annotations only cover readOnlyHint and openWorldHint; the description adds what actually happens (three outbound GETs from a third-party service to a live public target), the exact probes sent, and a full cost model: $0.001 USDC per successful call via x402 on Base/Solana/Arc with failed calls not charged. Cost and failure-billing behavior are exactly the kind of context 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 is front-loaded in the first clause, the scope limits follow immediately, and the pricing/billing note closes it. Every sentence carries either scope, a limitation, or a cost fact — nothing is padding.

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

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

For a single-parameter, read-only probe with an output schema already defined, the description supplies everything needed to decide and call correctly: what is tested, what is explicitly not tested, that it hits a live public endpoint, and the billing terms.

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?

One required parameter at 100% schema coverage, so the schema already documents 'url' as a public https:// endpoint. The description restates the public-HTTPS constraint but adds no format, normalization, or validation detail 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?

States a specific verb/resource (CORS check) with the exact mechanism: three GET requests using a made-up origin, the null origin and no origin, reporting echo/null/wildcard/credentials. This is precise enough to distinguish it from siblings like agent_intel_ssl_certificate_transparency, agent_intel_subdomain_takeover_monitor and agent_intel_x402_endpoint_health_vetting 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 scopes the tool: 'Only reads response headers of GET requests; it does not test preflight, methods or authentication,' which tells the agent when this tool is insufficient and a deeper/other audit is needed. It stops short of naming a specific alternative sibling, so it stays at 4 rather than 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely non-obvious operational facts beyond them: a $0.002 USDC cost per successful call, the x402 payment rails (Base, Solana, Arc), and that failed calls are not charged. That pricing/payment model is exactly the kind of detail an agent needs before invoking a paid endpoint.

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

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

One dense paragraph that front-loads what is returned, then restrictions, then price. Every sentence carries information, though the restriction and pricing clauses are run together in a way that is slightly hard to scan as separate concerns.

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?

An output schema exists, so return values need no prose, and the description covers scope, asset, exclusions, and cost. The only mild gap is that it doesn't say what happens for unsupported chain pairs (error vs. empty result), which matters for a paid, rate-anchored 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 the 'from' parameter even enumerates chain IDs, so the baseline is 3. The description earns above that by adding a constraint not in the schema: the pair must be one the Across limits API accepts, and the asset is fixed to USDC so no token parameter exists.

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 (Across bridge limits for USDC between two chains) and enumerates exactly the three values returned: max instant-fill, max deposit, min deposit. The 'Across only (not Stargate, Hop or CCTP)' clause separates it cleanly from sibling bridge/DeFi tools such as agent_intel_crosschain_gas_priority_fee and agent_intel_dex_depth_slippage_calculator.

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

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

Explicit eligibility conditions are given: Across only, USDC only, and the chain pair must be one the Across limits API accepts. It does not name a concrete alternative tool to use instead for other bridges or tokens, but the exclusion list ('not Stargate, Hop or CCTP') conveys when this tool is the wrong choice.

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 readOnly and openWorld; the description adds genuinely new operational facts: exact price ($0.001 USDC per successful call), payment rail (x402 on Base, Solana or Arc), and that failed calls are not charged. It also discloses the model's accuracy limit, which is behaviorally important for interpreting results.

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

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

Four compact sentences, each carrying distinct information (outputs, coverage, method, exclusions, pricing). Front-loaded with what is returned and for which chains. Slightly dense with parentheticals, but nothing is wasteful.

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

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

Output schema exists so return shape needs no description; the description covers chains, defaults, forecast limitations, cost, and payment mechanics. For a single-optional-parameter priced data endpoint, an agent has everything needed to call it and budget for 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% and the single `chain` parameter already documents 'ethereum, base or arbitrum (default ethereum)'. The description restates the same enumeration and the Solana exclusion but adds no format or casing guidance beyond the schema, so this is baseline territory.

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 (base fee and priority-fee percentiles at 10th/50th/99th) and the exact chains covered, plus the projection method (EIP-1559, next block from last block fullness). An agent can immediately tell this is a gas-fee oracle rather than any other onchain metric tool 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?

Explicitly bounds scope by excluding Solana ('Solana is not included here') and clarifies that forecasts are a one-block projection, not a congestion model — effectively telling the agent when not to rely on it for trend analysis. It does not name an alternative sibling for Solana gas data, so it stops short of full routing guidance.

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

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

Annotations only declare readOnlyHint/openWorldHint; the description adds substantive behavior beyond them: the pricing model ($0.005 USDC per successful call), the payment rails (x402 on Base, Solana or Arc), and the important detail that failed calls are not charged. It also discloses that no synthesis happens, setting expectations for output 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?

Three tight sentences, front-loaded with what the tool does, followed by the key caveat (no synthesis) and then payment terms. No filler or restatement of the title.

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 full schema coverage, an output schema, and readOnly annotations, the description covers everything material: source scope, return content, absence of synthesis, and billing behavior. Nothing an agent needs to decide or invoke 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 both parameters (query with a 2-200 char bound, limit with a 1-5 range and default) are already documented. The description reinforces that the query can be a research question or keywords and that results are the 'top' articles, but adds no syntax or formatting detail 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?

The description gives a precise verb and resource ('searches English Wikipedia'), states the exact return payload (top articles with summary text, description, last edit time), and explicitly scopes out the open web, which separates it from web_search_turbo. The role label 'Research starter' plus 'No AI synthesis' further distinguishes it from the synthesis-style siblings.

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

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

It states the operative context clearly: use this when the caller wants raw sources to read and combine rather than an AI-composed answer, and it rules out general web search. It does not name a specific alternative sibling (e.g. fact_brief_synthesizer) to route to when synthesis is wanted, so the when-not 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 only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the paid x402 model ($0.002 USDC per successful call across Base/Solana/Arc), that failed calls are free, the upstream data source, the exact per-pool fields returned, and a caveat about missing audit data. This is exactly the extra behavioral context a paid read tool needs.

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 sentences, each carrying distinct payload: what it ranks and returns, what it deliberately cannot tell you, and what it costs. The most decision-relevant fact (APY ranking, not safety) is placed prominently before the price detail.

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

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

Given an existing output schema, the description still summarizes returned fields, and it covers the two things structured fields cannot: the upstream data source's limitations and the payment/billing behavior. Nothing an agent needs in order to call it correctly or explain the charge 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 the schema already documents all five parameters including defaults for chain, limit, maxApyPct and minTvlUsd. The description restates the filtering dimensions but adds no syntax or format guidance 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 verb and resource ('Ranks DeFi pools by total APY'), names the underlying source (DefiLlama public yields), and enumerates the output fields. An agent can distinguish it from neighbors like dex_depth_slippage_calculator or stablecoin_peg_integrity_radar 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?

The description establishes scope ('filtered by chain, minimum TVL and optional stablecoin-only') and a clear exclusion ('Ranking is by APY, not by safety: there is no audit or exploit-history score'), which is a meaningful when-not-to-rely signal. However, it never names an alternative tool to use for safety/audit questions, so routing is left to inference.

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

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

Annotations cover safety (readOnlyHint) and world scope, and the description adds substantial behavior beyond them: the data source, the 50-transaction page limit and its consequence, and the paid-call model ($0.003 USDC via x402, failed calls not charged). These are exactly the operational facts an agent needs before invoking.

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?

Four dense sentences, each carrying distinct information (scope, limits, exclusions, price), front-loaded with the core purpose. The pricing clause is long but materially relevant to invocation decisions rather than filler.

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

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

Output schema exists, so return values need no explanation. Given a single-parameter, read-only tool, the description covers scope, pagination limits, exclusions, and billing—everything an agent needs to call it correctly and understand its limits.

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?

One parameter with 100% schema description coverage, so the schema already documents the 0x address format. The description adds only the contextual framing that the address identifies a deployer wallet, which is mild but useful; no additional parameter detail is 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+resource: contracts created by a deployer wallet on Ethereum, with the exact fields returned (creation hash, time, new contract address) and the data source (Blockscout public API). It also explicitly rules out related-but-different analyses (rug-pull, abandoned-pool, liquidity history), separating it from siblings like liquidity_lock_inspector and token_composite_safety_score.

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

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

Gives a clear context of use plus explicit exclusions ('No rug-pull or abandoned-pool judgement: liquidity history is not included') and a coverage caveat ('older launches are missing'). It stops short of naming a specific alternative tool to use when the deployer history is insufficient, so it is clear but not fully routing.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description goes well beyond that: it discloses the external data dependency, the pricing model ($0.002 in USDC via x402 on Base/Solana/Arc), and crucially that failed calls are not charged. The accuracy caveat by pool type is behavioral context an agent cannot get 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?

Front-loads the core purpose and model, then the exactness caveats, then cost. The final pricing sentence is long and carries multiple facts (currency, chains, failure billing), but every clause serves a purpose for an agent deciding whether to call.

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?

An output schema exists so return values needn't be explained; parameters are fully described in the schema. The description supplies the missing context an agent needs — data source, model assumptions, accuracy limits, exclusions, and pay-per-call cost — so nothing material 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%, so pair, side, chain, amount, feePct and slippagePct are already documented in the schema. The description's only param-relevant remark is 'with a fee', which does not add semantics beyond the existing feePct definition, 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 computation (estimated output, price impact, minimum output) on a specific resource (one DEX pair), and names the model (constant-product x*y=k with fee) and data source (DexScreener reserves). It also scopes validity, distinguishing exact pools (Aerodrome volatile, Uniswap V2) from approximations (v3/v4) and an excluded venue (Raydium).

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 conditions on when results are trustworthy (constant-product pools) versus approximate (concentrated liquidity) and an explicit exclusion (Raydium is not covered). It stops short of naming a sibling tool to use instead for those excluded cases, but the applicability guidance is otherwise 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 only say readOnly + openWorld; the description goes well beyond that by disclosing the underlying data source (Cloudflare 1.1.1.1 DoH), an important limitation (Cloudflare validates, this tool does not walk the chain to the root), and the x402 payment model with cost per successful call and no charge on failure. Those are exactly the operational facts an agent needs before invoking a paid, third-party-dependent lookup.

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 sentences, each doing distinct work: what is returned, how it is (and is not) validated, and what it costs. The most decision-relevant constraint — the chain-walk caveat — is placed immediately after the return description rather than buried.

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?

An output schema exists, so return values need not be explained in prose, and the remaining ambiguity (data source, validation depth, billing behaviour on failure) is fully covered. For a single-parameter read tool with annotations and an output schema, 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?

One required parameter with 100% schema description coverage, so the schema already carries the semantics. The description's mention that a URL is reduced to its host merely restates what the schema property says, adding no new parsing or formatting detail. 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?

The description states a precise verb+resource ("DNSSEC status for a domain") and enumerates exactly what comes back: AD flag, DS records in the parent zone, DNSKEY records with key-signing keys. It does not name or distinguish itself from near-neighbours such as agent_intel_ssl_certificate_transparency or agent_intel_domain_authority_credibility, so an agent must infer the difference from the resource name alone.

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

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

Usage is implied by the subject matter — a caller looking for DNSSEC validation will recognise it — but there is no explicit "use this when..." statement, no exclusions, and no routing to sibling lookup tools (SSL CT, domain authority, typosquat radar). The pricing/payment note is the only practical precondition disclosed.

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 say readOnly and openWorld; the description adds materially important behavior: a $0.002 USDC charge per successful call via x402 on Base/Solana/Arc, and that failed calls are not charged. That payment/failure policy is exactly the kind of context annotations cannot convey. It stops short of describing latency, rate limits, 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?

Front-loaded with what is returned and how it is paid for, which is good. However, the parenthetical justification of missing data ('Tranco rank API needs a key; DNS-over-HTTPS was unreachable from the test network') is internal-sounding filler that does not help the agent decide or invoke.

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?

An output schema exists so return values need not be explained, and the description covers the source, the capability boundary, and the payment model. With one simple string parameter, an agent has enough to call it correctly; only the absence of explicit sibling routing 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?

One parameter with 100% schema description coverage, including the useful note that a full URL is accepted and reduced to its host. The description adds nothing about the domain parameter, so the baseline 3 applies since the schema carries the 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?

Names a specific resource and source (registration facts from the public RDAP directory) and enumerates the returned fields (registration date, age, expiry, registrar, lock status). It also actively corrects the misleading tool name by stating there is no authority score, backlink or spam index, which distinguishes it from what an agent might infer from 'authority_credibility'. It does not, however, name any sibling tool it competes with.

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

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

Usage is only implied — an agent can infer this is for domain age/registration checks, and the description tells it when the tool will NOT answer (no authority, backlink or spam data). But no explicit when-to-use condition or named alternative (e.g. DNSSEC validator, typosquat radar) is given.

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

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

Beyond the readOnlyHint annotation, the description discloses publication cadence, data freshness (daily reference, not live), the approximate size of the currency list (~30), and full pricing details ($0.001 USDC per successful call via x402, with failed calls not charged). These are material behavioral traits an agent needs before invoking the tool.

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

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

The description is four sentences, front-loaded with what the tool provides and its cadence, followed by the nature of the data, the list size, and pricing. Every sentence adds necessary information with 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 simple read-only data tool with three optional parameters and an output schema, the description covers the source, update frequency, data limitations, currency list size, and payment model. Nothing essential 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?

Schema description coverage is 100%, so the input schema already documents the 'to', 'from', and 'amount' parameters completely. The description adds limited meaning beyond the schema, mainly noting that conversion is between two listed currencies and that the list has about 30 currencies. Baseline 3 is appropriate when the schema handles parameter semantics.

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

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

The description states a specific verb and resource: it provides European Central Bank euro reference rates and an optional currency conversion. The scope (about 30 currencies, daily reference, not live market quote) is explicit, making it easy to distinguish from any live-market 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?

The description gives clear context for when to use it: rates are the ECB's daily reference published once per working day around 16:00 CET, and it explicitly says these are not live market quotes. It does not name an alternative tool, but the timing and nature of the data make the appropriate use case 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?

Goes well beyond the readOnlyHint/openWorldHint annotations: discloses the 5-number batch cap, that some member states withhold names/addresses, that VIES can be down for an entire country at a time, and the exact billing model ($0.002 USDC per successful call via x402 on Base/Solana/Arc, failures uncharged). For a paid external call, this is precisely the context an agent needs before invoking.

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 action and scope in the first clause, then layers caveats and pricing in a tight, waste-free sequence. Every sentence carries decision-relevant information; nothing is padding.

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

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

An output schema already covers return shape, so the description need only add what structured fields can't: batch limit, partial-data member states, per-country outages, and cost/failure billing. All of those are present, making the definition complete for a single-parameter paid 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 100% and the single parameter already documents the comma-separated, 2-letter-country-code format. The description only reinforces this with an example ('DE143208032'); it adds format-adjacent value but no new semantics 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 verb and resource: checks up to 5 EU VAT numbers against the European Commission's VIES service, and enumerates the returns (valid yes/no, name, address, member-state error). No sibling in the catalog shares this domain, so an agent can identify it immediately without ambiguity.

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

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

Usage context is implied by the batch-limit phrasing ('up to 5') and the VIES framing, but the description never states when to choose this over alternatives (e.g. a single-number lookup or the LEI registry) or any prerequisites such as needing a funded x402 wallet before calling. Adequate but leaves routing to inference.

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

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

Beyond the readOnly/openWorld annotations, the description discloses cost ($0.002 USDC per successful call), payment mechanism (x402 on Base/Solana/Arc), and the important billing behavior that failed calls are not charged. It also states the maximum entity count and return fields, adding substantial operational context.

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

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

The definition is front-loaded with the core action and then layers scope, exclusions, return fields, and pricing without wasted text. Each clause contributes either selection guidance or operational transparency.

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 lookup tool with full schema coverage, annotations, and an output schema, the description supplies the remaining decision-critical context: what it does, what it explicitly does not do, what it returns, and how billing works. Nothing essential for correct invocation appears missing.

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

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

Schema coverage is 100%, so the statement parameter is already documented with its 10–1000 character range. The description adds useful semantic detail by explaining that the tool searches for up to three capitalised names or phrases and ignores numbers and dates, going beyond the schema's basic type/length description.

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

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

The description gives a specific verb and resource: it extracts up to three capitalised names/phrases from a statement and resolves each against Wikidata. It also explicitly distinguishes the output and scope, including the clarifying limit that it confirms entity existence rather than judging claim truth.

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

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

The description states clear when-not conditions: it does not judge whether a claim is true and does not find numbers or dates. It does not explicitly name alternative tools such as hallucination_claim_checker or web_search_turbo, so the routing guidance is strong but not fully comparative.

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 readOnlyHint/openWorldHint annotations: discloses a per-call price ($0.002 USDC via x402), the accepted payment chains (Base, Solana, Arc), and that failed calls are not charged. It also bounds output cardinality (up to 5 matches) and flags the parent-entity gap, which prevents false assumptions about graph traversal.

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?

One dense sentence plus a caveat and a pricing note — front-loaded with purpose, then limits, then cost. Every clause carries information; it is only slightly overpacked, which is acceptable for a paid external-data tool.

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

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

An output schema exists so return values need not be detailed, yet the field list is a helpful preview. Combined with the payment model, match cap, and the parent-expansion caveat, an agent has everything required 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 the baseline is 3; the description adds the mutual-exclusivity relationship between the two params and reinforces the LEI length constraint. It does not repeat the 3-100 character bound for name, but nothing is left ambiguous.

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

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

States a specific verb and resource ('LEI records from GLEIF's public database') and enumerates both access modes: name search returning up to 5 matches, or exact lookup by 20-character LEI. No sibling overlaps with this topic, and the agent can tell exactly what data comes back (legal name, country, city, entity and registration status).

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?

Makes the two operating modes explicit and implies they are alternatives ('or leave out and use lei' per schema). It also sets expectations about scope by noting parent companies are not expanded and would require a second request. What's missing is any statement of when to prefer this tool over an adjacent lookup (e.g. sanctions preflight or VAT validation), but no exclusions are needed here.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the material facts an agent cannot infer: a $0.001 USDC charge per successful call, the x402 payment rails (Base, Solana, Arc), and the crucial detail that failed calls are not billed. It also discloses coverage restrictions and explicitly names what is NOT returned, which prevents false expectations.

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?

Four tight sentences, front-loaded with the verb and resource, then coverage, then exclusions, then price. The duplicated ISO examples are minor waste, and the clause 'since no free source for them was used' is justification rather than operational information, but neither is costly.

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 lookup with an output schema, an existing schema that fully documents inputs, and read-only annotations, the description covers everything else an agent needs: coverage limits, excluded output fields, data source, and the paid-call economics including the no-charge-on-failure guarantee. Nothing material 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 parameters documented including ISO examples and the 2–12 character postal-code range. The description repeats the same ISO examples ('US, DE, TR, GB') but adds no format, normalization, or edge-case guidance 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 (resolves) and resource (postal code in one country) and enumerates exactly what is returned: place names, state/province, latitude and longitude. The upstream source (Zippopotam.us) is named, so an agent knows precisely what data lineage to expect and can distinguish it from any sibling in this large, unrelated tool set.

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 scopes applicability with 'Covers only the countries that service publishes' and rules out use for time zone or administrative municipality lookups. That is strong negative guidance, but there is no explicit statement of when to reach for this versus a geocoding alternative (none exists among siblings), so it stops short of the top band.

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 say readOnly/openWorld; the description adds the real behavioral detail an agent needs: the 5-capitalised-name cap, the per-entity found/not-found result with Wikidata ID, the separate year-sentence listing, and the x402 payment model ($0.003 USDC on Base/Solana/Arc, failed calls not charged). The charge/no-charge asymmetry is exactly the kind of cost context annotations cannot convey.

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

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

Two sentences, front-loaded with the core behavior and the limitation before cost. The final payment sentence is dense (three chains, two price conditions) but every clause carries operational value; no filler to cut.

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-input read-only check with an existing output schema, nothing an agent needs is missing: input shape, extraction limit, result semantics, known limitation, and billing behavior are all present. Return-value detail is partly redundant with the output schema but harmless.

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 at 100% schema coverage, so the schema already documents 'text' as the model answer with a 10–5000 char range. The description adds meaning beyond it by clarifying that only capitalised names (max 5) are extracted from that text, which tells the agent how to shape its input.

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 (checks), a specific resource (named entities in an AI answer) and the exact backing source (Wikidata), plus the output shape (found/not-found with Wikidata ID and description). An agent can tell this apart from citation_verifier or fact_brief_synthesizer 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?

Explicitly delimits scope: 'It checks that entities exist, not that claims about them are true, so a found entity can still have a wrong fact.' That tells the agent when this tool is and is not sufficient, plus the 5-name ceiling. It stops short of naming an alternative sibling for the fact-truth case, so not a 5.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses return format (SVG plus base64), version and capacity limits, 400 behavior on overlength text, payment method and price, and that failed calls are not charged. This is substantial operational 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?

Front-loads the core action and compactly includes only operationally relevant details: format, limits, return value, error behavior, and price. There is no filler.

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

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

With an output schema, full parameter description coverage, and safety annotations, the description supplies enough for correct invocation. Capacity limits, failure behavior, and payment terms are all present.

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, but the description adds exact byte capacities per error-correction level (17/14/11/7), which the schema only references generically. It does not describe scale, but the schema already fully covers that 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 verb and resource: makes a QR code as scalable SVG, pinned to 21x21 modules and version 1. It also gives exact capacity limits, so an agent knows precisely what this tool produces.

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

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

Provides clear when-not constraints: larger versions are unsupported and longer text returns 400, with exact byte caps by EC level. It stops short of naming alternatives, though no direct QR-code sibling appears in the list.

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 cover readOnly/openWorld; the description adds genuinely non-obvious behavior: $0.002 USDC per successful call, x402 payment across Base/Solana/Arc, and failed calls are free. It also discloses the upstream data ceiling (GoPlus top-10 only), which caps what the tool can answer — an important behavioral caveat.

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 metric list, then limits, then pricing — logical ordering with no filler. The parenthetical chain list is mildly redundant with the schema but serves as a quick scan aid.

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

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

With an output schema present, the description need not explain return shapes, yet it summarizes them anyway; parameters are fully covered by the schema, and cost, payment rail, billing behavior, and data-source limits are all disclosed. An agent has everything needed 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% and both parameters (chain enum values, 0x address format, ethereum default) are already documented in the schema. The description restates the supported chains but adds no syntax or semantics beyond what the schema provides, 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?

The description names the resource (holder concentration for an EVM token) and enumerates exactly what it returns: top-1/3/10 supply share, total holder count, and contract share of the top 10. It does not steer the agent away from related siblings such as anti_whale_limit_detector or token_composite_safety_score, so it stops short of a 5.

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

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

Usage is implied by the metric list and the EVM-only scope, and the 'top-20 view and funding-source clustering are NOT provided' line functions as a partial when-not. However, no alternative tool is named for those use cases, so the agent must infer routing on its own.

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 readOnlyHint/openWorldHint annotations by disclosing data provenance (GoPlus simulated buy/sell) and its key limitation that the tool performs no simulation of its own. It also discloses cost ($0.003 USDC per successful call), the x402 payment rails, and that failed calls are not charged — real behavioral context. It does not mention rate limits or failure/timeout behavior, 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?

Three tight sentences: purpose and returned flags first, the provenance/limitation caveat second, pricing last. No filler, and the most decision-relevant content is front-loaded.

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

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

With an output schema present and only two params (one required), the description covers what is needed to select and call it: source, scope, chains, native-simulation caveat, and cost. The only gap is operational detail (rate limits, error/charging edge cases) that would help an agent decide whether to retry or budget calls.

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 the chain enum-in-prose and the 0x address format are already documented in the schema. The description's parenthetical chain list merely restates that, adding no syntax, default, or validation detail beyond the structured fields — baseline 3.

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 ('Trap flags for an EVM token') and enumerates the exact checks returned (honeypot, taxes, blacklist, pausable, hidden owner, mintable, anti-whale). It implicitly separates itself from broader siblings like token_composite_safety_score or token_verdict_engine via the 'reports GoPlus's flags; runs no simulation of its own' line, but never names those siblings explicitly.

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

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

Usage context is implied by the listed signals and the EVM chain set, but there is no explicit 'use this when X, use token_verdict_engine/composite_safety_score instead when Y'. No exclusions, no prerequisites beyond needing a contract address.

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 readOnly and openWorld; the description adds real operational context beyond them: a 500 KB ceiling, explicit stripping of scripts/styles/nav/footers/forms/comments, table flattening to text, and the baseUrl dependency for absolute links. It also discloses the $0.001 x402 charge and that failed calls are free – pricing and failure semantics the annotations cannot convey. It does not describe output shape, but an output schema exists.

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

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

The core transformation and its element list come first, then behavioural caveats, then cost last. Dense but every clause carries information an agent needs – 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?

For a two-parameter, read-only converter with a full output schema, the description covers input limits, transformation semantics, link resolution, and billing. 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 100%, so the baseline is 3; the description earns above that by explaining the consequence of baseUrl (relative links become absolute) and restating the 500 KB input bound in human units. That clarifies intent behind both parameters rather than merely echoing their types.

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 transformation (raw HTML in, GitHub-flavoured Markdown out) and enumerates exactly which elements survive and which are stripped. The phrase 'raw HTML you send' implicitly separates it from fetch-based siblings like reader_markdown_extract, so an agent can pick 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?

The description makes the trigger condition clear: you use this when you already hold the HTML, and you must supply baseUrl if relative links matter. It stops short of naming an alternative tool or stating when not to use it, so no explicit 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?

Goes well beyond the readOnly/openWorld annotations: discloses the external dependency on OpenIBAN's directory, that results may be missing for some banks, the checksum-vs-account-existence limitation, the $0.001 USDC cost via x402 on three chains, and that failed calls are not charged. This is exactly the billing and reliability context an agent needs before calling a paid endpoint.

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

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

Three sentences with no filler: validation mechanics first, lookup caveats second, pricing third. Front-loaded and each sentence carries a distinct decision-relevant fact.

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?

Output schema exists so return values need not be explained, and the description supplies the remaining critical context: failure modes, dependency risk, and payment terms. Nothing an agent needs to invoke this correctly is missing.

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

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

The single parameter is fully documented in the schema (100% coverage) including the spaces-allowed format and an example, so the description adds little. 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 and resource chain: validate an IBAN via MOD-97 and country length, then resolve bank name, city and BIC via OpenIBAN. An agent can distinguish this from the many unrelated siblings 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?

Clearly frames the conditional flow (lookup only happens if checksum passes) and warns that a valid checksum does not prove account existence, which is the key usage caveat. It does not name alternatives, but no sibling tool overlaps this capability, so there is nothing to route away from.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the runtime dependency (env.AI binding), the failure behavior ('unparseable output is an error, not a guess'), the size ceiling, and the exact cost model ($0.004 USDC per successful call via x402; failed calls not charged). These are behaviors an agent needs to sequence and budget calls correctly.

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?

One dense paragraph that front-loads the extracted fields, then inputs, then behavior, then cost. Every clause carries actionable information; the pricing and error-handling sentences in particular justify their length.

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 three optional parameters, an output schema present, and a caller that must know about the AI binding and the payment scheme, the description covers the prerequisites, limits, and failure mode without needing to explain return values. Nothing essential to a 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 the schema already defines imageUrl, imageBase64, and mime. The description restates the format and size constraints already present in the schema rather than adding new semantics such as mutual exclusivity rules or default behavior, so it lands at the baseline 3.

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

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

The description names a specific verb ('Extracts') and resource (invoice image fields: vendor name, tax ID, line items, net subtotal, VAT rates, IBAN, BIC). No sibling tool performs invoice OCR, so the agent can identify this tool's role from the name and first clause alone.

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

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

It clearly states the applicable input conditions (PNG/JPEG, public https URL or base64, up to 4 MB) and the required env.AI binding, which tells the agent when the tool will work. It stops short of explicitly naming alternatives or exclusion cases (e.g., PDFs or local files), which keeps it from a 5.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the upstream data source (ip-api.com), the Tor list origin, the free-tier non-commercial licensing restriction, and the billing model: $0.001 USDC via x402 on Base, Solana, or Arc, with failed calls not charged. That payment and licensing detail is exactly the kind of context annotations cannot express and that an agent must know before invoking.

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 returned signals, then scope exclusion, then licensing and cost. Four tight sentences with no filler; the billing sentence is dense but every clause (amount, rail, failure policy) is decision-relevant for a paid x402 endpoint.

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?

An output schema exists so return values need no explanation, and the description still covers data provenance, licensing, cost, and failure charging. For a one-parameter read-only lookup, nothing an agent needs to invoke it correctly is missing.

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

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

The single `ip` parameter is fully documented in the schema (100% coverage, with an IPv4 example), so the description carries no added burden. It adds no format or normalization guidance beyond what the schema already states, which is the baseline-3 case.

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 first sentence enumerates the precise resource and outputs: country, ISP/ASN, Tor exit status, proxy/VPN, hosting flag, and a LOW/MEDIUM/HIGH level. An agent knows exactly what class of check this is, and the following sentence separates it from threat-score tools in the same namespace.

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 is not a threat score: no abuse-report or spam history is included' gives an explicit when-not-to-use condition, which steers an agent away from this tool for abuse-history questions. It stops short of naming a concrete alternative or stating a positive use case, so it is clear context without full routing guidance.

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

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

With annotations already covering the read-only and open-world profile, the description still adds substantial context the annotations cannot convey: the upstream data source, the staleness limitation, and the exact cost model ($0.001 USDC per successful call via x402 on Base, Solana or Arc, with failed calls free). The charge-on-success detail is materially useful for an agent deciding whether to spend a call.

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

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

Three sentences, each doing distinct work: what is being checked, how to read the answer, and what it costs. The core question is front-loaded and the pricing trail is last, matching the order an agent needs the 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 single-parameter read tool with an output schema, the definition covers source, coverage, return shape in prose, staleness caveat, and payment terms. Nothing an agent needs in order to decide to call it or to interpret the answer 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 single 'query' parameter is already fully documented with an example format. The description corroborates the accepted input types (wallet addresses, phishing domains with linked addresses) but adds no syntax or format detail 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?

The description opens with a precise verb-plus-resource framing: a yes/no membership check against the ScamSniffer community blacklist for a wallet address or phishing domain. It names the data source (public GitHub scam database) and the exact payload returned (listed yes/no plus list size), which separates it cleanly from siblings like agent_intel_typosquat_phishing_domain_radar or agent_intel_ofac_sanctions_preflight.

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

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

It gives clear interpretive guidance — a 'no' does not prove safety and the list is not real-time — which tells an agent how much weight to place on the result. What it does not do is name an alternative tool for cases where the blacklist is insufficient, so the agent must infer from the sibling list rather than being routed explicitly.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the commercial model that materially affects invocation: $0.003 USDC per successful call, paid via x402 on Base, Solana, or Arc, and failed calls are not charged. It also volunteers the key limitation of the underlying data source, which prevents the agent from over-trusting the output.

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 sentences, front-loaded with the returned data, then the estimation caveat, then pricing. The first sentence is a long run-on list of fields, but every clause carries information the agent needs; nothing is 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?

With an output schema present and annotations covering the safety profile, the remaining gaps an agent would care about are payment/auth mechanics and output reliability, and the description addresses both. A caller has everything needed to decide and 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?

The single 'coin' parameter is fully documented in the schema itself (100% coverage, with the same BTC/ETH/SOL examples), so the description adds no new meaning beyond restating that the tool is per-perpetual. Baseline 3 is appropriate 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?

The description names a specific verb and resource ('For one perpetual on Hyperliquid') and enumerates exactly what is returned: mark price, open interest in coins and USD, funding rate, and liquidation estimates at 5x/10x/20x/50x. That scope is distinct from the nearest sibling, agent_intel_perp_funding_rate_heatmap, which is a cross-market view rather than a single-coin 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?

It establishes the context clearly ('public info API', one perp at a time) and adds an important usage caveat: the liquidation levels are formula-based estimates, not observed positions, because the API does not expose per-trader liquidation prices. It does not name an alternative tool or list what to use when the estimates are insufficient, which keeps it from a 5.

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

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

With readOnlyHint/openWorldHint already covering the safety profile, the description adds genuinely new context: the upstream source (GoPlus lp_holders), the truncation to top 10 holders, the caveat that locker names appear only when GoPlus supplies them, and the paid-per-successful-call model ($0.002 USDC via x402, failures uncharged). The payment/auth requirement is exactly the kind of detail annotations cannot convey.

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

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

Three dense sentences with the core measurement front-loaded, followed by scope exclusions and pricing. Every sentence carries information, though the parenthetical asides and the elongated pricing clause make it slightly crowded.

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?

Output schema exists, so return structure needn't be explained, and 2 params at full coverage need no elaboration. For a read-only inspection tool the description covers source, scope limits, truncation behavior and cost — 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 both parameters (chain with default, address format) are fully documented in the schema. The description only restates the chain list and adds no syntax or behavioral meaning beyond it; 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-and-resource: the share of a token's LP tokens burned or locked, drawn from GoPlus lp_holders, with the supported chains enumerated. The listing behavior ('top 10 LP holders with lock flag and tag') and the explicit non-coverage (Uncx/Team.Finance/Streamflow) separate it from siblings like token_liquidity_migration_watch or token_composite_safety_score.

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

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

Usage is only implied: an agent can infer this is for LP lock/burn due-diligence, but nothing states when to pick it over siblings such as deployer_rug_forensics or token_verdict_engine. The negative scope ('does not query Uncx, Team.Finance or Streamflow directly') clarifies data-source limits rather than routing.

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

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

Beyond the readOnly/openWorld annotations, it discloses the comparison's data source limitation (archive-only), the 404 failure mode for unarchived pages, and the full pricing model including that failed calls are free. These are exactly the operational traits an agent needs before spending a paid call.

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

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

Well front-loaded: what it does first, then the archive constraint and 404 case, then pricing. Three sentences each carry distinct information; minor verbosity in the price-currency enumeration but nothing wasteful.

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

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

Output schema covers return values, annotations cover safety, and the description fills the remaining gaps an agent needs: comparison scope, failure mode, and cost. Nothing material is missing for correct invocation.

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

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

Schema coverage is 100%, so url and since are already documented including the 30-day default. The description adds the 'on or after a date' semantic for the baseline snapshot, but that is a modest increment over the schema and not enough to exceed 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 (compares) and clearly defined resources (a public page now vs. its earliest Wayback snapshot on or after a date), then enumerates the exact outputs (changed flag, word similarity, added/removed lines, price-like amounts). No sibling tool does page-diffing, so the agent can distinguish it unambiguously.

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

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

Gives a clear usage boundary: 'Only what the archive captured is compared; pages the archive never saved return 404,' which tells the agent when the tool will fail. It does not name an alternative tool, so it stops short of full when-not/alternatives guidance.

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

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

Annotations already cover readOnly and open-world behavior, yet the description adds real value: the exact paid-call cost ($0.002 USDC via x402 on Base/Solana/Arc) and the fact failed calls are not charged. It also discloses upstream data-source limits (NOAA-only tides, no wind/pressure). It does not describe latency or rate limiting, 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: what is returned, what is excluded, then the pricing model. The primary capability is front-loaded and no sentence is filler.

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

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

With an output schema present the description need not explain return shapes, and it still covers inputs, data-source constraints, and the payment mechanism. 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 coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining the conditional meaning of the optional 'station' parameter — supplying it is what triggers the tide-prediction branch of the response. Latitude/longitude semantics are left entirely to the schema.

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

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

States a specific verb+resource pair: current wave height and period at a coordinate from Open-Meteo Marine, plus next-24h high/low tide predictions when a NOAA station id is supplied. That is precise enough to separate it from every sibling, none of which return marine or tide 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?

Gives clear scope conditions: tide predictions only exist for NOAA stations, and no wind or pressure forecast is included. It does not name an alternative tool or explicitly say when not to call it, so it stops short of a 5.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses the data source (DexScreener current reserves), the model's key limitations (no mempool view, no competing bots, constant-product only, worst-case not predictive), and the billing model — $0.003 USDC per successful call via x402 on Base, Solana or Arc, with failed calls uncharged. Cost and failure-charging behavior are exactly the kind of context an agent needs before invoking a paid endpoint.

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

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

The core purpose is front-loaded in the first clause, then caveats, then pricing — a sensible order with high information density and no filler. It is a single dense sentence chain, which makes it slightly harder to scan than if the limitations and pricing were split out, but every clause carries weight.

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

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

With an output schema present, return values need no explanation, and the description covers inputs, data source, model assumptions and payment. The only residual gap is operational detail such as how stale the DexScreener reserves are and what happens if the target pool is not constant-product.

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 every parameter including side, chain, feePct and slippagePct is already documented in the schema. The description reinforces the victim/slippage framing that explains why amount and slippagePct matter, but adds no format, default or unit guidance beyond what the schema already states; 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 and resource: computes theoretical sandwich-attack profit for a swap of a given size in one DEX pool at current reserves. It bounds the scope explicitly (constant-product pools only, one pool, no mempool view, no competing bots), so an agent can tell it apart from generic slippage or MEV feeds 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?

The description gives clear applicability conditions — one constant-product pool, DexScreener reserves, victim trade with a given slippage tolerance — and frames the output as a worst-case estimate rather than a prediction, which tells the agent when to trust it. It never names a sibling though, notably not agent_intel_dex_depth_slippage_calculator, which is the obvious adjacent tool, so there is no explicit routing or when-not clause.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the return format (base64 audio as the model gives it), an infrastructure prerequisite (env.AI binding), and a full cost model ($0.003 USDC per successful call via x402 on Base/Solana/Arc, failures not charged). These are exactly the operational facts an agent needs before invoking a paid endpoint.

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

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

Four tight sentences, front-loaded with the core action and followed by return format, exclusions, and pricing. Every sentence carries information, though the pricing/dependency clause could be compressed 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 an output schema present, the description need not explain return values, yet it still notes base64 audio. Language limits, input bound, dependency, and billing are all covered, leaving nothing an agent needs 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 both parameters (text, lang) are already documented in the schema, and the description merely restates the character limit and language set. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description opens with a precise verb-and-resource statement ('Turns text ... into speech with a Cloudflare Workers AI TTS model') and enumerates the supported languages, making it clearly distinguishable from the inverse sibling agent_intel_speech_to_text_transcribe_turbo.

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 concrete operating bounds (up to 1000 characters) and explicitly excludes German and Turkish with a reason, which steers the agent away from unsupported inputs. It does not name an alternative tool for when TTS is the wrong choice, so it falls short of a full when/when-not/alternative statement.

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

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

Annotations already cover the read-only and open-world profile, and the description adds genuinely new behavior: a $0.002 USDC charge per successful call via x402 on Base/Solana/Arc, with failed calls free. That billing semantics is material for an agent deciding whether to retry or batch. It omits rate limits and data freshness/latency, which would complete the picture.

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

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

The core capability and section list are front-loaded in the first sentence, with constraints, exclusions and pricing following in priority order. It is dense but every sentence carries distinct information; the parenthetical about no free source for entity tags is slightly more justification than 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?

An output schema exists, so return values need no explanation; the schema fully documents all three optional parameters. The description covers what a caller still needs and cannot infer: source restriction to BBC, absent fields, and the paid-call model including which failures are free. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents q (keyword, length bounds, matching in title or summary), limit (1-30, default 10) and section (enumerated values, default world). The description only restates that a claim is 'optionally filtered by a keyword' and that one section feed is used, adding no syntax or edge-case detail 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 BBC News headlines from one section feed'), enumerates the exact section values, and specifies what each item contains (summary, link, publication time). An agent can distinguish this from generic siblings like agent_intel_web_search_turbo 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?

The 'BBC only: no other publishers, no entity tags and no trust rating' sentence functions as an explicit exclusion list, telling the agent when this tool is the wrong choice (e.g., when entity tagging or credibility scoring is needed). It stops short of naming the specific alternative sibling to use in those cases.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them: the exact upstream API, the price ($0.002 USDC via x402 on three chains), the fact failed calls are not charged, and the fuzzy-matching option limited to the SDN portion. These are billing and behavior facts an agent could not infer 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?

Four sentences, no filler, and the most decision-relevant facts (what lists, what is excluded) are front-loaded before the pricing note. Every sentence 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?

With an output schema present, return-value shape need not be described. For a paid, open-world lookup tool the description covers scope, exclusions, cost/failure billing, and result interpretation — nothing material 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 earns extra by clarifying that fuzzy matching applies only to the SDN half, not the UN list — a meaningful distinction the schema does not express. The character-length constraint on name is left to the schema, which is fine.

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 (name screening) against two named sources (US OFAC SDN and UN Security Council consolidated list) and explicitly carves out what it does not cover (crypto addresses, EU list). An agent can tell exactly what this returns — matching entries — 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?

The description gives clear positive scope plus explicit exclusions ('does NOT screen crypto addresses', 'does NOT check the EU list'), which is strong routing guidance. It also frames the output semantics ('a lead for a human reviewer, not a legal decision'). It stops short of naming a sibling alternative for the crypto/EU cases, so a 4 rather than a 5.

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing the paid model ($0.002 USDC per successful call via x402 on Base, Solana or Arc) and confirming failed calls are not charged — critical for an agent deciding to call a paid endpoint. It also discloses a real data limitation (no realized cap in free tier) and interpretation caveats, none of which appear in 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?

Four dense sentences, front-loaded with what is returned, followed by interpretation caveat, data limitation, and price. Every sentence carries distinct, decision-relevant information with no repetition of the title.

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?

Output schema exists and the description still orients the agent by naming the returned fields (latest value, window mean, standard deviation, z-score). Combined with the pricing and free-tier caveats, nothing needed to call this correctly is missing.

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

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

Schema coverage is 100%, so both parameters are already documented with defaults. The description reinforces that the window is a statistical window (mean/stddev/z-score over 'days') and that asset must be BTC or ETH, but adds no format or syntax detail beyond the schema — 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 metric and resource — 'Daily MVRV ratio (market cap / realized cap) for BTC or ETH' — and names the data source (CoinMetrics community tier). An agent can distinguish it from siblings like agent_intel_sopr_profit_taking_ratio or agent_intel_token_verdict_engine 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 clear usage context: BTC/ETH only, daily window, output labels are statistics 'not buy or sell calls', and the free tier cannot return realized cap. It does not explicitly name a sibling alternative or state when-not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnly and openWorld, and the description adds real context beyond them: the data source (Deribit public book summary), the pricing model ($0.003 USDC per successful call via x402 across Base/Solana/Arc), and the explicit 'failed calls are not charged' policy. That cost/billing disclosure is exactly the kind of thing an agent needs, though freshness/caching behavior and rate limits are unstated.

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 tight sentences: payload first, then exclusions, then price. Nothing is repeated and the most decision-relevant facts (metrics delivered, what is missing, cost) are front-loaded.

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

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

With an output schema present, the description needn't explain return shapes, and it correctly covers data provenance, metric scope, exclusions, and billing. Remaining gaps are minor: no mention of expiry horizon specifics or how stale the book summary can be.

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 optional parameter with 100% schema description coverage, so the schema already carries the burden ('BTC, ETH or SOL (default BTC)'). The description restates the same asset set without adding format, casing, or behavior for unsupported values, which is the baseline-3 outcome.

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: a Deribit option market summary for BTC, ETH or SOL, with an enumerated metric list (put/call OI and volume ratios, max-pain strike, ATM mark IV, nearest expiries). It is clearly distinguishable from volatility-adjacent siblings like perp_funding_rate_heatmap or leverage_liquidation_levels, though it never names an alternative explicitly.

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 negative scoping is genuinely useful: 'No 25-delta skew (needs per-option greeks, not fetched) and no order flow' tells an agent exactly when this tool will not satisfy a request, before it spends money. It lacks a positive 'use this instead of X' routing statement, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial operational context beyond them: an exact price ($0.002 in USDC per successful call), the payment rail (x402 on Base, Solana or Arc), and the billing rule that failed calls are free. It also discloses uneven per-exchange coverage (only Bybit supplies open interest and long/short ratio), which sets correct expectations for 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?

Three sentences, each front-loaded with the most decision-relevant facts (what it returns, what it is not, what it costs). No filler and no repetition of the schema or title.

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?

An output schema exists, so return values need not be re-explained; the description nonetheless covers the important edge cases (per-exchange field asymmetry, no history) and the x402 payment requirement. Nothing an agent needs to call or budget for the call 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% and the sole parameter (symbol) is fully documented with format and default in the schema. The description only reinforces that the rate is 'for one coin' and adds nothing on ticker syntax or the USDT-margined constraint at the parameter level, so baseline 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 verb and resource (current perpetual-futures funding rate for one coin across Binance, OKX, Bybit) and enumerates the returned fields (annualised rate, mark price, Bybit open interest and long/short ratio). It explicitly disambiguates against the misleading 'heatmap' name by stating it is a table of exchanges, not a time-series heatmap.

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

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

It clearly scopes applicability: one coin at a time, current snapshot only, and explicitly excludes funding history. That tells the agent when not to use it, though it does not name a specific alternative sibling (e.g. for historical funding or multi-coin scans) the way a top-tier definition would.

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

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

Goes well past the readOnlyHint/openWorldHint annotations by disclosing the data staleness model (allocation-time carrier, no porting awareness, no live status) and the full commercial model ($0.002 USDC per successful call via x402 on Base/Solana/Arc, failed calls uncharged). Those are exactly the facts an agent needs before spending money on a call.

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

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

Three sentences, front-loaded with the operation and its outputs, followed by the caveat and then pricing. No filler; every clause (including 'failed calls are not charged') carries decision-relevant 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?

An output schema exists, yet the description still summarizes returned fields and, more importantly, supplies the semantic caveats the schema cannot express (allocation-time carrier, no live status) plus cost. Nothing an agent needs to invoke or interpret this tool is missing.

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

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

Schema coverage is 100% and the single 'number' parameter is documented with format and examples, so the baseline is 3. The description only echoes the E.164 framing and adds no parsing rules, normalization behavior, or error cases beyond what the schema already states.

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

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

States specific verbs and resource: parses an E.164 number, checks it against libphonenumber metadata, and enumerates exactly what is returned (country, line type, formats, allocated carrier). It also disambiguates against the name's implication by declaring 'Not a live HLR query', so an agent knows precisely what class of answer to expect.

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 negative case: it is not a live HLR query, ported numbers retain the original carrier, and active/inactive status is not checked. That is real when-not-to-use guidance, though no sibling alternative is offered for callers who actually need live HLR or reachability data.

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

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

Annotations only declare readOnly and openWorld; the description adds the material behavior an agent cannot infer: billing model ($0.002 USDC per successful call via x402 on Base/Solana/Arc), the fact that failed calls are not charged, that detection is pattern-based and therefore lossy, and that the response includes both redacted text and counts. Cost and failure semantics are exactly the kind of context annotations cannot carry.

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 verb and scope, then detectors, then limitations, then pricing – a sensible information ordering with no filler sentences. The detector enumeration is long but each item materially widens or narrows what the agent expects to be caught.

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

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

With an output schema, annotations and a fully documented parameter, the description still adds the two things that matter – detection limits and pay-per-call cost. It stops short of stating whether the caller's text is retained or logged, which matters for a redaction tool handling secrets.

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 `text` parameter already documents its 1–50000 character bound, so the schema does the work. The description does not add any semantics about the input beyond the general notion of 'text', 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?

Specific verb ('masks') plus a precise resource ('secrets and personal data in agent logs or chat text'), followed by an explicit enumeration of detected pattern classes (0x private keys, base58 keys, JWTs, AWS key ids, token prefixes, Luhn-valid cards, emails). No sibling tool performs PII/secret redaction, so the scope is unambiguous against the rest of the catalogue.

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

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

The intended inputs are stated ('agent logs or chat text') and the coverage boundaries are given as explicit exclusions: it can miss unusual formats and does not detect seed phrases or names. What is missing is any redirection to an alternative tool for the out-of-scope cases, so there is clear context but no named alternatives.

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