SpendPreflight

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

Annotations declare readOnly/openWorld=false/idempotent, and the description adds substantial non-redundant behavior: no fetching of the caller's URL, no payment to the endpoint, no charge for unlisted/unavailable/stale data, $0.005 per cached lookup, a shared 3-call/day free trial, and the exact payment continuation protocol with 'stop and get approval' semantics. It also pre-empts a likely misinterpretation by explaining that an unknown score means missing evidence, not endpoint failure.

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 sibling routing are front-loaded and effective, but the body is heavily padded: disclaimers repeat ('not a guarantee', 'illustrative output excerpt, not a live result...', 'freshness/data/availability checks still apply'), and the multi-sentence payment walkthrough dominates the tool's description. Useful information is present but buried in boilerplate that 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?

For a cached lookup with an output schema and full annotation coverage, the description covers everything an agent needs: input exactness, pricing and free-tier limits, unknown-score semantics, scope exclusions, and safe payment handling. Nothing required to call it correctly or interpret a null 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 100% and both parameters are documented, so the baseline is 3; the description slightly exceeds it by reinforcing that the URL must be exact and already public, and by supplying a concrete minimal input example. It does not add new format or syntax detail beyond what the schema already says about the method parameter.

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

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

States a specific resource and scope: cached x402 endpoint observations returning a transparent score, its components, and seven-day unpaid probe history for an already-listed URL. It explicitly distinguishes itself from siblings by naming check_payee and preflight_payment and stating what each is for, so an agent can route without opening schemas.

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

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

Explicit when-to-use ('endpoint history and price context before paying'), explicit alternatives with conditions ('check_payee for wallet/name screening or preflight_payment for an allow/hold/block decision'), and a parameter-level usage rule ('add method when the URL has multiple advertised methods'). Negative guidance is also present: it never fetches the caller's URL and is not a compliance guarantee.

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 readOnlyHint/openWorldHint, it discloses that only public HTTPS targets are accepted, that no payment or request bodies are stored, that pricing is $0.05 USDC on Base, that a shared 3-calls-per-IP-per-UTC-day trial exists and is shared with HTTP trials, and that a generic MCP connector cannot complete a paid continuation. It also sets explicit expectations about the result (riskScore, flagged spans, rewrite suggestions) and states the important limitation that this is not Coinbase policy certification or guaranteed detection.

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 alias/routing statement is correctly front-loaded, but the body is roughly 350 words mixing purpose, screening scope, pricing, two illustrative output excerpts, payment-protocol steps and wallet-safety policy. The payment walkthrough and repeated 'illustrative only, not a live result' disclaimers are operational boilerplate that crowds out the tool's actual contract.

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 illustrative response excerpt (cdpPreflight, riskScore, flags, suggestedRewrite, screenComplete) valuably conveys the return shape, and the safety disclaimers and cost model are all present. The main gap is method-parameter behavior, but otherwise an agent has enough to call it correctly and interpret the result.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partly does: 'Public HTTPS only' constrains the url parameter, the 'no request bodies stored' note hints at POST semantics, and one minimal input example is repeated from the schema. The method enum (GET/HEAD/POST) is never explained — what method means for the target fetch, or when to choose each — so half the parameter surface remains undocumented.

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 plainly that this is a compatibility alias of listing_guard performing the same operation, and then describes the resource concretely: CDP technical validation plus a heuristic metadata screen covering URLs, tool calls, invisible Unicode, long fields and outlier prices. An agent can distinguish it from listing_guard without opening either schema. It falls short of 5 only because the core purpose is buried mid-sentence inside a long single-sentence block.

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 an explicit routing rule: use listing_guard for a new detailed metadata check, keep this only for existing clients, and warns the two are 'the same operation, not two independent checks' so they should not both be called. It also spells out the exact escalation path (try the shared free allowance first; on payment required, stop; obtain approval; retry with the x402 payload) and explicitly forbids silent fallback to payment.

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

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

Annotations only declare readOnly/idempotent/openWorld; the description adds the actual screening sources, the risk enum returned, example flags, the freshness disclaimer, and the full free-trial-then-paid-x402 flow including what not to do. The only deduction is the boilerplate payment prose restated in several forms, some of which repeats rather than adds.

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?

