Settled

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses real operational traits: a 300 calls/day free cap shared with HTTP free routes, a pass that lifts the cap, and a 5-minute cache that force bypasses at the cost of requiring a pass. It stops short of describing error/limit-exceeded behavior or result freshness guarantees.

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?

Rate-limit and caching context is usefully front-loaded, but the sentence then becomes a long comma-separated enumeration of returned fields. Since an output schema exists, that return-value listing duplicates structured data and dilutes the front-loaded 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 an output schema present, the description needn't explain return values, and it covers the key operational facts (free cap, pass, cache, force). What is missing is the sibling boundary against settled_preflight/peek, which an agent would need to select correctly among 18 tools.

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 all three parameters (url, pass, force) are already documented in the schema, including the header alternative and the pass requirement for force. The description largely restates the same cache/pass semantics rather than adding new meaning, so the baseline 3 applies.

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

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

The verb+resource are explicit ('Check an x402 endpoint before paying it') and the enumerated return surface makes the tool's scope concrete. It does not, however, distinguish itself from closely named siblings like settled_preflight or settled_peek, leaving an agent to infer the boundary from names alone.

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

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

'Check an x402 endpoint before paying it' gives a clear usage context, and the cache/force/pass notes explain operational conditions. There is no explicit when-not or named alternative (e.g. use settled_preflight for X), so the routing decision is only implied.

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 readOnlyHint=false, destructiveHint=true and idempotentHint=true; the description reinforces this by explaining that action:remove withdraws the claim. It also adds substantive context beyond annotations: the Free cost, the two-step challenge/signature auth flow per chain (EIP-191 on Base, ed25519 on Solana), and the reassurance that 'Claims never change scores'.

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 'Free.' followed by the core action, then the signed two-call flow, then the removal caveat. It is dense but each sentence carries distinct, actionable information with minimal waste.

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

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

An output schema exists, so return values need not be detailed, and the description covers the auth flow, signature formats, cost, and removal semantics adequately. Minor gaps remain (e.g., behavior when the wallet has no endpoints, or confirmation of idempotency), but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already documents each field and baseline is 3. The description adds procedural meaning by explaining how wallet, issued_at and signature relate across the two calls and that action:remove withdraws a claim, which goes beyond the field-level schema text.

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: 'Claim every x402 endpoint paid to your wallet' with a clear two-call workflow. The purpose is unambiguous and an agent can immediately tell what the tool accomplishes. It does not, however, explicitly differentiate itself from siblings like settled_sellers or settled_submit.

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 lays out the exact usage sequence: first call with wallet to obtain message_to_sign/issued_at, then call again with issued_at and signature, and note that action:remove withdraws a claim. This is clear contextual guidance. It stops short of naming when to prefer this tool over sibling alternatives 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?

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond annotations: a free daily quota of 300 calls per client and that events are returned newest first, with concrete categories of changes. It omits auth/pass details, but those are in the schema.

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

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

Three sentences with no wasted words. The quota note is front-loaded, followed by the event scope and the polling alternative. Slightly unusual ordering, but still appropriately sized and easy to parse.

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

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

With an output schema and complete parameter descriptions, the definition is largely self-sufficient. It covers purpose, usage, rate limits, event types, and ordering. It could more explicitly mention authentication/pass handling, but that is covered in the schema.

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

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

Schema description coverage is 100%, so both parameters (pass, limit) are fully documented in the schema. The description adds only 'newest first,' which is already in the limit parameter description, so it does not meaningfully extend parameter semantics.

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

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

States the resource clearly as a change feed of recent events and lists concrete event types (venue verdict flips, new suspected honeypots, settlement-integrity changes). It distinguishes the tool from re-reading the scorecard, but does not name or differentiate from sibling tools like settled_status or settled_peek.

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 to poll this instead of re-reading the scorecard, which provides a clear alternative and use context. However, it does not state when not to use this tool or name specific sibling alternatives beyond the scorecard.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's main addition is the quota behavior: 300 free calls/day shared with the HTTP free routes, liftable via a pass. That is genuinely useful operational context, but nothing is said about caching, result freshness, or how often the live status is re-verified. (Note: openWorldHint=false sits oddly against a tool that queries live endpoints across networks, but the description does not contradict it.)

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

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

Two dense sentences with no filler, and the discovery semantics are front-loaded. The opening quota/pricing sentence is arguably the less important half of the definition for tool selection, but it is short and useful.

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?

