horizon-pulse

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

Beyond the annotations, the description discloses substantial behavioral context: per-rail outputs, XRPL reserve/fee/trust line handling, no USD valuation, no risk score, public RPC usage, nothing stored, charging behavior on bad input or RPC failure, untrusted third-party content, per-call pricing, and payment terms. This is exactly the kind of context an agent needs before invoking a paid external read.

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

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

The description is front-loaded and information-dense, with no filler sentences. It is somewhat run-on and mixes tool behavior, pricing, payment rails, and legal terms in one paragraph, but nearly every clause adds actionable context.

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 balance-checking tool with no output schema, the description covers the rails, per-rail returned fields, limitations (no risk score, no USD valuation), error charging caveats, trust warning, and payment mechanics. An agent has enough information to invoke it correctly and interpret the results.

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 parameter descriptions already document evm, xrpl, and solana. The description repeats 'GET at least one of evm (Base+Polygon), solana, xrpl' and adds little parameter-level meaning beyond the schema; baseline 3 is appropriate 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?

The description states a specific verb and resource: 'Wallet balance API for x402 payers', listing supported stablecoins and chains. It distinguishes the tool's scope from generic portfolio or funding tools by specifying per-rail payer balances, gas/fees, canPay status, and call capacity, and by explicitly excluding risk scoring and USD valuation.

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 'for x402 payers' and the instruction to supply at least one of evm, solana, or xrpl. However, it does not explicitly say when to use this tool versus siblings like portfolio, funding, or x402_check, nor does it state when not to use it.

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

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

Annotations cover safety (readOnly, non-destructive) but the description adds the operational facts: per-item failure semantics, one charge if at least one item succeeds, Base-only payment, and that a failed call is not charged on Base but may be on other rails. It also explains partial failure handling, consistent with idempotentHint=false since each retry re-charges.

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

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

Front-loaded with purpose, then wire format, return shape, and economics; nothing is pure filler. The price-per-item arithmetic across four different quantities is more verbose than needed and could collapse into a single break-even sentence.

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?

Despite having no output schema, the description specifies the response shape (results array with index/route/status/ok/body, plus count and okCount) in request order. Combined with cost, failure handling, and payment rail, an agent has everything required to call this correctly on the first try.

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 already documents route and params, so the description only needs to reinforce meaning. It does add the GET form ('items=<same JSON>') and clarifies that params are the 'single route's query keys', which helps an agent construct valid nested payloads, though it largely restates the schema's own route list.

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 ('Batch chain checks API: up to 10 checks for one payment') and immediately names the exact routes that can be batched, which maps directly onto the sibling tools (balance, gas, tx_status, token_meta, chain_head, name_resolve). An agent can tell this is a fan-out wrapper around single-route reads 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?

Gives explicit alternatives ('the same single routes at $0.002 each, or public RPCs and block explorers') and the precise break-even rule: below 5 items singles are cheaper, at 5 they tie, above 5 batch wins. That is exactly the decision an agent needs to route between this and its siblings.

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

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

