Horizon Pulse

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

Annotations cover safety, but the description adds substantial behavior beyond them: public RPCs, nothing stored, no charge on bad input or RPC outage, the XRPL fee non-reservation caveat, per-call price and payment rail (Base-only x402), and an explicit prompt-injection warning about untrusted returned content. That is exactly the extra context annotations cannot express.

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

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

Purpose is front-loaded and the dense clause-per-fact style packs payment terms, failure behavior, and safety caveats efficiently. It is closer to a run-on list than a structured summary, but nearly every sentence carries non-redundant information.

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

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

With no output schema, the description carries the return burden well: it enumerates per-rail outputs (USDC/RLUSD balance, gas/fees, XRPL reserve/trust line, canPay, calls left) and covers pricing and error semantics. An agent has what it needs to call and interpret this tool.

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

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

Schema description coverage is 100%, so baseline is 3; each parameter is already documented with its rail and what it yields. The description restates the rail mapping (evm = Base+Polygon, xrpl = RLUSD/trust line/reserve) without adding format, validation, or mutual-exclusion detail 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+question answered: 'x402 payer balance check: can this wallet pay right now.' It also scopes itself against siblings by naming the rails (Base+Polygon, Solana, XRPL) rather than generic balance lookup, so an agent can separate it from gas, portfolio, or x402_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?

Gives a clear invocation rule ('GET with at least one of evm, solana, xrpl') and an implied use case (deciding whether a wallet can pay now). It does not explicitly name alternatives such as x402_check or gas, nor state when not to use it, so it stops short of full routing guidance.

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

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

Beyond the annotations (readOnly/openWorld/idempotent/non-destructive), it discloses that it reads CDP discovery plus /.well-known/x402, issues one unpaid request per route, never pays, is HTTPS-only, blocks private targets, does not charge on errors, and costs $0.01 via x402 USDC on Base. That is unusually rich behavioral context 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-loaded with the purpose and how to call it, then constraints, return shape, and pricing. Almost every clause earns its place, though the pricing/networks details add length that a shorter definition could compress.

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

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

With no output schema, the description compensates by naming the return fields (verdict, per-route indexed status and networks, fail/warn findings with fix lines). Combined with cost, transport constraints, and side-effect disclosure, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100% and the single parameter is already documented as 'host or https URL'. The description repeats this and adds only the HTTP verb (GET), so it meets but does not exceed the baseline where the schema carries the semantics.

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

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

The description states a precise verb+resource ('find out whether an x402 seller is listed in Coinbase CDP Bazaar') and even covers the negative case ('and, if not, why'). It is far more specific than a tautology, but it never names or contrasts the closely related sibling x402_check, so the agent must infer which one applies.

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

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

It gives a clear triggering condition ('Use to find out whether an x402 seller is listed... and, if not, why'), which is real usage guidance. It stops short of exclusions or naming the alternative x402_check for related diagnostics, so it is context-rich but not routing-complete.

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, openWorld, idempotent, non-destructive), yet the description adds material behavior the schema cannot: $0.03 per call via x402/USDC on Base, no charge for refusals/errors/under-30 decided posts, and returns of links only with no text or usernames. This is well beyond the annotation baseline.

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 identity ('Online discourse sample, NOT a poll') then packs pricing and constraints into one dense block with no filler sentences. It reads as a run-on in places, but every clause carries information.

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

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

No output schema exists, so the description compensates by sketching the return shape (per-side share with 95% interval and n, counts per source, links, caveats). Combined with the refusal and billing rules, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so q, sides and window are already fully documented in the schema with the same ranges, defaults and refusal notes. The description largely restates them (q required, sides 2-4, window 1-30d), adding little new semantic detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('see how public Hacker News and Bluesky posts split on a question') and explicitly disclaims being a poll. The named sources and the split-per-side output make it unmistakable against any sibling, none of which do sentiment/discourse aggregation.

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

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