Six of seven parameters are documented in-schema, an output schema exists so return values need no explaining, and quotas are covered. What is missing is the decision context an agent needs in a large sibling set: whether to call this before settled_check, what 'live' status means, and how the pass relates to the sibling tools that also consume quota.

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

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

Schema description coverage is 100%, so both the meaning and the examples for q, pass, sort, limit, status and network already come from the schema. The description merely restates the keyword/network/max-price/sort dimensions without adding format details, defaults, or precedence rules beyond what the schema provides.

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: ranked discovery of live x402 endpoints, with the ranking dimensions (keyword, network, max price, sort) and per-result signals (payability, delivery verification). It is clearly distinct from siblings like settled_check or settled_preflight, though it never names or contrasts an alternative explicitly.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no routing to sibling tools despite a 17-tool family containing plausible alternatives (settled_check, settled_preflight, settled_status). The free-cap sentence hints at cost but does not tell an agent when this discovery tool is the right choice.

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

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

Annotations already establish the safe read-only, idempotent, open-world profile, so the bar is lower; the description still adds real value by disclosing the authentication requirement ("Pass required") and the concrete flag categories it evaluates. It does not discuss rate limits or cost, but for a read-only scan this is solid disclosure.

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

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

Three dense sentences with zero filler, and the auth prerequisite is front-loaded before the mechanics. The parenthetical flag list is long but directly actionable rather than decorative.

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 spelled out, yet the description still tells the agent it gets trust, label and per-flag reasons. For a two-parameter read-only scan, nothing an agent needs in order 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 description coverage is 100%, so both parameters are already documented in the schema and the baseline is 3. "Pass required" adds the useful fact that authentication is mandatory rather than optional as the schema's required list implies, but no further syntax or format detail is provided 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 (fetches, scans) and resource (bounty issue, repository, listing page) and enumerates the exact pattern classes it looks for, so the agent knows precisely what this tool produces. It is clearly distinguishable from siblings like settled_preflight or settled_seller_reputation.

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?

"Call before working on an unfamiliar bounty" gives an explicit trigger condition, which is exactly the routing guidance an agent needs. It stops short of naming an alternative or stating when not to call it (e.g. versus settled_preflight), so it falls short of a 5.

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

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

Annotations already declare this a safe, idempotent, read-only, closed-world read, so the burden is lighter. The description still adds real value beyond them: authentication is required, suspected honeypots, dead and human-only listings are filtered out by default with a named opt-out, and each row carries heuristic scan flags with reasons plus an on-chain payout record.

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

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

Two sentences with the hard prerequisite ('Pass required') front-loaded, followed by one dense but purposeful sentence covering scope, provenance, payload and default exclusions. Efficient, though the second sentence is a long field list that could be trimmed given the schema lists the same fields.

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

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

An output schema exists, so return values need no explanation, yet the description helpfully previews the key fields. Auth, defaults, filtering rules and the opt-out are all covered; the only missing piece is how this call relates to its sibling listing/venue tools.

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% (8 params, each documented, two with enums), so the schema carries the parameter semantics and a 3 is the baseline. The description only restates the include_honeypots and agent-access behavior in prose, without adding syntax, defaults, or interaction rules the schema does not already cover.

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 clear resource - open bounties/tasks an agent can actually work on, sourced from sanctioned venue APIs - and enumerates the payload (reward, access policy, gating, honeypot flags, trust score, payout record). It does not explicitly contrast itself with the nearest siblings such as settled_income_venues or settled_income_check, so an agent still has to infer the split from the names.

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 precondition ('Pass required') and the default filtering behavior, including the override condition ('unless include_honeypots is true'), which tells the agent when to flip the flag. There is no explicit routing guidance telling the agent to prefer settled_income_venues for venue slugs or another sibling for a different query type.

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

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

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral value beyond that: it is free to call, and it discloses the verdict taxonomy and that gating signals (KYC, human claim, self-custody) and escrow payout data are included, telling the agent what judgment the data supports.

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 sentence, front-loaded with the cost signal and then the content categories. The colon-list is information-dense rather than padded, though it reads as a feature dump that could be trimmed slightly.

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

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

With an output schema present, the description need not explain return shape, and with zero parameters there is no input contract to document. It covers scope and content categories well; the only gap is freshness/source recency, which an agent making a money decision might reasonably want.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to carry; baseline is 4. Nothing in the description misdescribes the (empty) input contract.

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 enumerates its exact contents: a scorecard of bounty boards, task markets, audit contests and x402 sell-side, with a named verdict taxonomy. An agent can distinguish this from settled_income_listings and settled_income_check 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?

