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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that this is an on-chain transaction needing gas, that the default is a maximum approval (the ecosystem norm, so no repeat), that max approvals are refused under certain configs, and that allowance under a policy counts against budgets. This is exactly the kind of operational context annotations would otherwise 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?

Front-loaded with purpose, then gas, then default behavior, then the amount caveat. It is dense and the trailing sentence about Permit2's own limits borders on tangential, but every sentence carries real information for correct invocation.

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 no-annotation, no-output-schema mutation tool, the description covers everything needed: what it does, that it costs gas, the default allowance and its policy implications, and the safety mechanism (Permit2 only moves what signed authorizations allow). Nothing critical is missing.

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

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

Schema coverage is already 100%, so the schema documents all four parameters. The description still adds value beyond it by explaining the semantics of omitting amount (unlimited) versus passing it (bounded allowance) and the policy consequences of each, which goes past the schema's terse 'Omit for unlimited.'

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 (approve) plus a precisely scoped resource (ERC-20 token to the Permit2 contract), and the 'Permit2' qualifier distinguishes it from the sibling approve_token. An agent can tell exactly what operation this performs 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?

Explicitly states when it is needed ('before paying x402 upto endpoints with that token') and when to deviate ('pass amount ... required under AGENTWALLET_MAX_TX_TOKEN and under a spend policy'). It stops short of naming the alternative tool (approve_token) or when not to use this at all, so it is clear context without explicit 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?

No annotations, so the description carries the full burden and does well: it discloses that an approval counts as a spend against budgets, that the spender is checked as a recipient, and that 'max' is refused under a spend policy. These are non-obvious behavioral constraints beyond the schema. It omits that this is an irreversible on-chain transaction requiring gas, so not 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?

Four sentences, front-loaded with the core action, then usage context, then the amount convention, then policy behavior. Every sentence carries information and there is no filler, though it 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?

For a 6-parameter mutation with no annotations and no output schema, the description covers purpose, usage trigger, and policy behavior well. It leaves gas/on-chain irreversibility and the absence of a meaningful return value unstated, which are minor gaps for an agent.

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 every parameter including the 'max' convention for amount. The description's mention of 'max' and 'spender contract' largely restates the schema, adding only the spend-policy framing. 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: 'Approve a spender contract to transfer ERC-20 tokens on your behalf.' An agent knows exactly what the tool does. It does not, however, distinguish itself from close siblings like approve_permit2 or check_approval, 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?

Gives clear when-to-use context: 'Required before interacting with any DeFi protocol (DEXs, lending, etc.).' This is meaningful routing guidance. It stops short of naming alternatives (e.g. approve_permit2 for Permit2 flows) or stating when this tool is the wrong 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?

No annotations are provided, so the description carries the full burden. It discloses that this is a purchase transaction requiring on-chain payment with USDC and returns payment instructions, but lacks details on costs, rate limits, or error handling. The description adds some behavioral context but is incomplete for a financial transaction tool.

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

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

Two sentences that are front-loaded with the core action and usage context, with no wasted words. Every sentence adds value by explaining the tool's purpose and behavioral outcome efficiently.

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 no annotations and no output schema, the description covers the purpose and usage well but lacks details on costs, transaction confirmation, or error cases. For a financial tool with on-chain interactions, this leaves gaps in behavioral transparency, though it's adequate for basic understanding.

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 fully documents the 'count' parameter. The description doesn't add parameter details beyond the schema, but it contextually explains that credits are for verification beyond the free tier, which helps interpret the parameter's purpose. With 1 parameter and high schema coverage, baseline 3 is appropriate, but the added context justifies a 4.

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 clearly states the specific action ('Buy x402 verification credits with USDC on-chain'), identifies the resource ('verification credits'), and distinguishes it from siblings by focusing on credit purchasing for paywall owners, unlike tools like 'create_paywall' or 'get_usage'.

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 states when to use this tool: for paywall owners needing credits beyond the free tier (1,000/month) without Stripe billing. It also implies when not to use it (if within free tier or with Stripe), though it doesn't name specific alternatives.

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

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

With no annotations provided, the description carries the full burden and does an excellent job disclosing key behavioral traits: it explicitly states the operation is read-only, doesn't cost gas, doesn't modify state, and returns raw hex results. This covers safety, cost, and output format effectively.

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 perfectly front-loaded with the core functionality in the first sentence, followed by important behavioral details, and ends with a practical use case. Every sentence adds value with zero wasted words.

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

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

For a read-only tool with no annotations and no output schema, the description provides excellent context about behavior, safety, and use cases. The only minor gap is not explicitly mentioning potential error cases or limitations, but it's otherwise quite complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema descriptions, maintaining the baseline score of 3.

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 clearly states the specific action ('execute a read-only call against a smart contract'), the resource ('smart contract'), and the method ('eth_call'). It distinguishes from sibling tools like 'send_transaction' or 'sign_transaction' by emphasizing read-only nature and no state modification.

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 provides clear context for when to use this tool ('useful for reading on-chain data like token balances, prices, positions') and implicitly distinguishes it from write operations. However, it doesn't explicitly name alternatives or specify when not to use it beyond the read-only emphasis.

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

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

With no annotations the description carries the full burden, and it discloses the state machine (pending/approved/denied/expired) plus the follow-up call required on approval. It omits whether the call is a safe read, any auth/permission requirement, and polling or expiry timing.

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 short sentences with zero filler; the lifecycle constraint and the returned states are front-loaded, and the follow-up instruction is last where it belongs.

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

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

There is no output schema, so the description must (and does) enumerate the return states and explain the resulting action per state. Combined with the one documented parameter, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100% for the single approval_id parameter, so the baseline is 3. The description reinforces where the id comes from ('call pay_x402 again with approval_id'), but adds no format or validation 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 and resource (check the status of a payment approval) and explains the exact origin of that resource: an approval created when pay_x402 exceeded the hosted-wallet cap. This is clearly distinguishable from siblings like pay_x402, approve_token, and list_payments.

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 the operative context (only relevant after pay_x402 hit the cap) and an explicit next action: re-call pay_x402 with approval_id once approved. It stops short of saying whether the agent should poll, how long to wait, or what to do on denial/expiry.

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

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

