Vurto Swap

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

Beyond the annotations (which only assert non-read-only, non-idempotent, open-world), the description discloses the server-side validation chain, the 30-minute grant duration, single-use/replay protection, and a precise error taxonomy. This is exactly the behavioral context annotations cannot carry.

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

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

Three compact sentences, action front-loaded, with a trailing error list that is genuinely useful for handling failures. No filler or restatement of the tool 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 mutating authorization call with no output schema, the description covers inputs, validation, lifetime, and errors. It leaves the Solana `transaction` path and the exact success payload to the schema, a minor gap rather than a blocker.

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?

At 57% schema coverage, the description usefully clarifies what the signature must be *over* (the exact challenge, that receiver, that chain) and ties nonce/message back to destination_challenge. It stops short of explaining the Solana-only `transaction` alternative or the wallet/chainId fields, which the schema covers.

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 action (hand over the signature from destination_challenge) and the resulting effect (builds may deliver to that receiver for 30 minutes). It clearly distinguishes itself from the sibling destination_challenge, which produces the challenge this tool consumes.

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 makes the prerequisite explicit (you must first call destination_challenge to get nonce/message) and states the outcome window, giving clear context for when to call it. It does not state any when-not-to-call condition or name an alternative path, so 4 rather than 5.

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

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

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) only sketch the safety profile, and the description adds substantial context beyond them: the 403 destination_not_authorized enforcement, the chain-specific signing artifacts (EIP-712 typedData on EVM, never-landing memo proofTransaction for Ledger on Solana), and an explicit human-confirmation requirement. This is exactly the behavioral detail annotations cannot carry.

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 dense, run-on paragraph but every clause earns its place – the 403 trigger, the return shape, the per-chain signing path, and the confirmation rule. It is front-loaded with the lock behavior before the signing steps. Slightly overpacked, but not padded.

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, yet the description fully describes the return values ({nonce, message, expiresAt}, typedData, proofTransaction) and the complete downstream signing flow. For a complex, multi-step, safety-critical authorization tool, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, so wallet, chainId and receiver are already documented in the schema, and the description adds no syntax or format detail beyond it. It does contextualize the parameters by explaining the EVM vs Solana (chainId) branching and stressing that the full receiver address matters, but that is largely behavioral rather than semantic. Baseline 3 applies when the schema does the heavy lifting.

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

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

Although it opens with the terse label 'Destination lock,' the description immediately states the concrete effect: a receiver different from the signing wallet is refused by swap_build, double_build and nn_build (403 destination_not_authorized) until authorized. It names the sibling tools and the exact return payload ({nonce, message, expiresAt}, plus typedData/proofTransaction), so an agent can distinguish it from destination_authorize without opening a schema.

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

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

Explicit routing: sign via prepare_signing (EVM) or wallet message (Solana), then 'call destination_authorize.' It also gives clear when-not guidance: 'Never sign this without the user asking to send to that address. Paying an invoice does not need it.' Both the alternative tool and the exclusion condition are 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?