"Free." signals no credit cost, which is a mild usage hint, and the resource makes the intended context (an agent looking for venues that actually pay) fairly obvious. However, it never says when to use this versus settled_income_listings or settled_income_check, and gives no exclusions.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the call is free, rate-limited, returns coarse/cached data, and performs no fresh probe — all of which affect how an agent should treat the result.

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

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

Two terse sentences with zero filler; the cost/rate-limit caveat and the cached-data scoping constraint are both front-loaded. Every fragment earns its place.

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

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

An output schema exists, so return-value detail is not required. For a single-parameter read tool, the description supplies the essential caveats (free, rate-limited, coarse, no fresh probe); only an explicit pointer to the probing alternative 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 one parameter at 100% schema description coverage, the schema already documents the required URL and even gives a format example, so the baseline is 3. The description restates 'one x402 endpoint URL' but adds no syntax or format 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 ('Peek') and resource ('one x402 endpoint URL') and specifies what is returned: coarse status and a quality score. The parenthetical '(no fresh probe)' implicitly separates it from a probing sibling, though the distinguishing sibling is not named.

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

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

'Free, rate-limited' and 'no fresh probe' imply the conditions that favor this tool (cheap, cached lookup) over a probing alternative, but no sibling is named and no explicit when-not is stated. Usage is implied rather than spelled out.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering safety and idempotency. The description adds valuable context: 'Pass required,' 'one signed answer,' and the fact that it reuses a result up to 5 minutes old unless force is true. It reveals that the result is signed and includes a recommendation, which goes beyond annotations. It doesn't discuss rate limits or failure modes, but the added detail is substantive.

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

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

The description is a single, dense sentence that front-loads the key requirement ('Pass required') and the primary use case. It is appropriately sized for a complex tool and every clause adds information. It could be slightly more scannable, but it avoids waste.

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

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

An output schema exists, so the description needn't explain return values, and it doesn't. It covers the major checks performed, the signed answer, and the cache behavior. However, for a tool with openWorldHint and a claimed 'one signed answer,' it doesn't clarify what the signature guarantees or how the recommendation should be interpreted. Contextual completeness is adequate but not rich.

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

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

Schema description coverage is 100%, so the schema already documents url, pass, and force thoroughly. The description reminds that a pass is required and that force overrides the 5-minute cache, adding meaning beyond the schema for force. It doesn't add syntax or format details for url or pass beyond the schema, so it's slightly better than baseline but not exceptional.

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 performs a pre-payment safety check on an unfamiliar x402 endpoint. It enumerates the checks (liveness, quote, payability, payTo existence, seller endpoints, settlement integrity, delivery result, honeypot scan), making the purpose clear. It does not explicitly differentiate itself from siblings like settled_check or settled_verify, but the depth of pre-spend verification distinguishes it contextually.

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

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

It clearly says this is 'the one call to make before paying an unfamiliar x402 endpoint,' which sets the usage context. It implies when to use it (before paying an unknown endpoint) but does not explicitly state when not to use it or name alternative tools for different scenarios. No exclusions or alternatives are given, 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?

Beyond the annotations (idempotentHint=true, non-destructive), the description discloses substantial behavior: it is free, signing is required via EIP-191 personal_sign by the paying wallet with an exact message, one report per payment, one vote per wallet per endpoint, tallies only count after 3+ distinct wallets, and only per-endpoint tallies are retained. These are meaningful constraints 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?

It is front-loaded ('Free.'), then ordered from intent to inputs to rules. Every sentence carries weight, though the dense embedded signing-message string slightly stretches readability for a single description.

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

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

An output schema exists, so return values need not be explained. The description nonetheless completes the picture with auth/signature requirements, rate/duplicate limits, tally thresholds, and retention behavior, leaving nothing an agent needs to call it correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description goes further by spelling out the exact signed-message format the signature parameter must match and the lowercase requirement for tx, adding real meaning beyond the schema for the signature field.

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

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

The description states a specific verb and resource: report whether a paid x402 call worked, with the payment context (on Base, USDC). This is clearly distinct from outcome-adjacent siblings like settled_verify or settled_submit, so an agent can tell what this tool does 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 a clear activation context ('after paying an x402 endpoint on Base') and a workflow instruction ('call without a signature to get the exact message_to_sign'). It stops short of naming alternative sibling tools or stating explicit when-not-to-use conditions, so it falls just under the top bar.

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, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that a pass token is required — which goes beyond the annotations, but it says nothing about rate limits, failure modes, or result freshness.

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

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