With no annotations, the description carries the full burden and provides substantive behavioral context: it uses GoPlus Security (free, no key) with an on-chain fallback, and the result is 'a warning for the caller to weigh, never a block.' This discloses data sources, auth requirements, and the advisory nature of the output. It does not mention rate limits or latency, so not 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?

The description is front-loaded with the core action and then the usage context, followed by implementation details and behavioral caveats. Every sentence earns its place with no wasted words.

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

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

For a read-only advisory tool with two parameters and no output schema, the description covers purpose, data sources, fallback, and output nature ('a warning'). It does not describe the return structure beyond the warning nature or specify supported chains, leaving a small gap since no output schema exists.

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 both parameters well. The description adds nothing beyond what the schema provides about parameter syntax or semantics, making the baseline 3 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 verb (Assess) and resource (ERC-20 token) and enumerates the exact risk dimensions checked: honeypot, taxes, owner powers, verified source, holder concentration, DEX liquidity. This clearly distinguishes it from sibling tools like get_token_info or simulate_transaction.

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 usage context: 'before approving or swapping it.' This tells the agent when to invoke the tool. However, it does not name alternatives or state when not to use it, 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?

With no annotations, the description carries the full burden and delivers real behavioral context: it returns a public access URL that responds HTTP 402 until paid, and describes the on-chain pay-then-retry flow. It omits persistent-record side effects, auth/wallet prerequisites, and error behavior, keeping it below 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 tight sentences with the core action front-loaded ('Create an x402 paywall that charges...'). The subsequent sentences on the 402 response and payment flow each add value rather than repeating the name.

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 11-parameter creation tool with no annotations and no output schema, the description compensates by describing the return value (public access URL) and the 402/retry semantics an agent needs. Gaps remain around prerequisites and side effects, but the essential model is conveyed.

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 all 11 parameters are already documented in the schema, including defaults, enum values, and the get_chains cross-reference for token_address. The description adds no parameter-level meaning beyond that, 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+resource ('Create an x402 paywall') and clarifies what the artifact does. The verb 'create' separates it from list_paywalls/update_paywall/delete_paywall/get_paywall. It stops short of explicitly naming alternatives, so a 4 rather than 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 explains the payment flow a client follows (pay on-chain, retry with proof), which implies the tool's role. However, it gives no explicit when-to-use guidance or exclusions against siblings like update_paywall or pay_x402. Usage is implied but not stated.

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

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

With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies that private keys are encrypted server-side and never exposed, which is critical security information. However, it lacks details on error conditions, rate limits, or authentication requirements, leaving some gaps.

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 front-loaded with the core purpose in the first sentence, followed by a concise security detail. Both sentences earn their place by providing essential information without redundancy, making it efficiently structured and appropriately sized.

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 no annotations and no output schema, the description is moderately complete: it covers the creation action and security aspect but misses details like return format (beyond mentioning ID and address), error handling, or dependencies. For a tool with 2 parameters and no structured safety hints, it should do more to compensate.

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 fully documents the two parameters (label and chain_id). The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline of 3 for high coverage without extra 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?

The description clearly states the action ('Create') and resource ('new EVM or Solana wallet'), specifying it generates wallet ID and address. It distinguishes from siblings like 'get_wallet' or 'list_wallets' by being a creation tool, though it doesn't explicitly contrast with other creation tools (e.g., 'create_paywall').

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 through context: it's for creating wallets when needed, with no explicit guidance on when to use it versus alternatives like importing or retrieving existing wallets. It doesn't mention prerequisites (e.g., authentication) or exclusions, leaving usage decisions 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the outcome ('access URL will return 404 after deletion'), which is useful, but fails to mention critical aspects like whether deletion is permanent, requires specific permissions, has rate limits, or what happens to associated data (e.g., payments). This leaves significant gaps for a destructive operation.

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 extremely concise—two sentences with zero wasted words. It front-loads the core action and immediately follows with a key behavioral consequence, making it easy to parse and efficient.

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 destructive tool with no annotations and no output schema, the description is incomplete. It omits details on permissions, irreversibility, error handling, and response format, which are critical for safe and effective use. The provided context is insufficient given the tool's complexity and lack of structured 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?

Schema description coverage is 100%, with the parameter 'paywall_id' fully documented in the schema. The description does not add any meaning beyond the schema (e.g., format examples or constraints), so it meets the baseline of 3 where 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 clearly states the specific action ('Delete') and target resource ('an x402 paywall'), distinguishing it from sibling tools like 'create_paywall', 'update_paywall', 'get_paywall', and 'list_paywalls'. It precisely communicates the tool's function without ambiguity.

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 provides no guidance on when to use this tool versus alternatives like 'update_paywall' or 'pause_wallet', nor does it mention prerequisites (e.g., needing the paywall ID) or warn about irreversible deletion. It lacks explicit usage context 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?

With no annotations, the description carries the full burden and does disclose substantial behavior: it is a soft-delete (data retained), the wallet disappears from listings, transactions are blocked, and there is a read-before-delete safety guard that refuses to delete an unreadable wallet. It omits permission/auth requirements and does not explicitly confirm whether the change is reversible.

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-loading the operation and its key qualifier ('soft-delete') before the behavioral consequences and safety guarantee. Every sentence carries distinct, non-redundant information.

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

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

For a destructive tool with no annotations and no output schema, the description covers the mutation's effect and the safety guard reasonably well. It leaves minor gaps around authorization requirements and recoverability, but nothing that would cause an agent to call it incorrectly.

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 a single well-described wallet_id, so the structured field already documents the parameter fully. The description adds no syntax, format, or constraint beyond the schema, which is the expected baseline when coverage is high.

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 ('Delete ... a wallet') and immediately qualifies it as a soft-delete, which distinguishes it from a hypothetical hard delete. Combined with the sibling list, an agent can identify this as the wallet-removal tool without ambiguity.

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

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

The description explains the consequence of the operation but never states when to choose this over alternatives such as pause_wallet/unpause_wallet, nor when not to use it. Usage is only implied by the mutating verb, leaving the agent to infer the decision 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?