Gives clear when-to-use ('use to see how public Hacker News and Bluesky posts split on a question') plus hard exclusions (elections, health, a named person's conduct). It does not point to an alternative sibling for questions outside scope, 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?

Excellent behavioral disclosure beyond annotations. Annotations cover readOnly and idempotent, but the description adds critical operational details: 200KB HTML cap, 8s timeout, private targets blocked, 422 no-match responses, no charge for errors, untrusted content warning, and pricing ($0.015 via x402, USDC on Base). This is rich context that annotations don't provide.

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?

Very dense and front-loaded, packing a lot of information into a short paragraph. Every sentence serves a purpose (usage, modes, return shape, limits, error handling, security, pricing). It's efficient and well-organized, though the density might require careful reading.

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?

Comprehensive for a web-scraping tool with no output schema. Covers return format explicitly (title, description, canonical, language, links, images, headings, jsonLd, textSample), limitations (caps, blocked targets), error handling (422, no charge), security warning (untrusted content), and pricing. 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 baseline is 3. The description goes beyond the schema by explaining the fields parameter's structure (name to CSS selector, max 20), its behavior (unmatched fields are null with fieldErrors), and that no-match means no charge. It adds practical meaning, though the schema already documents most parameters thoroughly.

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: 'Web scraping to JSON fields.' This is clear and distinguishes it from the sibling 'fetch' by emphasizing structured extraction into named fields. However, it doesn't explicitly contrast with 'fetch' or 'http', leaving some ambiguity about when this is better than those siblings.

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

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

Provides clear usage context: 'Use when you need specific data from a page.' Also distinguishes GET vs POST modes. It doesn't explicitly name alternatives like 'fetch' or say when NOT to use this tool, but the context is clear enough to guide 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description goes well beyond them: it documents the JSON return fields, hard caps (200KB, 8s, 3 redirects), the private/localhost block, that errors are not charged, the x402/USDC-on-Base pricing, and an explicit prompt-injection warning about untrusted returned content. That is exactly the extra context the 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?

Dense but front-loaded: the core purpose and trigger come first, then return shape, then operational limits, then security and payment caveats. Every sentence carries distinct, actionable information with no filler.

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

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

No output schema exists, but the description enumerates the returned fields (content, format, finalUrl, upstreamStatus, contentType, bytesRead, truncated) as well as limits, error behavior, and payment terms. Nothing an agent needs to invoke or interpret the call is missing.

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

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

Schema coverage is 100% on a single param, so the baseline is 3. The description adds real constraint detail the schema does not: the URL must be absolute http/https, private/localhost targets are rejected, and it is required — enough to edge above baseline.

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

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

States a specific verb+resource ('URL to markdown scraper') and frames the outcome ('read a public web page as clean text or markdown for an LLM'), which implicitly separates it from a raw HTTP sibling and from screenshot/pdf extractors. An agent can tell what this returns 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 a clear context trigger ('use when you need to read a public web page as clean text or markdown for an LLM') and a hard exclusion (private and localhost targets are blocked). It does not, however, name an alternative sibling (e.g. http, extract, search) or state when not to use it, so routing is left partly to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: payment terms ($0.003/call via x402, USDC on Base only), that errors are not charged, data freshness (~5 min), the source (OKX public data), and an explicit disclaimer that the crowding hint is not a forecast. This is exactly the value-add structured fields 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 purpose, then output shape, payment, freshness, and disclaimer in a logical order. It is a dense block of distinct facts with little redundancy, though the number of separate clauses makes it slightly heavier than the tightest examples.

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

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

With no parameters and no output schema, the description carries the full load, and it does: it enumerates the returned fields (instId, fundingRate, fundingTime, crowding hint with thresholds), specifies the source, pricing, freshness, and disclaimers. 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 and 100% schema coverage, so the baseline is 4. The description reinforces 'Call GET with no parameters,' which removes any ambiguity about invocation but adds no per-parameter meaning (there are none to add).

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 (perpetual futures funding rates) with the exact assets covered (BTC, ETH, SOL) and the data source (OKX USDT swaps). An agent can distinguish this from siblings like money_market_rates, gas, or market_quote without opening a schema.

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

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

Gives a clear when-to-use trigger ('Use when you need current perpetual futures funding rates') and a practical when-to-avoid ('Data changes about every 5 min; calling more often returns the same values'). It stops short of naming sibling alternatives for related rate data, so it is not a full 5.

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

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses the upstream data source with a fallback path, the fact that errors are not charged, the x402 price and settlement chain (USDC on Base, Base-only payments), and the ~1-minute refresh cadence with the note that more frequent calls return identical values. The 'descriptive, not a forecast' framing also correctly sets expectations about the response's nature.

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 usage, invocation, returns, provenance, and cost – a logical order with no filler sentences. The single return-value sentence is dense and enumerates six fields, but since no output schema exists that enumeration is load-bearing rather than padding.

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

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

For a zero-parameter, no-output-schema tool, the description covers everything an agent needs: what it returns field by field, units (gwei, ETH, USD), sourcing, staleness, cost, and payment chain. Safety semantics are already handled by annotations, so 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?

The tool takes zero parameters, so the schema carries no semantic load and the baseline is 4. The description affirmatively states 'Call GET with no parameters', which removes any doubt about whether arguments are expected, but adds nothing further since there is nothing further to add.

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

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

States a specific resource and scope: 'Gas price and gas fee estimate (Base, Ethereum)'. An agent can immediately distinguish this from sibling chain-data tools like tx_status, tx_guard, or balance without opening a schema, and the networks covered are named 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?

Gives clear triggering context ('Use before sending a transaction on Base or Ethereum to choose fees and timing') plus invocation guidance ('Call GET with no parameters'). It does not name adjacent alternatives such as tx_guard or tx_status, so no exclusions are offered, but the when-to-use signal 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?

Well beyond the readOnly/idempotent/destructive annotations, it discloses determinism, no outbound calls, no price lookups, no persistence, per-call pricing ($0.002 via x402, USDC on Base) and that 400/422 responses are not charged. Those billing and side-effect details are exactly the behavior an agent cannot infer from annotations.

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

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

It is a single dense paragraph, but purpose and input shape are front-loaded and every clause (output fields, error handling, pricing) carries information an agent needs. It reads as a run-on rather than cleanly separated sections, which costs it a point.

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 return payload (name, canonicalId, qty, unit, metric, category, optional/toTaste, prepNote, pack size/hint, merged shoppingList, unparsed lines) and covers failure modes and cost. Nothing needed to call or interpret the result is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: the alternate GET query form (ingredients=line|line), the coupling of servings with targetServings, and the envelope shape of the POST body. It does not add per-parameter limits beyond the schema's max 100 lines / 200 chars.

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 phrase 'Recipe to shopping list normalizer' names a specific verb (normalize) and resource (recipe ingredients → shopping list) rather than restating the vague tool name. It immediately distinguishes the tool from every sibling, which are all payment/infra/fetch utilities.

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 patterns — POST JSON with {ingredients, servings?, targetServings?} or GET with ingredients=line|line — and notes that servings must be paired with targetServings to scale. It does not state any when-not-to-use condition, but there is no sibling that overlaps functionally, so guidance is effectively complete.

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 mark destructiveHint/openWorldHint; the description goes far beyond by disclosing hard caps (384KB response, 64KB body, 12s, 3 redirects), SSRF protection, cookie behavior, the billing distinction between upstream 4xx/5xx (charged) and proxy errors (not), the $0.01 x402/USDC-on-Base cost, and a prompt-injection warning. That is unusually rich behavioral context an agent cannot get from the structured fields.

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

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

A dense single paragraph, but front-loaded with purpose and ordered sensibly (modes, return shape, limits, security, billing). Nearly every clause carries signal; a bulleted structure would have helped readability, but nothing is padding.

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

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

No output schema exists, yet the description enumerates the return fields (status, filtered headers, body as text/base64, contentType, finalUrl, elapsedMs), plus limits, security posture, error/billing semantics, and payment requirement. 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%, so the baseline is 3, but the description adds the calling convention the schema does not encode: method defaults to GET, headers are JSON, and the POST-JSON-body mode is an alternative envelope carrying url/method/headers/body. That clarifies how the four parameters combine at call time.

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/API proxy for public URLs', with the dual invocation modes spelled out (GET with url vs POST JSON {url, method, headers, body}). The purpose is unmistakable, but the description never names or contrasts itself with close siblings such as 'fetch' or 'search', leaving the agent to infer the distinction.

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 HOW to invoke (GET vs POST JSON) and states one exclusion ('private hosts blocked', 'no cookies sent'), but gives no explicit when-to-use/when-not guidance relative to alternatives like fetch or search. Usage is implied by the mechanics 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial context on top: single unpaid probe, no charge on bad input/blocked hosts, the exact cost ($0.005 per call, USDC on Base, Base-only for MCP payments), and a prompt-injection warning that returned content is untrusted third-party data. That is exactly the value-add expected beyond structured hints.

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

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

Front-loaded with purpose and usage before the return-shape inventory. It is dense and long-ish, but nearly every clause carries distinct operational information (cost, safety, untrusted-data warning) 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?

No output schema exists, yet the description fully sketches the return payload (verdict pay/caution/avoid with reasons, per-network terms, Bazaar entry, payTo cross-check with the mismatch rule, buy plan). Combined with the pricing and safety notes, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so both parameters (url, method) are already documented, including the https requirement and the GET-default/POST-405-retry behavior. The description restates the same facts without adding new syntax or format detail, so the baseline of 3 is appropriate.

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

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

Opens with a specific noun phrase ('x402 price quote') and immediately states the operation and its purpose: getting terms before paying an x402 seller. It also enumerates the concrete outputs (verdict, live terms per network, Bazaar entry, payTo cross-check, buy plan), so an agent knows exactly what class of tool this is versus siblings like bazaar_check or x402_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?

Explicitly says when to use it ('Use before paying an x402 seller') and reinforces the safe posture ('One unpaid request, never pays'), plus that bad input or blocked hosts incur no charge. It does not name an alternative tool (e.g. bazaar_check, x402_check) or state when not to use it, so it stops short of a 5.

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

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

Beyond the annotations (which already cover readOnly/idempotent/openWorld), the description discloses cost ($0.005 per call via x402, USDC on Base), the rail restriction (MCP payments Base only), the no-results-is-free rule, the no-paid-ranking/no-custody policy, and the key safety warning that returned content is untrusted third-party data. That is substantial behavioral context an agent cannot get from structured fields.

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

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

Front-loaded with purpose and usage, then parameters, then behavior, then price; each block is dense and mostly load-bearing. It is on the long side and the "No paid ranking; we hold no funds" sentence is partly promotional, but it carries trust-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 compensates by summarizing the return shape (ranked offers with price, rails, health, and a direct-pay buy plan) and covers cost, payment constraints, safety, and failure semantics. 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%, so the parameters are already documented, and the description's recital of q/n/kind/rail/max_price/min_health adds little. It does add the transport method (GET) and the top-3 live re-check behavior, but its rail enumeration (base/solana) is narrower than the schema's full set (xrpl, evm, polygon, CAIP-2), so baseline 3 is warranted.

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 ("Find x402 APIs: agent marketplace search") and scopes it to paid x402 APIs for a task. It does not, however, explicitly distinguish itself from nearby siblings such as bazaar_check, x402_check, or market_quote, 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?

"Use to find a paid x402 API for a task" gives a clear triggering context, and the pricing/rail notes implicitly bound when it applies. It stops short of stating when NOT to use it or naming an alternative tool for non-x402 search.

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

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

With no annotations, the description carries the full burden and does well: it discloses no payment/auth barrier, that data are passed through unchanged and may not be current, and enumerates the holiday-aware status values (fresh, PENDING, STALE, no publish, UNVERIFIED) that govern whether data is usable. It stops short of describing pagination or rate-limit behavior.

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

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

The core purpose and the free/no-payment note are front-loaded effectively. However, three sentences of affiliation/endorsement boilerplate and the verbatim repetition of schema parameter constraints dilute the payload.

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 indicate return contents, and it does: each rate's source URL, terms notices, and a holiday-aware status. Combined with explicit date/rate parameter semantics, an agent has enough to call and interpret the tool, though return shape is only sketched.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters and their constraints. The description restates the same 'last (1-10) or startDate+endDate (YYYY-MM-DD, <=31 days, >=2018-04-02)' rules without adding meaning beyond the schema, so baseline 3 applies.

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

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

The description names a specific resource (NY Fed reference rates: SOFR, EFFR, OBFR, TGCR, BGCR) and its mode of delivery ('as published'). It is clearly distinguishable from most siblings by resource, though it does not explicitly name the near alternatives like market_quote or market_search.

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 'FREE (no x402, no payment)' and 'market data only, not a forecast, not a recommendation,' which hints at routing versus x402_check and forecast-style tools. However, there is no explicit when-to-use statement or named alternative among the many market/tokenized-stock 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?

Well beyond the annotations (readOnly/idempotent/destructive/openWorld), it discloses failure transport (422 for image-only), the 100K char cap, the charging model (fails are not charged, $0.02 via x402/USDC on Base), and a security warning that returned content is untrusted. This is unusually rich behavioral context for a read 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?

It is front-loaded with the core purpose and every sentence carries information (constraints, return shape, billing, safety). The single dense paragraph is efficient, though the packing of pricing and metadata fields makes it slightly heavy 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?

With no output schema, the description fully specifies the return payload (pages, totalPages, pagesReturned, truncated, bytes, finalUrl, meta), coverage limits, error behavior, and billing, so an agent has everything needed to call and interpret the tool correctly.

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

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

Schema description coverage is 100%, so both parameters (url, pages) are already documented with their constraints. The description restates the same facts (http/https, max 10MB, pages 1-50, default 50) without adding format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

The description opens with a precise verb+resource ('PDF to text') and scopes it to 'the text of a public PDF' via GET. This clearly distinguishes it from generic siblings like fetch, http, and extract, letting an agent route PDF-extraction tasks here without opening a schema.

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

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

It gives strong implied usage context ('public PDF', http/https, max 10MB, no OCR so image-only PDFs get 422), which tells the agent when the tool will and won't work. However, it never names an alternative sibling (e.g., fetch or extract) or explicitly states when to prefer this tool over them, leaving sibling 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), yet the description still adds substantial context: which chains are read, which assets are covered, error behavior (400 on invalid address, not charged), and paid-call mechanics ($0.04 via x402, USDC on Base only). This is well beyond what structured fields 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 is front-loaded in the first two words, then usage, input contract, data scope, return shape, safety, and pricing follow in tight order. The dense return-field enumeration reflects the absence of an output schema, so no sentence is filler.

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

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

With no output schema, the description carries the return-value burden and does: holdings fields, totals, concentration score and band, and rule findings. Payment model, error semantics, and chain coverage are all addressed, so an agent has everything needed to invoke and interpret it.

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

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

Schema coverage is 100% on the single `address` parameter, which sets the baseline at 3. The description adds meaning the schema lacks — the explicit 40-hex format requirement ('0x... (40 hex)') and that the address is snapshotted on both Base and Ethereum — earning a bump.

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 ('Wallet balance checker') and narrows scope to 'token holdings and USD value of one EVM address'. It is clear what the tool does, but it never distinguishes itself from the sibling tool named `balance`, which an agent could easily confuse it 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?

The sentence 'Use when you need the token holdings and USD value of one EVM address' gives a concrete triggering condition. It stops short of the 5 bar because it names no alternative or exclusion, despite a near-identically named sibling (`balance`) that begs for disambiguation.

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

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

With annotations already covering read-only/idempotent/open-world, the description layers on genuinely new behavioral facts: $0.002 per call via x402 with USDC on Base (MCP payments Base-only), errors not charged, data source with CoinGecko fallback via the source field, ~1 min update cadence, and an explicit disclaimer that momentum/sentiment labels are fixed rules, not advice.

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 usage, then return shape and cost/caveats, so structure is sound. The return-value enumeration is a long comma-chained sentence, but nearly every detail (cost, source, cadence, disclaimer) is decision-relevant rather than filler.

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

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

With no output schema, the description carries the return-value burden and does so fully: nested asset fields (priceUsd, change24hPct, momentum), top-level momentum/sentiment/direction/avgChange24hPct/asOf, plus cost, source, and staleness. Nothing an agent needs to call or interpret it is missing.

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

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

There are zero parameters, so the baseline is 4; the description usefully confirms 'Call GET with no parameters', removing any doubt about required input. Nothing further is needed.

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

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

States a specific verb+resource ('Crypto prices API: BTC, ETH, SOL spot price') and pins the exact asset set and quote currency, which distinguishes it from siblings like market_quote and market_search. An agent can identify it without opening any schema.

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

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

Gives an explicit trigger ('Use when you need current BTC, ETH and SOL spot prices in USD') plus a refresh cadence warning that calling more often returns identical values, which implicitly steers agents away from polling. No explicit when-not or named alternative sibling, so it stops short of a 5.

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

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

Far exceeds the annotations: headless Chromium engine, 504 on >25s, sub-request checking, private target blocking, errors not charged, $0.02 x402/USDC-on-Base pricing, and a prompt-injection warning about third-party content. This is exactly the behavioral context annotations cannot convey.

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

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

Front-loaded with purpose, then params, then return fields, then limits/pricing/trust warning in a single dense block. Every clause carries information, though the packed run-on style costs a little readability.

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

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

With no output schema, the description fully enumerates the return payload (imageBase64, mimeType, width, height, bytes, finalUrl, pageStatus, title, blockedRequests) and covers timeout, error billing, payment rail, and trust caveats — nothing an agent needs 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 ranges, defaults and the enum are already documented in the schema; the description mostly restates them (width 320-1920, fullPage clipped at 4000px). It even cites a delayMs 0-3000 parameter that does not appear in the input schema, adding no reliable semantic value.

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 ('Website screenshot API') plus intent ('to see how a public page renders'), which separates it from fetch/extract/pdf siblings implicitly. It never names an alternative tool, so it stops 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?

Usage is implied by 'to see how a public page renders', and constraints (public URL only, private targets blocked, 25s timeout) are given, but there is no explicit when-to-use-this-vs-fetch/extract guidance or when-not to use it.

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

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

Goes well beyond the annotations by disclosing billing mechanics ('Billed if any result returns; zero results or provider errors are not charged'), price and payment rail ($0.03 via x402, USDC on Base), per-page content caps (12K chars), and a prompt-injection warning that returned content is untrusted. These are exactly the operational facts an agent cannot get from readOnlyHint/openWorldHint.

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 is front-loaded with purpose before mechanics, billing, and safety. Nearly every clause carries distinct information (return shape, limits, price, trust warning), though the run-on style slightly hurts scannability.

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 present, the description carries the full burden and does so: it enumerates the returned JSON fields (rank, url, title, snippet, ok/status, content, resultCount, fetchedOk), states content caps, and covers billing and trust caveats. An agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so both q and n are already documented with their constraints and defaults. The description restates q (max 300) and n (1-5, default 3) but adds no syntax, format, or query-building guidance beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb+resource ('Web search API with page contents') and adds the differentiator that top results are fetched as markdown, which separates it from siblings like fetch and extract. It stops short of naming those siblings explicitly, but the agent can tell it is a search-plus-content tool rather than a single-URL 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?

'For current info with sources' implies the use case but gives no explicit when-not conditions or named alternatives. An agent can infer it should call this for fresh web results, but the routing versus fetch/extract is left to inference.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), but the description adds hard-to-find context: per-call cost ($0.005 via x402, USDC on Base, MCP payments Base-only), that errors are not charged, null semantics for macd on thin candles, data source fallback chain, and the ~5-min refresh window. That is substantive behavior far beyond structured hints.

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

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