Two sentences with the auth prerequisite front-loaded, which is the right priority. The second sentence is a dense comma-separated list, but no sentence is wasted.

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

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

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The auth requirement and the shape of returned data are covered, leaving only usage/alternative selection unaddressed.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, and the description adds no syntax, format, or constraint detail beyond what is there. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description enumerates the data returned (endpoints served, live/dead counts, price range, flags, settlements, payers) rather than stating a clear verb+resource purpose. Combined with the title 'Seller reputation by payTo address' an agent can infer the intent, but the description itself never says it looks up a seller's reputation and never distinguishes it from siblings like settled_sellers or settled_find_endpoints.

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 only usage-adjacent statement is 'Pass required,' which is a prerequisite rather than when-to-use guidance. With 17 sibling tools, no condition or alternative is named to help the agent choose this over settled_sellers or settled_find_endpoints.

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 behavior, so the bar is lower. The description goes beyond them by disclosing that the call is free and by explaining what 'claimed' actually means (one signature covers every endpoint and host paid to that wallet), plus pagination with a total.

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

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

Two dense sentences, front-loaded with the key qualifying detail ('Free.') and ending with the paging contract. The parenthetical on wallet/signature semantics is long but earns its place by defining the filter condition.

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-value shape need not be explained, and annotations carry the safety profile. Combined with the qualification semantics, contents, and paging behavior given here, an agent has enough 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 fully documented with types, bounds, and defaults. The description restates the limit/offset paging model and the total but adds no syntax or format 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 identifies the specific resource returned (sellers who proved wallet control, with profile and endpoint counts) and clarifies the qualification semantics. It reads more as a description of the record set than an explicit action verb, and it does not differentiate itself from nearby siblings like settled_seller_reputation or settled_find_endpoints.

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 leading 'Free.' signals no cost barrier, implying this is a safe browse-first call, but there is no explicit when-to-use guidance or routing to alternatives such as settled_seller_reputation. Usage context is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the cost model ('Free') and the scope of what is indexed, which is genuine added context, but says nothing about rate limits, auth, or result staleness semantics.

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

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

Two short fragments with zero filler, and the cost signal is front-loaded ahead of the content description. The one-word sentence 'Free.' is terse but earns its place; the style is slightly clipped rather than polished.

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

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

With an output schema present, the description does not need to enumerate return fields, and with no input parameters there is nothing else to document. For a simple status probe it is essentially complete, only missing context on how to act on the freshness data.

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

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

The tool takes zero parameters and the input schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-argument tool.

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

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

The description names the concrete resources it reports on (the x402 endpoint index and the on-chain ledger) and the two dimensions returned (size and freshness). That is enough for an agent to know this is a status/health read, though it does not explicitly contrast itself with siblings like settled_peek or settled_preflight.

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

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

The leading word 'Free' implies this call costs no credits, which is a usable selection signal against paid siblings, but the description never states when to call it versus settled_preflight or settled_peek, nor any prerequisites. Usage is only implied.

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=false, destructive=false, idempotent=true and openWorld=true. The description usefully adds that the call is free and rate-limited, and the word 'Queue' implies asynchronous processing, but it gives no specifics on the rate limit or what happens after queueing. This is genuine added value beyond the annotations, but thin.

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

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

Two short fragments, front-loaded with the cost/rate-limit caveat before the action. Nothing is wasted, though it is so terse that it arguably under-specifies rather than optimizes.

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

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

With an output schema present, return values need not be explained, and the single parameter is fully covered by the schema. What is missing is any guidance on auth requirements, duplicate submissions, or what indexing entails after the queue step, leaving the agent with a minimally viable picture.

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 'url' parameter is fully documented in the schema as a URI to an x402 endpoint. The description adds no format, constraint or validation detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb (Queue) and resource (an x402 endpoint URL) with the goal (for indexing), which clearly separates it from sibling readers like settled_find_endpoints, settled_check and settled_verify. It does not explicitly name those siblings, so it falls 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 description says what the tool does but never states when to use it versus alternatives such as settled_check, settled_verify or settled_watch, nor any prerequisites or when-not conditions. The only contextual cue is 'for indexing,' which merely restates the purpose.

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

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

Annotations already establish readOnly/idempotent/non-destructive. The description adds value beyond them by disclosing that it is free (cost), that it recomputes a hash and recovers the signer (the mechanism), and that it reports authenticity and integrity. It stops short of describing failure behavior for tampered or missing attestations.

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

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

Two tight sentences with the cheap-cost signal front-loaded, then the core action and outcome. No filler and nothing buried.

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

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