With no annotations, the description carries the burden and does well: it discloses that results are read-only/no-cost, that prices are re-derived from the client's own registry, and that listing text is unverified seller-authored content — a real data-quality caveat. It stops short of describing rate limits, index freshness, or result cap behavior.

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

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

Four short sentences, front-loaded with the core action, then scope, then return shape, then the routing caveat. No filler; each sentence adds a distinct 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?

No output schema exists, and the description compensates by naming the returned fields (method, price, chain) and flagging the provenance caveat, while the schema itself covers offset/next_offset pagination. Still missing any note on empty-result or truncation behavior, but broadly complete for a read-only search tool.

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

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

Schema coverage is 100%, so every parameter (limit, query, offset, chain_id) is already documented in the schema, and the description adds little syntax detail. 'By subject' loosely maps to query and the return fields (method, price, chain) hint at chain_id's purpose, but this is baseline territory.

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 ('Find') plus a precisely scoped resource ('x402-paid APIs by subject in the public x402 index — the Bazaar published by the CDP facilitator'). It is clearly distinguishable from the payment-oriented siblings quote_x402 and pay_x402.

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 tells the agent this tool does not spend money ('Nothing is paid') and routes to the correct next step ('follow up with quote_x402 or pay_x402'). The when-to-use (discovery) and when-not-to-use (anything involving payment) boundaries are both stated.

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

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

With no annotations, the description carries the full burden, and it does disclose two real behavioural traits: the result is text rather than a written file ('write it wherever it belongs') and rows are ordered oldest first. It does not state whether the export is complete or paginated when since/until are omitted, nor any permission or rate constraints.

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 sentences, front-loaded with the resource and scope, and the second sentence carries the non-obvious return-behaviour detail. The trailing 'for expense records' is mildly redundant but does add framing, so no significant 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?

With no output schema, the description correctly takes on the return-value burden by stating the export is returned as text and is ordered oldest first. It leaves open what 'every spend' means when both bounds are omitted, but otherwise the agent has what it needs for a zero-required-parameter read export.

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 67%; the since/until ISO 8601 bounds are described in the schema itself. The description compensates for the undocumented format parameter by stating the output is 'CSV or JSONL text', clarifying both the allowed values and that the result is a text payload.

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 (export) and resource (receipts) plus the content that is exported: every spend in the ledger. This is clear enough to call the tool, but it does not explicitly distinguish itself from near neighbours like list_payments or get_usage, leaving the agent to infer the difference from the word 'export'.

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 phrase 'for expense records' implies the intended use case, so usage is inferable, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many payment/usage/ledger siblings. An agent must guess whether this or list_payments is the right source.

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

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

With no annotations, the description carries the full burden, and it discloses a critical behavioral trait: the export is 'deliberately human-gated and is not performed by this tool.' That prevents an agent from assuming a key is returned. It does not, however, say what the tool does return (instructions/URL, etc.).

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; the key clarification (that the tool only explains, and export is human-gated) is front-loaded. Nothing 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?

For a one-param informational tool with no output schema, the description covers purpose, gating, and scope adequately. The main remaining gap is not describing what the agent gets back, but this is minor given the simplicity.

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 a single documented param ('Hosted wallet ID to export'), so the schema already carries the semantic load. The description adds no format or constraint detail beyond it, which is the baseline case.

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 uses a specific verb ('explain how') and resource ('private key of a hosted custodial AgentWallet'), and explicitly distinguishes itself from the action its name implies by stating it is educational, not an exporter. It is clear and self-distinguishing, though the name 'export_wallet_key' still risks misleading an agent at a glance.

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 context of use ('so it can be moved to self-custody or any other wallet') and clarifies the tool does not perform the export. It does not name sibling alternatives, but the purpose-to-context mapping is clear enough to route correctly.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the return shape (raw and human-readable) and implies a read-only operation, but says nothing about required permissions, whether the wallet must be unlocked, or failure modes.

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 with the core action front-loaded and no filler. The return-format sentence and the usage sentence both carry 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 a read-only lookup with no output schema, the description is nearly sufficient: it explains what is returned and when to reach for it. It falls just short by not resolving its overlap with check_approval or noting any preconditions.

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 all five parameters are already documented in the schema. The description only restates the spender concept and adds no syntax, defaults, or edge-case detail 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 — checking the ERC-20 allowance a spender can transfer — which is concrete and easy to act on. However, it does not differentiate itself from the similarly named sibling check_approval, leaving the agent to guess which of the two to use.

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

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

Provides one clear usage context ('check if an approval is needed before a DeFi transaction'), which is genuinely helpful. But it never names alternatives or exclusions, so with a near-duplicate sibling (check_approval) present, the routing guidance is incomplete.

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

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

With no annotations provided, the description carries the full burden. It discloses the return format (balance in wei/lamports and human-readable), which is valuable behavioral context. However, it doesn't mention potential errors, rate limits, or authentication requirements, leaving gaps for a tool that queries financial data.

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, efficient sentence that front-loads the core purpose and includes essential behavioral details about return formats. Every word earns its place with zero waste or redundancy.

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

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

For a tool with no annotations and no output schema, the description provides good purpose and return format clarity but lacks details on error handling, chain compatibility, or authentication. Given the complexity of blockchain operations, it's adequate but has clear gaps in completeness.

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 both parameters fully. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain wallet_id or chain_id formats or defaults in more detail). Baseline 3 is appropriate 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 clearly states the tool's purpose with a specific verb ('Get') and resource ('native token balance for a wallet on a specific chain'), and distinguishes it from sibling tools like 'get_token_balance' by specifying it's for native tokens only. This provides precise 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?

The description implies usage by specifying the resource (wallet balance on a chain), but doesn't explicitly state when to use this tool versus alternatives like 'get_token_balance' or 'get_wallet'. It provides some context but lacks explicit guidance on exclusions or prerequisites.

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?

No annotations are provided, so the description carries the full burden. 'List' implies a non-mutating read, and the description usefully discloses the fields returned, but it says nothing about whether the registry is static or live, whether RPC status can change, or about caching/pagination behavior.

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

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