Front-loaded with purpose and usage, then progressively adds cost, freshness, and return-shape details; every sentence carries operational value. It is densely packed into long compound sentences, which slightly hurts scannability for an agent parsing it quickly.

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

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

There is no output schema, yet the description enumerates the return keys (rsi14, macd{macd,signal,histogram}, bollinger{upper,middle,lower,period}, lastClose, fundingRate/fundingTime) and their null cases. Combined with cost, freshness, and sourcing, nothing needed to call and interpret the tool is missing.

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

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

The tool takes zero parameters with 100% schema coverage, so the baseline is 4. The description reinforces this with 'Call GET with no parameters', leaving no ambiguity about invocation, but there is nothing further parameter-wise to clarify.

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 resource and the exact indicators returned (RSI, MACD, Bollinger), then scopes it to BTC/ETH/SOL. It explicitly distinguishes itself from price-oriented siblings with 'rather than just prices', so an agent can route between this and market_quote/funding without opening a schema.

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

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

States exactly when to use it ('when you need indicators... rather than just prices'), how to invoke it ('Call GET with no parameters'), and adds a cadence constraint tied to data freshness ('changes about every 5 min; calling more often returns the same values'). This is explicit when-to-use guidance with the sensible alternative 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 read-only/idempotent annotations by disclosing the paid-call economics ($0.002 via x402, USDC on Base, Base-only payments), the no-charge-on-failure policy for bad input or RPC outages, and an explicit prompt-injection warning that returned content is untrusted third-party data. These are material behaviors 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?