Annotations only say readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true — they say nothing about atomicity or failure modes. The description adds the critical disclosure that the legs are NOT atomic, that there is no combined contract call, that each leg is a separately signed transaction, and that partial execution leaves the wallet with half the intended ratio. This is exactly the behavioral context metadata cannot carry.

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 purpose and return shape before the operational rules. Every sentence carries unique information: what it builds, the swap_build equivalence, the non-atomicity caveat, and the sequencing rule with its rationale. 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, the description supplies the return contract ('{ legA, legB }, each a full SwapPlan exactly like swap_build's'), and for a nested-object, 4-required-param, open-world mutation tool it also supplies the two things an agent would otherwise get wrong: execution order and abort-on-failure. The remaining field-level detail is adequately covered by the 60% schema coverage.

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 60%, so the schema documents most parameters (amount vs amountRaw, receiver constraints, symbol resolution). The description adds only the conceptual mapping that each of legA/legB is 'a full SwapPlan exactly like swap_build's,' which clarifies the nested object shape but not individual field semantics. 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 ('Builds signable/sendable plans for BOTH legs of a Double Out or Double In swap') and immediately disambiguates from the closest sibling by explaining it is 'two ordinary swap_build calls under the hood.' An agent can tell from the first sentence exactly what this produces and how it differs from swap_build.

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

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

Gives explicit operational sequencing: 'Execute leg A fully first (steps, signing, report_execution) and confirm it landed before starting leg B,' plus a clear when-not rule ('If leg A fails or is rejected, do NOT execute leg B'). It implies the alternative (two separate swap_build calls) rather than naming it, and never mentions double_quote as the natural predecessor despite the quoteId param, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: this is NOT a combined/atomic route, each leg is an independent swap_quote call, and native-asset legs require gas twice, so a full-balance split will starve the second transaction.

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 rationale, then constraints and the gas caveat. Dense but every sentence carries a distinct constraint; the gas warning is a slight tangent but materially affects correctness.

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

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

Covers mode semantics, cross-leg constraints, non-atomicity, and gas budgeting, which is most of what an agent needs for a nested-object quote call. With no output schema, it does not describe the returned ranked-route/quote shape, a minor remaining gap against annotations that already carry the safety profile.

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 60% on a nested 5-param tool, and the description compensates by spelling out the cross-leg invariants (shared source/destination per mode) and warning that amounts must be supplied exactly because no percentage/split computation happens. It does not re-explain mode's own enum, but cross-parameter logic is the higher-value addition.

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

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

States a specific verb (compares) and resource (ranked routes for two swap legs), then names the two modes and the sibling it wraps (swap_quote). An agent can distinguish it from swap_quote and double_build 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?

Explains exactly when to use it (when both legs must be priced at the same instant, e.g. building a pool or matching a target ratio) and explicitly routes two-sequential-swap needs elsewhere. The per-mode shared-token invariants ('out' requires legA.tokenIn == legB.tokenIn) are stated as hard conditions.

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

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

Annotations already declare openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds substantial context beyond them: no signing or sending happens, a free screening runs first with screening_blocked (403) and screening_unavailable (503), payer must be the creator or the result is not_invoice_creator (403), and the full error set is enumerated. This is rich behavioral disclosure, though some of it, like the swap-build instructions, is operational rather than behavioral.

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 definition is a single wall of text covering two models, with repeated instructions to call invoice_report_analysis_payment and duplicated swap guidance for EVM and Solana. Key constraints like the payer restriction and screening error codes are buried mid-paragraph rather than front-loaded. The content is dense and mostly relevant, but it is not structurally concise.

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 output schema and only three parameters but a complex dual-chain flow, the description covers prerequisites, screening behavior, error codes, the EVM plan reference (same shape as invoice_pay), and the Solana receiverAnalysis return. The EVM return shape is left by reference to a sibling rather than detailed, which is a minor gap, but overall the agent has enough to call it correctly.

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

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

Schema coverage is 100%, so the schema already defines id, payer (EVM creator vs Solana paying wallet), and checks (Solana-only, [] gives up). The description echoes those meanings and adds the pricing context of checks (0.30/0.075/0.375) but does not add syntax or semantics the schema lacks. Baseline 3 is appropriate when the schema carries the parameter burden.

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 operation: builds one USDC transfer of analysis.amount to the Vurto fee wallet, signed by the invoice creator, and explicitly says nothing is signed or sent. It distinguishes itself from invoice_pay (which refuses while awaiting payment) and invoice_report_analysis_payment (the reporting step). The dual EVM/Solana semantics make the purpose slightly sprawling, but the core verb+resource remains identifiable.

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 precise precondition: only for invoices created with paid checks whose analysis.status is awaiting_payment, pointing to invoice_get. It names alternatives: paying from another token must go through POST /v1/swap or POST /v1/svm/swap, and checks: [] explicitly abandons an unpaid analysis. The Solana path spells out that invoice_pay refuses with receiver_analysis_unpaid (409) until this is done, so the agent knows exactly when to route here.

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

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

Annotations already declare non-readonly, open-world, non-idempotent behavior, and the description adds substantial context: no signature/API key needed, verified stablecoin allowlist, split-fee conditions, third-party data sharing, error codes, and Solana-specific screening. This is rich behavioral disclosure beyond structured fields.

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

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

The first sentence is front-loaded and clear, but the description is very long and dense, with repeated error and check details that could be tightened. It is appropriately structured for a complex tool but not concise.

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 explains the returned invoice fields and covers major behavioral conditions, error cases, paid checks, and Solana differences. For an 8-parameter creation tool with rich annotations, this is complete enough for correct invocation.

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

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

Schema description coverage is 100%, and the schema already documents each parameter in detail. The description reinforces token resolution, amount decimals, checks, payerChecks, and confidential behavior, but adds little parameter-specific meaning beyond the schema baseline.

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

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

The description opens with a specific verb and resource: "Create a payment request," then names the key dimensions (recipient, token, amount, network) and the returned invoice fields. An agent can distinguish this creation tool from retrieval/payment siblings 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?

It explains when optional paid checks apply, when to use payerChecks instead on Solana, and that invoice_analysis_pay handles payment of analysis. It does not explicitly route retrieval to invoice_get or state when not to create an invoice, but the creation context is clear.

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

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

Goes well beyond the readOnly/idempotent annotations: it discloses that pending payments are re-checked on-chain at most twice per read and once per 15 seconds, that confidential invoices can no longer be paid, and that the receiver field is scrubbed under the confidential rule. These are operational traits the annotations do not convey.

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

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

The purpose is front-loaded in the first clause, which is good, but the single paragraph then sprawls into deep nested return detail (analysis.report subfields, sourceOfFunds, confidential legacy rules) that is hard to scan. It is informative rather than wasteful, yet far longer than needed for tool selection.

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 carry return-value semantics, and it does thoroughly: status values, paying transaction, on-chain received amount, checks, analysis.report contents, and confidential edge cases. Nothing an agent needs to interpret a response is missing.

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

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

Schema coverage is 100% and the single id parameter is fully documented in the schema ("INV-XXXX-XXXX or the 8-character id"); the description's mention of dashes being optional duplicates that. No additional parameter meaning is added, 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?

Opens with a specific verb and resource ("Read an invoice by id") and immediately enumerates the exact fields returned, so an agent knows precisely what it gets. It also distinguishes its role from invoice_pay by stating how that sibling behaves on confidential invoices (private_invoice_paused).

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 read-oriented framing and by the note that a signed web session sees more detail, but there is no explicit "use this when / use invoice_pay or invoice_analysis_pay instead" routing among the many invoice_* siblings. An agent can infer the read case but must guess at boundaries.

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 only generic annotations, the description carries extensive behavioral context: it discloses third-party Scorechain/Didit screening, auth requirements via destination_challenge/destination_authorize, rate limits like 3 or 2 payer wallets per invoice, status codes such as payer_signature_required and analysis_attempts_exceeded, and the fact that nothing is signed or sent here.

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 first sentence is front-loaded well, but the rest is a dense run-on wall of text. Key points are repeated, such as the both-wallet screening and the payer-proof-before-analysis flow, making it harder than necessary to scan.

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

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

For a complex payment-planning tool with no output schema, the description is unusually complete: it explains the returned plan shape, EVM and Solana signing flows, required follow-up calls, screening behavior, paid analysis constraints, and the major error conditions an agent will encounter.

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 description still adds meaningful context beyond the schema by explaining that tokenIn defaults to the invoice token and that choosing another token changes the method, and by connecting slippageBps to the guaranteed minimum and the payer's requested amount.

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

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

The opening states a specific verb and resource: 'Build the plan to pay an invoice from payer,' and immediately clarifies that nothing is signed or sent. It distinguishes the transfer and swap variants and their scope, so an agent can tell what the tool does 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?

The description gives explicit branching instructions: use method "transfer" for same-token payment, "swap" for another token, and "swap_then_transfer" for the split flow. It also names required follow-ups like prepare_signing, invoice_report_payment, destination_authorize, and invoice_pay again with next.body, plus error-specific alternatives such as retrying after price_moved.

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

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

The description adds substantial behavioral context beyond the annotations: on-chain verification rules, screening behavior, pending and rejected states, specific rejection reasons, tx_already_used handling, and Solana payer constraints. It is consistent with the annotations and gives the agent a rich picture of what happens on success and failure.

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

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

The core action is front-loaded and the dense error-code details are relevant to correct invocation. The single-paragraph format is somewhat run-on, but most sentences carry useful operational 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 complex payment-reporting tool with no output schema, the description covers success behavior, retry conditions, error codes, Solana-specific requirements, and the receiver analysis result. It gives enough context for an agent to call and interpret the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for txHash and especially payer on Solana, including the requirement that the transaction be signed by that payer. It does not add much beyond the schema for id, but overall it improves parameter understanding.

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 action and resource: reporting an analysis payment transaction to the server after it is mined, with on-chain verification details. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as invoice_analysis_pay or invoice_report_payment.

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

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

It clearly says to call once the transaction is mined and to retry after a few seconds when the payment is pending. It also explains error conditions, but it does not explicitly name when to use this tool versus related siblings like invoice_analysis_pay.

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

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

Goes well beyond the annotations by disclosing payer re-screening with payer_blocked semantics, the 10-year retention of refusals, the pending-until-mined behavior with 409, the 5-pending/30-unconfirmed throttling with 429, and single-use txHash rules with tx_already_used. This is exactly the error/limit/auth context annotations cannot carry.

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

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

Front-loads the core action and keeps every sentence substantive with no filler. However, it is a dense single paragraph where distinct concerns (screening, pending, limits, hash reuse) run together rather than being cleanly separated, slightly reducing scannability.

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

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

For a write-oriented reporting tool with no output schema, the description covers return-relevant states and error codes, idempotency behavior, rate limits, and proof semantics. An agent can invoke and handle responses correctly with this alone.

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 four parameters (id, payer, method, txHash) are already documented in the schema. The description reinforces that the payer must be the signer and the txHash is the proof, but adds no format or constraint detail beyond what the schema already provides, 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 action (report a payment transaction to the server) and resource (invoice payment), and explains that the server verifies on-chain what reached the receiver. It is clearly distinguishable from invoice_pay (which sends the payment) by the 'right after sending it' framing, though it never explicitly names the sibling it complements.

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

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

Gives concrete usage context: call right after sending the transaction, call again once mined when you get payment_pending (409) or too_many_pending (429). It stops short of explicitly contrasting with invoice_report_analysis_payment or payout_report_payment, leaving that routing 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?

The description discloses critical behavior beyond the minimal annotations: no quoteId handoff, fresh re-quoting, optional machine credential rate-limit effects, approve-step targeting of VurtoSwapRouter rather than underlying providers, approval_required simulation flow, routeSwitch fallback semantics, and unsupported status endpoints. This is far more than the annotations alone provide.

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 long, but the complexity of the tool justifies the length. It is front-loaded with the core purpose and organized around major behavioral topics (quoting, auth, steps, routeSwitch, status). A few sentences are slightly redundant, such as the repeated no-quoteId point, but no sentence is filler.

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

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

With no output schema, the description fully explains the return shape (steps[] with approve steps and one transaction step), the approval flow, the routeSwitch replacement behavior, and the correct post-send verification path. It covers auth, prerequisites, and error/fallback conditions, leaving no critical gap for an agent to call it correctly.

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

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

Schema coverage is moderate at 60%, and the description adds contextual meaning by tying chainId/inputLegs/outputLegs to the fresh re-quote behavior and by explaining that wallet is the signing wallet. It does not walk through every parameter, but the schema already documents the individual fields, and the description clarifies how they are used together.

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

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

The description opens with a specific verb and resource: 'Builds ONE signable/sendable atomic transaction executing every leg of an N:N basket through VurtoSwapRouter.' It clearly distinguishes itself from related tools by emphasizing the N:N basket scope, the absence of quoteId handoff, and the contrast with swap_build's per-provider approvals.

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

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

It gives explicit when-to-use guidance: pass the same fields as nn_quote or skip nn_quote and call directly, and no API key is required. It also states when not to use supporting tools: report_execution and swap_status do not support this build's transaction step, so the agent should check the receipt directly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the waterfall allocation, the atomicity, the fact that failures[] can result in a partial basket that is 'never silently dropped,' and the relationship to nn_build (legs are what will be executed). It also discloses chain-specific failure modes (multi_swap_not_supported_on_chain) and Solana's runtime all-or-nothing rule. This goes well beyond the annotations.

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 dense but every sentence earns its place: it defines the tool, explains the allocation, gives the outputPercent constraint, states limits, and describes the return shape. It is longer than average, but the complexity of the tool justifies the length. The most critical differentiator (NOT decomposable) is front-loaded early. Slight redundancy exists between the schema's outputPercent description and the tool description, but that is minor.

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

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

For a complex N:N quoting tool with no output schema, the description does a strong job: it explains the return shape (legs[] with NormalizedQuote, failures[]), the partial-basket behavior, the leg count bound, and the chain-specific constraints. It does not detail pagination or exact failure error formats, but those are less critical for a quote tool. The annotations cover safety, and the schema covers parameters. The description is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 60%, so the description carries some burden. It adds meaning to inputLegs[] and outputLegs[] by explaining the allocation semantics: outputPercent is 'an integer percent of the TOTAL basket value, not a fixed amount, because the actual split depends on the allocation.' It also clarifies the leg count limit and the resulting on-chain leg count formula. The wallet parameter is not discussed in the description, but the schema already covers it well. The description compensates for the schema's gaps on the core basket 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?

The description opens with a precise definition: 'N:N — quotes a basket where N input tokens fund M output tokens in ONE atomic on-chain transaction.' It names the specific verb (quotes), the resource (a basket), and the key differentiator (atomic, waterfall allocation). It also explicitly contrasts with swap_quote/double_quote, making sibling differentiation 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?

The description explicitly states when NOT to use this tool: 'NOT decomposable into independent swap_quote/double_quote calls — the allocation itself is the thing being computed.' It also explains the outputPercent constraint and the partial-basket behavior, giving an agent clear conditions for invocation. The sibling list includes swap_quote and double_quote, and the description directly addresses why those alternatives are not equivalent.

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

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

Goes well past the annotations: discloses pre-flight OFAC/freeze screening, that failures are atomic (refused before anything is created), and pins each error to a code and HTTP status (payer_blocked, receiver_blocked with details.index, screening_unavailable 503). It also explains output shape and transaction packing against the network limit, which matters for a non-idempotent, open-world write.

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

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

Front-loads purpose, then workflow, then errors — a sensible order with no filler sentences. It is a single very dense paragraph with heavy parenthetical nesting, which slightly hurts scannability for such a long body.

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 supplies the return contract (invoices[], transactions[], invoiceIds per transaction) plus the next step for each signature. For a 4-param, non-idempotent, multi-step money-movement tool, an agent has everything needed to call it and recover from each documented failure.

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 only 50% (chainId and the recipients array lack field descriptions), and the description compensates: it ties 'token' to a verified/listed token via token_not_listed, states the 20-wallet cap, and converts recipient rules into actionable errors (batch_duplicate_recipient says to sum amounts into one row, batch_self_payment enforces payer exclusion). Remaining gap is that chainId and the per-recipient memo/amount formatting are only covered in 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?

Opens with a specific verb+resource+scope: pay up to 20 wallets their exact amounts, in the payer's token, on Solana, with an explicit 'no swap' qualifier that separates it from swap_build/swap_quote. The follow-up relationship to payout_report_payment and prepare_signing is named, so an agent can place it in the sibling set 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 the full activation-to-completion chain: build the batch, sign each transactions[i].transaction via prepare_signing + /v1/svm/execute, then confirm with payout_report_payment. It is clear when to reach for this rather than swap/double/nn builds, but it never states exclusion conditions (e.g. when to use invoice_pay for a single recipient instead).

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

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

Annotations already declare idempotentHint=true and destructiveHint=false; the description corroborates this by telling the agent re-calling is safe and expected while items are pending. It also discloses that verification is on-chain against the actual receiver, which the annotations do not convey. Return shape is not described, but no output schema exists to lean on.

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, no filler, and the primary action plus its prerequisite (send first) is front-loaded ahead of the pending/retry caveat. Every clause carries 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 3-parameter reporting tool with no output schema, the description covers the prerequisite, the source of invoiceIds, the verification model, and the pending/retry behavior. It is close to complete; only the sibling-vs-sibling distinction is left implicit.

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

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

Schema description coverage is 100%, so payer, txHash and invoiceIds are already documented, including that invoiceIds come from payout_batch.transactions[i].invoiceIds. The description adds only the framing that the call handles 'one batch transaction', leaving 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?

States a specific action (hand a batch transaction to the server) on a specific resource, and ties the input back to payout_batch. It does not explicitly distinguish itself from the sibling invoice_report_payment, so the batch-vs-single boundary is only implied by the word 'batch'.

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 timing ('right after sending it') and a retry rule ('call again a few seconds later if some are still pending'), which is genuinely actionable. It never names the alternative tool (invoice_report_payment) or states an exclusion, so it falls short of a 5.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses critical behavior: the command blocks until user approval/rejection/timeout, prints one JSON line, and exits; expected_keys tells which result field to read; Solana returns a different signer with the same shape and requires POSTing to /v1/svm/execute. This is rich, non-obvious behavioral context that annotations alone would not provide.

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 long but every sentence carries high-signal operational detail. It is front-loaded with the core purpose, then flows into agent instructions, EVM behavior, and Solana behavior. There is no filler or repetition of schema content.

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

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

Despite having no output schema, the description fully explains the return behavior: one JSON line, expected_keys values (txHash, signature, signedTransaction), and the follow-up POST for Solana. It also covers blocking behavior, chain-specific differences, and the private-key handling rule, making it complete for a complex 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 the baseline is 3, but the description adds meaningful parameter semantics: it explains EVM step types (approve/transaction/signature), Solana's lack of steps[] and approve, the exact step shape to pass for Solana, and the significance of executionRef absence. This goes beyond the schema's field-level descriptions.

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

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

The description states a specific verb and resource: it 'synthesizes the local CLI signer invocation for one step of a swap_build plan' and explicitly distinguishes itself by noting it 'does not call the Vurto backend'. This clearly separates it from backend-calling siblings and makes its role 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 gives explicit operational guidance: the agent must not ask for a private key, should run the command as a background task, and should never ask the user 'did you sign?'. It also clarifies when EVM vs Solana parameter shapes apply. It does not name sibling tools as alternatives, but the context is clear enough for correct use.

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

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

The description goes well beyond the annotations by disclosing server-side behavior: the server reloads the stored build, submits the signed CoW order, returns a uid, verifies the Solana fee payer/transaction, and has no transaction hash for the CoW path. It also clarifies credential behavior, adding real context without contradicting the annotations.

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 dense but every clause earns its place. It front-loads the purpose, then gives three compact path-specific sentences and a final credential note, 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?

For a multi-path, 6-parameter tool with no output schema, the description covers parameter routing, server-side effects, auth, and the CoW path's uid return. It stop short of describing return or error semantics for the EVM-transaction and Solana paths, which is a minor but real 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 baseline is 3, but the description adds crucial cross-parameter relationships: wallet + txHash + quoteId for EVM, wallet + chainId + quoteId + signature for CoW, and buildId + signature for Solana. This combinatorial guidance is not visible in the flat schema and meaningfully helps an agent assemble correct calls.

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

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

The description opens with 'Reports a completed swap, closing the loop,' which clearly names the action and resource. It then details three distinct invocation paths (EVM transaction, EVM CoW signature, Solana), making it easy to distinguish from sibling build/quote/status tools.

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

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

The description gives precise parameter combinations for each execution path and an explicit exclusion: 'never report an approve step as an execution.' It also notes that no API key is required. It does not explicitly name sibling alternatives like swap_status, but the path-specific guidance is strong enough to route correct usage.

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

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

Annotations only declare the safety profile (readOnly=false, openWorld=true, idempotent=false), so the description carries real behavioral weight and delivers: step ordering/required-revert behavior, approval_required vs incomplete simulation handling, signature-step semantics (uid not hash), the cowswap native-asset registration caveat, routeSwitch fallback meaning, and the destination authorization prerequisite. This is far beyond what annotations provide.

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 purpose and the recommended mode, then a clearly enumerated list of pitfalls. Dense but each sentence earns its place; minor flaw is the numbered list introduced as 'Four things' that actually contains five items.

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

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

For a complex, multi-step mutation tool with no output schema, the description covers execution flow, failure modes, ordering requirements, credentials, and downstream verification. An agent has everything needed to call it and interpret results correctly.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds genuine meaning: wallet is the signer and only a machine credential (not an API key) raises limits, amount vs amountRaw are mutually exclusive, and receiver behavior/authorization constraints are spelled out. Some of this duplicates schema text, keeping it just below 5.

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

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

States a specific verb+resource ('Build a signable/sendable plan for a swap') and immediately distinguishes itself from swap_quote by explaining the quoteId-omitted vs quoteId-passed modes. An agent can route between the quote and build tools without opening either schema.

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

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

Explicitly recommends omitting quoteId to quote-and-build in one call, names the alternative (pass quoteId from swap_quote to build exactly that route), and points to swap_status for post-execution verification. When-to-use and the sibling alternative 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?

Goes well past the annotations: discloses the ~10-12 second quote TTL and the non-persistable quoteId, the ranking basis (net value after gas and platform fee, single unit price for the output token), the estimatedGas/gasUsd pairing for self-sourced gas prices, and provider filtering when a receiver is set. The idempotentHint=false annotation is corroborated by the ephemeral-quote 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?

Purpose and the 'no build, no spend' guarantee are front-loaded, and the operational caveat (quote expiry) closes the entry. It is dense and mostly earns its length, though the ranking rationale sentence is wordier than needed.

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 eight parameters, the description covers what matters: return concepts (quotes[], quoteId, estimatedGas, gasUsd, supportsReceiver), key error paths (ambiguous_token, receiver_native_sol_unsupported, destination_not_authorized), and cross-tool linkage to destination_challenge/authorize. It stops short of describing the full quote payload shape, but nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so every parameter including the subtle wallet/receiver semantics is already documented structurally. The description restates the wallet executability rule and receiver provider-filtering rather than adding syntax or constraints the schema lacks, so it lands at the baseline 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?

States a specific verb and resource ('Compare ranked routes across providers for a swap') plus an explicit negative scope ('without building or spending anything'), which cleanly separates it from swap_build. An agent can pick this over its siblings without reading 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?

Clear when-to-use context (pre-build comparison) and a routing hint to swap_build as the consumer of a quoteId, including the advice to re-quote rather than hold a stale id. It does not, however, differentiate itself from other quote siblings such as double_quote or nn_quote, so the alternative-selection 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?

Annotations already mark the tool read-only and idempotent; the description adds meaningful behavioral detail: for CoW ETH-flow it consults the orderbook and distinguishes order_expired_refundable from order_expired_refunded (rather than trusting the receipt), and for Solana it lists the possible network statuses (confirmed, pending, failed, expired). This goes beyond the annotations without contradicting them.

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 well-organized sentences with no fluff. The core purpose is front-loaded ('Re-checks a swap'), and the EVM/Solana split is clear and scannable. Every clause adds value; nothing is redundant.

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

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

The tool handles multiple chains and optional parameters, yet the description explains the chain-specific inputs and even hints at possible outcomes (statuses for Solana, distinguishing expiry types for CoW). With no output schema, it gives enough about the expected return behavior. It doesn't describe the exact return structure, but for a status-check tool this is sufficient.

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%, giving a baseline of 3. The description adds cross-chain usage context: it specifies which parameters apply to which chain (wallet+executionId for EVM, signature for Solana), and clarifies that executionId comes from report_execution. This is additional meaning beyond the schema's per-parameter descriptions, which are more generic.

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

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

The description opens with a specific verb+resource ('Re-checks a swap') and immediately separates EVM and Solana variants, clarifying that this is a status-check tool distinct from the build/quote/execution siblings. It even names the source of the executionId (report_execution), which disambiguates it from that sibling.

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

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

It explicitly tells the agent which parameters to pass for each chain ('EVM: pass wallet + executionId', 'Solana: pass signature') and references report_execution as the source of the id, implying this tool is used after execution to re-check status. It doesn't explicitly say 'use this instead of X', but the contextual guidance is clear enough given the sibling names.

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

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantive behavior: the three possible verdicts (passed, blocked, unavailable), that invoice_pay auto-runs this and refuses with receiver_blocked, and that paid checks (Scorechain/Merkle Science) return paid_check_requires_invoice (400) here. These are non-obvious failure modes and costs that annotations cannot convey.

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

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

Front-loads the core action in the opening clause, then layers scope, then integrations. It is dense but not padded; the only mild redundancy is the paid-check caveat appearing both in the description prose and again in the schema's `checks` description.

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

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

With no output schema, the description carries the return-value burden and does so ('Returns verdict passed, blocked or unavailable, with each check'). It also covers cost, error codes, and the invoice-flow integration — everything an agent needs to call it and interpret the result.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by explaining the trap around the `checks` parameter: it is 'kept for compatibility; leave it out', costs 0.15/0.60 USDC, and is refused here with a specific error code — meaning an agent understands not just the type but why it exists and what will happen.

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

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

Opens with a specific verb + resource + scope: 'Check any wallet (EVM 0x address or Solana base58, case-sensitive) before paying it'. It then enumerates exactly what is checked (OFAC SDN, issuer freeze lists, fund trail), which distinguishes it from sibling tools like invoice_pay or swap_build without requiring the schema.

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

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

Gives an explicit when ('before paying it or taking its money'), names the automatic alternative ('Paying an invoice (invoice_pay) runs this check... so a payment... never reaches a sanctioned or frozen wallet'), and names exclusions ('Plain swaps (swap_build, double_build, nn_build) do not run it'). An agent can route correctly with no inference.

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