A single sentence, front-loaded with the action and resource, followed by the payload contents. Every clause earns its place 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?

With no output schema and no parameters, the description does the work of describing the return payload (chain IDs, native tokens, stablecoins, RPC config status), which is adequate. Minor gaps remain about list ordering/completeness.

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; baseline 4 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 ('List') and resource ('all supported chains'), then enumerates what each entry contains (chain IDs, native tokens, stablecoins, RPC status). No sibling tool in the list overlaps with chain discovery, so the purpose is unambiguous, though it does not explicitly differentiate itself from 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?

Usage is only implied: an agent infers it should call this to discover which chains are supported before doing chain-dependent work. There is no explicit when-to-use statement, but there is also no competing alternative that would need to be excluded.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'pricing, access URL, payment stats, and configuration,' which adds some context about output content. However, it doesn't cover critical aspects like error handling (e.g., what happens with an invalid ID), authentication requirements, rate limits, or whether it's a read-only operation. For a tool with zero annotation coverage, this is insufficient.

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 highly concise and well-structured, consisting of two sentences that efficiently convey the tool's purpose and return values. Every sentence earns its place: the first defines the action and input, and the second lists the output details. There is no wasted verbiage, making it easy to parse and understand.

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

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

Given the tool's low complexity (single parameter, no nested objects) and high schema coverage, the description is adequate but has clear gaps. It lacks an output schema, so the description's mention of return values ('pricing, access URL, payment stats, and configuration') is helpful. However, without annotations, it misses behavioral details like error handling or auth needs, making it incomplete for optimal agent use.

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 input schema has 100% description coverage, with the single parameter 'paywall_id' documented as 'Paywall ID' of type integer. The description adds value by specifying that this ID is used to get details for a 'specific' paywall, reinforcing its purpose. However, it doesn't provide additional semantics beyond what the schema already covers, such as format examples or constraints, so it meets the baseline for high schema coverage.

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 clearly states the tool's purpose: 'Get details for a specific x402 paywall by ID.' It specifies the verb ('Get details'), resource ('x402 paywall'), and scope ('by ID'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_paywalls' or 'get_paywall_payments', which would require 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 provides no guidance on when to use this tool versus alternatives. It mentions retrieving details for a 'specific' paywall by ID, but doesn't clarify prerequisites (e.g., needing a valid paywall ID) or contrast it with similar tools like 'list_paywalls' (for multiple paywalls) or 'get_paywall_payments' (for payment data). This lack of explicit usage context leaves gaps for an AI agent.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose that only 'verified payments' are returned and what fields come back. However, it omits pagination behavior, auth/permission requirements, and any rate-limit or ordering context, so the disclosure is partial rather than 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?

Two short sentences with the purpose front-loaded and return contents second; there is essentially no filler. Slightly cursory but well-structured.

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

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

For a read-only lookup with a fully documented 3-parameter schema and no output schema, the description covers purpose and enumerates the returned fields, which is what the missing output schema would otherwise need. It stops short of describing pagination semantics and failure modes.

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 paywall_id, page, and per_page are already documented in the schema. The description adds only the notion that paywall_id scopes results to one paywall; no format, default, or limit details 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 — 'Get payment history for a specific x402 paywall' — with a clear scope (single paywall). It does not, however, explicitly distinguish itself from siblings like list_payments or get_x402_revenue, leaving the agent to infer the boundary.

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

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

The description never says when to use this tool versus alternatives such as list_payments or get_x402_revenue, nor does it state prerequisites. It only describes what the call returns, leaving selection entirely 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?

No annotations are provided, so the description carries the full disclosure burden. It does reveal the return shape (raw balance plus human-readable balance), which is genuinely useful, but it does not address permissions, rate limits, or behavior when decimals is omitted.

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 short sentences, zero filler, with the core purpose front-loaded and the return contract and helper-tool hint following in priority order.

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

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

There is no output schema, but the description compensates by stating exactly what is returned (raw and human-readable balance). For a read-only balance lookup with fully documented params, 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 description coverage is 100%, so the schema already documents all four parameters in detail. The description's only additive hint is the get_chains pointer for token addresses, which justifies the baseline 3 rather than more.

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: 'Get the ERC-20 or SPL token balance for a wallet on a specific chain.' The token-standard wording implicitly separates it from the native-balance sibling get_balance, but it never names that sibling, so differentiation is inferred rather than explicit.

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 one routing hint ('Use get_chains to find stablecoin addresses for each chain'), which helps with the token parameter but says nothing about when to prefer this over get_balance or get_token_info. Usage is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a read-only operation for token metadata discovery, but doesn't mention potential limitations like rate limits, error conditions, or whether it requires authentication. The description adds useful context about the tool's purpose but lacks operational details.

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 perfectly concise with two sentences that each earn their place: the first states exactly what the tool does, and the second provides valuable usage context. No wasted words, and the information is front-loaded with the core functionality.

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

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

For a read-only metadata tool with no annotations and no output schema, the description provides adequate context about what information is returned and when to use it. However, it doesn't describe the return format or structure, which would be helpful given the absence of an output schema. The description covers the essentials but leaves some implementation details unspecified.

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 100% schema description coverage, the input schema already fully documents both parameters (token address and chain ID). The description doesn't add any additional parameter semantics beyond what's in the schema, such as explaining why chain_id matters or providing examples. This meets the baseline for high schema coverage.

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 clearly states the specific action ('Get'), resource ('ERC-20 token'), and exact data returned ('name, symbol, and decimals'), distinguishing it from sibling tools like get_balance or get_token_balance which focus on different token attributes. The verb+resource combination is precise and unambiguous.

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 provides clear context about when to use this tool ('before transfers or approvals'), which helps differentiate it from other token-related tools. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the context implies it's for metadata rather than balance or allowance checks.

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

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

