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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description goes further by disclosing the no-wallet error case and a critical cross-field caveat (the `eth` gas field is absent on Arc and must never be added to the USDC balance). It does not cover rate limits or refresh/freshness behavior, so it stops 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 sentences, front-loaded with the core read action, followed by the field caveat and the error case. The parenthetical enumeration of the four networks is slightly heavy but genuinely useful since it defines the valid scope; nearly every sentence 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?

With no parameters and no output schema, the description carries the burden of explaining the return shape, and it does so reasonably: it names the two balance types, flags the missing `eth` field per chain, and states the error case. Minor gap is freshness/caching and what happens across multiple networks at once.

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

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

The tool takes zero parameters, so the baseline is 4. The description's field-level discussion (USDC vs `eth` gas balance and their relationship on Arc) concerns returned values rather than inputs, but it does add interpretive value that the empty schema cannot.

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 ('Reads') and resource (USDC and gas-token balances) for the active account, and pins the scope to the active network with named chains. An agent can immediately distinguish this from get_wallet_status or get_history 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?

Usage is implied by the purpose but never stated as when-to-use or when-not-to-use, and no sibling tool is named as an alternative. The only routing signal is the failure condition ('Errors if there is no wallet'), which is a precondition rather than guidance on choosing 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 only declare readOnlyHint and openWorldHint; the description carries substantial extra behavior: per-status meaning, which statuses mean no money moved (reverted, expired), that 'unknown' may have gone through and the wallet rechecks it on-chain, that 'received' comes from an app-driven on-chain scan back to 90 days. This is exactly the context annotations cannot supply.

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

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

The core purpose is front-loaded and every clause carries information — the status enumeration is necessary because there is no output schema. It loses a point because the status glossary is delivered as one very dense run-on sentence rather than a scannable list.

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

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

With no output schema and only one optional parameter, the description fully covers what the agent needs: return ordering, default limit, and the complete semantics of every status value including financial and safety implications. Nothing material is missing.

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

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

Schema description coverage is 100% for the single 'limit' parameter, so the schema already documents default 20 and max 200; the description only restates the default. Baseline 3 applies since the schema does the heavy lifting and the description adds no new parameter syntax.

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

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

States a specific verb and resource — 'Returns the active account's recent transaction attempts, newest first' — including scope (active account) and ordering. The resource is unmistakably distinct from siblings like get_balances and get_wallet_status, so an agent can route 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?

Usage is implied by the resource and by the embedded warning 'never resend on the strength of this entry alone', which quietly steers the agent away from acting on 'unknown' entries via x402_resubmit. However, it never explicitly says when to call this versus alternatives, nor states prerequisites or 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 readOnlyHint=true and openWorldHint=false, and the description goes well beyond them: it enumerates the state values (encrypted/legacy/none), clarifies that address is the ACTIVE account while accounts lists all accounts, and discloses that only the user can switch accounts in the wallet app. It also reassures no password is needed, which is actionable auth context.

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

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

Front-loaded with the core purpose, then structured field-by-field. Every sentence carries information, though the trailing 'No password needed — read only' partially restates the readOnlyHint annotation.

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, no output schema, and annotations covering safety, the description supplies exactly the missing pieces: what fields come back, what the state values mean, and how the active-account concept relates to sibling tools. Nothing an agent needs to call this correctly 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?