Front-loaded with the purpose and scoping, then packs payment, error, and safety semantics into short clauses with no filler sentences. Slightly dense and run-on, but each clause carries distinct information.

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

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

With no output schema, the description still enumerates the returned fields (paused flags, supply, supply cap, multiplier, issuer, token address), plus failure behavior and payment mechanics. An agent has everything needed to invoke and interpret 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 already 100%, so the baseline is 3, but the description adds genuinely useful semantics: accepted forms (bare ticker AAPL, suffixed AAPLc, or Base token address) and the meaning of omission (all 13 listed stocks).

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 check for Base") and immediately scopes what it covers: Coinbase tokenized stocks like AAPLc, NVDAc, TSLAc. It also explicitly excludes price data, which cleanly separates it from siblings such as market_quote or market_search.

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

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

Gives concrete usage context: pass an optional symbol in any of three forms, or omit it to get all 13. It implies but never names the alternative tool to use for pricing, so the routing guidance is clear but not exhaustive.

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, open-world), and the description adds substantial context beyond them: per-check verdict semantics (allow/warn/block), data provenance and staleness (Treasury snapshot with source URL and pull date, ScamSniffer list with up to 7-day delay), bad-input billing behavior, x402 pricing in USDC on Base only, and an explicit untrusted-content / prompt-injection warning. This is exactly the extra behavioral layer annotations cannot provide.

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?

