Settled

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

Goes well beyond the readOnly/idempotent annotations by disclosing quota mechanics (25/day per address, 300 with a payer record, uncapped with a pass) and cache staleness (up to 5 min), which materially affect result freshness and failure modes. It also surfaces downstream workflow obligations (submit if unknown, report after paying).

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

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

Dense but every sentence carries information; the use/not-for/next-step structure is easy to parse. Mild weakness: the pricing/quota sentence is front-loaded ahead of the core purpose, so the most decision-relevant statement is not first.

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 only cover selection, cost, and caching — all of which it does, plus cross-tool handoffs. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by tying the free-tier behavior to the payer record/pass and by framing `force` as a probe that bypasses the 5-minute cache and requires a pass. It does not add syntax or format detail beyond the schema, hence not a 5.

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 concrete verb+resource ('Check an x402 endpoint'), names the data source ('Settled's index, cached up to 5 min'), and enumerates the returned signals (status, payability, latency, price/network/payTo, payee history, reports, risk flags). It also explicitly separates itself from settled_preflight (fresh probe) and settled_find_endpoints (search), so an agent can pick it 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 explicit 'Use when' (deciding whether to call an endpoint; routine re-checks) and 'Not for' clauses naming the two alternatives. It further routes follow-ups: settled_submit when status is unknown, settled_report after paying — a full decision tree rather than an implied 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 declare the write/idempotent/non-destructive profile, and the description adds substantial context on top: it is free, requires a two-step sign-then-submit flow, only the payTo wallet may sign, action=remove is reversible by re-claiming, and claims never change scores. That covers cost, auth, side effects, and an important non-effect.

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 audience and value, then use/not-for, then the flow, then the remove caveat. Dense but every clause (cost, signature flow, reversibility, score neutrality) carries information an agent needs.

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

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

For an 8-parameter, annotated, write tool with an output schema, the description covers audience, precondition, two-step flow, cost, and removal semantics. Return values are covered by the output schema, so nothing essential is missing.

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

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

Schema coverage is 100%, so the individual fields are already documented. The description adds cross-parameter semantics the schema cannot convey: the ordering between wallet/profile, message_to_sign/issued_at, and signature across two calls, plus the action=remove behavior. It stops short of deeper per-parameter detail, which the schema already owns.

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 (claim) and resource (x402 endpoints paid to your wallet), and names the audience (sellers). It is clearly distinguishable from siblings like settled_check, settled_watch, and settled_income_* which serve different purposes.

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 'Use when: you operate x402 endpoints' and 'Not for: buyers or third parties; only the payTo wallet can sign,' giving both the trigger condition and the exclusions/precondition. This is textbook when/when-not 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 rate-limit and quota tiers (25/day, 300 with payer, uncapped with pass) that annotations do not carry, plus result ordering — genuine context beyond readOnly/idempotent hints. It does not disclose how far back events are retained or that there is no cursor parameter, so 'what changed since last time' implies statefulness the schema can't support.

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

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

Dense but every sentence carries information: quota, payload contents, usage trigger, exclusions, and polling advice. The quota line leads, which delays the purpose statement slightly in favor of operational constraints.

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 annotations, full schema coverage, and an output schema, the remaining burden on the description is small and it covers usage, quotas, and alternatives. The notable omission is how much history is available and how to avoid re-processing events when polling, which matters for the scheduled-agent use case it recommends.

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 value by explaining what a pass and payer record buy in quota terms, mapping free-tier behavior to those two parameters. It says nothing extra about `limit` beyond the schema's own 1-200/default-50 documentation.

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

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

Names the resource concretely and enumerates the event types returned (venue verdict flips, new honeypots, settlement-integrity changes) with ordering (newest first). An agent can tell it apart from settled_income_venues and settled_watch 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?

Uses explicit 'Use when' / 'Not for' framing and names the two alternative siblings with the conditions that select them. It also states the operational preference: poll this instead of re-reading 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 safety (readOnly, idempotent, non-destructive, closed-world), but the description adds genuinely non-structured behavior: a free quota of 50 calls/day, a pass lifting it to 1,000, and the fact that results carry payability and delivery verification. It doesn't discuss result volume/pagination beyond the schema's limit, which keeps it just short of a 5.

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

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

Three compact sentences that front-load the quota and the ranked-results framing, then the routing guidance. Densely packed but every clause carries information; no filler.

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

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

With 8 optional params, full schema coverage, annotations, and an output schema in place, the description supplies exactly the missing layer: quota behavior, what the ranking means, when to use it, and the required follow-up check before paying. Nothing an agent needs to select or call it is absent.

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

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

Schema description coverage is 100%, so every parameter is already documented, including the sort enum and the CAIP-2 network format. The description only restates keyword/network/price/sort semantics and adds no format or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('find/rank live endpoints') plus the filters and sort dimension, and frames the result set (payability and delivery verification). It is clearly distinct from the sibling set, which is mostly per-URL checkers and seller/reputation 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?

Explicit 'Use when' condition, an explicit 'Not for: verifying one known URL (settled_check)' exclusion naming the alternative, and an 'After' step routing to settled_check or settled_preflight before paying. This is the full when/when-not/next-action triad.

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

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

Annotations cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds real context beyond them: an auth requirement ('Pass required'), the returned fields (trust, label, every flag with its reason), and decision guidance ('Treat a suspected_honeypot label as do-not-work; a clean result is not a promise of payment') — the last being a key non-obvious behavioral caveat.

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

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

Front-loaded with the blocking constraint ('Pass required'), then what it does, what it returns, usage routing, and interpretation caveat. Four dense sentences with no filler; every clause carries information an agent needs.

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

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

An output schema exists, so the description needn't enumerate return fields, and it still summarizes them (trust, label, flags with reasons). Auth, scope, sibling exclusions, trigger conditions and result interpretation are all covered for what is a read-only scan tool.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds a clarifying constraint not evident from the schema: the pass token is effectively mandatory ('Pass required'), explaining why it sits in properties but not in the required array (it may arrive as the x-settled-pass header). The url parameter's meaning is left entirely to the schema, so this is a modest but genuine addition.

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

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

Specific verb+resource: fetches a bounty issue, repository or listing page and scans it for bait patterns, with the pattern categories enumerated (hidden HTML-comment instructions, prompt injection, credential requests, fork/star anomalies, dead/archived repos, reward anomalies). It explicitly differentiates from the sibling settled_check by scope ('Not for: x402 API endpoints'), so an agent can select correctly without opening a schema.

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

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

Gives explicit when-to-use ('about to work on an unfamiliar bounty or task, especially one not in settled_income_listings'), an explicit when-not ('x402 API endpoints'), and names the alternative tool (settled_check). Nothing about tool selection 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 establish readOnly/idempotent/non-destructive, and the description adds useful behavior beyond that: the pass prerequisite, the exclusion defaults (honeypots, dead, human-only), and the trust/honeypot fields returned. It does not spell out pagination or pass failure behavior, but the safety profile is well covered.

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 requirement and the result set, then the when/not-for clauses, then a follow-up instruction. Dense but every clause carries routing or behavioral information; only mild redundancy in restating the exclusion policy already implied by the param.

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, and the description still names the key fields. Combined with annotations and the explicit sibling routing, an agent has everything needed to call this correctly and follow up with settled_income_check.

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 eight parameters are documented in the schema (enums, defaults, ranges). The description only reinforces a couple of defaults (include_honeypots, agent-access gating) and adds no syntax or format detail beyond the schema. 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 opens with a clear scope statement ('Open bounties and tasks an agent can actually work on, from sanctioned venue APIs') and enumerates the data each listing carries. It names the sibling it is not for (settled_income_venues), letting an agent separate this listing tool from the venue-level tool 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?

Explicit 'Use when' and 'Not for' clauses name the exact alternative (settled_income_venues), and the exclusion behavior is stated ('Suspected honeypots, dead and human-only listings are excluded unless ...'). It also routes a follow-up action ('run settled_income_check on its URL'), which is real invocation guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: it is 'Free', it surfaces gating requirements (KYC, human claim, self-custody wallet), it implies the underlying data changes over time by recommending settled_events polling, and it enumerates the verdict values an agent will receive.

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

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

Front-loaded with the most decision-relevant word first ('Free.'), then the resource scope, then use/not-for routing and a polling hint. The verdict enumeration is dense but each token is decision-relevant; only the length of the single paragraph slightly hurts scannability.

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

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

An output schema exists, so return values need no explanation, and with zero parameters there is no input contract to document. The description covers purpose, routing to siblings, gating caveats, data freshness, and cost — everything needed to call this correctly.

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

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

The tool takes zero parameters, so the baseline is 4 and there are no parameter semantics for the description to compensate for. Schema coverage is 100% and the description correctly spends no space restating inputs.

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 (a scorecard of bounty boards, task markets, audit contests and the x402 sell-side) with its scope spelled out via the verdict taxonomy (paying / paying small / measuring / no payouts seen / unmeasured / closed to agents / defunct). It explicitly names the sibling tools it is not (settled_income_listings, settled_find_endpoints), 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?

Contains an explicit 'Use when:' clause (choosing where an agent should look for paid work, or checking whether a venue actually pays) and an explicit 'Not for:' clause naming the two alternative tools for individual listings and x402 endpoints. It also pre-empts re-polling by directing the agent to settled_events for changes.

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 safety profile (readOnly, idempotent, non-destructive, non-open-world), and the description adds traits annotations cannot convey: it is free but rate-limited, results come from the index rather than a live probe (staleness), and the unknown-URL fallback path. This is exactly the extra context the scoring bar rewards.

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 cost and scope in the first sentence, then gives 'Use when' / 'Not for' / fallback in tight sequence. No sentence is redundant and each carries routing or cost information.

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

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

An output schema exists, so return-value detail is unnecessary. For a one-parameter read tool, the description covers cost, freshness limitation, sibling routing, and the unknown-URL recovery path — everything needed to invoke it correctly.

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

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

Schema description coverage is 100% and the single url parameter already has a format constraint and a worked example. The description only echoes the parameter as 'one x402 endpoint URL', adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('coarse status and quality score for one x402 endpoint URL') plus the scope constraint ('from the index only, no fresh probe'). An agent can distinguish this from settled_check and settled_preflight without opening any schema.

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

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

Uses explicit 'Use when:' and 'Not for:' clauses, names the two alternative tools with their cost/freshness tradeoffs, and routes the unknown-URL case to settled_submit. Nothing about when to pick this tool is left to inference.

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

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

Annotations already cover safety (readOnly, idempotent, openWorld, non-destructive), but the description adds context they do not: authentication ('Pass required'), the freshness model behind force (probe now vs. reuse a result up to 5 minutes old), and that the output is a signed answer with a pay/caution/avoid recommendation. It stops short of stating failure modes or rate limits, so a 4 rather than 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?

Front-loaded with the critical constraint ('Pass required'), then intent, then Use when / Not for / After in a scannable structure. It is dense and slightly long, but nearly every clause carries operative information rather than filler.

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

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

An output schema exists, so return values need no elaboration; the description still flags that the response is a signed recommendation with reasons. Combined with the use-when/not-for/after guidance and the auth requirement, an agent has everything needed to decide, invoke, and sequence this call correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: 'Pass required' ties the pass parameter to an auth gate, and 'a fresh probe' explains the semantics of force (probing now rather than reusing a cached result). The url parameter is left to the schema's own description.

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

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

The description names a specific action (a pre-spend probe/check) on a specific resource (an x402 endpoint about to be paid) and enumerates exactly what the check composes: fresh probe, parsed quote, payability, payTo on-chain history, seller integrity, scout delivery result, honeypot scan. It clearly separates itself from settled_check ('stale or not enough') and from 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?

Explicit 'Use when: real money is about to leave your wallet and settled_check was stale or not enough' and 'Not for: browsing (settled_find_endpoints) or endpoints you already verified', plus a named follow-up sequence ('compare pay_to and price ... pay, then call settled_report'). Alternatives and exclusion conditions are stated directly.

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

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

Annotations declare a non-read-only, idempotent, non-destructive write; the description adds substantial context beyond that: the tool is free, requires an EIP-191 signature from the paying wallet, has rate/consistency limits (one report per payment, one vote per wallet per endpoint), and retains only per-endpoint tallies. These are real behavioral facts the annotations do not convey.

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

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

Front-loads 'Free', then separates Use-when, Not-for, and Flow into scannable clauses with no filler. Every sentence carries actionable information.

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

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

For a two-phase signed write with an output schema present, the description supplies the when/when-not, the signing flow, and the retention/rate constraints an agent needs. Return values are covered by the output schema, so no gap remains.

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

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

Schema description coverage is 100%, with each field already documenting its type, pattern, and role, including the 'omit on first call' signature behavior. The description restates the same tx/url/ok/signature semantics in scenario language but adds no format or syntax detail beyond the schema, so the baseline 3 applies.

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

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

The description states a precise verb and resource (report whether a paid x402 call worked) and anchors it to a concrete scenario: an agent that just made a real USDC payment on Base and holds the tx hash. It is clearly distinguishable from siblings like settled_check and settled_verify without opening any schema.

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

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

Explicit 'Use when' (just paid, has tx hash) and 'Not for' (unpaid endpoints, other chains) clauses remove ambiguity, and the two-step flow tells the agent exactly how to proceed. Nothing about selection or prerequisites is left to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, but the description still adds valuable operational context: 'Pass required' flags the auth prerequisite and the field list tells the agent what evidence the judgment rests on. It stops short of describing freshness or rate limits, so not a full 5.

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

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

Three tight sentences, front-loaded with the payload summary then the when/when-not routing, with zero filler. Every clause carries selection-relevant information.

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

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

An output schema exists, so return-value documentation is unnecessary, and the description covers selection, auth prerequisite, and input provenance. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100% and the schema already states the 0x+40-hex format and the 402-quote provenance, so the description largely restates what is structured. 'Pass required' and 'Input is the wallet address from a 402 quote' add workflow context but no new syntax or semantics 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 and resource ('Everything Settled knows about one payTo address') and enumerates exactly what is returned: endpoints, live/dead counts, price range, clone-farm and quote-only flags, settlements, unique payers. This is clearly distinguishable from settled_check, which it names as the single-endpoint alternative.

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

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

Explicit when-to-use ('several endpoints share a seller', 'a payTo looks unfamiliar') and explicit when-not ('Not for: a single endpoint's status') with the named alternative (settled_check). 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 establish readOnly, idempotent and non-destructive behavior, so the description isn't burdened with the safety profile. It adds context the annotations lack: the call is 'Free,' it is paged with a total, and claims never alter scores. It stops short of describing sorting or what fields a profile contains, but with an output schema present that is acceptable.

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

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

Information-dense with zero filler: cost, definition, when/when-not, and paging are all front-loaded and each sentence earns its place. 'Free.' as a leading word is a deliberate, useful signal.

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

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

Given an output schema exists, return values need no explanation. Cost, use/avoid conditions, paging behavior and the relationship to scoring are all covered, so an agent has everything needed to select and 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 limit/offset are already fully documented with defaults and ranges. The description restates the limit cap and offset and adds that a total is returned, which is marginal value over the structured fields. 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 defines the returned resource precisely: sellers who cryptographically proved control of the wallet their x402 endpoints are paid to, along with profile and endpoint counts. The verb is implicit rather than stated ('Paged: limit... offset'), but an agent can immediately tell this is a listing of verified/claimed sellers, distinct from the scoring-oriented siblings.

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

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

It gives explicit when-to-use triggers (want a contact or docs link, or want to see which sellers stand behind their endpoints) and an explicit when-not with the alternative named ('Not for: judging an endpoint's quality... use settled_check'). 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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still adds genuinely new context: 'Free' (no paid invocation), 'No input', and the fact that the response covers both index freshness and paid-route pricing. It does not discuss rate limits or update cadence, but for a status read that is a minor gap.

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

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

Front-loaded with the cost fact ('Free.'), then purpose, then when-to-use, then exclusion. Every clause earns its place; no filler.

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

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

An output schema exists, so return values need not be described. Combined with full annotation coverage and zero parameters, the description supplies everything needed to decide when to call it and what to expect.

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

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

Zero parameters, so the baseline is 4. The description confirms 'No input', which is consistent with the empty schema and prevents an agent from inventing arguments.

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 ('the x402 endpoint index and the on-chain ledger') and exactly what aspect it reports ('size and freshness'). It also names the sibling it is not for (settled_check), so an agent can route between them 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?

Explicit 'Use when' clause names the decision it supports (judging data currency, route cost before relying on other tools) and an explicit 'Not for' clause redirects to settled_check. Both selection conditions are unambiguous.

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

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

Annotations already cover idempotency and non-destructive/write semantics, but the description adds genuinely new context: it is free, rate-limited, asynchronous, and the first probe runs within minutes. That timing/rate-limit detail is what the agent most needs. Only minor gap is no mention of what a submission returns, though a separate output schema exists.

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

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

Tight and front-loaded: cost/limit caveat first, then the action, then when/when-not/after in short clauses. Every sentence carries operational signal with no filler.

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

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

For a single-param submission tool with an output schema present, the description fully covers cost, rate limits, selection criteria, exclusions, follow-up, and idempotency. Nothing an agent needs to call it correctly is missing.

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

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

Single required parameter with 100% schema coverage, so the schema already documents 'url' fully. The description implies the URL must be an x402 endpoint, which aligns with the schema but adds no syntax or format detail beyond it. Baseline 3 applies.

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

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

States a specific verb and resource: 'Queue an x402 endpoint URL for indexing.' The x402 qualifier and the 'indexing' action distinguish it cleanly from siblings like settled_check and 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?

Explicit when-to-use ('settled_check or settled_peek reports the URL as unknown or not indexed'), explicit when-not ('URLs already indexed... or non-x402 URLs'), and a follow-up step ('wait a few minutes, then call settled_check'). 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 readOnlyHint/idempotentHint/destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real context beyond them: the call is 'Free', it recomputes a hash and recovers the signer, and it only works on the full response object passed unchanged. It stops short of describing failure modes (e.g., mismatch behavior) or auth needs.

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

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

Front-loads the cost note, then purpose, then when/when-not, then the input constraint. No sentence is padding; each clause carries a distinct decision-relevant fact.

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

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

An output schema exists, so return-value semantics need not be spelled out; the description covers purpose, routing, and the input integrity requirement. For a single-parameter verification tool with an output schema, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the single 'document' parameter is already documented as the complete signed answer with attestation. The description still adds a constraint the schema does not express — it must be the full response object, unchanged — which is exactly the detail that determines verification success.

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 concrete verb and resource — recompute the hash of a signed Settled response and recover the signer to test authenticity — plus the outcome ('tells you whether it is authentic and unaltered'). The 'not for answers you just received directly over this server' clause separates it from the fresh-answer path used by siblings.

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

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

Explicit 'Use when' (a Settled answer arrived via a third party, cache, or log and you need to trust it) and explicit 'Not for' (answers just received directly over this server). The selection condition is stated, not inferred.

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

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

Goes well beyond the annotations by disclosing the $2.00 USDC cost on Base, the x402 payment handshake on first call, 30-day duration, ~15-minute probe interval, and that alerts are signed and fire on status/payability/price/payTo changes. The non-idempotent, mutating nature is clear from 'buys 30 days' and 'renew', consistent with readOnlyHint=false.

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

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

Every clause carries information and the use/not-for routing is compact. The payment preamble is dense and parenthetical, slightly delaying the core purpose statement, but nothing is filler.

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

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

For a paid, long-lived, alerting watch tool the description covers price, payment flow, duration, probe frequency, alert channel, and return value (watch_id). With annotations and an output schema present, nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds decision-level semantics: url vs watch_id as mutually exclusive entry paths with renewal implications, and webhook vs polling via settled_watch_alerts. That is meaning beyond the field descriptions, though the 30-day renewal effect of watch_id is only implied.

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 and resource: buys 30 days of monitoring for one x402 endpoint, with probe cadence and alert triggers spelled out. It also explicitly carves itself apart from settled_check, so an agent can distinguish it from siblings without opening any schema.

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

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

Contains explicit 'Use when: your agent depends on one endpoint and must learn quickly if it changes' and 'Not for: one-off checks (settled_check)', naming the alternative directly. It also routes the two entry modes (url to start, watch_id to renew) and the alert delivery choice (webhook vs settled_watch_alerts).

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/no-destruction, so the bar is lower. The description adds real operational context: it is free, the endpoint is probed roughly every 15 minutes, and next_since should be passed on the following call. It does not discuss pagination limits or error behavior, keeping it short of a 5.

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

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

Front-loaded with 'Free' and what is returned, then Use when and Not for as labeled cues. No filler; every clause carries routing or scheduling 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?

Despite an output schema existing, the description still conveys the return shape, the cursor handoff, cost, and polling cadence. For a polling/alert tool with a required watch_id, nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents watch_id, since, and limit. The description reinforces the since/next_since round-trip pattern, which is useful, but adds no format or bounds beyond what the schema states. Baseline 3 is appropriate.

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

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

States a specific verb and resource: reading everything a Watchdog recorded for an endpoint, enumerating the exact fields (status, payability, price, payTo) and the cursor field next_since. It explicitly distinguishes from sibling settled_check with a Not for clause.

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

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

Gives an explicit precondition (you created a watch with settled_watch and gave no webhook), names the exclusion and its alternative (endpoints without a watch use settled_check), and prescribes the polling cadence. An agent knows exactly when to pick this tool.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds genuinely useful context not in the annotations: it is free, published Mondays, and the window and ledger coverage are carried in the body. It stops short of describing staleness guarantees or failure modes if no report has been published yet.

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

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

Front-loaded with the one-word qualifier 'Free', then payload summary, then when/not-for, then publication cadence. Every clause carries distinct information and none repeats the annotations or schema.

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

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

An output schema exists, so the description need not explain the return shape and correctly points to the body for window and ledger coverage. For a zero-parameter read tool, the alternatives, cadence, and cost are sufficient for an agent to decide and call correctly.

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

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

The tool takes zero parameters, so the baseline of 4 applies and there is no schema semantics for the description to duplicate or compensate for. It correctly adds nothing parameter-related, though it makes no statement about determinism of the returned week (e.g. whether one report per week is retained).

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

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

Names a specific resource (the latest published Agent Income Report) returned as JSON, and enumerates its contents: paying venues, worker wallets, flagged honeypots, x402 index health. That enumeration distinguishes it from siblings like settled_report, settled_status, and settled_events without needing their 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 'Use when' clause scopes it to the week's summary for a digest or a decision about where to look for work, and the 'Not for' clause names the exact alternatives (settled_status, settled_income_venues) that serve live numbers. When-to-use, when-not-to-use, and alternatives are all present.

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