The tool takes zero parameters, so the baseline is 4. The description additionally documents the shape of the returned object (index, address, label, active index), which is useful given no output schema exists, though these are return values rather than input 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 a specific verb and resource ('Returns the wallet's state and address') and enumerates the exact fields returned (state, address, accounts, account). The sibling set (get_balances, get_history, request_payment) is clearly distinct, and the description anchors its scope to the active account rather than those other resources.

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

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

Usage is implied rather than stated: it explains that balances, history, and payment requests all key off the active account, which tells the agent why it might call this first, but it never explicitly says when to use this tool versus get_balances/get_history, nor names an alternative.

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 and openWorldHint, and the description goes well beyond them: it discloses that nothing is fetched off-chain, that registration is permissionless, and that being registered is not evidence of safety. This is exactly the kind of adversarial-context caveat an agent needs before treating the result as a trust signal.

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

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

Front-loads the core action, then the return fields, then the comparison behavior, then the safety caveat. The enumerated return list is long but every item earns its place given there is no output schema. Slightly dense, but no filler sentences.

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

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

With no output schema, the description fully enumerates the returned fields (registered, owner, wallet, token_uri, uri_domain, declared_name, feedback_clients) plus the conditional comparison outputs. For a read-only lookup with three parameters, nothing an agent needs to call or interpret it is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantics: agent_id is the number in the Identity Registry, and pay_to/resource exist specifically to produce address and domain comparisons. That comparison behavior is not derivable from the terse schema property descriptions alone.

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: reads an agent's ERC-8004 record from the on-chain registry on the active network. It immediately scopes what the tool does not reach ("the wallet never fetches the agent's website"), which separates it cleanly from the payment/wallet siblings. An agent can tell what this returns without opening the schema.

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

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

Gives concrete invocation guidance (supply agent_id; optionally pass pay_to and/or resource to trigger a comparison) and states the condition under which the result is trustworthy (mismatch only matters when the agent number came from a source you trust). No sibling alternative is named, but the siblings are unrelated domains so the omission is minor. Clear context without explicit when-not-to-call routing.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds far more: a 5-minute approval timeout, password-entry-only-in-app, app-enforced per-payment/daily limits and emergency lock, autopay preconditions (unlocked session, small limit, trusted address), and the semantics of approved/rejected/failed/unknown including the no-retry rule on unknown. That is exactly the behavioral disclosure a payment tool needs.

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

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

Front-loaded with purpose, then arguments, then return semantics in a logical order. It is long, but the length is justified by the absence of an output schema and the high stakes of an irreversible transfer; each section 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?

With no output schema, the description fully documents the return contract (status, tx_hash, detail, explorer link) and the three status branches, plus the critical unknown-may-have-been-sent caveat. Nothing needed to invoke or handle the result is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds operative meaning beyond the schema: 'USDC by default', the instruction to always fill in memo because the user reads it, and a caution that agent_id mismatch is the useful signal while a match proves nothing. It largely restates the schema fields, but the added rationale has real value.

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

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

States a specific verb+resource ('Asks the user to make a payment') and immediately distinguishes it from read-only siblings like get_balances/get_history by describing the approval-window flow. An agent can tell this is the mutating spend path without opening the schema.

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

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

Gives explicit when-to-use and when-not-to-act guidance: the approval window is the normal path, autopay is the only auto-approval exception and only under user-enabled conditions, and on 'unknown' the agent must never retry on its own but hand off to the user. This is actionable routing logic, not vague context.

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 destructive/openWorld/non-idempotent, while the description discloses far more: the retry-safety semantics of the `payment` field ('none'/'confirmed'/'unknown'), the double-payment hazard, facilitator vs eip3009-client-broadcast gas behavior, redirect handling under a payment header, the 100k truncation and saved_file behavior, and the warning never to retry on HTTP status alone. This is exactly the value-beyond-annotations the dimension rewards, and the destructiveHint is consistent with money leaving the wallet.

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 basic request flow is front-loaded before the settlement and retry-safety detail, and nearly every sentence carries operational or safety weight. It is nevertheless very long for a single tool, with some density that could be tightened, so it stops short of a 5.

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

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

There is no output schema, so the description carries the full burden of explaining returns — and it does: payment/paid/status/http_status/body/amount/pay_to/settlement, tx/explorer vs settlement_tx, and notice. For a 6-param destructive payment tool, an agent has everything needed to call it and interpret the result safely.

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: it explains memo is what the user reads to decide, agent_id drives an on-chain ERC-8004 verification note, and it warns never to pass a password as an argument. These are semantic additions beyond the 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?

The opening sentence gives a specific verb and resource ('Calls an x402 paid API or URL') and the whole description keeps the scope tight around paid HTTP fetching. It distinguishes itself from request_payment by reference ('Approval works exactly as in request_payment') and from x402_resubmit by naming it as the no-pay-again path. An agent can separate it from every sibling 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 clearly states the triggering condition (server answers 402 → user approval → same request resent), when the tool is a plain fetch (no 402), and routes to x402_resubmit when a tx came back without content. It does not give an explicit 'prefer X over request_payment when...' decision rule, but the surrounding context is strong enough to infer usage.

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

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

Far exceeds the annotations: it states no new money moves and no approval is requested, describes the on-chain pre-check and each resulting status (pending, reverted with payment none), and discloses the seller acceptance window (~10 minutes on the reference server) and 7-day proof retention. The idempotent/read-only nature is confirmed in prose rather than left to the hints alone.

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

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

Purpose is front-loaded in the first clause, followed by the usage trigger and then the behavioral detail. The length is justified by the number of distinct outcomes (pending, reverted, refused) that the agent must handle correctly.

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?

Although there is no output schema, the description states the return shape matches x402_fetch and enumerates every status the caller may encounter along with the correct reaction to each. Nothing an agent needs to invoke or interpret this tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the tx must be one the wallet broadcast itself and is re-sent together with the saved challenge values to the same URL. That provenance and pairing context goes beyond the schema's bare field description.

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

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

States a specific verb and resource (resubmits the on-chain proof of an x402 payment this wallet already broadcast) plus the goal (to get the content it paid for). It also distinguishes itself from the sibling x402_fetch by explicitly framing itself as the follow-up for a tx that came back without content.

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 names the trigger condition: 'Use it when x402_fetch returned a `tx` without content (status pending, unknown or undelivered, or settlement_failed with a tx).' It also names the alternative (x402_fetch) and warns against paying again in the settlement_failed/refused cases.

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