Extremely dense but front-loaded: purpose first, then checks, then disclaimers, pricing, and the untrusted-data warning. Every clause carries information, though the telegram-style packing ('GET chain (base, polygon, solana, xrpl), to; optional expected, token') costs some readability.

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 describing return shape (per-check allow/warn/block, source URL and pull date in every response), coverage limits (chain list, 7-day list delay), and billing behavior. Nothing an agent needs in order to invoke and interpret this tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description nonetheless adds meaning by tying parameters to the checks they drive (expected → lookalike check, token → scam-token flag) and noting the chain enum. It does not clarify that token is Base/Polygon-only beyond the schema's own wording, so it is one step above baseline rather than fully additive.

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

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

The description opens with a precise verb+resource framing ('Pre-transfer recipient check') and enumerates exactly what is checked (lookalike, OFAC SDN, account age, scam-token flag), so an agent knows precisely what the tool does. It does not name any sibling tool (e.g. tx_status, x402_check) to draw an explicit boundary, so it stops short of a 5.

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

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

The 'pre-transfer' framing clearly conveys when to reach for this tool (immediately before sending funds) and the enumerated checks make the context concrete. There is no explicit when-not-to-use statement or named alternative for cases like post-transfer verification, which keeps it below 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 cover the read-only/idempotent/non-destructive safety profile, and the description adds substantially more: public RPCs, no charge on bad input or RPC downtime, x402 payment pricing in USDC on Base (MCP payments Base only), and an explicit warning that returned content is untrusted third-party data. That is rich behavioral context beyond the structured fields.

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

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