Essential purpose, trigger and alternative are front-loaded in the first three sentences. The tail, however, is a long payment-mechanics block plus two overlapping 'illustrative output excerpt / not a live result' disclaimers that pad rather than inform.

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

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

An output schema exists, yet the description still explains the risk levels and flags usefully; combined with pricing, the at-least-one-input rule, and the sibling routing, an agent has everything needed to call it. Minor redundancy with the output schema rather than a gap.

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

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

Schema coverage is 100% (baseline 3), but the description adds a constraint the schema does not express: all three params are optional yet 'at least one of domain, address, or name' is required, and inputs may be combined. It also restates that domain accepts hostname or URL, which the schema already says.

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 ('Screens a payee wallet address and name against the OFAC SDN sanctions list and checks the merchant domain's registration age and DNS') and names the sibling it is not (preflight_payment). An agent can distinguish it from check_token, check_endpoint and preflight_payment without opening a schema.

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

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

Explicit trigger condition ('Call this before a USDC payment when you only have a payee name, wallet or domain') plus an explicit alternative and the condition that selects it ('For an x402 challenge or cart... use preflight_payment instead'). Nothing is left to inference.

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

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

Annotations already declare read-only, open-world, non-destructive behavior, and the description adds substantial context: bounded public-chain reads, OFAC screening, unknown data handling, absence of a safe-to-buy verdict, trial limits, and payment requirements. It also discloses unassessed risk categories and the informational-only 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?

The purpose is front-loaded and the information is mostly relevant, but the text is very long and repeats pricing and trial details. Payment mechanics and disclaimers dominate, reducing conciseness even though the structure remains readable.

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

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

Given the tool's complexity, paid access flow, tiered behavior, and lack of output schema, the description is highly complete. It includes an illustrative output excerpt, unassessed categories, pricing, trial limits, and payment handling 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the basic/deep tier distinction and provides an example input, but it does not fully define the address and chain parameters beyond the example and schema constraints.

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 operation: Base contract safety signals from public-chain reads and OFAC. It clearly differentiates basic versus deep tiers, but does not name or distinguish itself from sibling tools such as security_check or check_payee.

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 what basic and deep cover and explicitly lists what is NOT assessed, which helps set expectations. However, it gives no explicit guidance on when to choose this tool over alternatives like security_check, check_payee, or check_listing.

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?

Substantial disclosure beyond the annotations: fixed Cloudflare DoH resolver, 7 queries per shared 8s window, 128KiB cap, no SMTP, no query storage, no DNS changes, and explicit 'unknown' semantics for missing selectors or inherited DMARC. The idempotentHint=false annotation is consistent with the warning that live DNS results vary. It stops short of 5 because much of the behavioral text is defensive boilerplate repeated around payment rather than crisp operational fact.

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, which is good, but the text is a dense wall that repeats the price twice ('0.005 USDC' then 'Price: 0.005 USDC'), packs a full x402 payment protocol into a tool description, and appends multiple disclaimer sentences. A large share of the content does not help an agent decide or invoke, so it fails the 'every sentence earns its place' test.

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 supplying an illustrative output excerpt showing spf.status, dmarc.status, dmarc.alignment_verified, mx.status and smtp_reachability, plus explicit unknown semantics. Coupled with rate limits and payment requirements, an agent has enough to call it correctly; only the illustrative (non-normative) nature of the return shape leaves a small gap.

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

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

Schema description coverage is 0%, so the description carries the burden. It does clarify that 'domain' is a public domain and that 'selectors' are DKIM selectors the caller supplies, and provides a minimal input example plus the rule that absent selectors yield 'unknown'. However it never states that selectors is optional or capped at 3, and the maxLength/pattern constraints in the schema are unexplained in prose.

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 names a specific verb and a well-defined resource set: MX, SPF, direct DMARC, supplied DKIM selectors and resolver-reported DNSSEC evidence. An agent can immediately tell this is an email-authentication DNS observation tool. It loses a point only because it never references a sibling, and the closest-sounding sibling (security_check) is left un-contrasted.

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 rather than stated: 'Observe a public domain's ... records' plus the caveat that 'Missing selectors and inherited DMARC policy stay unknown' and 'Published records and resolver AD are not proof of inbox delivery.' There is no explicit when-to-use/when-not or named alternative, so the agent must infer that this is the pre-check for domain-based mail posture.

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

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

Annotations only cover readOnlyHint and openWorldHint (both consistent with a static archived snapshot read), so the description's additions are genuinely load-bearing: snapshot staleness, unknown current conditions, cost of $0.01 USDC, the shared free allowance, and the exact x402 retry protocol including '_meta["x402/payment"]' and the prohibition on separate USDC transfers or silent fallback. That is unusually rich behavioral disclosure 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?

Purpose is front-loaded, but the text is bloated with near-duplicate hedging ('Illustrative output excerpt' repeated, 'not a live result, signature, approval or guarantee' stacked with 'Freshness/data/availability checks still apply') and a payment walkthrough longer than the tool description itself. Many sentences do not add 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 does supply an illustrative response shape and the key caveat that distances are 'great_circle_not_road_distance', and it covers cost and payment mechanics thoroughly. What's missing is coverage area of the snapshot and parameter meanings, but an agent could call it correctly from this text.

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

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

Schema description coverage is 0%, so the description must compensate. It provides a concrete example object covering all five parameters and the phrase 'straight-line proximity' implicitly explains radius_km, but it never defines what 'service' enum values mean, what 'limit' bounds, or how radius and limit interact. Partial compensation only.

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 (nearest RV dump/water stations) and names the exact data source (FillPoint's dated September 17, 2026 ODbL snapshot), with the computation method spelled out as bounded straight-line proximity. It doesn't need sibling differentiation because no sibling in the list is a proximity/station lookup, but the signal is diluted by payment boilerplate that follows.

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 explicitly lists what the tool is NOT for: 'not live access, potable-water assurance or road routing', plus 'Freshness/data/availability checks still apply', which effectively tells an agent when to reach for other tools. It also clearly defines the free-trial path (3 eligible calls per IP per UTC day) versus paid continuation and instructs STOP-and-approve before paying. No named alternatives are given, which keeps it below a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral scope in the negative: it 'performs no payee screening or payment decision' and takes no arguments, which prevents an agent from wrongly expecting a decision from it. Return format is left to the output 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?

Three sentences, front-loaded with the identity of the tool and its contents, then routing guidance. Dense but every clause carries routing or scope information; the middle 'optional' clause is slightly redundant with the preceding conditional but not wasteful.

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

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

An output schema exists, so return values need not be described. For a zero-argument reference tool with full annotation coverage, the description supplies everything needed to choose it correctly versus its three siblings.

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 reinforces this with 'Takes no arguments,' matching the empty schema and the 'Example arguments: {}' note. No parameter semantics are needed or 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+resource ('free, read-only service reference') and enumerates the exact content it returns: prices, default spending rules, payment setup, trial allowance, and an example call. An agent can distinguish this from check_payee and preflight_payment immediately.

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 when-to-use conditions and names both alternatives with their selecting conditions: 'If you already have a payment challenge or cart, call preflight_payment directly; this reference call is optional' and 'Use check_payee for standalone payee risk.' Nothing is left to inference.

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

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

Goes well beyond the annotations: discloses the pricing model, that no payment or credentials are transmitted, what the heuristic riskScore means, and explicit caveats that scores are not safety or Bazaar-acceptance guarantees. Minor tension: annotations set readOnlyHint=false while the description frames the call as a passive, unpaid, non-mutating GET; openWorldHint=true does explain the external reach, so this reads as conservative annotation rather than a real conflict.

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 branding ('Free x402 Lint by SpendPreflight') and then packed with pricing, caveats, a CI Action URL, and a badge path that most agents will never need. The useful routing and constraint sentences are there, but they are buried among promotion and infrastructure detail.

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

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

With no output schema, the description still enumerates the return payload (riskScore 0–100 or unknown, fixes, seven-day report link) and the failure modes it cannot cover. What is missing is only shape-level detail, such as field names or how 'unknown' is distinguished, which is a modest gap for a one-parameter diagnostic tool.

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

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

Schema coverage is 0% for the single url parameter, so the description has to carry the meaning, and it does: the argument must be a public HTTPS endpoint and must not be a private URL. That constraint, plus the schema's embedded example, is enough to fill the parameter's semantics even without a formal field description.

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

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

States a specific verb and resource (lints a public HTTPS endpoint via an unpaid GET) and enumerates exactly what is inspected: v1/v2 challenge shape, payTo/asset/network syntax, price, Bazaar metadata, CORS headers. That scope is distinct from siblings like check_endpoint or security_check, so an agent can route 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 clear operating conditions: free passive check by default, optional $0.10 full report but 'no automatic payment', and 'no paid call is made', which tells the agent the free path is the default. It also states exclusions ('GET cannot validate a POST-only endpoint or paid delivery') and a privacy rule ('Do not submit private URLs'), though it never names a sibling tool or the situation that would select one.

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 this as read-only and open-world, and the description adds substantial context beyond them: it states limitations (not policy certification or guaranteed detection), data-handling constraints (no target payment or request bodies stored), public-HTTPS-only scope, trial/payment behavior, and what happens if payment is required. These details materially improve safe 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?

The purpose is front-loaded, but the description is heavily bloated with repeated disclaimers, duplicate price statements, illustrative-output caveats, and lengthy payment instructions. Much of this is useful operationally, but the repetition and volume reduce clarity and make it harder to extract the core tool-selection and invocation guidance.

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

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

With no output schema, the description usefully names returned fields and includes an illustrative output excerpt, and it covers key safety and payment constraints. It is complete enough to understand the tool's scope and billing model, though the lack of method semantics and sibling-routing guidance leaves minor gaps.

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

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

Schema description coverage is 0%, so the description needs to compensate for two required parameters. It adds only the useful constraint that the URL must be public HTTPS and repeats a minimal example; it does not explain the method enum values GET/HEAD/POST, when each is appropriate, or why method matters for the screen.

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: CDP technical validation plus a bounded heuristic metadata screen for Bazaar listings. It also enumerates what is screened (agent-directed instructions, embedded URLs, tool calls, invisible Unicode, long fields, anomalous prices) and what is returned. It is clear, but it does not explicitly distinguish itself from close siblings such as check_listing or check_endpoint.

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 screening behavior and heavily covers payment mechanics, but it gives no explicit when-to-use guidance versus alternatives. With siblings like check_listing, check_endpoint, and lint_endpoint present, an agent must infer selection rather than being routed by the description.

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 (readOnlyHint, openWorldHint), it discloses cost ($0.01 USDC on Base), that ambiguous matches fail without charge, what a successful response contains (signed observation, OFAC flags, confirmations, printable HTML), and a detailed x402 payment-continuation protocol. The payment boilerplate is somewhat generic and the price is stated twice, which keeps it from a 5, but the safety-relevant context (never send a separate transfer, never paste keys, inspect unknown-outcome authorizations) is genuinely 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 useful content is front-loaded, but the text is bloated: the price appears twice ('Price $0.01 USDC on Base... Price: 0.01 USDC'), and the illustrative-output disclaimer is restated two sentences apart. The long payment-procedure block, while relevant, crowds out the input contract.

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 compensates with an illustrative response shape and a list of returned artifacts, and it explains the payment handshake an agent must follow. With six optional parameters and a novel pricing model, the definition is nearly sufficient to invoke correctly; only the parameter-level edge cases and effective timeout/retry behavior remain thin.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: log_index is framed as a disambiguator for tx_hash, amount is required to be exact decimal, and start/end must be past and span at most 90 days — constraints absent from the schema. It does not describe log_index bounds or the amount precision limit of 6 decimals that the schema encodes.

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

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

The description names a specific verb and resource ('Verify a native Base USDC transfer') and enumerates the two accepted lookup modes. It also bounds scope negatively ('Not invoice ownership or finality proof'), which helps an agent avoid over-reading results, though it never positions itself against the sibling 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 states the two concrete input paths (tx_hash with optional log_index, or pay_to + amount + start/end within 90 days) and the failure condition ('Ambiguous matches fail without charge'). It also states there is no free trial and that a non-x402 MCP client cannot complete a paid call, which is clear when-to-use context. It stops short of naming an alternative tool for cases this one declines.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=false; the description adds substantial context beyond that. It explains the allow|hold|block decision, receipt creation on repeat calls, the no-sign/no-settle/no-hold guarantee, pricing, trial allowance, and the requirement to stop and inspect payment terms before continuing.

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 opening sentence is well front-loaded, but the description is long and contains redundancy, such as the price appearing twice and repeated 'illustrative' caveats around the output excerpt. The payment how-to is useful but could be tightened for an agent that mainly needs selection and invocation guidance.

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

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

Given the complexity of x402 payment flows, nested inputs, annotations, and an output schema, the description covers what the tool returns and how to invoke it safely. Nothing critical is missing for an agent to decide whether to call it and how to proceed after a payment-required response.

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, but the description adds practical meaning: it says to send the x402 PaymentRequired body (v1 or v2) or a cart, enumerates the optional rules categories, and notes spent_today_usd's role in the daily cap. The minimal input example further clarifies intended argument shape.

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: call before any x402/USDC payment to evaluate a challenge or cart before signing. It clearly distinguishes itself from check_payee by scope (payment preflight vs. standalone screening), so an agent can choose without opening either schema.

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

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

Explicitly says when to use it ('before any x402/USDC payment', 'before every payment') and names the alternative for a different need: check_payee for standalone wallet/name/domain screening without a payment. It also covers the retry path after payment approval, which is unusual and valuable 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?

The description contains rich behavioral detail, but it contradicts the readOnlyHint=true annotation by repeatedly stating that a usable comparison costs $0.001 USDC, requires payment, and requires a signed x402 payment payload. A paid operation that settles or requires wallet approval is a side effect and cannot be treated as read-only, so the description contradicts the structured annotation.

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, but the description is long and repetitive: it repeats the price, payment warning, illustrative-output caveat, and x402 payment procedure multiple times. Much of the payment safety guidance is useful, but the text is not tightly edited.

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 comparison tool with no output schema, the description supplies an illustrative output excerpt, explains unknown/no-charge behavior, and details the x402 payment flow. It still omits parameter semantics and explicit sibling routing, but otherwise gives an agent enough operational context to avoid unsafe payment handling.

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

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

Schema description coverage is 0% and there are six parameters, so the description must carry the burden. It provides an example covering url, amount, payTo, asset, and network, but does not explain amount units, asset/network formats, payTo semantics, or the optional method parameter, leaving important parameter meaning implicit.

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: compare a supplied x402 quote against cached public unpaid quote data and retained history. It is clear enough to distinguish this as a historical quote comparison rather than a payment approval tool, though it does not explicitly differentiate itself from sibling tools such as preflight_payment or security_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?

It gives clear usage context: this is informational historical comparison, not payment approval or loss prevention, and it explains that missing/stale/ambiguous evidence returns unknown without charge. It does not name specific sibling alternatives, but it does set useful boundaries around when this tool is and is not appropriate.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description goes well beyond them: exact price (0.10 USDC on Base), no trial and no automatic payment, what is explicitly NOT disclosed (paid-response caching, replay/idempotency, header parser behavior, settlement-before-delivery), that resource binding is 'advertised only', and that results are not an audit or safety guarantee. It even gives an illustrative output showing assessment_complete=false and unknown_count=5, correctly labeled as not a live result, and prescribes behavior for an unknown payment outcome rather than auto-retrying.

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?

Core facts are front-loaded, but the body is heavily padded with near-duplicate disclaimers: two separate 'Illustrative output excerpt' passages and repeated 'not a live result / signature / approval / guarantee' caveats around an already-shown example. The payment safety instructions are valuable yet restated in multiple forms, roughly doubling the length without adding new 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 paid, no-output-schema tool this is thorough: price and asset/network, example arguments, an illustrative (clearly marked non-live) response shape, explicit statement of which risks remain unmeasured, and the exact payment handshake. An agent has everything needed to decide whether it can call this and how to proceed if payment is demanded.

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

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

Schema coverage is 0% for the single report_id parameter, so the description must carry the meaning — and it does: the id must come from an existing, unexpired, complete free Lint report, and an example UUID is supplied. What is missing is whether an expired or incomplete id produces a specific failure mode beyond the generic 'freshness/data/availability checks still apply' line.

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 the resource and scope precisely: detailed passive findings plus source-linked fixes drawn from an already-existing, unexpired free Lint report, with 'No new target request' making clear it does not scan anything new. That implicitly separates it from the scanning sibling (lint_endpoint), though the sibling is never named directly, so an agent must infer the handoff relationship.

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

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

Explicit sequencing: inspect the free Lint summary first, obtain a current complete report_id, use only an x402-capable MCP client, and on payment-required STOP and get explicit wallet/budget approval before letting the client attach _meta["x402/payment"] and retry the identical arguments. It also names the failure mode ('a generic MCP connector without payment support cannot complete a paid continuation') and forbids silent fallback from free to paid, which is unusually complete routing guidance.

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

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

Annotations only say readOnly/openWorld=false; the description adds substantial context beyond them: results come from a cache with no new endpoint request, ranking inputs (observed unpaid availability, 402 shape, price consistency, Lint risk), that missing evidence stays unknown, and that scores are not safety or proof of paid delivery. The payment-failure and unknown-outcome handling rules are exactly the kind of behavioral disclosure an agent needs and 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?

The purpose and pricing are front-loaded and the 'How to pay (MCP)' section gives readable structure. However, the 'Illustrative output excerpt' and its 'not a live result / signature / approval or guarantee' boilerplate appear twice, and the stacked Never/Only-after hedges add bulk without new 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 paid, stateful-looking read tool with no output schema and 0% param coverage, the description does cover pricing, payment handshake, failure handling and a sample response shape. It is still incomplete on two of four parameters and never states what the ranked result fields actually contain beyond the empty-results excerpt.

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

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

Schema description coverage is 0%, so the description carries the full burden, yet only 'capability' and 'limit' get any treatment (example input plus 'up to 12' free-vs-paid framing). The 'network' and 'max_price_usd' parameters are never explained, leaving half the inputs with no semantics anywhere.

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 'Search cached public x402 sellers by capability' states a specific verb, resource and scope, and 'cached public' implicitly separates it from the check_* / lint_* siblings that probe live endpoints. It stops short of naming an alternative tool, so a 5 is not warranted.

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 conditions: first three matches free, extended results cost 0.01 USDC, no shared trial, and a generic MCP connector without payment support cannot complete a paid continuation. It also prescribes the STOP / inspect accepts / obtain approval / retry with _meta['x402/payment'] flow. What it lacks is guidance on when to choose this index versus check_endpoint, check_listing or lint_endpoint.

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 readOnlyHint=true and openWorldHint=false; the description goes far beyond them, disclosing cost ($0.02 per calculation / 0.02 USDC), that inputs are not stored, a 3-call-per-IP-per-UTC-day free allowance shared with HTTP trials, that a non-x402 MCP client cannot complete a paid continuation, and explicit stop/retry semantics via _meta['x402/payment']. It also states the results are illustrative and not live, and warns against silent free-to-paid fallback and automatic retries on unknown outcomes — exactly the operational hazards an agent 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?

The purpose is correctly front-loaded in sentence one, and the input/output examples are useful. But roughly two-thirds of the text is payment and legal boilerplate, and the output excerpt is presented twice with redundant disclaimers ('Illustrative output excerpt...' repeated), which dilutes the signal an agent needs to decide and call.

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

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

For a read-only calculation with no output schema, the description does supply an illustrative output shape (daily_energy_wh.battery_side, pv.minimum_nameplate_watts, assumptions flags), plus the nested-argument example, so an agent knows roughly what comes back. Remaining gaps are per-field semantics for panel_watts and inverter_efficiency rather than anything about behavior or return values.

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

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

Schema description coverage is 0% (only a bare example sits in the schema's description field), so the description must carry the load; it partially does by naming loads, peak sun hours, PV losses and optional battery assumptions, and by giving a concrete nested example. But panel_watts and inverter_efficiency appear only in the example or not at all, and nothing explains units or meaning for peak_sun_hours or how load watts/quantity interact. Partial compensation, not full.

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 names a specific artifact ('Off-grid PV energy-balance estimate') and the computation it performs (loads + peak sun hours + PV losses -> energy balance). It also states explicit non-scope (no location/weather lookup, electrical design, surge or installation certification), which prevents the common misread of this as a full design tool. It does not name a sibling alternative, but the sibling set (endpoint/listing/payment checks) is so far from this domain that no differentiation is needed.

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 lists the inputs to supply and marks the battery assumptions as optional, which implies the calling context, and the exclusion sentence rules out weather/location-based sizing. However, it never states positively when an agent should reach for this tool versus reasoning about PV sizing itself, nor what result to expect from omitting battery versus providing it. The lengthy payment procedure is 'how to pay', not 'when to use'.

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, the description discloses cost (0.01 USDC), a shared trial of 3 calls per IP per UTC day, that 'not-read is uncharged', that there are nine explicit outcomes, that the result is a signed JSON observation rather than an approval, and that payment requires explicit wallet/budget approval with no silent fallback. These are exactly the side-effect and failure-mode details annotations cannot convey. It stops short of enumerating the nine outcomes or saying what triggers each, which would be the full 5.

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

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

The purpose and the pinned-block scope are front-loaded, which is good, but the body is bloated: the illustrative-output disclaimer is stated twice ('not a live result, signature, approval or guarantee'), and the x402 payment walkthrough runs several sentences longer than needed. Dense but padded with repeated caveats.

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 showing an illustrative result object with kind/outcome/block_number/block_timestamp plus a jws field, which is genuinely useful. However, with a nested requirement object, an undocumented agentId/registry, and nine unenumerated outcomes, an agent still lacks enough to predict what it will get back or how to fill the optional fields.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it only partially does. The inline example illustrates the nested requirement object (scheme/network/asset/amount/payTo) and resource_url, but agentId and registry — including that registry expects an eip155:chainId:0x... form — are never explained in prose.

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 a specific verb and resource: verify a payee binding via endpoint origin plus ERC-8004 agent wallet or EIP-712 delegation at a pinned registry block. That is far more specific than a restated title. It does not, however, distinguish itself from sibling tools such as check_payee, preflight_payment, or security_check, which an agent would need to 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 only implied: the tool verifies payee binding before paying, and the description says the result is 'not payment approval' and that freshness/data checks still apply. No sentence says when to call this instead of check_payee or preflight_payment. The bulk of the 'how' text is payment-transport mechanics, not tool-selection 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?

Adds substantial behavior beyond the annotations: hard limits (1000 transfers / 128 RPC calls / 25 seconds), failure-without-charge semantics, exact price and network, x402 payment mechanics including _meta["x402/payment"] retry, and warnings against silent fallback or duplicate authorizations. This is rich context an agent could not infer 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?

The purpose is front-loaded, but the body is heavily bloated: price is stated three times ('Price $0.05 USDC on Base. No free trial. Price: 0.05 USDC.'), disclaimers repeat ('Illustrative output excerpt' twice, 'not tax advice'), and payment instructions dominate over core tool semantics. Meaningful content is buried in redundancy.

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

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

Covers the essentials an agent needs for a paid, read-only export: input example, output shape excerpt, limits, failure behavior, and payment flow. Output schema is absent but an illustrative excerpt is supplied. The verbosity costs some clarity, but nothing critical 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 0% schema description coverage, the description carries the burden and largely does: it gives a full minimal input example, states start/end boundary semantics, and identifies format as json/csv. The address parameter is only conveyed via the example rather than explained (no mention that it must be a 40-hex 0x address), so a small gap remains.

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: 'Export native Base USDC wallet transfers as JSON or CSV for a past range up to 90 days.' The scope (native Base USDC, 90-day window, json/csv) is unambiguous. It does not explicitly contrast with any sibling, but the resource is distinct enough from the check_*/quote_* siblings that an agent can select it correctly.

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 usable preconditions: past ranges only, max 90 days, start inclusive/end exclusive, no free trial, and a detailed payment-required workflow with an explicit instruction to STOP and seek approval. It lacks explicit routing to alternatives (e.g., when to prefer payment_receipt or check_* instead), 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.