With no annotations, the description carries the burden, and 'Get' implies a read-only, zero-parameter call. It usefully discloses the scope limit (current month only, no historical periods) and the returned fields, but says nothing about permissions/auth needs or rate limits.

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 sentences, zero filler, with the scope and purpose front-loaded before the return-value summary.

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 appropriately enumerates the returned fields (operations count, tier info, remaining quota, fees) and scope. It is nearly complete for a zero-param read tool, missing only auth/permission context.

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; there is no parameter syntax the description could add. The description's field listing is return-value information rather than parameter guidance.

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 (Get) and resource (usage statistics) and narrows scope to the current month, plus enumerates what is returned. No sibling tool covers usage/quota, so differentiation is implicit rather than explicit, keeping it just under 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., historical usage or per-resource usage tools). Usage is only implied by the phrase 'current month's usage statistics'.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return fields (address, label, etc.) but lacks critical details like whether this is a read-only operation, authentication requirements, error handling, or rate limits. For a tool with zero annotation coverage, this is insufficient.

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, efficient sentence that front-loads the core action ('Get details for a specific wallet by ID') and adds useful return field information. Every word serves a purpose with no wasted text.

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

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

Given the simple input schema (1 parameter, 100% coverage) and no output schema, the description adequately covers the basic purpose and return fields. However, as a read operation with no annotations, it should ideally mention safety (e.g., read-only) or authentication context to be more complete.

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 schema description coverage is 100%, with the single parameter 'wallet_id' documented as 'Wallet ID'. The description adds no additional meaning beyond this, such as format examples or constraints, so it meets the baseline score when schema coverage is high.

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 clearly states the verb 'Get details' and resource 'specific wallet by ID', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_wallets' or 'get_balance', which would require more specific language about scope or data returned.

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 provides no guidance on when to use this tool versus alternatives like 'list_wallets' (for multiple wallets) or 'get_balance' (for balance-specific info). It states what it does but offers no context about appropriate use cases 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?

No annotations exist, so the description carries the full burden. It discloses the return shape (totals plus a per-chain and per-token breakdown), which is genuinely useful, but says nothing about auth requirements or any rate/latency behavior for an account-scoped read.

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 zero filler, and the purpose is front-loaded before the return-value detail. 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 output schema, the description usefully compensates by stating what is returned (total payments and revenue, broken down by chain and token). For a zero-parameter aggregate read this is nearly complete, though it omits any scoping or auth caveat.

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. There are no arguments for the description to clarify, and the empty object schema plus additionalProperties:false leaves nothing ambiguous.

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 (get) and resource (x402 revenue statistics) scoped to 'across all your paywalls,' which distinguishes it from the per-paywall get_paywall_payments sibling. It does not name that sibling explicitly, but the aggregate scope makes the distinction clear.

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 aggregate framing: use this for a rolled-up revenue view rather than per-paywall payment listings. However, it never states when to prefer this over get_paywall_payments, list_payments, or get_usage, so the agent must infer the 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?

With no annotations, the description carries the full load and does substantially: it discloses ordering (newest first), per-item outcome semantics (signed, settled, declined, unknown, broadcast, void), and the crucial data-source distinction between a hash-chained append-only ledger file and process-only state based on AGENTWALLET_LEDGER or policy. It still omits read-only confirmation and pagination behavior, but this is solid behavioral 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?

Two dense sentences that front-load what the tool lists before moving to ledger/storage nuance. No filler, though the second sentence is somewhat cryptic about the ledger configuration.

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 list tool with no output schema and no annotations, the description covers content, ordering, and outcome values reasonably well, but omits return shape beyond the outcome field and gives no pagination/limit guidance despite a 500-item cap on limit. Adequate but with clear gaps.

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

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

Schema coverage is 75%, so the schema documents most parameters (host, limit, since, outcome). The description complements the outcome filter by enumerating the possible outcome values, but says nothing about host, limit, or since beyond what the schema already 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?