Dense but front-loaded: purpose first, then inputs, then return shape, then cost and safety caveats. Every sentence carries information, though it is on the long side and could be split for scannability.

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 the return fields (status, final, confirmations, block, fee, decoded token transfers, pollAgainSeconds), plus coverage of cost and input validity. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents both params, and the description largely repeats the accepted network values and the 0x-hash requirement. It adds only marginal value (the poll-until-final hint) beyond what the schema states, 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: it answers 'did a payment or swap land, and is it final.' It also names the two required inputs, so an agent can distinguish this status-lookup from siblings like tx_guard 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?

Usage is well-pictured: GET semantics, required tx, and network only for 0x hashes, plus an explicit retry rule ('poll again after pollAgainSeconds until final is true'). It does not explicitly name when to prefer this over tx_guard, but the operational context is clear.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description goes well beyond them: change-detection return shape, the 20-line cap on added lines, statelessness ('nothing stored'), SSRF guarding, non-charging on bad input/blocked/upstream errors, the $0.002 x402/USDC-on-Base price, and an untrusted-content warning. That is exactly the kind of operational detail an agent cannot get from annotations.

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

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

Front-loaded with the core purpose and the required/optional parameter pattern before cost and safety caveats. It is dense and somewhat run-on, packing payment, error-charging, and security notes into one paragraph, but nearly every clause carries decision-relevant information.

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

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