An output schema exists so return values needn't be explained, and the safety profile is covered by annotations. The description is complete enough for a one-param verification tool; only the failure/negative-result behavior is left implicit.

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

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

With a single parameter at 100% schema coverage, the schema already documents 'document' and its attestation requirement. The description's 'any signed Settled response (attestation included)' restates the schema rather than adding new syntax, 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 gives a specific verb+resource ('Verify a signed Settled response') and then states exactly what happens: recompute the hash, recover the signer, and report authenticity/integrity. This is distinct from siblings like settled_check or settled_preflight, so an agent can route correctly without reading 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?

It clearly states the input condition to invoke it ('pass any signed Settled response') and adds a cost signal ('Free'), giving clear context for use. It does not name alternatives or an explicit when-not, so it falls short of the 5 reserved for definitions that route between 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?

Annotations only say this is a non-read-only, non-idempotent, open-world call. The description adds the full behavioral picture: price ($1.00 USDC on Base), payment rails (x402 inside MCP, first call returns payment requirements), monitoring cadence, what triggers a signed alert, and validation before any charge.

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

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

Front-loads the cost and payment mechanics, then renewal, webhook, and fallback in a single dense paragraph. Every sentence carries information, though the run-on structure and embedded parentheticals make it heavier than ideal.

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

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

An output schema exists, so return values need not be explained, yet it still notes watch_id is returned. Payment/auth requirements, failure behavior (refused before payment), and the non-MCP fallback are all covered, leaving nothing an agent needs missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: watch_id renews for 10 more days on the same feed rather than creating a new watch, and webhook is optional with alerts otherwise readable via settled_watch_alerts. It stops short of clarifying precedence if both url and watch_id were supplied.

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 action (buy a watchdog) on a specific resource (one x402 endpoint) with concrete scope (10 days, ~15-minute probes). It is clearly distinguished from the sibling settled_watch_alerts, which is named as the read path rather than the purchase path.

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 covers the url-vs-watch_id branching for new vs renewal purchases, when to supply a webhook versus reading alerts via settled_watch_alerts, and gives a non-MCP fallback (POST /v1/watch over x402). It also states the precondition that bad urls/webhooks are rejected before 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 already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds non-obvious context: the call is free, the backend probes roughly every 15 minutes, and next_since should be threaded to the next call. These behavioral details go beyond what the 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?

Two tight sentences, front-loaded with the free/polling cue and the payload description. It is information-dense without wasted words, though the packed clause listing change types is slightly heavy.

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

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

With an output schema present, the description needn't explain return values, and it still covers cost, cadence, scope, and the pagination handoff. Nothing essential for calling 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 description coverage is 100%, so the schema already documents watch_id, since, and limit. The description reinforces the since/next_since pagination pattern but adds no syntax or format detail beyond what the schema provides; baseline 3 is appropriate.

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

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

The description states a specific resource and scope: everything a Watchdog has recorded for its endpoint since an alert id, listing the change types (status, payability, price, payTo). It clearly differs from sibling reads, but it never contrasts itself with a named alternative such as settled_check or settled_status, 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?

"Poll it whenever your agent runs; the endpoint is probed about every 15 minutes" gives concrete when-to-use and cadence guidance tied to the 15-minute probe cycle. It lacks any explicit when-not-to-use or alternative-tool routing, but the operating 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 declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description does add two pieces of non-annotation context: it is free to call, and the data is a published (i.e. not real-time) snapshot. It says nothing about publication cadence, caching, or rate limits, so it clears the lowered bar without being rich.

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 sentence, front-loaded with the cost qualifier 'Free' and then the payload. The colon-delimited content list is dense but readable. Minor cost: the 'Free.' fragment is slightly clipped, but nothing is padded or redundant.

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

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

With zero parameters, a full output schema, and complete annotations, the description only needs to say what the report is and what it contains — which it does. The remaining gap is not knowing how current 'latest published' is or whether the report is weekly-cadence fixed, a minor omission for a read-only report tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly avoids inventing parameter semantics that do not exist.

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 — the latest published weekly report — and enumerates its contents (venue payouts, worker wallets, honeypots, x402 index health), so an agent knows exactly what comes back. It stops short of distinguishing itself from the near-identical sibling 'settled_report', which is the one place confusion is most likely.

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

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

There is no when-to-use guidance beyond the implicit 'you want the latest report'. With a similarly named sibling (settled_report) and adjacent tools like settled_events and settled_income_check, the description offers no routing rule or exclusion criteria to pick between them.

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