Goes well beyond the annotations: it discloses the actual probe behavior (reads CDP discovery plus the host's /.well-known/x402, then sends one unpaid request per route), states it never pays, and flags that errors are not charged on Base while other rails may charge. Pricing ($0.01 USDC on Base, MCP payments Base-only), the https-only restriction, and the terms link are all surfaced. None of this contradicts readOnlyHint/destructiveHint=false — the network probes are reads.

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 purpose and the return shape before the pricing boilerplate. Dense but nearly every clause carries operational information. The pricing/terms sentence is long but defensible for a paid tool, though it could be tightened.

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

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

There is no output schema, and the description compensates by naming the return shape (verdict, per-route indexed status and networks, fail/warn findings with fix lines). Cost, payment rail, and access restrictions are all covered. The only real gap is sibling disambiguation against x402_check and x402_check_deep.

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

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

With one parameter at 100% schema coverage, the schema already carries the baseline. The description nevertheless adds real meaning to it: the value may be a bare host or a full https URL, and private targets are rejected. That is a meaningful constraint the schema does not encode.

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

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

Opens with a specific verb+resource ("x402 Bazaar listing checker") and immediately frames the question it answers: listed or not, on which networks, and why not. That is far more informative than a restated title. It does not, however, differentiate itself from the near-identically named siblings x402_check and x402_check_deep, which an agent must choose between.

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 phrasing (check a seller host against CDP Bazaar discovery) and constrained by "https only; private targets blocked." But there is no explicit statement of when to use this versus x402_check or x402_check_deep, nor any exclusion criteria. The agent has to infer the routing from names alone.

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

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

Goes well beyond the annotations by disclosing that queries hit third-party public RPC servers, the precise billing rule (charged only if at least one network answers; not charged on Base when all RPCs fail or input is bad), the x402/USDC-on-Base payment rail, and a terms link. A non-idempotent, open-world read with real payment consequences is fully disclosed.

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 the tool returns and keeps the network default early; the payout/terms detail is dense semicolon-chained prose but each clause carries operational weight. Slightly heavy for a one-parameter tool, yet nothing is truly wasted.

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

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

With no output schema, the description compensates by naming every returned field (chainId, height, headTime, headAgeSeconds, finalizedHeight, finalityGap) and clarifying the per-chain meaning of finality. Billing, defaults, and payment rail are also covered, leaving no material gap for correct invocation.

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

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

Schema coverage is 100% and the single 'network' parameter is already documented, including the CAIP-2 alternative. The description's 'comma list; default all five' restates the schema rather than adding syntax examples or behavior for mixed/invalid network entries. 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 resource (current block number / slot / ledger index) and enumerates the five chains covered, which is enough to distinguish it from siblings like gas, balance, and tx_status. An agent knows exactly what it gets back 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 explains the network parameter's default ('all five') and billing trigger, which implies usage, but never says when to pick this over gas/balance/tx_status or when a narrower per-chain call is preferable. No explicit exclusions or alternatives are named.

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

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

Goes well beyond the readOnly/idempotent annotations: states the price ($0.01 base, USDC on Base only), the payment protocol (x402 v2, HTTP 402), the charging rules (bad input refused before payment and not charged; no series returning data → refused and not charged; partial data → full price charged), and data freshness (up to 1 hour old). These are exactly the behavioral facts 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?

Front-loading is good, but the text is a dense run-on with clear duplication: 'USDC on Base only' appears twice, 'up to 10 CPI series ids' twice, 'up to 20 years' twice, and the BLS attribution is restated. The payment-mechanics sentences and the API-spec sentences are interleaved rather than grouped, making the key fact (it returns a quote, not data) harder to extract.

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

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

There is no output schema, so the description should convey the shape of the returned quote; it gives the price and currency but not what the response contains (e.g. payment requirements, header template, request body to replay). Given a 0-param tool this is adequate but leaves the agent guessing about how to act on the quote.

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

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

The tool takes zero parameters, so the baseline is 4. The description additionally documents the shape of the underlying paid request (series list up to 10 ids, optional start/end year, up to 20 years), which is useful context even though it technically belongs to the downstream endpoint rather than this 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?

Opens with a specific verb and resource — 'Returns the payment terms for https://horizonpulse.dev/api/bls/cpi' — and immediately disambiguates that 'this tool never runs the check or pays', which separates it from an execution/fetch tool. However, the bulk of the text then describes the downstream paid GET endpoint (?series=...&start=...&end=...), which blurs what this tool itself does versus what the API it prices does.

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

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

The use case is implied (get a quote, then 'Pay the 402 over HTTP with x402 v2') and refusal/charge rules are stated, but there is no explicit when-to-use versus the sibling quote tools or x402_check / x402_check_deep. An agent must infer that this is the pre-payment step rather than being told so.

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 the safe-read profile; the description adds the cost model ($0.03 via x402, USDC on Base), the fact that under-30-post results, refusals and errors are not charged on Base but may be on other rails, and the terms link. It also discloses what the response contains and deliberately omits (links only, no text or usernames, Bluesky DID included), which is real behavioral context an agent cannot infer.

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 purpose and the 'NOT a poll' correction, then constraints, then output shape, then pricing. Dense but well ordered; the parameter restatement and terms URL are the only near-wasteful parts, and both are arguably load-bearing.

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

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

No output schema exists, yet the description explains the return payload (per-side share with 95% interval and n, per-source counts, links-only, caveats). Combined with the refusal rules and billing terms, an agent has everything needed to call it and interpret results.

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 every parameter detail in the description (sides 2-4 default yes,no; window 1-30d) is already documented in the schema, so it adds no new meaning. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Hacker News and Bluesky opinion split') and preemptively disambiguates from a poll, which is the most likely misreading. No sibling does anything similar, so there is nothing else to differentiate against.

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

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

Gives explicit exclusion domains (elections, health, a named person's conduct) and a minimum-evidence threshold (under 30 decided posts refuses), so the agent knows when calls will fail. It stops short of naming alternatives, but the sibling list contains none that overlap.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: exact price points ($0.02 single, $0.25 bulk), USDC-on-Base-only settlement, the verdict taxonomy (registered/likely_unregistered/unknown), the rule that failed or throttled sources degrade to 'unknown, never available', and explicit non-guarantee/not-legal-advice disclaimers. This is exactly the extra behavioral layer 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?

Purpose and the 'does not pay' boundary are front-loaded, and every sentence carries distinct information (pricing, protocol, verdict semantics, failure mode, TLD exclusion). It is a dense single block that would scan better split into price/protocol/output/caveats groupings, which is the only thing keeping it off a 5.

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

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

With no input params and no output schema, the description carries the full burden and discharges it: what comes back (verdict plus age, status flags, RDAP/DNS/TLS, look-alike signal, optional OFAC screen), what happens on source failures, what the price is, and what is explicitly out of scope (.dev/.app, guarantees). An agent can decide and act without further data.

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

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

The tool takes zero parameters, so the baseline is 4. The description goes further by documenting the HTTP-level inputs the quote pertains to (domain query param, domains array, tier selection), which pre-answers how a caller would eventually invoke the underlying endpoint.

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

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

Opens with a specific verb and resource ('Returns the payment terms for https://horizonpulse.dev/api/domain/precheck') and immediately draws the boundary that matters: 'this tool never runs the check or pays.' That distinguishes it from execution/check siblings such as x402_check or bazaar_check without the agent needing to open a schema.

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

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

It explains that consumption happens over HTTP with x402 v2 (GET for single tier, POST for bulk), which tells the agent this call is a pricing/terms lookup step, not the action itself. It also gives a concrete usage rule for .dev/.app names (refused before payment, stripped from bulk batches). It stops short of an explicit 'call this before X, otherwise use Y' routing statement naming a sibling.

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 safe/read-only/idempotent profile, and the description adds useful business behavior: the price ($0.005), the payment rail (USDC on Base), and the explicit 'never runs the check or pays' guarantee. Some behavioral detail (direct port-443 handshake, no HTTP request sent) describes the paid endpoint rather than this tool, which slightly muddies the read operation semantics but does not contradict the annotations.

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

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

The quote/payment intent is front-loaded, which is good, but the rest is a dense, semicolon-chained run-on mixing endpoint URL, price, payment protocol, and a bulleted return-field list. It is information-rich but could be broken into clearer, shorter statements without losing content.

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

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

With no output schema and no parameters, the description carries the burden of explaining what the caller gets, but it describes the certificate fields (issuer, SANs, days remaining, etc.) that the paid endpoint returns rather than what this quote tool itself returns. An agent may be unsure whether calling this tool yields payment terms or those certificate details.

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

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

There are zero input parameters, which normally sets a baseline of 4, but the description introduces 'GET ?domain=example.com (one hostname per call)' and 'one name per call,' which reads like a parameter the tool takes even though the schema is empty. This risks the agent expecting a domain argument; the reference is actually to the paid HTTP endpoint.

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 states a specific verb and resource: it returns payment terms for an SSL quote endpoint, and explicitly notes it never runs the check or pays, which distinguishes it from an actual check tool. The remaining sentences describe the underlying paid endpoint, slightly blurring whether the description is about the quote tool or the check it prices.

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 signals the quote-only nature ('never runs the check or pays') and describes how payment is made over HTTP with x402 v2, which implies usage context. However, it does not explicitly route the agent between this and the similarly named siblings (domain_precheck_quote, domain_whois_quote) or say when a quote is preferable to invoking the paid endpoint directly.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds important context beyond them: the tool returns only payment terms and never runs the check or pays, the price is $0.25 in USDC on Base only, unsupported TLDs are refused before payment, and buyer-side usage restrictions apply. These details materially inform whether and how an agent should call 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 front-loaded: purpose and price come first, followed by payment instructions, bundle contents, restrictions, and buyer terms. It is appropriately sized for a payment-and-legal context, but it repeats 'USDC on Base only' and the TLD restriction, which slightly reduces efficiency.

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 quote-only tool with no output schema, the description covers the endpoint, price, payment protocol, bundle contents, TLD restrictions, currency/chain constraints, and legal usage terms. Nothing an agent needs in order to decide to call it or how to redeem the quote is missing.

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

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

With zero input parameters, the baseline is 4. The description still adds useful semantics by showing that the paid HTTP call takes a single ?domain=example.com query parameter and that only .com, .net, or .org names are accepted, which the empty schema cannot convey.

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 states the exact resource (payment terms for the specific endpoint) and explicitly clarifies that this tool never runs the check or pays. That distinction separates it from sibling check-execution tools. The description also names the paid bundle contents, so the agent immediately knows what it is quoting.

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 explains how to redeem the quote via HTTP with x402 v2 and gives the ?domain=example.com pattern, which is useful invocation guidance. However, it does not explicitly compare this tool to siblings such as domain_precheck_quote, domain_ssl_quote, domain_whois_quote, or x402_check, nor does it state when an agent should choose this bundle over those narrower quote tools. Usage is implied rather than fully routed.

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

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds real substance beyond them: exact cost ($0.005), payment rail (USDC on Base only), the fact that no check is executed and no payment occurs, pre-payment refusal of other TLDs, absence of contact data in results, and licensing terms on how results may be used.

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 key facts (price, no execution, TLD limits) are front-loaded, but the prose is cluttered and repetitive: 'USDC on Base only' appears twice and the .com/.net/.org restriction is restated three times across the response-content and refusal sentences.

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

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

With no output schema, the description carries the burden of explaining what the endpoint returns and does so in detail (registrar, dates, status, nameservers, DNSSEC, registry notices, source URL, no contact data). It never describes the structure, fields, or expiry of the quote object this tool itself returns, which is the one remaining gap.

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

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

The schema has zero parameters, so the baseline is 4. The description still clarifies the only user-supplied value that matters downstream (a single .com/.net/.org domain supplied as ?domain=example.com in the paid GET), which is useful context even though nothing appears in the schema.

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

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

The first clause gives a specific verb+resource ('Returns the payment terms for .../api/domain/whois') plus the price, and immediately scopes what it is not ('this tool never runs the check or pays'). The exact endpoint path also distinguishes it from the similar-sounding sibling domain_precheck_quote, which targets a different resource.

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 tells the agent the tool only yields terms and that the paid call must be made separately ('Pay the 402 over HTTP with x402 v2: GET ?domain=example.com'), and it states hard constraints (one name per call, only .com/.net/.org, other TLDs refused before payment). It stops short of naming the sibling tools (domain_precheck_quote, http/fetch) that carry out the alternatives.

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

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

Beyond the annotations, the description discloses key behavior: it never runs the check or pays, the base price is $0.003, payment is USDC on Base only, the x402 v2 flow uses GET with an email query, no SMTP connection is made, and bad input or DNS failure is 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?

The purpose and price are front-loaded, followed by payment mechanics and relevant caveats. There is some repetition, notably 'one address per call' and 'USDC on Base only,' but the content remains focused.

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

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

For a zero-parameter quote tool with rich annotations and no output schema, the description covers the return purpose, price, payment protocol, underlying check capabilities, and charge conditions. An agent has enough information to understand what this tool does and does not do.

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

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

The tool takes zero MCP parameters, so the baseline is 4. The description explains that the email address is supplied in the underlying HTTP payment call rather than as an argument to this tool, which helps prevent confusion.

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

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

The description states a specific verb and resource: it returns payment terms for the email check endpoint. It also immediately distinguishes itself from the actual check by saying it never runs the check or pays.

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 context that this tool is for retrieving payment terms before paying over HTTP with x402 v2, and it explicitly says it never runs the check or pays. It does not name a specific sibling alternative for performing the check, 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 read-only, open-world, non-destructive, but the description goes well beyond them: 200KB HTML and 8s caps, private targets blocked, 422 on no match, the billing policy (uncharged errors on Base, other rails may charge), the $0.015 x402/USDC-on-Base price, and a warning that returned content is untrusted third-party data. These are exactly the operational facts an agent cannot 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?

The purpose and return shape are front-loaded in the first two sentences, with limits, errors, pricing, and trust caveats following in priority order. It is dense but nearly every clause is load-bearing for an agent. The one cost is a run-on final stretch cramming pricing, payment rail, and legal terms into a single breath.

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

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

There is no output schema, so the description must describe return values itself — and it does, listing title, description, canonical, language, links, images, headings, jsonLd, textSample, plus per-field values and fieldErrors. Combined with caps, blocking rules, error codes, and billing behavior, an agent has everything needed to call this correctly.

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

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

Schema description coverage is 100%, so the schema already documents url, html, fields, the selector/attr/all/limit sub-shape, the max-20 limit, and the fieldErrors behavior. The description restates the same facts (GET url vs POST body, max 20 fields) without adding syntax or edge-case guidance the schema lacks. Baseline 3 applies when the schema carries the parameter burden.

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

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

The opening clause names the operation and resource precisely: a scraping API that turns a public page or supplied HTML into JSON fields, and it enumerates the default return shape. An agent immediately knows this is structured extraction rather than a raw fetch. It stops short of a 5 because it never explicitly contrasts itself with siblings like fetch, http, or pdf, which overlap in the 'retrieve a web resource' space.

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

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

It gives concrete invocation routing: use GET with a url, or POST with JSON {url or html, fields}, and explains that supplying fields yields matched values plus fieldErrors. That is actionable context for choosing between the two call shapes. There is no explicit when-not-to-use clause or pointer to an alternative sibling, so it falls 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?

Goes well beyond the annotations by disclosing hard caps (200KB, 8s, 3 redirects), redirect following with finalUrl, private/localhost blocking, partial-result signaling via truncated/bytesRead, error charging behavior, and that returned content is untrusted third-party data. These are exactly the operational facts an agent cannot get from readOnlyHint/openWorldHint alone.

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

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

Front-loaded with the purpose, then return shape, then limits, then pricing/terms — a sensible order. The pricing and buyer-terms sentence is long boilerplate but is genuinely actionable for a paid x402 tool, so it earns most of its space.

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

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

No output schema exists, and the description compensates by enumerating every returned field (content, format, finalUrl, upstreamStatus, contentType, bytesRead, truncated). Combined with caps, target restrictions, error-charging behavior, and price, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and the single parameter is already documented, but the description adds a real constraint not in the schema: the URL must be absolute and http/https, which prevents a common malformed call. Beyond that it adds nothing to parameter meaning.

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: turns a public web page into clean text/markdown for an LLM, with the transport (GET url) named. It does not distinguish itself from plausible siblings like http, extract, pdf, or screenshot, so an agent must infer which to pick.

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 'a public web page ... for an LLM' and constrained by 'absolute http/https' plus the private/localhost block. There is no explicit when-to-use-vs-alternatives guidance (e.g., when to use http or extract instead) and no stated when-not conditions beyond the private target exclusion.

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

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

Beyond the annotations, it discloses cost and rail ($0.003/call via x402, USDC on Base only), that failed calls are not charged on Base, that a bad symbol returns 400, the 5-minute data staleness, and buyer terms. For a paid tool this is exactly the extra 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?

It leads with what the tool returns and what the output looks like, which is the right order. The payment and legal-terms material is dense but relevant for a paid tool, though the disclaimer and terms sentences could be tightened.

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

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

With no output schema, describing the returned fields (instId, fundingRate, fundingTime, crowding hint with sides and levels) and the error/billing behavior covers nearly everything needed to call it. The remaining gap is the symbol parameter that the description promises but the schema does not define.

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

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

The input schema declares zero properties, yet the description says a single coin can be requested via 'symbol=', a parameter that exists nowhere in the schema. The high schema coverage is vacuous with no parameters, so the description's invented parameter creates a concrete risk of malformed calls rather than adding accurate 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: current OKX USDT-swap perpetual funding rates for BTC, ETH and SOL, with an optional single-coin mode. That is far more specific than the bare name 'funding', but it never names a sibling (funding_report, funding_reports, market_quote) to say how this differs from the report-style tools.

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

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

It gives clear usage boundaries: coverage is limited to BTC/ETH/SOL, and data refreshes roughly every 5 minutes so calling more often returns identical values. It stops short of naming an alternative tool or an explicit 'do not use this for historical/multi-asset series' exclusion.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description adds genuinely new behavior: the tool only returns the unpaid 402 and never pays, plus the price and payment rail (USDC on Base). The legal disclaimers about New York Fed affiliation and investment advice add little operational value for an agent.

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 critical constraint (returns an unpaid 402, never pays) and the payment URL are front-loaded in the first two sentences. The remainder is product and legal boilerplate, but for a paid-quote tool that context is relevant and does not bury the operational instruction.

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

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

For a one-parameter quote tool with no output schema and full annotation coverage, the description covers what is returned (a 402 quote rather than the report), what the report contains, and how payment is completed. An agent has enough to call it correctly and act on the result.

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

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

With a single parameter at 100% schema description coverage, the schema already documents 'id' as coming from funding_reports or defaulting to latest. The description only echoes 'by id or latest' and adds no syntax, format, or failure-mode detail beyond that.

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

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

The opening sentence gives a precise verb and resource: it returns payment instructions (an unpaid HTTP 402 quote) for a single $1 report, and explicitly states it never pays. This distinguishes it from an actual payment step and from the sibling listing tool funding_reports referenced in the schema, though it never names funding_reports or x402_check directly as alternatives.

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

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

It clearly tells the agent the next step: pay the 402 over HTTP with x402 v2 (USDC on Base) at the given GET URL, implying this is a quote-only step before external payment. It also points to an alternative resource for a different need (raw published values are free at /api/money-market-rates), but it does not explicitly state when to prefer x402_check, x402_check_deep, or funding_reports over this tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds little beyond a return-field list: no ordering, freshness, pagination, or completeness behavior. The closing sentences are legal disclaimers ('not affiliated', 'does not sanction', 'no payment required') that consume space without informing invocation.

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?

Only the first sentence carries tool information. Two of the remaining three sentences are corporate/legal boilerplate about Horizon Pulse and the New York Fed, and 'No payment required' is an unexplained interjection. The useful content is front-loaded, but the definition is padded.

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

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

With no parameters and no output schema, listing the returned fields (id, title, date, abstract) is genuinely helpful and largely completes the contract. What is missing is a sense of what a 'Funding Pulse Weekly' report is and whether the index is exhaustive, which limits an agent's ability to decide when the call is appropriate.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. The description correctly implies a no-argument listing, and the schema is empty as expected; baseline 4 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 first sentence states a specific resource ('Funding Pulse Weekly index') and enumerates the fields returned (id, title, date, abstract), which clearly distinguishes it from the single-report sibling funding_report. It never explicitly names that sibling, but a reader can tell this is the list/index variant.

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?

There is no statement of when to use this tool versus funding, funding_report, or pulse. The only quasi-guidance is 'No rate values', which implies a content scope but not a usage condition; an agent must infer that this is a listing call.

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

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

Annotations only say read-only and open-world; the description adds substantial context beyond them: cost ($0.002/call via x402, USDC on Base), that errors are not charged on Base but other rails may charge, upstream sources (eth_feeHistory with eth_gasPrice fallback), cache cadence, and a buyer-terms link. This is exactly the payment/auth/freshness detail 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?

Purpose and the response field list are front-loaded, and each clause carries distinct information (fields, source, fallback, price, freshness, terms). It is dense to the point of being a wall of text in one paragraph, but no sentence is filler.

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

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

There is no output schema, and the description compensates by enumerating the returned fields (baseFeeGwei, priorityFeeGwei with p10/p90, suggestedMaxFeeGwei, timingHint, simpleTransfer cost, ethUsd). With freshness, pricing, and error-charging behavior also covered, an agent has everything needed to call and interpret it.

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

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

Zero parameters, so the baseline is 4; the description correctly confirms 'no parameters' and instead spends its words on the response shape, which is the more useful information here. Nothing about parameter meaning is missing because there are none.

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

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

Opens with a specific verb+resource+scope: 'Gas price API for Base and Ethereum: base fee, priority fee and a max-fee suggestion in one GET, no parameters.' No sibling tool covers gas pricing, and the description makes that scope unambiguous.

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

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

States explicitly that it takes no parameters and that 'calling more often returns the same values' with data refreshing about every 1 min, which tells the agent when to call and when not to bother. It also clarifies the output is 'descriptive, not a forecast.' It stops short of naming a sibling alternative, but none in the list is a plausible substitute.

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

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

Goes well beyond the annotations: discloses pay-per-call pricing ($0.005 via x402, USDC on Base, MCP payments Base-only), that failed/no-match/source-down calls are not charged, data licensing and attribution per source, that allergens may be incomplete, and that returned content is untrusted third-party data. This is exactly the behavioral 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?

Purpose is front-loaded, but the body is a dense run-on that crams pricing, terms URL, licensing, and error-charging policy into one paragraph, including a malformed clause ('Bad input, no match or source down: not charged on Base'). Valuable content, but not well-structured.

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

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

No output schema, so the description must convey returns; it lists the per-100g nutrient fields and sources plus attribution caveats. It stops short of describing the per-item response shape or how multiple matches per item are structured, which an agent would need for parsing.

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

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

Schema coverage is 100%, so baseline is 3; the description adds real value by tying q to grocery_normalize canonicalIds, clarifying barcode is a GTIN read live from Open Food Facts, noting n is 1-5 USDA matches, and stating 'one price per call' for the 10-item cap.

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 ('Ingredient nutrition facts API') and enumerates both access shapes (GET with q/barcode, POST batch of up to 10). It links q to the grocery_normalize canonicalId, partially differentiating from that sibling, though the dense API-doc phrasing makes the core purpose slightly harder to extract than a plain sentence would.

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?

Implied usage comes through the parameter walkthrough: single lookup via GET, batch up to 10 via POST, barcode reads live from Open Food Facts. But there is no explicit 'use this instead of X when...' guidance and no stated alternatives besides the canonicalId pointer to grocery_normalize.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), yet the description adds substantial behavior the annotations do not: deterministic output, no outbound calls, nothing stored, 400 vs 422 failure semantics, and a per-call price with the payment rail and buyer terms. That is exactly the kind of context an agent needs before calling a paid x402 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 purpose is correctly front-loaded in the first clause, and most sentences carry real information. But the whole definition is a single dense run-on paragraph, and the payment/legal boilerplate (price, rail, terms URL, 'other rails may charge') consumes roughly half the text and is hard to scan.

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

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

There is no output schema, but the description enumerates every returned field (name, canonicalId, qty, unit, metric, category, optional/toTaste, prepNote, pack size, pack hint) plus the merged shoppingList and unparsed lines. Combined with the error and payment semantics, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the schema already documents all three parameters, making 3 the baseline. The description goes beyond it by explaining that servings and targetServings are meant to be supplied together for scaling, and by documenting a GET query-string mode (ingredients=line|line) that does not appear in the input schema at all.

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 parses recipe ingredient lines and returns normalized per-line fields plus a merged, serving-scaled shopping list. That is far more concrete than the title alone. It does not, however, distinguish itself from the sibling grocery_ingredient tool, leaving the agent to guess which one handles single ingredients.

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 request shape: POST a batch of lines with optional servings/targetServings to get a scaled shopping list, or use GET for a single pipe-delimited string. There is no explicit 'use this when...' clause, no exclusions, and no pointer to grocery_ingredient for the single-item case, so the agent must infer 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?

Goes well beyond annotations: hard caps (384KB response, 64KB body, 12s, 3 redirects), SSRF protection, no cookie propagation, upstream 4xx/5xx returned as charged data versus uncharged proxy errors, payment rail and per-call price, and an untrusted-content warning. The destructiveHint=true annotation is also coherent with the disclosed non-GET methods.

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

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

Front-loads purpose, then invocation, then return shape, then limits, then cost/terms — a dense but well-ordered block where each clause carries a distinct constraint. No filler sentences.

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

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

Despite no output schema, the description names every returned field and distinguishes data-bearing HTTP errors from proxy failures. Payment requirements, rate/size caps and trust level of returned content are all covered, leaving no gap an agent needs before calling.

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

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

Schema coverage is 100%, so the baseline is 3, but the description exceeds it by enumerating the accepted methods (GET/POST/HEAD/PUT/PATCH/DELETE) where the schema only says 'HTTP method', and by giving body/header size limits that bound the body parameter. The alternative POST JSON envelope shape is also clarified.

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 ('HTTP request proxy API for public URLs') plus the two call shapes, and enumerates the returned fields. It never contrasts itself with related siblings such as fetch, extract, screenshot or pdf, so an agent cannot tell from this text alone which of those to prefer.

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 'public URLs' scope and 'private hosts blocked' rule imply when the tool is usable, and the two invocation forms are spelled out. But there is no explicit when-to-use/when-not guidance relative to fetch, extract or screenshot, which are the obvious alternatives in this sibling set.

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 far beyond the annotations (which only cover readOnly/idempotent/destructive) by disclosing price ($0.01 base), currency and chain (USDC on Base only), charging semantics (bad input refused before payment; full price charged if any series returns data, refused if none do), and data staleness (up to 1 hour old). It also supplies attribution and non-affiliation with BLS, which matters for a data-resale 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?

Purpose is front-loaded and the body is mostly high-value. However, it repeats itself: 'USDC on Base only' appears twice and the 20-year cap is stated twice, and the payment/charging rules could be tightened into fewer clauses.

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

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

For a zero-parameter quote tool with no output schema, the description covers pricing, payment protocol, refusal/refund rules, and data provenance, which is nearly everything an agent needs. The one gap is that it never characterizes the shape of the returned payment-terms payload (e.g., what fields the quote contains).

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

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

Zero schema parameters, so the baseline is 4, but the description adds genuine meaning by documenting the underlying query options: optional start/end years with a 2024/2026 example and a 20-year cap. That is information the empty input schema cannot convey.

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

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

Opens with a specific verb and resource: returns payment terms for a named URL, with the explicit scope limit that it never runs the check or pays. The resource (BLS U.S. jobs figures: payrolls, unemployment rate, average hourly earnings) distinguishes it from sibling quote tools like cpi_series_quote or sec_filings_quote without needing 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 workflow: get the quote here, then pay the 402 over HTTP with x402 v2 via a parameterless GET or ?start/?end. It also sets an exclusion boundary ('this tool never runs the check or pays'). It stops short of naming sibling alternatives for other datasets, but the usage context is unambiguous.

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

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

Adds substantial context beyond annotations: cost ($0.005 per call via x402, USDC on Base only), payment-rail caveats on blocked hosts, legal/buyer terms, and an explicit trust warning that returned content is untrusted third-party data. The one-request framing and mismatch behavior are also useful behavioral disclosures.

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

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

The description is dense and run-on, packing pricing, legal terms, return shape, security caveats, and host behavior into one paragraph. It is front-loaded with the core purpose, but the lack of structure makes it harder to scan than necessary.

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

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

With no output schema, the description does a good job explaining the JSON return shape: verdict, reasons, per-network live terms, Bazaar entry, payTo cross-check, and buy plan. It also covers cost and terms, though some behavioral nuance around the single request versus POST retry could be clearer.

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

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

Schema coverage is 100% and both parameters are documented in the schema, so the schema already carries the parameter burden. The description restates that the URL is https and that GET/POST are optional, but adds little beyond the schema's method default and 405 retry detail.

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

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

States a specific verb and resource: an unpaid x402 quote and payTo check for a single seller URL. It is clear what the tool does, but it does not explicitly distinguish itself from siblings like x402_check, x402_check_deep, bazaar_check, or verified_brief_quote.

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 usage through phrases like 'without paying' and 'before paying', and notes blocked/unreachable host behavior. However, it gives no explicit when-to-use or when-not-to-use guidance relative to the many adjacent x402 and bazaar checking siblings.

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

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

Goes well past the annotations: discloses that the top 3 results are re-checked live, that payTo is cross-checked against the index, that ranking is not paid, that Horizon Pulse holds no funds, that a no-result call is free on Base but may be charged on other rails, and that returned listing text is untrusted. Pricing ($0.005/call, USDC on Base, MCP payments Base-only) and buyer terms are also stated.

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

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

Front-loaded with purpose and parameters, then trust/cost caveats, with no filler sentences. The telegraphic 'GET q; optional n (1-10), kind, rail (...)' phrasing is dense but still parseable; a small amount of the parameter enumeration duplicates the schema.

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

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

No output schema exists, yet the description specifies the return shape (ranked offers with price, rails, health, plus a direct-pay buy plan) and the empty-result behavior. For a paid, open-world search tool, the cost, payment-rail and trust caveats cover everything an agent needs before calling.

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

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

Schema description coverage is 100%, so all six parameters are already documented, and the description largely restates them (n 1-10, rail list, max_price in USD, min_health 0-1). The only added value is the 'GET q' hint and the note that the top 3 are re-checked, so the baseline 3 applies.

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

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

States a specific verb and resource ('find paid x402 APIs for a task') plus the exact corpus searched ('Coinbase CDP Bazaar'), which separates it from generic siblings like search, bazaar_check and x402_check. An agent knows immediately what it gets back: ranked offers with price, rails and health.

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 scope ('paid x402 APIs for a task in Coinbase CDP Bazaar') implicitly tells the agent when this tool applies, and the cost/payment notes give practical call conditions. It does not, however, explicitly route away from look-alike siblings such as bazaar_check, x402_check or market_quote.

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

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

The description provides massive behavioral context beyond annotations, detailing data status (fresh, PENDING, STALE), specific sourcing (NY Fed Markets Data API), and legal disclaimers that define how the data should be used.

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 excessively long, dominated by repetitive legal disclaimers and affiliation notices which are necessary for the domain but poor for conciseness in a tool definition.

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

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

For a regulated financial reference tool, the definition is incredibly thorough, covering data provenance, format, limitations, and necessary legal warnings. Nothing crucial 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?

Although schema coverage is 100%, the description adds necessary semantic context by enumerating the acceptable rate types (SOFR, EFFR, etc.) and clarifying mutual exclusivity between the 'last' and date-range parameters.

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

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

The description clearly identifies the tool's purpose: retrieving published NY Fed reference rates like SOFR, EFFR, etc. It specifies the data source and the specific types of financial markers it handles.

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 tool provides critical usage boundaries by stating it is a reference feed, not a forecast or paid service. It clearly sets expectations regarding data currency and recommendation status.

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 far beyond the readOnly/openWorld annotations: discloses pricing ($0.002/call, x402, USDC on Base, Base-only for MCP), that found:false is still billed while bad input/RPC failure may not be, that returned names are untrusted third-party data, and that reverse results are forward-verified with a true/false flag. None of this is derivable from annotations or schema.

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

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

Front-loaded with purpose and mode, then billing and trust caveats in descending importance. The style is telegraphic sentence fragments and the ordering is dense, but nearly every clause (billing, CCIP-Read exclusion, untrusted data) 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?

With no output schema, the description correctly explains what comes back: address/resolver/registry forward, verified primary names reverse. Also covers cost and failure billing, which an agent must know before paying. Minor gap: behavior when both name and address are supplied is left unspecified.

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 properties already carry descriptions including the same "Give name or address" phrasing, so the description adds little parameter-level meaning. The forward/reverse outcome mapping is useful but sits closer to return-value semantics than 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?

Names the specific resource (ENS and Basenames) and both verbs of operation (name→address forward, address→primary name reverse), with concrete examples (vitalik.eth, jesse.base.eth). No sibling tool in the list does naming resolution, so it is unambiguously distinguishable.

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?

"Give name or address" plus the forward/reverse split tells the agent which parameter selects which mode, and the explicit exclusion of off-chain/wildcard (CCIP-Read) names prevents a class of futile calls. It stops short of stating when to prefer this over an alternative path (e.g. caching via other tools), but no true sibling alternative exists.

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 declaring read-only, open-world, non-idempotent, non-destructive behavior, the description adds substantial context: exact return shape, truncation behavior, 422 on image-only PDFs, charging policy for failed downloads, and an untrusted-third-party-data warning. Pricing and payment rails are also disclosed, which is 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 the core purpose and packed with useful detail in a compact block. It is dense but nearly every clause (limits, error cases, pricing, untrusted-data warning) earns its place; the terms URL is the only marginal element.

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?

Even without an output schema, the description enumerates the JSON fields returned (pages, totalPages, pagesReturned, truncated, bytes, finalUrl, meta) and covers error, size, and payment behavior. An agent has everything needed to call and interpret the result correctly.

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

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

Schema description coverage is 100%, so both parameters are already fully documented in the schema, and the description largely repeats them (http/https, max 10MB, pages 1-50 default 50). It adds the GET method detail but no new syntactic meaning beyond the schema.

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

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

States a specific verb+resource: extracts text from a public PDF, page by page. It is unambiguous what the tool does. It does not, however, explicitly differentiate itself from potentially adjacent siblings such as extract, fetch, or http, leaving the agent to 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?

Gives clear context for use (public http/https PDF, max 10MB) and notable exclusions (image-only PDFs return 422 because there is no OCR; max 100K chars). It stops short of naming an alternative sibling for cases when a non-PDF or image document must be handled.

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

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

Goes well beyond the annotations with details the agent could not otherwise know: no logging/storage of submitted text, $0.02 per-call x402 pricing in USDC on Base, bad input is not charged, and redacted text returned only when redact is true. The readOnly/non-destructive safety profile is consistent with annotations and the added privacy and billing behavior is exactly the kind of context a caller 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?

Front-loaded with the pattern list, which is good, but later sentences are repetitive boilerplate: 'USDC on Base' appears three times, plus a warranty disclaimer and a terms URL that add bulk without aiding tool selection. Roughly a third of the text could be trimmed.

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

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

There is no output schema, and the description compensates by describing the return shape (findings with type and offsets, plus redacted text conditionally), the input encoding, the privacy posture, and the billing model. An agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so text and redact are already fully documented in the schema. The description's 'POST JSON {text, redact?}' and the redact-true behavior restate the schema rather than adding syntax, limits, or format guidance. 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 ('scan of supplied text') and enumerates exactly what is detected: email, phone, SSN, Luhn-checked cards, mod-97 IBANs, IPs, private-key shapes, BIP-39 phrases, API-key shapes. This is clearly distinguishable from nearby sibling tools such as extract, search, or http, which do not perform pattern classification.

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 framing for use: 'best-effort only, not a compliance assessment' and 'Informational only, no warranty', which tells the agent when results are and aren't authoritative. It does not explicitly name an alternative tool (e.g., extract) or state when not to call it, 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?

The description goes well beyond the annotations by disclosing that invalid addresses return 400, that Base calls are not charged for invalid addresses while other rails may charge, the $0.04 x402 price with USDC on Base, the MCP payments constraint, and the buyer terms link. This is exactly the behavioral context an agent needs before invoking a paid read-only endpoint.

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

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

The description is dense but front-loaded: purpose first, then payload, then payment and validation caveats. It is longer than a minimal description, but most of that length is earned by payment, error, and legal context; the terms URL and pricing detail could be tightened 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?

For a paid, read-only portfolio endpoint with no output schema, the description covers the return fields, concentration scoring, validation behavior, pricing, payment rails, and legal terms. An agent has enough to call it correctly and understand the cost and failure modes.

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% for the single `address` parameter, so the baseline is 3. The description adds useful validation detail ('0x...', 40 hex) and confirms the address is snapshotted across Base and Ethereum, which adds meaning beyond the schema.

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

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

The description states a specific verb/resource: a wallet balance and portfolio API for one EVM address on Base and Ethereum, naming the assets covered and the JSON payload returned. It is very clear what the tool does, but it does not explicitly distinguish itself from the sibling `balance` tool.

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

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

It gives some operational guidance (GET with an address, read-only, not advice) and payment rails, but it does not say when an agent should use this portfolio tool versus the sibling `balance` tool. Usage is implied rather than explicitly routed.

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

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

Annotations already mark it read-only, idempotent, non-destructive, and closed-world, but the description adds substantial behavior: cost, x402 payment flow, USDC-on-Base-only constraint, never-runs-check/pays semantics, FCRA use restrictions, found:false behavior, and no charge for bad input. No contradiction with annotations.

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

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

Front-loads the core purpose, endpoint, and price, which is good. However, it repeats 'USDC on Base only' and the GET license/purpose details, and packs legal restrictions and underlying-check facts into a dense paragraph that could be tighter.

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

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

Covers price, currency/network, payment protocol, what the underlying check returns, legal-use limits, and bad-input charging behavior. With no output schema, it could say more about the quote response shape, but it is largely complete for a zero-parameter quote tool.

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

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

The tool has zero input parameters and 100% schema description coverage, so the baseline is 4. The description mentions license and purpose for the downstream HTTP GET, but those are not inputs to this tool, so they do not raise the parameter-semantics score.

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

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

States a specific verb and resource: returns payment terms for the pros/verify endpoint, including base price and USDC-on-Base constraint. It also clarifies that it never runs the check or pays, distinguishing it from a verification/payment action, though it does not name sibling quote tools 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?

Explains that the tool only returns payment terms and that payment happens separately over HTTP via 402/x402 v2 with a GET using license and purpose. This gives clear usage context and an implicit exclusion from running the check or paying, but does not explicitly compare against sibling alternatives.

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

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

Goes well beyond the annotations: names the upstream sources and the Coinbase→CoinGecko fallback with a source field, discloses the ~1 min data refresh, that labels are fixed rules rather than forecasts, that errors are free on Base, the $0.002 x402/USDC-on-Base cost, and links buyer terms. The read-only/open-world hints are supplemented with exactly the operational and billing 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?

Front-loaded correctly with what it does and the returned fields, which is the right order. The tail is bloated and parenthetical ('Errors are not charged on Base (other rails may charge)... USDC on Base (MCP payments are Base only)') repeating rail/cost constraints twice and bolting a terms URL into the same sentence.

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

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

For a zero-parameter, no-output-schema tool, the description carries the return shape (field-by-field), freshness, cost and provenance, which is close to everything an agent needs. The one hole is that its documented single-coin mode has no matching schema entry, leaving the agent unsure whether symbol is real.

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

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

The schema declares zero properties, yet the description instructs 'or one coin via symbol= (bad symbol: 400)'. That references a parameter that cannot be passed, so an agent following the description would emit an invalid call. The return-field list (priceUsd, change24hPct, momentum, sentiment, direction) is genuinely useful since there is no output schema, but the phantom input parameter is a real defect rather than a baseline-4 no-param 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?

Opens with a concrete verb+resource: a current USD price snapshot for BTC, ETH and SOL, and states the use case ('quick market context'). It does not name or exclude any sibling (market_quote, tokenized_stock, signals), so an agent cannot tell from this text alone which price tool to prefer, which keeps it below 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?

It gives utility-level guidance ('for quick market context', a ~1 minute refresh so repeat calls are wasted, and the 400 behavior for a bad symbol), which is more than nothing. However, it never states when to use this over the price-adjacent siblings, and the one single-coin instruction it offers points at a parameter that does not exist.

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

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

Goes well beyond the annotations: headless Chromium rendering, 25s timeout returning 504, 4000px fullPage clip, sub-request filtering, error billing exceptions, x402 USDC-on-Base pricing, and the untrusted-data warning. This is unusually complete behavioral disclosure for a read-only tool.

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

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

Front-loads what the tool does, then constraints, then behavior, then pricing. Dense but nearly every clause carries information; the terms URL and payment-rail detail are slightly tangential to invocation.

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

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

With no output schema, the description helpfully enumerates return fields (imageBase64, mimeType, finalUrl, pageStatus, blockedRequests). The only completeness gap is the phantom delayMs parameter, which conflicts with the actual schema.

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

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

Schema coverage is 100%, so the schema already documents all five parameters including ranges and defaults. The description restates the ranges but also advertises a delayMs (0-3000) parameter that does not exist in the schema (additionalProperties: false), which could mislead an agent.

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

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

Opens with a specific verb+resource: renders a public web page as PNG/JPEG. This is clearly distinguishable from siblings like fetch, pdf, and extract, which handle different content types.

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?

States the target must be a public http(s) URL and that private targets and sub-requests are blocked, giving clear preconditions. It stops short of explicitly naming when to prefer fetch or pdf instead.

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

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

Beyond the annotations, the description discloses substantial behavior: Serper/Google sourcing, top-result fetching, per-page ok/status and fetchedOk fields, the 12K character cap, billing only when results return, non-charging on zero results or provider errors, $0.03 pricing via x402 in USDC on Base, Base-only MCP payments, and a security warning that returned content is untrusted third-party data. This is unusually rich disclosure for a paid tool.

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

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

The purpose and key constraints are front-loaded, and the pricing, billing, security, and terms details all earn their place for a paid API. It is still a dense single paragraph that could be more scannable, but it is not padded.

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, open-world search tool with no output schema, the description is complete: it explains the return JSON shape, per-page success/failure fields, character limits, billing behavior, payment rail, and untrusted-content risk. An agent has enough information to call it and interpret partial failures correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description restates q's 300-character limit and n's 1-5 range with default 3, but adds no meaning beyond the schema. A baseline 3 is appropriate 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?

The description states a specific verb and resource: 'Web search API with page contents: current results with sources as markdown.' It also names the underlying provider (Serper/Google) and clarifies that top results are fetched as markdown. However, it never explicitly distinguishes itself from siblings like fetch, extract, or market_search, 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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling alternatives are named. The agent can infer this is for web searches, but with nearby tools such as fetch, extract, market_search, and http, the description leaves routing entirely 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 mark it read-only, non-destructive, and idempotent. The description adds critical operational context beyond that: cost ($0.50), network (USDC on Base only), payment protocol (x402 v2), no side effects, and data provenance/disclaimers.

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 payment terms are front-loaded appropriately, but the description repeats 'USDC on Base only' and includes lengthy legal disclaimers that are not central to tool selection. It earns its core place, but the repetition and boilerplate reduce conciseness.

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

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

For a zero-parameter quote tool with annotations covering safety behavior, the description is substantially complete: it names the endpoint, cost, network, payment protocol, and underlying data. It does not describe the returned payment-terms object, but with no output schema and a simple quote contract this is a minor gap.

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

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

The tool has zero input parameters, so there is no tool-side parameter semantics to explain. The description clarifies the underlying HTTP query pattern with GET ?cik=320193, which is helpful context even though it is not a tool input 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?

The description states a specific verb and resource: returns payment terms for the SEC 10-K risk endpoint, and explicitly says it never runs the check or pays. This sharply distinguishes it from actual data-fetching or x402 execution tools in the sibling list.

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

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

It explains that this is a quote-only tool and gives concrete payment instructions: pay the 402 over HTTP with x402 v2 via GET ?cik=320193. It does not name an alternative execution tool such as x402_check explicitly, but the when/when-not distinction is otherwise clear.

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

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

Beyond the annotations, the description discloses the price ($0.02), payment asset and network (USDC on Base only), payment protocol (x402 v2), that it returns a 402 rather than performing the check, and important data limitations: quarterly filing cadence, 45-day lag, original 13F-HR only, and possible staleness.

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 payment terms and next step are front-loaded, but the description is long for a zero-parameter quote tool and repeats 'USDC on Base only.' The final legal and non-advice boilerplate is not directly necessary for tool selection or invocation.

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

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

For a zero-parameter, no-output-schema payment quote tool, the description is complete enough: it states what is returned, the price and payment rail, the exact HTTP call to make, and relevant data freshness caveats. An agent has enough information to call it and act on the result.

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

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

The tool itself has zero input parameters, so the baseline is 4. The description goes further by documenting the downstream HTTP query parameters (cik required by example, period optional), which helps the agent understand what to send when paying the quote.

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

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

The description opens with a specific verb and resource: returns payment terms for a named SEC 13F endpoint. It also explicitly distinguishes itself from execution-oriented siblings by saying it 'never runs the check or pays,' so an agent can tell it apart from x402_check-style tools.

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

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

It gives clear next-step instructions: pay the 402 over HTTP with x402 v2 and call GET ?cik=... with an optional period. It also states the tool itself does not run the check or pay, which defines its scope, though it does not explicitly name sibling alternatives such as x402_check or fetch.

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

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

Annotations cover the safety profile (readOnly=true, destructive=false, openWorld=true), so the description's job is the extra context it supplies: IFRS companies return 404, pricing is $0.02 per call via x402 in USDC on Base, and MCP payments are Base-only. Those are real operational facts an agent must know before calling, and nothing contradicts the annotations. It stops short of describing what happens on an unknown ticker/CIK or whether the result is cached.

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

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

The return payload is front-loaded in one dense sentence, followed by scope limits and then commercial terms. The legal/payment boilerplate ('not affiliated with or endorsed by the SEC', 'not investment advice', terms URL) is defensible for a paid x402 endpoint but does consume roughly a third of the text.

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

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

There is no output schema, and the description compensates by enumerating the returned metrics, both annual and quarterly granularity, the as-of date and source link. Combined with the 404 caveat for IFRS filers and the payment mechanism, 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 description coverage is 100%, so the CIK and ticker parameters are already documented, including the 'give ticker or cik' guidance. The description adds no additional parameter meaning (e.g. which wins if both are supplied, or case sensitivity), so the baseline 3 applies.

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

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

States a specific verb+resource: key financial facts for one SEC-reporting company from EDGAR XBRL filings, and enumerates the exact metrics returned (revenue, net income, assets, liabilities, equity, shares outstanding, operating cash flow, EPS). The scope is precise enough that an agent can distinguish it from quote/price-oriented siblings like market_quote without reading 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 clause 'Company facts only' plus the US-GAAP-only restriction implies this is for fundamentals rather than prices or tokenized instruments, which partially routes against siblings. However, no sibling is named and there is no explicit statement of when not to use it (e.g. for IFRS filers, use X instead), so guidance is implied rather than stated.

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

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

The annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond that: base cost $0.02, USDC on Base only, never executes/pays, and no charge for bad input or unknown tickers. It stops short of explaining quote expiration or the exact response shape, but the added charging behavior is valuable.

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

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

The first sentence is front-loaded and useful, but the description becomes repetitive and unfocused: 'USDC on Base only' appears twice, and several sentences describe the paid endpoint's filings data, query syntax, and legal disclaimers rather than the quote tool itself. The extra material does not earn its place for an agent trying to select or invoke this zero-parameter quote 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?

For a zero-parameter quote tool with no output schema and annotations covering safety, the description does provide the essential quote context: endpoint, price, payment rail, and no-charge behavior. But it is muddled by unrelated filings-data details and does not clearly separate what this tool returns from what the paid HTTP endpoint returns.

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

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

The tool has zero input parameters, which gives a baseline of 4. The description mentions HTTP query parameters like ticker, optional form, and limit 1-20, but those appear to belong to the paid API rather than this quote tool's empty input schema, which could confuse an agent even though there are no tool parameters to document.

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

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

The opening sentence states a specific verb and resource: it returns payment terms for a named SEC filings endpoint, and explicitly says it never runs the check or pays. That distinguishes it from an execution/check tool, but the description does not name a sibling alternative and the later EDGAR-filings detail blurs whether the tool itself returns filings or just a quote.

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

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

It implies usage by saying the tool never runs the check or pays, and describes how to pay the 402 over HTTP, which helps an agent understand it is a quote-only step. However, it does not explicitly say when to choose this tool instead of related tools such as x402_check or sec_company_facts, leaving the routing guidance implicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real behavioral facts: fixed $0.02 base price, USDC on Base only, no execution or payment, and the important billing rule that unknown ticker / no filings / SEC outage are not charged. It omits whether prices ever change or how the quote is returned, but the added value is genuine.

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 key facts (payment terms, no execution, price, USDC/Base) are front-loaded, which is good. But the ticker/cik/limit instruction appears twice verbatim in substance, and a third of the text is legal/affiliation boilerplate that does not help an 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?

With 0 params and no output schema, the description does supply the endpoint, payment protocol, query parameters, and the data the paid call returns. What it lacks is what the quote response itself looks like or how the returned 402 terms should be consumed, leaving a gap between 'get quote' and 'pay'.

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

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

The input schema is empty (0 parameters), so the description is the only source of invocation semantics, and it supplies the actual query shape: ?ticker=AAPL or ?cik=320193 with an optional limit of 1-10. That is meaningful compensation, though it repeats the same parameter sentence twice rather than adding further detail such as behavior for conflicting ticker+cik.

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 states a specific verb+resource: returns payment terms for a named x402 endpoint, with price and network, and explicitly says it does not run the check or pay. It does not differentiate from near-siblings like sec_filings_quote or market_quote, but the quote-vs-execute distinction is unmistakable.

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

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

It implies the workflow ('Pay the 402 over HTTP with x402 v2') and states the tool's own boundary ('never runs the check or pays'), so the agent can infer it is a pre-payment quote step. However, it never explicitly says when to use this instead of sec_filings_quote or the other *_quote siblings, leaving selection 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 it discloses pricing ($0.005 per call via x402, USDC on Base), that Base errors are not charged while other rails may be, the 5-minute cache cadence, the CoinGecko-to-Coinbase fallback source, and the 400 on a bad symbol. It even explains the null-macd edge case for too-few candles, which is real behavioral context an agent cannot get from the annotations.

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

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

It is front-loaded with the payload contents and return shape before moving to pricing and terms, which is the right order. The closing legal/terms sentence and the double disclaimer ('not a forecast and not financial advice') add bulk that an agent does not need for selection or invocation.

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

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

With no output schema, the description carries return-value documentation itself and does so well (field list, null semantics, data sources, freshness, error behavior, cost). The one real hole is the symbol parameter that exists in prose but not in the input schema, leaving invocation ambiguous.

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

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

The schema declares zero properties yet the description introduces 'one coin via symbol=' and its 400 failure mode, so the semantics it supplies do not match any declared parameter. The documented meaning of symbol= is useful, but the schema/description mismatch means an agent cannot tell how to actually pass it.

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

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

The description names the exact resource (precomputed RSI-14, MACD, Bollinger Bands plus OKX perp funding), the covered assets (BTC, ETH, SOL) and the single-coin variant, then enumerates the returned JSON keys. An agent can distinguish this from siblings like funding, funding_report and market_quote purely from the text.

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

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

It gives clear use conditions: no candle fetching needed, data refreshes roughly every 5 minutes so repeat calls return identical values, and it is descriptive only, not a forecast. It never names an alternative sibling or an explicit when-not condition, so routing between this and the dedicated funding tools 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?

Beyond the annotations (non-read-only, non-idempotent), it discloses that submissions go to human review only, nothing ships automatically, there is no reply, retention is up to 90 days, and it specifies exact rate limits (5/hour, 20/day, shared daily cap). It even explains the HMAC-of-IP privacy mechanism and counter expiry — a level of transparency well past the annotation bar.

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

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

Dense but well ordered: legality, purpose, fields, retention, exclusions, then limits. The closing sentence about HMAC retention and 25-hour counter expiry is lengthy and could be trimmed, but nearly every clause carries actionable 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 write-side feedback tool with no output schema, the description covers everything an agent needs: what to send, what not to send, what happens afterward, and the practical throttling that could cause failures. 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% and the description largely restates the schema (enum values for type, the 1-500 character text limit, optional symbol and route). The added detail that links are stored masked is useful but is behavioral rather than a clarification of parameter meaning, 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?

The description states a specific verb and resource — telling Horizon Pulse about a missing coin, data field or route — and enumerates the accepted categories, which lets an agent distinguish it from all data-retrieval siblings like search or fetch.

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 conditions for use (something missing from the dataset) and explicit content exclusions (no personal data, secrets or keys; links not followed). It does not name alternative tools for data corrections, but the context is unambiguous enough for selection.

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

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

Goes well beyond the readOnly/openWorld annotations: discloses the $0.002 x402 USDC-on-Base charge, that failures (unknown symbol, bad input, RPC down) are not charged on Base but may be charged on other rails, and that returned content is untrusted third-party data. It also links buyer terms, which matters for 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?

Tight, front-loaded sentences that pack scope, format, return fields, and error/payment behavior without filler. The legal/terms clause is necessarily dense but slightly bloats the tail of a one-line description.

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

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

With no output schema, the description partially compensates by naming the returned fields (paused flags, supply, supply cap, multiplier, issuer, token address) and covering failure behavior and payment. What it lacks is any indication of response shape, such as a per-token vs aggregate object, or caching/freshness.

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

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

Schema description coverage is 100% and already documents accepted forms (AAPL, AAPLc, token address, omit for all), so the description's near-identical wording adds little. The only net-new detail is the count of 12 listed stocks; otherwise the schema does the heavy lifting.

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

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

States a specific verb+resource (tokenized stock status for Coinbase tokenized stocks on Base) and enumerates concrete tickers (AAPLc, NVDAc, TSLAc). It also draws the boundary against price-oriented siblings with 'On-chain token state only, no price,' so an agent can distinguish it from market_quote or token_meta.

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

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

Explicitly gives the call pattern: optional symbol, omit for all 12, and states what is out of scope (no price). It stops short of naming a concrete alternative tool for pricing, so the exclusion is implied rather than routed.

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 per-call pricing ($0.002 via x402, USDC on Base, MCP payments Base-only), that found:false is a billed answer, that bad input or RPC outage is unbilled on Base but other rails may charge, and a security caveat that returned names/symbols are untrusted third-party data. The buyer-terms link and payment rail constraint are exactly the kind of operational 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-loads what is returned and the chain-state exclusion, then moves to billing and trust caveats in roughly priority order — all sentences carry information. It is a dense semicolon-chained run-on, which slightly hurts scanability but wastes almost nothing.

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

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

With no output schema, the description carries the burden and does: it enumerates the returned fields per chain, explains the found:false sentinel, and covers cost, billing exceptions and data-trust. An agent has everything needed to call it, interpret a miss, and predict the charge.

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 parameter descriptions already state the accepted formats (0x address / mint address / CURRENCY.rIssuer; network list or CAIP-2). The description's restatement of 'network and token (0x address, mint, or CURRENCY.rIssuer)' adds little beyond the schema, so the baseline 3 applies.

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

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

Names a specific verb+resource (token metadata) and enumerates exactly what is returned per rail: ERC-20 name/symbol/decimals/total supply on Base/Polygon/Ethereum, Solana mint decimals/supply/authorities (Token-2022 name+symbol), XRPL supply/issuer flags/transfer fee. The closing 'Chain state only: no price, no token-list check' explicitly separates it from price/quote siblings like market_quote and from token-list checks.

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 positive conditions (chain state for a given network+token, three address formats) and negative exclusions ('no price, no token-list check'), which steers the agent away from misusing it as a price oracle. It stops short of naming the alternative sibling tools explicitly, so it is strong but not a full when/when-not/alternatives 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 read-only/idempotent/non-destructive, but the description adds real value the annotations cannot: exact price ($0.01 base), accepted currency and chain (USDC on Base only), the explicit statement that it does not execute the check or payment, and the payment protocol/verb. It also clarifies units (debtUsd in USD, cashUsdMillions in millions) and negatives ('Not a forecast'). It stops short of describing what the 402 response body looks like.

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?

Key information (it's a quote, the price, the protocol) is front-loaded, which is good, but the text repeats itself: 'No parameters' appears twice and 'USDC on Base only' appears twice in a compact block. The payload-field roster is dense but earns its place given no output schema.

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

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

With no output schema, the description does the work of naming the returned fields (total, held by public, intragovernmental, 1d/30d/1y change, TGA balance and daily change) and their units, plus the data source. An agent knows what it will get once the 402 is paid. Only the shape of the quote/payment response itself is left unspecified.

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

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

Zero parameters, so the baseline is 4, and the description reinforces this twice ('No parameters', 'GET with no parameters'), eliminating any ambiguity for the agent. No schema-level meaning is missing.

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

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

States a specific verb and resource ('Returns the payment terms for .../treasury/debt') and then describes the underlying dataset (total debt, public/intragovernmental split, TGA balance). It cleanly separates itself from data-fetching by saying 'this tool never runs the check or pays', which is the key distinction from the fetching siblings. It does not explicitly differentiate against the other *_quote siblings (market_quote, x402_check, x402_check_deep), which keeps it off 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?

Gives procedural guidance for the follow-up step ('Pay the 402 over HTTP with x402 v2: GET with no parameters'), which implies the quote-then-pay workflow. However, it never says when to choose this over x402_check, x402_check_deep, or market_quote, nor what happens if the agent skips the quote step. Usage is implied rather than stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: price ($0.01), payment rail (USDC on Base only), the fact the tool never executes the check, refusal-before-charge behavior, full-price-on-partial-data rule, and data staleness (up to 30 minutes old). These are exactly the operational details an agent needs before committing funds.

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

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

Information density is high, but the text is a run-on paragraph with repeated content ('USDC on Base only' appears at both start and end, and the 'refused and not charged' rule is stated twice). The key fact (quote only, never pays) is front-loaded, but legal/attribution boilerplate interrupts the operational rules.

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

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

With no output schema and no parameters, the description carries the burden well: it covers price, rail, request shape, refusal rules, data contents (1M–30Y tenors plus 2s10s and 3M/10Y spreads), and freshness. It does not describe what the returned payment-terms payload looks like, which would help an agent know what to expect back.

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

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

The input schema is empty (0 params), so all parameter knowledge comes from the description, which fully specifies the downstream query parameter: optional date=YYYY-MM-DD, defaulting to the latest published day, plus the refusal behavior for invalid dates. Without this text an agent could not construct the correct request.

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: 'Returns the payment terms for https://horizonpulse.dev/api/treasury/yield-curve', and immediately disambiguates the action by saying 'this tool never runs the check or pays'. The named endpoint distinguishes it from siblings like treasury_debt_quote, though no sibling is explicitly named as an alternative.

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

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

Explains the workflow clearly: get the quote, then pay the 402 over HTTP with x402 v2 using GET with no parameters or ?date=YYYY-MM-DD. It also specifies when charges do and don't apply ('Bad input is refused before payment, not charged'; 'If no curve exists for the date, it is refused and not charged'). It stops short of routing to alternatives such as x402_check or treasury_debt_quote for other 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?

Goes well past the annotations: discloses $0.002/call x402 pricing with USDC on Base only, that Base bad input is not charged while other rails may be, that returned content is untrusted third-party data, and that 'allow' means only that no check flagged the address rather than a safety guarantee. The dated-snapshot and GPL-3.0 source caveats further set expectations. Nothing here contradicts readOnlyHint/openWorldHint/idempotentHint=false.

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

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

Front-loaded with what is checked, then the verdict semantics, then cost and caveats — a sensible order with little filler. The clipped, fragment-dense phrasing ('GET chain ..., to; opt. expected, token') and the odd 'mechanical' cost some readability, but every sentence carries information an agent needs before calling a paid 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?

With four fully documented parameters and a clear safety annotation profile, the remaining burden is on return values and cost, and the description covers both: 'allow, warn or block per check' plus the explicit caveat on what 'allow' means, and the per-call price. The one gap is that the shape of the per-check results (verdicts, which check failed) is not sketched, and there is no output schema to fall back on.

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 explains to, chain, token and expected in detail. The description's terse restatement ('GET chain (base/polygon/solana/xrpl), to; opt. expected, token') adds no meaning beyond that, 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?

Enumerates the concrete checks performed (lookalike, OFAC SDN snapshot, account age, ScamSniffer) against a named resource (a recipient address before a crypto transfer), which clearly separates it from siblings like tx_status, name_resolve or x402_check. The opening sentence is telegraphic ('..., mechanical') and takes a second read, but the resource and scope are unambiguous.

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

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

'before a crypto transfer' implies the trigger condition, and the allow/warn/block explanation clarifies what the outcome means. However, no alternative tool is named (name_resolve, x402_check, tx_status), no when-not guidance is given, and the caller is left to infer that this is a pre-send gate rather than a general address lookup.

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 billing semantics ('not_found is a charged answer', RPC failures not charged on Base but possibly charged on other rails), price and payment rail, that returned content is untrusted third-party data, and the polling contract. These are exactly the behaviors an agent must know before invoking a paid tool.

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

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

Front-loads purpose, then inputs, then return shape, then commercial terms — a sensible ordering with little filler. The pricing/terms tail is dense but each clause carries operational 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?

For a paid, read-only, open-world lookup with no output schema, the description covers inputs, expected JSON fields, the polling loop, cost per call, payment rail, and the untrusted-data caveat. Nothing material 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 coverage is 100%, so both parameters are already fully documented, including the hash formats and the network enum. The description restates 'hash or Solana signature' and 'network optional for Solana and XRPL' but 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?

States a specific verb+resource ('Transaction status API: did a payment or swap land, and is it final') and names the exact chains covered. An agent can distinguish it from siblings like tx_guard, chain_head, or balance 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?

Gives concrete call conditions: pass the tx hash or Solana signature, network is optional for Solana and XRPL hashes, and poll again after pollAgainSeconds until final is true. It does not explicitly say when to prefer this over the sibling tx_guard, which keeps it 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/idempotent/non-destructive, and the description is consistent with them while adding real substance: it discloses that no payment occurs, that payment must be Base USDC via x402 v2, and that the paid flow only charges when at least 2 claims are confirmed in two independent sources, otherwise a 422 with no charge. The 'charged only if' sentence slightly blurs the quote tool with the paid report, and no rate limits are mentioned, keeping it just short of 5.

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

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

A single dense paragraph that front-loads the core behavior ('returns the payment instructions... never runs the brief or pays') before the payment mechanics and pricing rule. Length is justified by a multi-step payment protocol, though the contract and terms URLs plus the claims-confirmation clause push it toward the upper bound of what an agent needs up front.

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

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

With no output schema and a non-trivial x402 payment protocol, the description supplies what's missing: what is returned, that it is unpaid, the exact network and asset, the endpoint to pay at, the accepted question scope, and the charge/422 condition. An agent can act correctly on this definition without opening the contract links.

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% (both q and the type enum are documented), so the schema already carries parameter meaning and baseline 3 applies. The description restates the allowed question domains but adds a small inconsistency, saying 'three question types only' while the enum exposes four values (base_gas, eth_gas, usdc_supply, x402_spec), which could cause momentary confusion.

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

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

States a specific verb and resource: returns the unpaid HTTP 402 payment instructions for the $1 verified brief, and explicitly negates what it does not do ('never runs the brief or pays'). That negation alone distinguishes it from siblings like fetch, http, or x402_check, which an agent might otherwise reach for.

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

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

Gives the follow-up path explicitly: to actually obtain the brief, pay the 402 over HTTP with x402 v2 (Base USDC only) at the named GET endpoint. It does not name which sibling tool to use for the payment step or when to prefer it over fetch/http, so usage is clear for the next step but not for sibling selection.

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

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

Goes well beyond the annotations with statelessness ('nothing stored'), SSRF guarding, output truncation (added lines up to 20 plus counts), billing behavior (changed:false is charged, bad input/blocked/upstream errors are not), price and payment rail, and a warning that returned content is untrusted third-party data. These are exactly the non-obvious traits an agent needs before invoking a paid, open-world tool.

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

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

Front-loads purpose and call mechanics in the first two clauses; the remaining sentences each carry distinct operational facts. The payment/terms tail is dense but not redundant.

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

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

No output schema exists, yet the description specifies the return shape (changed boolean, added lines, added/removed counts), the truncation limit, and the failure/charging semantics. An agent has everything needed to call and interpret results.

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 parameters are already documented; the description still reinforces the `since` token's role as state carried from the prior answer and the omit-on-first-call rule. Baseline 3 is exceeded only slightly since it largely restates 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?

Names a specific verb and resource: detects whether a public page/endpoint changed since a prior check. It is functionally distinguishable from fetch/screenshot/http siblings by the change-detection framing, but it never names an alternative tool, so the differentiation is left implicit.

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

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

Explains the call pattern clearly: GET the url, pass `since` from the previous answer, omit it on the first check. That gives solid context for correct sequencing but offers no explicit exclusions or named alternatives for when a plain fetch would be better.

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?

Far beyond the annotations: it discloses price ($0.02), settlement rail (USDC on Base only), per-answer billing even on empty results, pre-payment input validation, data freshness (up to 60 s old), upstream source (api.weather.gov), and an explicit non-affiliation/life-safety disclaimer. Annotations only cover read-only/idempotent safety, so this is genuinely additive.

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

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

Front-loaded with the price and the 'never executes' constraint, which is right. But it is one dense run-on with repeated facts ('USDC on Base only' appears twice) and a heavy parenthetical clause, so signal is interleaved with restatement.

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

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

With no output schema, the description carries the return contract and does so: enumerated alert fields, freshness window, empty-result billing, and safety disclaimers. What it omits is the actual quote payload shape (e.g., whether a 402 challenge or address is returned), which an agent calling a payment-quote tool might want.

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

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

Zero-parameter schema means baseline is 4, and the description usefully explains the request shape the price covers: one point (?lat=38.9&lon=-77) or one state (?area=CA), with example values and the mutual exclusivity of the two modes. The mismatch that these inputs live outside the input schema slightly muddies it.

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

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

The description opens with a specific verb+resource: it returns payment terms for a named endpoint, and explicitly scopes itself ('never runs the check or pays'). That cleanly separates it from the check/execution siblings, though it never names a specific sibling quote tool it pairs 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?

It states the operative rule clearly: pay the 402 over HTTP with x402 v2, and this tool only quotes. The cost model ('charged per answer, including when no alerts are active; bad input is refused before payment, not charged') tells the agent when a call is wasteful. It stops short of naming an alternative tool or an explicit 'do not use this if...' branch.

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

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

Goes well beyond the annotations: it discloses that exactly one unpaid request is sent, that no signing occurs, and gives explicit billing rules (any HTTP answer including 4xx/5xx is billed; bad input, blocked hosts, connection failures and timeouts are not), plus price and payment network constraints.

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

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

Front-loads purpose and the no-payment guarantee before billing details. It is dense with several clauses, but each (billing rules, return fields, price, terms) carries operational value rather than filler.

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

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

With no output schema, the description enumerates the returned fields (httpStatus, isX402, x402Version, decoded accepts, discovery metadata, pass/warn/fail checks), and it covers billing and payment requirements, leaving nothing essential for a correct call unstated.

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

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

Schema description coverage is 100%, so the schema already documents url, body and method, including the 405-retry behavior. The description's parenthetical restates this rather than adding new meaning, making the baseline 3 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 (decodes) and precise resource (an x402 endpoint's 402 payment terms), with the key qualifier 'without paying'. It does not explicitly name the sibling x402_check_deep or distinguish shallow vs deep probing, so it falls short of full sibling differentiation.

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

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

The 'without paying / never pays or signs' framing clearly conveys the use case: inspecting payment terms before committing. However, it never states when to prefer x402_check_deep or http instead, so alternatives are left implicit.

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

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

Goes well beyond the annotations: it discloses that no payment or signature ever occurs, that the target server sees a live HTTP probe, the exact billing boundary, the price and payment rail (USDC on Base, Base-only for MCP), and links the buyer terms. The non-idempotent/hit-or-miss billing behavior is exactly the kind of context annotations alone cannot convey.

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

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

Front-loaded with the core verb and the safety guarantee, then the added checks, then billing. It is dense and the payTo parenthetical runs long, but nearly every clause carries decision-relevant information (cost, billing edge cases, payment rail).

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

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

With no output schema, the description must convey what comes back, and it does by naming the source report and the categories of live findings. Combined with explicit billing and payment constraints for an open-world, paid tool, an agent has enough to call it correctly; only the response shape of the added checks remains vague.

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 url, method and body in comparable detail. The description's 'GET url (optional method, body)' confirms behavior but adds no new semantics such as constraints on url or how body interacts with method beyond what the schema 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 specific verb+resource (deep check of an x402 endpoint) and immediately scopes it: never pays or signs, returns the full /api/x402-check report plus live checks. The enumeration of what the deep layer adds (TLS, security headers, CORS, payTo verification, lookalike detection, drift across well-known/openapi/CDP Bazaar) makes it clearly distinguishable from the sibling x402_check and bazaar_check.

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 rather than stated: the 'deep' framing and the cost ($0.03/call) tell an agent this is the heavier, paid variant, but the description never explicitly says when to prefer it over x402_check or bazaar_check. The billing rules (any HTTP answer billed; bad input, blocked hosts, timeouts not) do help decide whether a probe is worth issuing, which lifts it above a bare 2.

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 annotations: discloses pricing ($0.02/call via x402, USDC on Base, MCP payments Base-only), that errors are not charged on Base, the fixed filter thresholds (TVL >= $10M, non-outlier APY), fetch-time pass-through from DefiLlama, and data staleness. The annotation idempotentHint=false is consistent with a per-call charge.

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

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

Front-loads purpose and return shape, then layers filters, freshness and billing. It is dense but nearly every clause carries decision-relevant information; the terms URL sentence is the only borderline item and is justified by paid-call obligations.

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

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

With no output schema in structured data, the description fully enumerates the returned fields (project, chain, symbol, tvlUsd, apy, apyBase, apyReward, apyMean30d, stablecoin, exposure, ilRisk, poolId), the ordering rule, the result cap of 25, and the cost model. An agent has everything needed to call and interpret it.

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

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

Zero parameters, so baseline is 4; the description explicitly confirms 'no parameters', which matches the empty schema. No additional semantics are needed or offered.

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: current APY for stablecoin and DeFi pools. Scope is clear enough to pick it over generic siblings, but it never distinguishes itself from money_market_rates, which plausibly overlaps, 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?

Gives a concrete when-not-to-call rule ('data changes about every 1 h; calling more often returns the same values'), which usefully suppresses redundant paid calls. It stops short of naming alternatives or prerequisites beyond the implicit x402 payment requirement.

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