With no output schema and no annotations covering returns, the description steps in to specify the response (changed true/false, added lines up to 20, added/removed counts). Combined with the payment, error-charging, and SSRF notes, 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 both parameters are already documented, and the description's 'required url' plus 'since (state token from your previous answer)' largely restates the schema. It adds only minor workflow framing (omit on first check) rather than new syntax or format 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?

States a specific verb and resource ('Page change watch API: has a public web page or endpoint changed since your last check') and names the scope (public page or endpoint). An agent can immediately separate this from siblings like fetch or http, which retrieve content rather than reporting a change signal.

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 operating context: GET with required url, optional since taken from the previous answer for this url, and omit it on the first check. It establishes the polling workflow well, but never explicitly contrasts itself with the obvious alternative (fetch) or states 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 declare it read-only, idempotent and non-destructive, but the description goes well beyond: it never pays, sends exactly one unpaid request, and spells out the billing boundary (any HTTP answer including 4xx/5xx is billed; bad input, blocked hosts, connection failures and timeouts are not). It also discloses the transactional cost model — $0.01 per call, USDC on Base, MCP payments Base-only — which the agent cannot infer from annotations.

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

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

Well front-loaded: purpose, then when-to-use, then mechanics, return shape, billing rules and price. Every sentence earns its place, though the dense parentheticals make some clauses heavy going.

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

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