States a specific verb+resource ('Spends recorded in this wallet's ledger') and enumerates the kinds of spends it covers (x402 payments, transfers, auto-pay). It clearly defines what the tool returns, though it never names the sibling it competes with (e.g., export_receipts or get_paywall_payments) to sharpen selection.

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

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

The description explains what is listed but gives no when-to-use guidance or exclusion criteria. With siblings like export_receipts, get_paywall_payments, and get_usage in the same namespace, an agent gets no help deciding when this is the right 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the returned fields (IDs, names, pricing, URLs, payment counts, revenue), which partially compensates for the absent output schema, but says nothing about pagination behavior, result limits, or authentication requirements.

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 sentences, zero filler, with the operation front-loaded and the return shape following immediately. Every clause 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's enumeration of return fields is genuinely valuable and makes the tool callable without guessing the response shape. It is only mildly short of complete because routing against sibling list/get tools and pagination expectations are 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 page and per_page are already fully documented with defaults and bounds. The description adds no additional parameter meaning, which is the expected baseline 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?

States a specific verb (list) and resource (your x402 paywalls) with clear scope ('all your'), which an agent can distinguish from get_paywall or get_paywall_payments. However, it never names those siblings or explains how this differs from a single-paywall or payments lookup.

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?

No when-to-use guidance, prerequisites, or alternatives are given. With siblings like get_paywall and get_paywall_payments in scope, the description should route the agent but instead leaves selection entirely 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?

No annotations are provided, so the description carries the full burden. It does disclose auth context ('authenticated user') and enumerates the returned fields, which is genuinely useful with no output schema. However, it says nothing about pagination, ordering, rate limits, or behavior for users with no wallets.

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, zero filler, and the scope constraint is front-loaded. The second sentence substitutes for the missing output schema rather than padding.

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

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

For a zero-parameter read tool with no output schema, the description covers ownership scope and the returned fields, which is most of what an agent needs. Missing only edge-case behavior (empty results, pagination) to be fully complete.

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 to disambiguate and the baseline is 4. The description appropriately spends its words on scope and return shape instead of inventing 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 a specific verb (List) and resource (wallets) with an explicit scope: 'owned by the authenticated user'. This distinguishes it from create_wallet/delete_wallet, and the scope phrase implicitly separates it from the singular get_wallet, though it never names that sibling directly.

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 explicit when-to-use guidance and no mention of the obvious alternative get_wallet for a single wallet. The only implicit signal is that this returns 'all' wallets, leaving the agent to infer the list-vs-single choice on its own.

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

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

With no annotations provided, the description carries the full burden. It discloses the behavioral effect ('No transactions can be signed while paused'), which is useful. However, it lacks details on permissions required, reversibility, or rate limits, leaving gaps for a mutation tool.

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

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

The description is two sentences with zero waste, front-loading the key action and effect. Every word earns its place, making it highly efficient and easy to understand.

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 mutation tool with no annotations and no output schema, the description is adequate but incomplete. It covers the purpose and effect but lacks details on permissions, error cases, or return values, which are important for safe usage.

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 the 'wallet_id' parameter fully. The description does not add any additional meaning or context about the parameter beyond what the schema provides, meeting the baseline for high coverage.

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 clearly states the specific action ('Emergency pause a wallet') and the resource ('wallet'), distinguishing it from sibling tools like 'unpause_wallet' and 'get_wallet'. It explicitly mentions the effect ('No transactions can be signed while paused'), which adds clarity beyond just the verb.

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 implies usage in emergency situations ('Emergency pause'), providing clear context for when to use it. However, it does not explicitly state when not to use it or name alternatives (e.g., 'unpause_wallet' for reversing the action), which prevents a perfect score.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that the 'exact' scheme requires no gas and nothing is broadcast by the payer, that 'upto' settles via a cap-bounded Permit2 authorization, that the call retries with a payment header, and that it returns both the final response and a settlement receipt. It also flags the approval flow and the one-way cap semantics of max_payment.

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 in the first sentence and the dense technical detail that follows is mostly justified for a complex payment tool. It is somewhat run-on and mixes scheme semantics with cap semantics, but every clause contributes 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?

For a 10-parameter mutation tool with no output schema, the description explains the return value (final response plus settlement receipt) and the safety-relevant flow. Combined with fully documented parameters, it is nearly complete, though it could say more about failure modes and the approval round-trip.

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 all ten parameters (including max_payment, approval_id, request_approval, fresh_authorization) are already documented in the schema, making 3 the baseline. The description adds some connective context about how the payment schemes relate to these fields, but does not introduce meaning the schema lacks.

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

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

The description names a specific verb and resource: it fetches a URL and, on HTTP 402, completes an x402 payment then retries. It distinguishes itself from siblings like quote_x402 and discover_x402 by describing the actual pay-and-retry flow, and it reconciles the two settlement paths (EIP-3009 'exact' vs Permit2 'upto').

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 trigger condition (server returns 402) and notes that AgentWallet paywalls are instead paid by on-chain transfer, and that the 'upto' scheme uses Permit2. It doesn't explicitly route the agent to sibling alternatives (e.g. quote_x402 to preview, discover_x402 to find endpoints) or state when not to use it, so it stops short of full 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?

With no annotations, the description carries the full burden and does well: 'nothing is signed' is a critical safety disclosure given siblings like sign_transaction and pay_x402, and it reveals the tool evaluates the per-payment cap, spend policy and rolling budgets rather than just reading a price. It stops short of stating auth requirements, rate limits, or failure behavior when the endpoint is not x402, leaving some gaps for a no-annotation tool.

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

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

A single long sentence, but it is front-loaded with the core action ('Ask what an x402 endpoint charges without paying') before enumerating what gets returned. Dense and mostly waste-free, though the list-heavy clause makes it slightly run-on.

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 or annotations, the description compensates by describing what the tool returns (chain, asset, amount, recipient, and policy/budget allowance verdicts) and confirming no signature is produced. That is sufficient for an agent to call and interpret 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 all five parameters (url, body, method, headers, prefer_chain) are already documented in the schema. The description adds only indirect context by mentioning chain/asset/amount/recipient as outputs of a preferred-option selection; it does not explain parameter syntax or interactions 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?

The description states a concrete verb+resource (fetch a URL and parse its 402 requirements without paying) and explicitly contrasts itself with pay_x402, which performs the actual payment. An agent can distinguish quote_x402 from its payment sibling 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?

It gives an explicit trigger: 'Call it before pay_x402 when the price is unknown.' The alternative and the condition that selects it are both named, leaving nothing 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?

With no annotations provided, the description carries the full behavioral burden and does disclose key traits: server-side signing (no private key required from the caller), broadcast via RPC, and the cross-chain return format. However, it omits irreversibility, permission or wallet-state prerequisites, and failure behavior, leaving meaningful gaps for a mutating operation.

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 short sentences, front-loaded with the action and followed by the return format and signing model. Every sentence adds distinct information with no filler or repetition.

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 10 parameters with 100% schema coverage, no annotations, and no output schema, the description is fairly complete: it explains the server-side signing/broadcast model and the chain-specific return value. It could do slightly more on prerequisites or error conditions, but the schema already covers all inputs.

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 one of the 10 parameters is already documented in the input schema. The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline 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 states a specific verb and resource: 'Sign and broadcast a transaction.' The inclusion of 'broadcast' distinguishes it from the sibling sign_transaction, which presumably only signs, so an agent can tell them apart 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?

No explicit guidance is given on when to use this tool versus alternatives such as sign_transaction, simulate_transaction, or call_contract. The description implies it is for submitting transactions, but it does not state conditions, prerequisites, or when-not-to-use cases.

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

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

With no annotations the description carries the full burden and does so well: it discloses per-chain return formats (raw hex for EVM, base64 for Solana), the non-broadcast side effect, and the non-obvious policy consequence that a signed tx is treated as a spend (checked, reserved on the ledger, counted against budgets). The spend-policy disclosure is exactly the kind of hidden behavior an agent must know before calling.

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?

Four sentences, front-loaded with the core action and return behavior, followed by the crucial exclusions. Every sentence carries distinct, non-redundant information; nothing restates the name 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?

For a 10-parameter, no-annotation, no-output-schema tool, the description supplies the missing behavioral and return-value context (both chain formats, non-broadcasting, spend-policy accounting) that annotations and schema do not cover. Nothing an agent needs in order to call it 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?

Schema description coverage is 100%, so the schema already documents all 10 parameters with per-chain notes (EVM-only fields, Solana-only token_mint/token_decimals, value units). The description adds no parameter-level detail beyond the schema, which makes the baseline 3 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 first sentence states a specific verb+resource ('Sign a transaction with a wallet's private key') and the rest differentiates it from the closest sibling by explaining exactly what it returns versus what send_transaction does. An agent can route between sign_transaction and send_transaction 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 exclusions and alternatives are given: 'Does NOT broadcast' and 'Use send_transaction for sign + broadcast.' This is the exact when-to-use/when-not split an agent needs, stated with no inference required.

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?

No annotations, so the description carries the full burden - and it discloses rich behavior: the exact guard set checked, the spend policy, that the gas estimate fails on revert, worst-case fee, balance coverage, and the significant local-vs-hosted mode difference. It omits any permission/auth requirements or rate limits, but for a read-only simulation this is close to complete.

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 action, then a dense enumeration of what it verifies, closing with the mode distinction. The first sentence is a long list but every clause earns its place; only the run-on length keeps it from 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?

With no output schema and no annotations, the description steps up to describe the returned checks (gas estimate, worst-case fee, balance coverage, return data) so an agent knows what comes back. It does not describe failure/error shape or how to interpret a failing guard, leaving a minor gap.

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

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

Schema coverage is 100%, so the schema already documents every parameter (including that wallet_id is ignored in local mode). The description adds contextual framing (cap checks, spend policy) but no syntax or format detail beyond the schema, so the 3 baseline 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 ('Dry-run/simulate') and resource (EVM transaction) and sharpens the distinction from sign/send siblings with 'with nothing signed'. An agent can immediately tell this is a non-mutating 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?

'Dry-run ... with nothing signed' clearly establishes the preflight context, and the local-vs-hosted mode note signals when each path applies. It stops short of naming alternatives (e.g. send_transaction) or stating the ordering ('call before sending'), so no explicit 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?

With no annotations, the description carries the full burden and does disclose the key behavioral trait: it is read-only. It also compensates for the absent output schema by enumerating the return payload (sha256, rolling budgets spent/remaining, per-host spending, ledger path and integrity). It does not discuss error modes or refresh semantics, so not 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?

It is a single dense sentence with the core concept ('the spend policy this server enforces') front-loaded, followed by the fields returned. It reads as a field dump rather than prose, but every clause earns its place given the missing output 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?

For a zero-parameter, non-mutating introspection tool with no output schema and no annotations, the description supplies both the read-only guarantee and a field-level preview of the response. Only minor gaps remain, such as failure behavior and whether the policy can change between calls.

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. No parameter semantics are needed or offered, and none are missing.

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

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

The description names the resource (the server's enforced spend policy, AGENTWALLET_POLICY) and enumerates its contents, which tells an agent what data this returns. It is clear but does not distinguish itself from neighbors like get_usage or get_x402_revenue, and it describes the payload more than the action, so it stops short of a 5.

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

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

There is no statement of when to call this versus alternatives such as get_usage, check_approval, or list_wallets. The mention of 'whether the connected client can answer approval questions' touches on approval context but gives no routing guidance.

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

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

With no annotations, the description carries full burden. It does disclose the important behavior that it 'signs and broadcasts' (i.e. a real, irreversible on-chain write that moves funds) and auto-converts to wei/lamports. It omits gas/fee handling, confirmation semantics, failure modes, and wallet state requirements (e.g. paused 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?

Three tight sentences, front-loaded with the operation and asset class, followed by the amount convention and the transaction lifecycle. No filler or repetition.

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 mutating tool with no annotations and no output schema, the description covers what it does, the amount convention, and that it broadcasts. It lacks fee/confirmation behavior and any hint of what is returned (e.g. tx hash), which leaves meaningful gaps for a destructive operation.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents the address format, amount format, chain IDs, and wallet_id. The description adds only the conversion behavior ('converted to wei/lamports automatically'), which is a marginal gain over 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 ('Send') and resource ('native tokens'), and its enumeration of native assets (ETH, AVAX, BNB, POL, PLS, SOL) implicitly distinguishes it from the sibling transfer_token. It stops short of naming the alternative outright, so an agent must infer the ERC-20 boundary.

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

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

Usage is implied by the 'native tokens' scope, but there is no explicit when-to-use/when-not statement and no routing to siblings like transfer_token or send_transaction. The amount-format guidance is helpful but is invocation detail rather than a usage rule.

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

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

With no annotations, the description carries the full burden. 'Signs and broadcasts the transaction' is a genuinely useful disclosure beyond the schema, but it omits irreversibility, gas/fee source, confirmation behavior, and required permissions for a mutation tool that moves funds.

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 short sentences, front-loaded with the core action and resource, with no wasted filler. The trailing 'Use get_chains to find stablecoin addresses' is slightly tangential but still earns its place as a cross-tool pointer.

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

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

No output schema or annotations exist, so the description must fully inform the agent. It covers the signing/broadcast behavior and amount format but is silent on gas handling, failure modes, and whether a native-token or approval prerequisite applies to a fund-moving tool with six parameters.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the human-readable amount format and decimals resolution rule. The description only restates the amount convention, adding no parameter meaning beyond the structured data, 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 (Send) and resource (ERC-20 tokens on EVM / SPL tokens on Solana) with the address target, which is clear. However, it never distinguishes itself from the sibling 'transfer' or 'send_transaction', leaving the agent to infer which tool handles which asset type.

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

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

Provides an implied usage hint ('Use get_chains to find stablecoin addresses') and the human-readable amount convention, but gives no when-to-use guidance relative to the many sibling transfer/send/sign tools. The distinction between this and 'transfer' or 'send_transaction' is left entirely 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool resumes a paused wallet, implying a state change, but doesn't cover permissions required, whether the operation is reversible, error conditions, or rate limits. This leaves significant gaps for a mutation tool.

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

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

The description is a single, efficient sentence that front-loads the core action and purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.

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

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

Given the tool is a mutation (resuming a wallet) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like side effects, response format, or error handling, which are critical for safe and effective use.

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 input schema has 100% description coverage, with 'wallet_id' clearly documented. The description doesn't add any parameter-specific details beyond what the schema provides, such as format constraints or examples, so it meets the baseline for high schema coverage.

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 clearly states the action ('Resume') and resource ('a paused wallet'), with the specific outcome ('so transactions can be signed again'). It distinguishes from siblings like 'pause_wallet' by indicating the opposite operation, though it doesn't explicitly name alternatives.

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 implies usage when a wallet is paused and needs to resume signing transactions, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'create_wallet' or 'get_wallet', nor does it mention 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the conversion action and amount format, it lacks critical information such as whether this requires gas fees, what permissions are needed, whether it's reversible, potential rate limits, or what the expected output looks like. For a financial transaction tool with zero annotation coverage, this is a significant 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?

The description is efficiently structured in two sentences: the first states the purpose and scope, the second provides specific parameter guidance. Every sentence adds clear value with no wasted words, making it easy to parse and understand quickly.

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

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

Given the complexity of a financial conversion tool with no annotations and no output schema, the description is incomplete. It covers the basic purpose and parameter format but misses critical behavioral details (e.g., transaction costs, success/failure responses, error conditions). However, it does adequately explain the core functionality for a user familiar with blockchain concepts.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (wallet_id, amount, chain_id) with descriptions. The description adds value by clarifying the amount format with an example ('0.5' for 0.5 WETH), but doesn't provide additional context for wallet_id or chain_id beyond what the schema states. Baseline 3 is appropriate when schema does most of the work.

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 clearly states the specific action ('Unwrap wrapped tokens') and resources involved (WETH, WAVAX, WBNB, etc. back to native tokens). It distinguishes from sibling tools like 'wrap_eth' by specifying the opposite operation, and from other tools like 'transfer' or 'send_transaction' by focusing on token conversion rather than movement.

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 implicitly indicates when to use this tool (to convert wrapped tokens to native tokens) and provides an example format for the amount parameter. However, it doesn't explicitly state when NOT to use it or name specific alternatives (e.g., when to use 'transfer_token' instead for moving wrapped tokens without conversion).

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

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

With no annotations, the description carries the full behavioral burden for a mutation tool and it does not deliver. It never says whether omitted fields are preserved or wiped, what permissions are required, whether the change is reversible, or what happens on an invalid paywall_id. This is a significant gap for a write operation with zero structured safety metadata.

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 sentences with the action front-loaded in sentence one and the scope in sentence two; nothing is padded. The trailing 'or any other field' is slightly vague but does convey partial-update intent, so it largely 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?

For an eight-parameter mutation tool with no annotations and no output schema, the description plus full schema coverage is minimally adequate — the agent can populate fields. What is missing is the update contract (partial vs. replace), permission requirements, and post-update behavior, which the schema cannot express.

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 all eight parameters are already documented in the schema with formats, bounds, and defaults (e.g. token_decimals read from the paywall when omitted). The description only restates three fields and adds no syntax, format, or interaction detail beyond the schema, 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 ('Update') and resource ('x402 paywall configuration'), which cleanly separates it from sibling verbs like create_paywall, get_paywall, list_paywalls, and delete_paywall. The second sentence enumerates the changeable fields, so the scope is concrete. It stops short of an explicit sibling reference, but the verb alone is unambiguous.

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 guidance on when to use this tool versus alternatives, no stated prerequisites (ownership, wallet context, or whether the paywall must exist), and no clarification of partial vs. full-replacement update semantics. The 'or any other field' phrasing hints at partial updates but never states it, leaving the agent to infer the core usage contract.

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

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

With no annotations, the description carries the burden and does disclose meaningful behavior: in local mode 'the private key never leaves this machine,' which is a real security-relevant trait an agent should know. It omits auth/prerequisite details, but for a zero-argument read-only probe the risk surface is small.

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, zero filler, with the mechanism named first and the actionable guidance second. Nothing is redundant with the name.

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

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

For a zero-param read tool with no output schema, the description covers what it does, its two outcomes, and when to call it. It could state the return shape (e.g., a mode/custody value), but the semantics are otherwise sufficient 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?

The tool takes zero parameters, so there is nothing to document; baseline 4 applies. The description correctly implies a no-input query.

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 (report) and resource (wallet signing/custody mode) and defines the two possible outcomes precisely: local self-custody versus hosted AgentWallet API. No sibling tool covers custody-mode reporting, so an agent can distinguish it immediately.

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

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

Gives an explicit trigger: 'Use this to verify custody before moving funds.' That is a clear context, though it names no alternative or exclusion — acceptable here because no sibling overlaps.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action (wrapping tokens) and mentions the requirement for DeFi protocols, but does not cover other behavioral traits such as transaction costs, confirmation times, error conditions, or what happens on failure. It adds some context but is incomplete for a mutation tool with zero annotation coverage.

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 appropriately sized and front-loaded, with three sentences that each earn their place: the first states the purpose, the second provides usage context, and the third clarifies parameter formatting. There is zero waste, and the structure is clear and efficient.

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

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

Given the complexity (a mutation tool with no annotations and no output schema), the description is partially complete. It covers the purpose, usage context, and parameter formatting, but lacks details on behavioral aspects (e.g., transaction outcomes, errors) and does not explain return values. It is adequate but has clear gaps for a tool that modifies blockchain state.

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

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

Schema description coverage is 100%, so the schema already documents all parameters (wallet_id, amount, chain_id). The description adds meaning for 'amount' by specifying the format ('human-readable format') and providing an example ('0.5' for 0.5 ETH), but does not add semantics beyond what the schema provides for 'wallet_id' or 'chain_id'. Baseline 3 is appropriate as 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 clearly states the specific action ('Wrap native tokens') and resources involved (ETH, AVAX, BNB, POL, PLS into WETH, WAVAX, etc.). It distinguishes from sibling tools like 'unwrap_eth' by specifying the conversion direction and mentions the purpose ('Required for most DeFi protocols that use ERC-20 tokens instead of raw native tokens'), making it highly specific and differentiated.

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 provides clear context on when to use this tool ('Required for most DeFi protocols that use ERC-20 tokens instead of raw native tokens'), but does not explicitly state when not to use it or name alternatives (e.g., 'unwrap_eth' for the reverse operation). It implies usage for DeFi compatibility but lacks explicit exclusions or comparisons to siblings.

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