With no output schema, the description carries the return-value burden and does so fully, enumerating httpStatus, isX402, x402Version, decoded accepts, discovery metadata presence and pass/warn/fail checks. Combined with the billing and cost disclosures and annotations covering safety, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the parameters ('GET with required url (optional method GET/POST, JSON body for POST)') but adds no syntax or format detail beyond the schema, which actually carries more nuance (POST retry on 405, 8KB body limit).

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 ('x402 endpoint checker') and immediately narrows the scope: sends one unpaid probe request and never pays. That distinctively separates it from generic siblings like http, fetch, or 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?

'Use before paying an unknown x402 endpoint, or to debug your own' gives two concrete triggering scenarios. There is no explicit when-not or named alternative (e.g., versus bazaar_check or http), 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?

Goes well beyond the annotations by disclosing cost ($0.02/call via x402, USDC on Base), that errors are not charged, that data refreshes hourly and repeated calls return identical values, and the built-in TVL/outlier filters. These are exactly the operational facts an agent needs and none are in the structured fields.

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

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

Front-loads purpose then usage, return shape, filters, and pricing in order. It is dense and long for a single paragraph, but each sentence (cost, freshness, filters, return fields) carries distinct, useful information rather than padding.

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

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

With no output schema, the description enumerates the returned fields (project, chain, symbol, tvlUsd, apy, apyBase, apyReward, apyMean30d, stablecoin, exposure, ilRisk, poolId) plus ordering and caps, and covers cost and freshness. Nothing needed to invoke it correctly is missing.

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

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

Zero parameters, so the baseline is 4; the description confirms 'Call GET with no parameters,' removing any ambiguity about whether arguments are expected.

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 ('DeFi yields and APY') and scope ('stablecoin and DeFi pools'), and names the distinguishing use case, letting an agent separate it from siblings like money_market_rates or funding.

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

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

Gives clear when-to-use guidance ('Use when you need to compare current DeFi pool yields, especially stablecoin or single-asset pools') but never names an alternative sibling tool or states when NOT to use it, so the routing is implied rather than explicit.

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