Laso Finance

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds useful behavioral context: it returns a `destination_id`, it supports multiple destination types (US bank, IBAN, crypto), and it warns that bank destinations are rejected without a postal address, so supplying `recipientAddress` avoids a dead end. This goes beyond the schema and 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 compact and front-loaded: the core action and return value appear in the first sentence, followed by a one-word 'Free.' and then a concise but informative parameter walkthrough. Every sentence earns its place; no fluff.

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 has an output schema, so return values are covered. The description covers prerequisites, the dead-end scenario, and the editable field. It could be slightly more explicit about the exact structure of the `destination` object, but the schema already provides that. Overall, an agent has enough context to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the relationship between `recipientId` and `createBankingRecipient`, clarifying that `nickname` is the only editable field later, and explaining why `recipientAddress` is needed (name-only recipients cause rejection). This adds value beyond the raw 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 clearly states the verb 'Attach' and the resource 'bank details to a recipient', and explicitly mentions the returned `destination_id` used by `/send-bank-payment`. This distinguishes it from sibling tools like `create_banking_recipient` (creates the recipient) and `update_banking_destination` (edits later).

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 when to use this tool: to attach bank/crypto details to a recipient, and notes the prerequisite that a recipient must exist from `createBankingRecipient`. It also mentions the alternative `updateBankingDestination` for editing the nickname later. It doesn't explicitly say when NOT to use it, but the context is clear enough.

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

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

Beyond the annotations, the description discloses that no SOL is needed for fees, that a provider fee up to 0.25% plus pool fee is included, the 45-second wait, and the succeeded/pending status outcomes with outputAmount and txHash. It also clarifies that funds remain in the wallet and swaps do not count against spend limits, which is valuable operational 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?

The description is front-loaded with the core action, then adds usage context, prerequisites, fee behavior, timing, return values, and spend-limit implications. Each sentence contributes useful information without 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 the tool's complexity, the output schema, and the annotations, the description is complete enough for an agent to call it correctly. It covers purpose, workflow, fees, timing, return statuses, and the important wallet/spend-limit behavior.

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 already documents all four parameters at 100% coverage, including amount units, native SOL handling, USDC default, and slippage limits. The description reinforces the USDC default and the token-discovery workflow, but does not add parameter-level detail beyond the schema, so the baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: swap one asset in the managed agent wallet for any other Solana token, defaulting into USDC. It clearly distinguishes this from the quote and token-search siblings, so an agent can identify the tool 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 gives explicit when-to-use cases: making a held token spendable or buying a needed token. It also names prerequisite and alternative tools: get_agent_wallet to see held tokens, search_swap_tokens to find mints, and agent_wallet_swap_quote to check price first.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the non-mutating nature is covered. The description goes beyond them by disclosing the balance precondition that causes refusal and by interpreting the output ("the gap is what the swap costs"), which is real behavioral context. It doesn't mention quote staleness/expiry, which matters for a live price.

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 price-don't-execute distinction, then output semantics, then the refusal condition. No filler, and the most decision-relevant fact comes first.

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

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

With an output schema present the description needn't enumerate returns, yet it briefly frames their meaning, and it covers the one precondition an agent could trip over. For a read-only four-parameter quote tool with full annotations, nothing needed for correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description still adds value: it ties slippage_bps to minimumOutputAmount ("the least the swap delivers at the slippage limit") and ties from_mint to a required wallet balance, which the schema does not state.

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 ("Price a swap inside your managed agent wallet") and immediately delimits it with "without making it," which is exactly what separates it from the sibling agent_wallet_swap. An agent can pick between the two 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?

"Same arguments as agent_wallet_swap" plus "without making it" gives clear implied routing: quote first, execute later with the sibling. The precondition "Refused if the wallet holds less of from_mint than amount" adds a concrete when-it-fails condition. It stops short of an explicit "call this before agent_wallet_swap" instruction, so not 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?

The description adds substantial behavior beyond the annotations: CCTP bridging, 0.01% fee, 1 USDC minimum, spend-limit ceiling, ~1 minute delivery, automatic Base-to-Solana pullback (~15s), and the fact that other tokens are valued at market price for spend limits. These are exactly the operational details an agent needs for a destructive, non-idempotent, open-world transfer.

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 text is dense but front-loaded: the primary transfer use case and cross-chain caveat come first, followed by funding-source mechanics and the alternative-token path. Every sentence carries operational information, though the final sentence about other assets is long and could be slightly tighter.

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

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

With an output schema present and annotations declaring destructive/open-world/non-idempotent behavior, the description fills the remaining gaps: funding source, bridge mechanics, limits, timing, and how other tokens are handled. Nothing critical for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real meaning: omitting 'mint' means USDC, 'amount' is in USDC unless mint is set, and 'destination_network=base' changes address format and enables bridging with specific limits. It does not repeat schema text verbatim; it explains the interaction between parameters.

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 (transfer) and resource (USDC out of the managed agent wallet) plus cross-chain behavior. It explicitly distinguishes itself from the sibling 'withdraw' by noting that withdraw draws on the separate Laso account balance, so an agent can route correctly 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 clear usage contexts ('pay someone or move funds to another wallet you control') and an explicit exclusion/routing rule versus 'withdraw'. It also explains the alternative path for non-USDC assets via the mint parameter. However, it does not mention 'move_agent_wallet_funds' or 'agent_wallet_swap', which are close siblings an agent might otherwise consider.

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 indicate readOnlyHint=false and destructiveHint=false. The description adds context about the side effects (starting a session, returning wallet funding state) which is not in annotations. However, it does not describe what happens if called again or whether it can be called multiple times, but idempotentHint=false already signals that. Overall it adds useful behavioral context without contradiction.

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, front-loaded with the critical instruction 'Call this FIRST'. Every sentence serves a purpose: the first explains what it does and when, the second mentions the extra return value. 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 tool with an output schema (not shown) and two well-documented parameters, the description fully covers the tool's role, timing, and return value. An agent can correctly invoke it as the first step without missing information.

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 both parameters have descriptive text (message, agent_name with max lengths). The description mentions 'Introduce yourself with agent_name and message' but adds minimal new meaning beyond the schema. Baseline of 3 is appropriate since the schema already carries the 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?

The description states a specific purpose: resolving the connection screen, naming the agent in the dashboard, and starting a session. It clearly distinguishes itself from all sibling tools by positioning itself as the mandatory first call.

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 instructs 'Call this FIRST, before any other Laso tool' and explains the context (human watching a waiting screen). It also notes it doubles as a setup check, giving the agent clear when-to-use 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 only cover the safety profile (non-read-only, non-idempotent, non-destructive); the description supplies the behavior that actually matters: the human approval gate via approval_url that the agent must never open, the ~45s wait versus a potential two-minute live turn with state: done/running plus turn_id polling, and that the route is free with no identity verification. This is behavior beyond what structured fields convey.

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

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

Front-loaded with the purpose, then a numbered flow, then timing behavior; nearly every sentence carries operational weight. It is longer than strictly minimal, but the density of actionable detail (approval routing, poll fallback, free/no-KYC note) justifies most of the length.

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-turn live-merchant purchase flow with nested address input and an output schema, the description covers the conversation lifecycle, the approval gate, and the async return states, so an agent knows what to expect at each call and how to resume.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantics: which parameter to send on which turn, that delivery_address should go on both the cart-requesting call and the confirm, and that the cart is bound to the address it was shown for. It does not restate the hash pattern or field formats, which the schema already 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?

States a specific verb and resource ('Buys from online merchants ... and pays with the card the account holder saved'), names concrete merchants, and distinguishes itself from siblings like order_gift_card, order_intl_card, and send_payment by tying the payment to the holder's saved card. An agent can route to it without opening the schema.

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

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

Gives an explicit four-step when-and-how sequence, names the sibling route for prerequisites (GET /get-saved-cards) and the polling alternative (GET /get-purchase-turn), and states the precondition that nothing can be charged before confirm. Exclusions and conditions are all spelled out.

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

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

Annotations already declare destructiveHint=true, readOnly=false, and idempotent=false. The description adds valuable behavioral context beyond annotations: the charged amount is credited back to the account balance, and the state precondition (`state=queued`) is disclosed. No contradiction with 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 concise and front-loaded: first line states the action and resource, then the paragraph adds the eligibility condition and financial effect. Every sentence earns its place without 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 single-parameter mutation tool with a provided output schema and annotations covering destructiveness, the description covers the essential operational facts: what is cancelled, when it can be cancelled, and what happens to the charged amount. Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100% and the only parameter, `card_id`, is already well documented by the schema with its source (`returned from /order-intl-card`). The description reinforces that it is a queued order ID but does not add significant meaning 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 uses a specific verb ('Cancel') and resource ('queued international card order'), and adds the key qualifier 'non-reloadable' with the state constraint `state=queued`. This clearly distinguishes it from sibling ordering tools like `order_intl_card`, `order_card`, and `order_gift_card`.

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 the tool applies: only for a previously queued order that has not yet been fulfilled by an admin. It gives a clear exclusion ('as long as it has not yet been fulfilled') but does not name an alternative tool or explain what to do if the condition is not met.

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?

It discloses important side-effect and security behavior beyond annotations: the raw key is shown once, only a hash is stored, and the key cannot be retrieved again. This substantially helps an agent reason about consequences, and it does not contradict the readOnly/destructive/idempotent hints.

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 compact and front-loaded: the action appears first, followed by the critical one-time-raw-key caveat. The heading-like first sentence and 'Free.' are slightly redundant but not wasteful.

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 single optional parameter, the presence of an output schema, and annotations, the description covers the essential operational facts: what is created, the credential-handling caveat, and normal human/dashboard context. It does not explain key lifecycle follow-ups, but that is not required 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?

The only parameter, label, is already fully described in the input schema ('A label to recognize the key by'), and the description adds no additional semantics about how the label behaves. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description states a specific verb and resource: it issues a durable `lasoak_` API key for the account, and adds the distinguishing detail that the raw key is returned only once. It is not a tautology, though it does not explicitly name a sibling to differentiate from.

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

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

The only usage guidance is 'Normally the human does this from the dashboard,' which implies privileged/manual operation but gives no explicit when-to-use or when-not-to-use conditions. It does not mention alternatives like exchange_api_key or refresh_token.

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, so the description doesn't need to re-establish safety. It adds real context beyond the annotations: the two-sided wallet structure (Solana walletId/address, Base baseWalletId/baseAddress) and the operational note that either address must be funded with USDC to use paid tools. It stops short of auth/rate-limit detail, but the added behavioral context is substantial.

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 create-or-return behavior, then return shape, then usage guidance, then funding note. Each sentence carries distinct information with no repetition of the name or title.

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

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

An output schema exists, yet the description still concisely maps the return fields, and it covers the practical question of what the wallet is for and how to fund it. Nothing an agent needs to invoke this correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics to disambiguate, and the description correctly does not invent any.

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 ('Create your managed agent wallet') with a precise scope qualifier: it returns the existing wallet rather than creating a duplicate. It clearly distinguishes itself from the sibling get_agent_wallet by naming it 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?

Explicitly states when NOT to use it ('Rarely needed: the dashboard provisions the wallet') and names the alternative ('get_agent_wallet creates a missing Base side'). This is exactly the when/when-not/alternatives guidance that makes selection unambiguous.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the description doesn't need to restate those. The description adds meaningful behavioral context: on-ramp issues a virtual US bank account and converts dollars to USDC in the managed wallet, off-ramp pays out to a registered bank account, and off-ramp is opened automatically by another tool. It also discloses that the tool is free. This goes beyond the annotations and helps the agent understand side effects.

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 well-structured with a clear title, a short definition of each account type, and a note about when not to call it. Every sentence earns its place, and the most important distinction (on-ramp vs off-ramp) is front-loaded. The 'Free.' note is a minor extra but not wasteful.

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 description covers the core behavior, the two modes, and the automatic off-ramp path, which is enough for an agent to decide whether to call it. The output schema exists, so return values don't need to be explained. It could mention prerequisites like needing a banking profile or KYC, but the schema and sibling tools (get_kyc_status, submit_banking_application) partially cover that 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?

Schema coverage is 100%, so the schema already documents all 7 parameters. The description adds context for the two account types and mentions defaults (Solana mainnet, ACH and wire, managed agent wallet), which aligns with the schema. However, it doesn't add much beyond what the schema already says, so a baseline 3 is appropriate.

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

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

The description clearly states the tool opens a banking rail and distinguishes between on-ramp and off-ramp accounts, explaining what each does. It names the specific resource (banking account) and the verb (open), and the title reinforces this. It also differentiates from siblings by noting off-ramp accounts are opened automatically by send-bank-payment, so most agents won't need to call this for off-ramp.

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 explains when to use on-ramp vs off-ramp, and even tells agents they usually don't need to call this for off-ramp because send-bank-payment does it automatically. It also mentions the 'Free' pricing, which is a clear usage signal. This is strong guidance for an agent deciding whether to invoke this tool.

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

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

Annotations only indicate it's not read-only, not idempotent, not destructive. The description adds crucial behavioral context: it's the only step an agent cannot complete itself, it returns kycRequired and kycUrl when verification is pending, and advises to retry after the human finishes. This goes well beyond annotations and is essential for the agent to handle correctly.

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 concise and front-loaded with the purpose and key prerequisite. The only blemish is the trailing 'Free.' sentence, which appears to be a stray or unrelated note and adds no value. This prevents a perfect score.

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 tool with an output schema, the description fully covers what an agent needs: the purpose, the prerequisite, the failure mode (kycRequired), and the required human interaction. Nothing essential is missing. The output schema handles return values, so no further detail is needed.

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 zero parameters, the description has no parameter details to add. Per the rubric, the baseline is 4 for zero-parameter tools. The description appropriately focuses on preconditions and behavior instead of 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?

The description clearly states the tool creates the banking profile and explains its role as the foundation for all other banking calls. It distinguishes itself from siblings like create_banking_account (accounts vs. profile) and get_banking_profile_status (status vs. creation). The verb-resource pairing is specific 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 implies when to use it: before other banking calls, and it explicitly states the prerequisite (identity verification) and the action to take if verification is missing (hand the kycUrl to the human). However, it doesn't explicitly name alternatives or say when not to use it, such as checking if the profile already exists via get_banking_profile_status. This is a minor gap given the clear prerequisite and positioning.

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=false (write operation) and idempotentHint=false. The description adds 'Free' (a cost signal) but otherwise does not disclose potential failures, side effects, or prerequisites beyond what the schema provides. Since annotations cover the basic safety profile, this is adequate but not exceptional.

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 concise and well-structured: a title, a one-sentence definition, a key usage note pointing to the next step, and a cost indicator. No redundant information, and all sentences earn their 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 a simple create operation with two parameters and a rich schema (100% coverage) and an output schema present, the description is sufficiently complete. It covers the main purpose, the next step (addBankingDestination), and a key prerequisite (address). It doesn't explain return values but the output schema presumably does.

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 covers both parameters, and the description adds meaningful context: it explains that address is required before a bank destination can be attached, and supplying it here avoids a second call. This enhances understanding of the address parameter beyond the schema's basic description.

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

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

The description clearly states the tool creates a payout recipient (a person or company) and differentiates it from attaching bank details by referencing addBankingDestination. This distinguishes it from sibling tools like add_banking_destination and delete_banking_recipient, making the purpose 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 that bank details are attached separately via addBankingDestination, implying the correct sequence of use. However, it does not explicitly mention when not to use this tool or alternatives like update_payment_recipient, so it is slightly incomplete but still helpful.

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?

Discloses far beyond the sparse annotations (readOnlyHint=false, destructiveHint=false): the route is free with no x402 payment, the 402 response when the balance is short, the funding path (USDC-on-Base deposit address with ~minutes credit, Apple/Google Pay top-up), and the behavior that created cards are Laso-issued so no approval step applies. Rich operational detail an agent needs before invoking.

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?

Well-organized with front-loaded essentials and effective bold callouts (reusable, this route is free, if the balance is short), but verbose: roughly seven sentences for a two-parameter create. Asides like the Apple/Google Pay dashboard top-up and the 'so an agent and a human end up with the same product' framing could be trimmed without losing decision-relevant content. Structured, but not tight.

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?

Comprehensive for its complexity: an output schema exists (so return shape is covered), and the description handles error behavior (402 + funding remedy), payment cost, reusability, and follow-up reads via get-card-data. The only soft gap is that the 'approval step' for externally-created cards is referenced but never explained — minor in 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?

Schema description coverage is 100%, so the schema already documents both parameters (usd_amount as dollars-not-cents with $1 minimum; reusable defaulting true). The description adds narrative on the reusable semantics ('stays open across charges until its limit is spent', 'closes after its first approved charge') but this merely restates the schema meaning — no new syntax or format detail. Baseline 3 applies since the schema carries the load.

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 ('Creates a reloadable card funded from the account holder's balance') and grounds it in a concrete scenario — 'the same card the holder creates in the Laso dashboard.' It marks this as the free, balance-funded creation route, which distinguishes it from card siblings like order_card, fund_card_balance, and push_to_card without needing their schemas opened.

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 strong context for when to use it: it's free (no x402), it mirrors the dashboard product, and it is the route for a Laso-issued card whose data comes back directly ('the approval step applies only to cards the holder created in a different app'). It names companion follow-ups (get-card-deposit-address, get-card-data) but never crisply names a sibling alternative and the trade-off for choosing it over order_card.

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

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

Adds substantial context beyond the annotations: single-use semantics (consistent with idempotentHint=false), expiry at expires_at, client-side encryption where Laso never sees the card number, and zero prerequisite setup. These are non-obvious behavioral traits an agent cannot infer from the annotation block.

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 purpose, then bold callouts for the critical agent action and the polling loop, then prerequisites. Well ordered and mostly every sentence earns its place, though the aside comparing the page to identity verification is slightly more color than instruction.

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

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

An output schema exists, so return-value detail is delegated appropriately; the description still calls out url and expires_at to tie the polling instruction to a field. For a zero-parameter tool it covers the full agent workflow: how to deliver the link, what the holder does, how to detect completion, and what happens if the link lapses.

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 is empty with zero parameters, so the baseline is 4. The description correctly implies no inputs are needed and instead surfaces the relevant return fields (url, expires_at), but there is no parameter semantics to add meaning to.

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 — minting a single-use link that lets a holder save their own card — and elaborates on exactly what the link is for. An agent can distinguish it from get_saved_cards (listing existing cards) and buy_with_saved_card (spending) without opening any schema.

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

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

Gives explicit operational guidance: send the url to the human rather than opening it, poll GET /get-saved-cards until the card appears, and re-mint if the link expires. It also states the route is free and needs no identity verification or prior setup. It stops short of explicitly contrasting this link flow against sibling link generators like get_auth_link or get_kyc_link, so it doesn't reach the full when/when-not/alternatives bar.

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

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

The description adds valuable behavior beyond the annotations: deletion only forgets the name mapping, has no effect on past transfers, and cannot target another account's book. The name-is-not-an-instruction warning also prevents misuse. This is consistent with destructiveHint=true and idempotentHint=true.

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 action and scope are front-loaded, but the description includes off-topic material — 'Free.' and the extended agentWalletTransfer name-vs-address warning — that is not needed to invoke a delete. A tighter version would keep the own-book scope and no-past-transfer effect.

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-parameter delete tool with an output schema and annotations covering destructiveness and idempotence, the description covers scope, effect on history, and account limitations. 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?

The schema already documents the single address parameter with 100% coverage, so the baseline is 3. The description adds context that no user parameter is needed, but it does not detail address format or requiredness.

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 gives a specific action and object ('Remove a saved recipient'), and the rest ties it clearly to the address book ('the authenticated account's own book') rather than banking or payment recipients. This clearly separates it from sibling delete 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?

It identifies the target context — the human-managed address book — and explicitly notes it operates only on the authenticated account's own book with no user parameter. It doesn't name alternative tools or exclusion cases, 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?

The description adds significant behavioral context beyond the annotations: it discloses cascade deletion (destinations and off-ramp accounts), irreversibility, and that the operation is free. Annotations already flag destructiveHint=true, but the description enriches this with specifics that matter for agent decision-making, and it does not contradict any annotation.

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 exceptionally concise—two sentences plus a short paragraph—yet it front-loads the core action ('Delete a recipient') and packs in essential behavioral details (cascade, irreversibility, cost) without any fluff. 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?

For a low-complexity delete tool with one parameter and an output schema, the description covers the key behavioral aspects an agent needs: what gets deleted, reversibility, and cost. It does not mention prerequisites like authentication, but that is implicit for API tools and not a significant gap here.

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 provides 100% coverage for the single parameter (recipientId) with a clear description. The tool description adds no additional parameter-level meaning, so it stays at the baseline of 3 where the schema carries the semantic load.

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?

Clearly states the verb 'Delete' and the resource 'recipient', and goes further to specify the scope: it deletes the recipient, its destinations, and any off-ramp account that paid out to it. This distinguishes it from sibling delete tools like delete_payment_recipient and delete_address_book_entry, which target different resource types.

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—use it to delete a banking recipient—but it does not explicitly mention alternatives or provide when-not guidance. While the sibling list includes similar delete tools, no exclusion criteria are given, so an agent must infer the correct choice based on the resource type.

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

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

Beyond the destructiveHint annotation, the description adds meaningful behavior: the action is not reversible through the API, payment history is kept, only the saved entry stops being offered, and parameters may go in body or query string. No contradiction with 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 well organized and efficient: it states the action, the irreversible consequence, the preferred alternative, and the transport option. Slight redundancy between the opening title and first sentence, but 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?

For a two-parameter deletion tool with an output schema, the description covers all essential operational facts: irreversibility, history preservation, alternative archiving behavior, consent caution, and body/query flexibility. 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 100%, so the baseline is 3. The description adds genuinely useful transport semantics by stating that `platform` and `recipient_id` may be sent in the JSON body or query string, and clarifies that `recipient_id` is the opaque id from `GET /payment-recipients`, not the phone number or email.

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 and resource: 'Removes a saved Venmo or PayPal recipient.' It clearly distinguishes this from sibling tools like delete_banking_recipient by naming the payment recipient scope and noting that payment history is preserved.

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 tells the agent when to prefer an alternative: archive via `POST /payment-recipients` with `archived: true` when the owner may want the recipient back. It also instructs to confirm before removing someone the owner did not ask to remove, providing clear selection 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 indicate destructiveHint=true and idempotentHint=true, so the description correctly aligns. It adds valuable context: that other notification channels continue, and the account owner is notified. No contradiction.

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 concise and well-structured: a clear title line, then a brief explanation of scope and side effects. Every sentence adds value, and the key point (only webhook stops) is front-loaded.

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 is simple with no parameters and an output schema exists (not shown but indicated). The description covers the main behavioral implications: removal scope and notification to owner. It could mention the return value or idempotency implications, but overall it's complete 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?

There are zero parameters, so schema coverage is trivially 100%. The description doesn't need to explain params; it correctly focuses on behavior. This is a baseline of 4 for parameter-free tools.

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 'delete' and resource 'webhook', and specifies it removes the calling wallet's webhook registration. It distinguishes itself from sibling tools like register_webhook and get_webhook by focusing on removal.

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 it: to remove the webhook for the calling wallet. However, it does not explicitly state when NOT to use it or mention alternatives, but the distinction from get/register webhook is implicit.

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

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

Adds substantial context beyond the annotations: what is preserved (card and balance stay with the issuer), what breaks (reloadable card routes and POST /buy-with-saved-card), that the operation is repeat-safe with a stable response, and the resulting status (not_started via get-card-issuer-status). This also explains why destructiveHint=false is accurate — only the Laso link is removed.

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 and its effect, then structured into named blocks for consequences and repeat behavior. Slightly long with the bolded headers and the 'This route is free' coda, but nearly every sentence carries actionable information.

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

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

With an output schema present and zero parameters, the remaining burden is behavioral and recovery context, all of which is covered: side effects, failure modes, recovery route, and post-call status.

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; the schema is trivially complete. Baseline 4 applies for a no-argument tool.

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

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

States a specific verb+resource ('Unlink the card issuer', 'Removes the link between this Laso account and the card issuer') and immediately clarifies it is the dashboard disconnect action. This clearly distinguishes it from siblings like start_card_issuer_link, verify_card_issuer_link, and get_card_issuer_status.

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

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

Explicitly names when to use it ('the same as the disconnect button in the dashboard'), adds a caution ('Confirm with the account holder before calling this'), and names the alternative recovery path (POST /start-card-issuer-link with a fresh code only the holder can receive). An agent needs no inference 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?

Annotations declare `readOnlyHint: false` and `destructiveHint: false`, but the description adds important context: it is a session-exchange that produces short-lived credentials (one hour), returns an `auth_url` so a human can monitor activity, and is a prerequisite for authenticating other endpoints. This is more informative than the bare annotations. A minor gap is that it does not explicitly state side effects like invalidating an older session, but this is not a strong deduction given the annotations are already present.

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 compact, front-loads the core exchange mechanism, states the token duration, the auth_url purpose, prerequisites, and fallback path, all in three short paragraphs. No unnecessary detail; the format 'Free.' is an oddity but does not hurt clarity. The wording is direct and every sentence adds value.

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 description covers the essential context: what is exchanged, what the tokens do, how long they last, the human-facing `auth_url`, and the fallback if no key exists. The output schema is present, so return values don't need to be elaborated. A slight deduction: the description does not clarify behavior on invalid or expired keys, but given the presence of a clear prerequisite and output schema, this is not a major shortfall.

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 and a single required `api_key` parameter, the schema fully explains the parameter. The description enriches it by clarifying the expected format (`lasoak_`) and that the key is durable and must be created by a human if absent. That is valuable additional semantics beyond the bare schema, though the schema already uses the same `lasoak_` example.

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 exchanges a durable `lasoak_` API key for a short-lived `id_token` and `refresh_token`, and names the returned `auth_url` for human oversight. It also positions this as the first call an agent makes and that the `id_token` authenticates every other endpoint, which sharply distinguishes its purpose from other endpoints like `refresh_token` or `create_agent_api_key`.

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 says this is the first call an agent makes, that the resulting `id_token` authenticates all other endpoints, and that the only alternative to having a key is having the human create one at the dashboard URL. This tells an agent when to use this tool, that it must precede other calls, and what to do if no key is available.

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 flag a destructive, non-idempotent, open-world write, and the description adds genuinely useful traits beyond them: exact pricing with no markup, CCTP bridging from Solana/Base, the paid→bridging→delivered→credited status lifecycle, delivery timing under a minute, and explicit failure semantics ('nothing is stranded', funds credit the Laso balance). This is well beyond 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?

Front-loads the one-line purpose and uses bold section headers (Why/Price/requirement/Delivery/Follow/Recovery) so an agent can skim. It is on the long side and could trim some narrative detail, but nearly every section carries actionable information.

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

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

For a money-moving tool with an output schema already present, the description covers the remaining agent-facing gaps: prerequisites, payment routing across two chains, timing, status tracking endpoints, and failure recovery. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and already documents the amount bounds, so the baseline is 3; the description adds meaningful semantics the schema does not — the x402 price equals the amount, the exact amount is credited, and Laso absorbs the bridge cost. That additional pricing meaning 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?

States a precise verb+resource — loading the account holder's reloadable card balance at the card issuer — and immediately scopes it against siblings by naming create_reloadable_card as the follow-up and push/create-card tools as distinct steps. An agent can tell this apart from other funding tools without opening a schema.

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

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

Gives strong context: a linked card issuer account is required, the agent wallet must exist and be funded first (get_agent_wallet), this should be followed by create_reloadable_card, and failures can be retried or recovered with withdraw. It lacks an explicit 'when-not to use this vs. a sibling' exclusion, which keeps it just 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?

Goes well beyond the annotations: free, exact `amount` debited, delivery to the deposit address usually within a minute, automatic return of funds if delivery fails, and the polling path (`top_up_id` plus list-card-transactions / get-card-deposit-address) to confirm crediting. This is rich operational context for a non-idempotent mutation that annotations alone would 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?

Bold section headers (Free, Tracking, Amount) and the funding-source caveat is front-loaded, so it is easy to scan. It does slightly restate the min/max already present in the schema, a small redundancy, but the remaining sentences each carry new 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?

With an output schema present, the description does not need to enumerate return fields, yet it still explains the key `top_up_id` and the follow-up sequence needed to finish the flow. Prerequisite, cost, failure behavior, and amount constraint are all covered for a one-parameter money-movement 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% and already documents the $5–$10,000 bounds, so the baseline would be 3. The description adds a constraint not expressible in the schema — the amount cannot exceed the account balance — which genuinely improves the agent's ability to pick a valid value.

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

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

States a specific verb (top up), a specific resource (reloadable card), and a specific funding source (the account balance), which cleanly separates it from the sibling fund_card_balance/push_to_card tools. The added note that GET /fund-card-balance takes a new payment while this spends already-held money makes the distinction 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?

Explicitly names the alternative (fund_card_balance takes a new payment) and the condition that selects this tool instead (money the account already holds, e.g. an unfulfillable paid request). It also states the prerequisite (a linked card issuer account via POST /start-card-issuer-link).

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), yet the description adds substantial business-logic context beyond them: the ledger-vs-on-chain distinction, the USDC flow that makes a paid request appear as a deposit then a debit, and the expectation that `balance` can legitimately be 0 after a purchase. This is exactly the kind of non-obvious behavior an agent needs to interpret results correctly.

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 summary line followed by two paragraphs of interpretation; the opening line restates the title verbatim, which is mild waste. The remaining prose is dense but every sentence carries real semantics, so length is largely justified by the two-balance model.

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

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

An output schema already documents the return structure, and the description goes further by explaining what the returned numbers mean and how they move. For a zero-parameter read tool with full annotation coverage, nothing an agent needs to call or interpret it is missing.

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

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

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

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

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

States a specific verb and resource ('Get account balance') and immediately specifies exactly what is returned: the Laso account balance, total deposits, and the managed agent wallet balance under `agent_wallet`. It also distinguishes this tool's dual-balance scope from the single-wallet view implied by the sibling `get_agent_wallet`, so an agent can differentiate without opening a schema.

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

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

Usage is only implied: the phrase 'so both are visible in one call' and the note that 'a `balance` of 0 after a purchase is expected' tell the agent when the returned values matter, but there is no explicit when-to-use, when-not-to-use, or named alternative. Adequate but leaves selection logic to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive context beyond them: the limit defaults to $1,000 and ranges $1–$50,000, only the account owner can change it (via dashboard, not this tool), and the call is free. This goes well beyond the structured safety hints.

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 return fields and the actionable rule, and every sentence carries unique information. It is longer than strictly necessary and leans on prose where a compact list would read faster, keeping it just short of a 5.

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

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

Even though an output schema exists, the description supplies the decision logic an agent needs (compare fee-inclusive totals, don't split payments, escalate to human) plus limit bounds and ownership rules. Nothing required to call and act on this tool is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description compensates by thoroughly documenting the returned values and their semantics (bounds, remaining 24h budget, current per-payment ceiling), which is the relevant 'input' an agent needs to reason about.

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 ('Read the spend limits') and immediately enumerates the exact fields returned (maxPerPaymentUsdc, maxPerDayUsdc, maxPaymentNowUsdc), so an agent knows precisely what this tool yields and how it differs from balance/payment-status 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?

Explicitly instructs to check an amount against maxPaymentNowUsdc BEFORE attempting a payment, to compare the fee-inclusive total, and what to do on exceed (stop and tell the human, do not split payments). It also names the affected operations (agentX402Pay / url endpoints), routing the agent 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?

Annotations only declare readOnly/idempotent/openWorld=false; the description adds substantial behavioral context the annotations cannot: a documented failure mode ('base_balance_usdc is null when its live chain read fails'), how balances aggregate across chains, and the deposit-then-debit accounting quirk that makes an account balance of 0 after purchase expected.

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 and the pre-call check, then moves to funding, balance semantics, and token list. The long semicolon-chained sentence about balances is dense and could be split, but nearly every clause carries information an agent would otherwise get wrong.

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

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

An output schema exists, yet the description still supplies the cross-tool accounting model (wallet balance vs. Laso account balance) and the null-on-chain-read-failure caveat that the schema alone would not make actionable. Nothing needed to call and correctly interpret this tool is missing.

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

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

Zero parameters, so the baseline is 4. The description instead spends its budget explaining output fields (balance_usdc, solana_balance_usdc, base_balance_usdc, tokens) with enough semantics that an agent can interpret results without guessing.

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 ('Get your managed agent wallet') and immediately enumerates what it returns: existence, Solana/Base funding addresses, USDC balance, funding status. It also differentiates itself from siblings by name (get_account_balance, agent_wallet_transfer, agent_wallet_swap).

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?

States explicit when-to-use ('check it before your first paid call' since 'paid tools draw from this wallet') and gives the follow-up routing: send assets via agent_wallet_transfer or convert via agent_wallet_swap. It also preempts a likely confusion by explaining when get_account_balance is the wrong place to look.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses critical behavioral details: the URL carries a short single-use login code, it passes through credential filters intact, and fetching/opening the URL would consume the human's login. This is exactly the kind of non-obvious behavior an agent needs to know.

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, then adds essential usage and security context. Every sentence earns its place: return value, use case, credential-filter behavior, and the explicit warning not to fetch the URL. No redundant or filler 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?

For a zero-parameter tool with a rich annotation set and an output schema, the description covers everything an agent needs: what the tool returns, why it is useful, how to relay the URL, and a critical behavioral warning. There are no meaningful 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?

The tool takes zero parameters, so parameter semantics are trivially satisfied. The description correctly adds no parameter-specific details because none exist; the baseline of 4 applies given the empty 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 opens with a specific verb and resource: 'Get a login link for the web dashboard.' It clearly distinguishes this from sibling tools like get_kyc_link by specifying that the link logs the human into the Laso Finance web dashboard as the authenticated user, and it states the purpose ('see what their AI agent has been doing').

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 a clear use case: 'Useful for humans who want to see what their AI agent has been doing (view cards, transactions, balances, etc.).' It does not explicitly name alternative tools or state when not to use it, but the context is unambiguous enough for an agent to select this tool appropriately.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat those. It adds value by explaining the output fields (ready, applicationStatus, outstanding questions) and the nuance that identity answers carry over from verification, which is behavioral context beyond the annotations. No contradiction exists.

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

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

The description is structured with a clear first line that summarizes the purpose, followed by a concise explanation of return values and context. It is slightly verbose with the trailing 'Free.' which adds little value, but the core message is front-loaded 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 read-only, zero-parameter tool with an output schema, the description is highly complete. It explains what the tool returns, clarifies that identity answers are inherited, and describes the nature of remaining questions. No critical information for an agent to invoke the tool 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?

The tool has zero parameters, so there is nothing to explain. Per the calibration rule, 0 parameters earns a baseline score of 4. The description does not need to add parameter details since there are none.

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 that the tool reads the banking application and returns readiness, status, and outstanding questions. It distinguishes itself from update/submit siblings by being a read operation, but it does not explicitly name any alternative tools. The verb 'Read' and the resource 'banking application' are specific 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 implies usage after verification to discover non-identity questions, but it does not explicitly state when to use this tool versus others like submit_banking_application or update_banking_application_details. It provides context about what remains to be answered, but lacks direct guidance on alternatives or exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context by specifying that the tool reports existence and application stage, and it also adds the note 'Free.' There is no contradiction with 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 appropriately short and front-loaded. The opening line repeats the title almost verbatim, and 'Free.' is a minor extra, but the overall length is well controlled and the core behavior is stated in one sentence.

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-only status tool with an output schema, the description provides sufficient context: it states what resource is being read and what aspect of its state is returned. Nothing essential for correct invocation appears to be 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?

The input schema has zero propertiesanding 100% schema description coverage, so there are no parameter semantics to explain. The description instead indicates the kind of information returned, which helps the agent interpret the output for a parameterless call.

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

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

The description identifies a specific verb ('Reads') and resource ('banking profile') and clarifies what is returned: whether the profile exists and where its application stands. It is clear and easy to distinguish from creation/submission siblings, though it does not explicitly contrast with get_banking_application or other related 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 clearly establishes the use case: call this when you need to know the current state of the banking profile. It does not explicitly name alternatives or provide exclusion guidance, but the context is unambiguous and not misleading.

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 carry readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety behavior. It adds useful context beyond those annotations: the transaction can be an on-ramp arriving or off-ramp paying out, it returns a normalized status, and it is free. No contradiction with 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 three short sentences with no filler. The key action and scope are front-loaded, and the extra details (on-ramp/off-ramp, normalized status, free) each add value without bloating the 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?

For a low-complexity single-parameter read tool with an output schema and strong safety annotations, the description is complete. It communicates what the transaction represents, the status normalization, and the cost, so an agent has enough context 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 input schema fully documents transactionId (100% coverage) with 'The transaction to read.' The description does not add additional parameter details such as expected format or how to obtain the ID, but the schema carries the necessary semantic weight. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Reads a single banking transaction') and a clear resource, explicitly narrowing the scope to one transaction as opposed to a list. The on-ramp/off-ramp clarification also disambiguates the transaction types covered, and the singular framing distinguishes it from sibling list_banking_transactions.

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 context is clear: use this to fetch one banking transaction. However, it never explicitly names alternatives such as list_banking_transactions for multiple transactions, nor does it state when not to use this tool. Usage is implied rather than spelled out.

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

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

The description adds rich behavioral context beyond the annotations. . The readOnlyHint=true and idempotentHint=true annotations are consistent with the description's read-only nature, and the description elaborates on the behavior of polling, approval gates, and data availability windows, which are not inferable from the annotations alone.

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

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

The description is long but every section is purposeful and necessary for correct operation. It is structured with clear paragraphs for each card type and edge cases. The most critical usage information (how to poll) is placed early, and the response format is not over-explained since an output schema exists. No redundant sentences.

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

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

Given the tool's complexity (three card types, approval gates, polling behavior, and a complex output schema), the description is thorough. It covers all necessary conditions for successful invocation, including edge cases like missing billing_address and approval flows. The output schema exists, so the description doesn't need to enumerate return values. It is complete for an agent to use 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 schema description coverage is 100%, so parameters are well documented in the schema. The description adds value by providing additional context on how parameters interact (e.g., card_id lookup across all types, approval_id only for certain cards), but the schema already defines their basic semantics. The baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: to get card details and status. It specifies the resource (cards), the action (get), and differentiates between single card lookup and listing by card type. It also distinguishes from siblings like order_card and order_intl_card by describing the retrieval of card data, not creation.

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 explicit guidance on when to use this tool versus alternatives, such as mentioning that reloadable cards are set up in the dashboard rather than ordered through the API. It explains the conditions for using card_id versus card_type, and how to handle different card types. It also clarifies when to use approval_id and how to poll for updates, which is critical for 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 already mark the tool as read-only, idempotent, and non-destructive, and the description adds significant behavioral context beyond that: the issuer provisions the address on first read so calling creates it, deposits typically confirm within minutes, the address is stable per holder, and it should be read fresh rather than cached. These are valuable operational details not present in 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?

Although the description is longer than typical, every paragraph earns its place: purpose, funding semantics, chain constraint, polling workflow, and caching guidance. The content is front-loaded with the main purpose and organized with bolded key points, 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?

The description covers the complete invocation context: why to call it, what it returns, the one-time provisioning side effect, the critical chain restriction, expected timing, confirmation polling, and the next step. With an output schema also present to define the return shape, nothing an agent needs to call and use this tool 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?

The tool has zero parameters and schema description coverage is trivially 100%, so there is nothing for the description to clarify about inputs. This matches the baseline for a parameterless tool; no additional parameter-level semantics are needed.

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 operation: retrieve the account holder's USDC deposit address and current balance for a reloadable card. It also articulates the tool's unique role clearly ('This is how an agent funds a reloadable card balance with crypto'), which distinguishes it from the many card and payment siblings.

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

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

It explicitly says when to use this tool: to fund a reloadable card balance with crypto. It gives a concrete workflow—poll until balance confirms, then call POST /create-reloadable-card—and provides an explicit exclusion: fund from a wallet holding USDC on Base rather than transferring from a Solana-managed wallet, with a warning that other chains are unrecoverable.

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 by disclosing the `400` error text emitted by dependent routes, the meaning of each status value, the kyc_required fallback condition with its kyc_url, and the unusual constraint that only the account holder may receive and enter the code. It also flags that the route is free.

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 one-line purpose and the status enum before the caveats, and nearly every sentence carries operational weight. The bolded account-holder code-handling rule is more relevant to the start/verify steps than to this read-only check, which is a small amount of off-target bulk.

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

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

An output schema exists, so return values need not be detailed; the description nonetheless explains the status enum and the kyc_url handoff. Combined with the annotation safety profile, an agent has everything needed to call this zero-argument check correctly and act on its 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?

The tool takes zero parameters, so the baseline is 4. There is nothing parameter-level for the description to clarify, and it correctly spends no space on parameter syntax.

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

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

States a specific verb and resource: it reports whether the account has linked the card issuer, and enumerates the exact `status` values returned. This is clearly distinguishable from the mutating siblings start_card_issuer_link and verify_card_issuer_link, which advance the same flow.

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 the context in which the check matters — it is the one-time setup prerequisite for reloadable card routes, which otherwise answer `400`. It stops short of explicitly naming when to call this versus start_card_issuer_link or verify_card_issuer_link, so the routing is inferred 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond that: the link is one-time, meant to be opened or handed to the wallet owner, and is part of a larger verification flow. No contradictions with 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 appropriately sized and well-structured, front-loading the optional nature of KYC and then explaining the flow. A minor redundancy exists in repeating that KYC is optional, but overall each section earns its place.

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

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

Given the output schema exists, the annotations cover safety/idempotency, and there are no parameters, the description is complete. It explains why the tool exists, when to use it, what it returns, and how it fits with `get-kyc-status` and `send-payment`.

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 has zero parameters and schema description coverage is 100%, so the description does not need to explain parameters. The baseline is therefore strong, and the description correctly focuses on behavior and flow rather than parameter details.

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 gets a one-time identity-verification link (`kyc_url`) for the calling wallet, with the explicit verb 'Get' and specific resource. It also differentiates itself from related endpoints like `get-kyc-status` by describing the verification flow.

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 says KYC is optional and only needed for certain features such as Venmo/PayPal payouts via `/send-payment`. It also prescribes a clear conditional flow: call `/get-kyc-status` first, and only call this if `kyc_verified` is `false`. This gives strong when-to-use and when-not-to-use 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?

The description transparently states that the endpoint reads cached status maintained by a webhook, does not start verification, and does not return a verification link. It also communicates the important behavioral nuance that a false status would not cause /send-payment to fail destructively—the USDC would land in the account balance and be recoverable. This goes well beyond the annotations, which only declare readOnly/idempotent/destructive hints.

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 somewhat long but every sentence earns its place: it explains optionality, the pre-flight use case, the failure mode, and the alternative endpoint. The opening bolded 'KYC is optional' is an effective front-loaded summary, though the paragraph could be trimmed slightly without losing key guidance.

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

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

For a zero-parameter read-only tool with an output schema available, the description fully covers what an agent needs: what the tool returns, how to act on the result, what it does not do, and how it relates to other endpoints. No important operational context 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?

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds relevant context about the returned field `kyc_verified` and its semantics, which is useful for interpreting the output, though it doesn't need to document any parameters since none exist.

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

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

The description clearly states the tool returns the calling wallet's cached KYC verification status, uses a specific verb and resource, and distinguishes this read-only status check from the related /get-kyc-link endpoint. It is not confused with any sibling tool despite many similar-looking KYC-related operations.

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 says when to use the tool (as a free pre-flight check before calling /send-payment), what to do if kyc_verified is false (do not call /send-payment; call /get-kyc-link instead), and even provides nuanced fallback context about recoverable USDC. This is exemplary usage guidance with clear alternatives and 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 establish the safe read-only, idempotent, closed-world profile, and the description adds substantially more: the cost model, the full state machine with plain-English meanings, polling cadence, the one-hour stale-in-process heuristic, and the caveat that state is absent on pre-state-tracking payouts. That is real behavioral context 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?

Front-loads purpose and cost, then the call modes, then the state reference. It is dense but every sentence carries operational information (states, polling, webhook escape hatch, exclusions) with no filler 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?

With an output schema present, the description rightly avoids restating return shapes and instead covers everything else an agent needs: invocation modes, state vocabulary, freshness handling, cost, and explicit sibling boundaries. Nothing material is missing.

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

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

Schema coverage is 100% and both params are documented, setting the baseline at 3, but the description adds the interplay the schema can only partially express: the 'call with neither' mode that lists all sent payouts, plus the newest-first ordering and the recipient_id provenance. Marginal but genuine added meaning.

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 (check payout status) scoped to Venmo and PayPal payouts sent via GET /send-payment. It explicitly disambiguates from siblings by excluding bank payouts (use listBankingTransactions) and push-to-card transfers, so an agent can distinguish it from get_withdrawal_status and the banking 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?

Enumerates the three invocation modes (payment_id, recipient_id, or neither) with the exact outcome of each, names the alternative (register a webhook via POST /register-webhook to avoid polling), and states what is out of scope. This is about as explicit as when/when-not/alternatives gets.

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

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

Annotations already cover the read-only/idempotent profile, but the description adds substantive behavior: no auth or payment header required, no charge incurred, and the exact fee computation formula including rounding and min-fee interaction. It also explains that the fee_rate reflects any live promotion, which the agent cannot infer elsewhere.

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

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

Front-loaded with the core purpose, then progressively adds formula and quote-retrieval detail. Every sentence carries information, though the third paragraph is fairly dense and could be tightened 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?

Even though an output schema exists (so return fields needn't be spelled out), the description goes further by explaining the fee formula and the authoritative per-route quote path. An agent has everything needed to call this correctly and interpret its output.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify. It correctly implies a parameterless global read.

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 the fee schedule') and immediately enumerates the returned fields: route, amount range, fee rate, minimum fee. This is clearly distinguishable from billing-related siblings like get_account_balance or get_payment_status, which report state rather than pricing.

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 context for use ('so you can budget before you have an account') and routes the agent to the 402-challenge path when an exact per-request total is needed. It does not explicitly name or exclude any sibling tools, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety bar is pre-met; the description adds real value by stating what the record exposes (turn state, last checkout attempt, per-order charge status) and its reconciliation role. No auth, rate-limit, or pagination notes, but those are minor for a read-only call.

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, front-loaded with the verb and resource and then the use case; little waste. The long parenthetical of failure states is dense but each element is load-bearing, so it earns its space.

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

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

An output schema exists, so return values need not be explained, and the description covers inputs, purpose, and the operational trigger well. The one real gap is the absence of any differentiation from get_purchase_turn, which an agent choosing between the two would want.

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

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

Only one parameter with 100% schema description coverage, so the schema already documents `conversation_id` as the id from a purchase turn. The description adds no format, sourcing, or edge-case detail beyond that, making the baseline 3 correct.

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 (read a purchase conversation's orders) and enumerates the payload: turn running state, last checkout attempt, and each order's charge status. It is clear what the tool returns, but it never names or distinguishes itself from the sibling get_purchase_turn, which an agent must disambiguate against.

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 when-to-use guidance: to track an order, and to settle an unclear outcome before repeating a confirm, with the exact triggers (`in_progress`, `charge_status: unknown`, `failed` turn). It lacks any when-not or explicit alternative routing, so it stops short of a 5.

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

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

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, not open-world), yet the description still adds real behavior: the response matches the POST shape, the polling cadence, and the important caveat that a failed confirm may still have placed the order. It does not cover rate limits or what states other than running/done/failed look like, so it stops just short of exhaustive.

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 paragraphs, front-loaded with the core read, then the polling rule, then the failure warning. No sentence is redundant and each advances correct usage.

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

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

An output schema exists, so return values need not be enumerated — and the description's note that the response mirrors the POST is a useful pointer rather than padding. For a one-parameter polling read with full annotation coverage, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the single parameter already documents its provenance in the schema description. The prose adds no syntax, format, or constraint 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?

States a specific verb ('Read') and resource ('a purchase turn') scoped precisely to turns from POST /buy-with-saved-card that returned state: running. It also implicitly distinguishes itself from buy_with_saved_card (the creator) and names get_purchase_conversation as a related read, so an agent can place it among siblings 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?

Gives an explicit operational loop: poll every few seconds until state is done or failed. It also names the alternative action and its precondition — read GET /get-purchase-conversation before resending a failed confirm. When-to-use, when-to-stop, and the alternative are all spelled out.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world, but the description adds meaningfully beyond them: no card is issued or prefunded, no identity verification is required, purchases are approved by the holder on their device, and the payload never contains a card number. That last point is critical safety context for an agent handling payment 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?

Front-loaded with the core action, then semantics, then response shape and next step — a logical order with no filler sentences. It runs three short paragraphs where two would do, and the bolded 'Nothing is issued or prefunded' clause is slightly promotional, but every line 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 zero-parameter, annotated, output-schema-bearing read tool, the description covers the remaining unknowns: what a saved card actually is, that no verification or issuance occurs, that numbers are absent from the response, how to read an empty list, and what to do next. Nothing an agent needs to call and interpret it is missing.

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

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

The tool takes zero parameters, so there is no parameter surface for the description to clarify; baseline 4 applies. Nothing in the text misrepresents or invents inputs.

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

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

Specific verb+resource ('List the holder's saved cards') and immediately disambiguates the resource from sibling concepts: these are cards the holder already owns, typed once at the issuer and passkey-locked, not newly issued cards. This separates it cleanly from order_card, create_reloadable_card, and get_card_data.

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 downstream routing for the empty-result case ('call POST /create-saved-card-link and send the returned url to your human'), which is genuine when-to-act guidance. It does not, however, state when to prefer this over other read tools such as get_card_data or list_card_transactions, so the routing is one-directional rather than a full use/avoid statement.

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 this as read-only, idempotent, and non-destructive, but the description adds substantial behavioral detail: it blocks for ~60 seconds, returns 204 on incomplete signup, treats 401/410 as terminal with 'terminal': true, and delivers api_key exactly once. This goes far beyond the annotations and gives the agent a precise mental model.

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 earns its place: it front-loads the core purpose, then covers retry behavior, terminal statuses, and the one-time api_key delivery in a structured, bolded format. No filler or repetition beyond the title echo.

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 long-polling tool with an output schema, the description covers all essential context: blocking behavior, status code semantics, retry policy, terminality, api_key delivery, and downstream implications like not needing announceAgentConnection. 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 100%, with both claim_token and claim_code described as coming from POST /signup. The description does not add extra parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Wait for your human to finish the signup' and then explains the long-polling behavior. It clearly distinguishes itself from siblings like start_signup and announce_connection by describing exactly what this tool does and what it does not do.

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 when-to-use and when-not-to-use guidance: 'Retry on 204 and nothing else', 'Every other status is final', and 'announceAgentConnection is not needed on this path'. It also warns against a naive 'retry until 200' loop, which is actionable and prevents misuse.

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

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

Annotations already declare readOnlyHint/idempotentHint/no-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: 'Free, no auth or payment header,' plus which products are U.S.-only vs global and where `countries: null` occurs, which an agent needs to interpret results.

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 purpose and return format, then appends dense product-specific caveats. It is on the long side for a zero-param tool and some sentences verge on tangential endpoint routing, but every sentence carries distinct, decision-relevant information.

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

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

With no parameters, an output schema present, and full annotations, the definition needs little more; the description still supplies the domain semantics (per-product scope, U.S.-only vs global, null list) that make the returned codes interpretable. 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?

This tool takes zero parameters, so the baseline is 4. The `country` reference in the description pertains to a different endpoint rather than this tool's inputs, but there are no parameters to clarify.

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 ('Get supported countries') and then immediately clarifies what that means concretely: 'Returns where each product can be used or sent, as ISO 3166-1 alpha-2 country codes.' No sibling does the same thing, so the agent can distinguish it without opening the schema.

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

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

Gives clear context for the various product-specific country lists and routes the agent to the right alternative endpoints (e.g. `GET /order-gift-card` with a listed code, `GET /search-merchants` for the international card). It doesn't phrase explicit 'use this vs X' when/when-not rules, but the routing guidance covers the relevant 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?

Annotations already cover read-only, idempotent, non-destructive behavior, but the description goes further: it declares the endpoint is free, needs no auth or payment header, explains aggressive client-side caching, and documents the response header and freshness beacon. This is rich context 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 description is front-loaded: purpose first, then return contents, usage, and supporting headers. It is longer than strictly necessary for a zero-param tool, and the final paragraph about RFC 9727 API catalog and Link header is tangential, but no sentence is confusing or out of 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?

With an output schema present, the description need not enumerate return values, yet it still explains api_version, versioning policy, and docs_version clearly. Combined with explicit auth and cache-detection guidance, an agent has everything needed to call this 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?

The tool takes zero parameters, so the schema is empty and schema coverage is 100%. Per the rubric, zero parameters sets a baseline of 4; there is nothing to clarify or compensate for.

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 ('Get the current docs version') and details exactly what version data is returned. It never names a sibling or differentiates itself from tools like search_docs, so it stops short of the top score.

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 states when to call it ('use this to detect a stale cache') and gives the triggering condition (docs_version differs from last seen). It also points to the X-Laso-Docs-Version header as an equivalent mechanism, though it never states when not to call it or how it relates to the sibling search_docs.

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 readOnly/idempotent/destructive annotations, the description adds meaningful behavior: the signing secret is never returned, it is only shown once at registration, and registrations auto-disable after 50 consecutive delivery failures. This gives the agent useful operational context that annotations alone do 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 compact and front-loaded with the tool's purpose. The follow-up sentences each add necessary operational details, and there is no filler or redundant schema 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?

With no parameters, an output schema available, and annotations covering safety, the description provides everything needed to call the tool correctly. It also covers the important edge case of auto-disablement and the path to recovery.

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 zero parameters, so there are no parameter semantics to document. The description still adds relevant context by clarifying that the operation applies to the calling wallet's webhook, which is the only implicit input.

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 and resource: 'Get webhook registration & delivery health.' It also scopes the operation to 'the calling wallet's' webhook, making the read-only intent unambiguous and clearly distinguishing it from sibling tools like register_webhook and delete_webhook.

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 routes the agent away from this tool when the signing secret is needed or when rotation is desired, pointing to POST /register-webhook instead. It also explains that a disabled registration must be re-registered to re-enable, giving concrete when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds useful contextual behavior: results are scoped to the authenticated user and the single-vs-all behavior depends on the withdrawal_id parameter. No contradictions with 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 compact and front-loaded, stating the core purpose in the first line and then explaining the conditional behavior in two short sentences. Every sentence earns its place without unnecessary elaboration.

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 simple read-only status lookup with one optional parameter and an output schema, the description covers all essential behavior: scope, conditional branching, and result type. An agent has enough information 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 description coverage is 100%, and the description's parameter guidance mirrors the schema: omitting withdrawal_id returns all withdrawals, providing it returns a single withdrawal. This adds no new semantic detail beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly identifies the operation: getting withdrawal statuses for the authenticated user. It also contrasts the two behavioral modes (single withdrawal when an ID is provided, all withdrawals when omitted), which makes the tool's purpose unambiguous among the many status-related 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?

The description provides clear context on how to use the optional withdrawal_id parameter and what happens when it is omitted. It does not explicitly name alternative tools, but the resource (withdrawals) and scope (authenticated user) make the intended use clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description does not contradict them. It adds useful behavioral context: the operation is free, scoped to the authenticated account's own book, has no user parameter, and names are labels rather than instructions for sending money. This goes beyond the structured 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 somewhat longer than needed and repeats the title phrase 'List saved recipients,' but each paragraph earns its place by adding use-case, cost, scope, and a safety warning. The core function is stated up front and the important warning about name resolution is clearly emphasized.

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-only list operation with rich annotations and an output schema, the description provides everything an agent needs to invoke it correctly: purpose, usage scenario, account scope, cost, and a safety caveat. 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?

The input schema has zero properties, so there is no parameter to document. The description explicitly confirms this by saying there is no user parameter to pass, which is helpful for ruling out a common mistake. This meets the baseline for a zero-parameter tool.

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

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

The description opens with 'List saved recipients' and explains that these are recipient names a human manages on their dashboard and can be resolved to an address. This clearly identifies a specific verb and resource. It does not explicitly contrast itself with sibling recipient-list tools like list_banking_recipients or list_payment_recipients, 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?

The description gives a concrete use case: when a request names a saved recipient such as 'the coffee vendor', this tool resolves the name to an address rather than asking the human. It also states a scope constraint—it operates only on the authenticated account's own book. It does not name exclusions or alternatives, but the context is clear.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description nonetheless adds real behavioral context: revoked keys are omitted, raw keys are never returned because only hashes are stored, and OAuth-approved connections surface here labelled with the client name. These are traits not derivable from 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?

Front-loaded with the purpose and then the field list; every clause carries information. The opening "List API keys" lightly duplicates the annotation title, a minor redundancy that costs a point.

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

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

An output schema exists, so return values need not be explained, yet the description still previews the returned fields and the ordering. For a no-argument list tool this is 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 the baseline is 4. The description correctly adds no parameter detail because there is nothing to parameterize.

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 ("List ... API keys") and pins down scope with concrete detail: live `lasoak_` keys, newest first, revoked keys excluded. An agent can immediately tell this apart from create_agent_api_key, revoke_agent_api_key, and exchange_api_key without opening any schema.

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

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

Usage is implied by the operation itself (a read-only listing), and the trailing "Free." note signals there is no cost to calling it. However, there is no explicit when-to-use vs. when-not guidance and no reference to the sibling keys tools (create/revoke/exchange).

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, idempotentHint=true, and destructiveHint=falseking, so the safety profile is covered. The description adds useful behavioral context by disclosing the deliberate omission of the off-ramp deposit address and explaining why, which helps set expectations about the returned 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 short and front-loaded with the core purpose, followed by the valuable off-ramp caveat. Minor redundancy: the opening phrase 'List banking accounts' repeats the tool name, and the trailing 'Free.' is ambiguous and adds little value.

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?

This is a simple zero-parameter read-only tool with an output schema available. The description captures the essential semantic nuance (on-ramp vs off-ramp), explicitly flags the one notable limitation, and leaves nothing an agent needs 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 has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to compensate for. Per the baseline for zero-parameter tools, this dimension is well satisfied.

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 ('Lists') and defines the resource as 'the account's banking rails and their details.' It goes beyond the tool name by explaining on-ramp vs off-ramp semanticsholics, which clearly separates it from siblings like list_banking_transactions and list_banking_recipients.

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 clear use context: an on-ramp needs routing and account numbers to give to a payer. It also explicitly tells the agent the off-ramp deposit address is deliberately withheld, so it knows this tool is not for payout plumbing. It does not explicitly name alternative tools or state when-not-to-use, so it stops short of a 5.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds that account numbers are masked and that it is a free paywalled route, which is valuable beyond the annotations. No contradiction found.

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 short and front-loaded with the core purpose. The additional details about masking and the free route are useful and not redundant. Every sentence serves a purpose.

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 simple list tool with no parameters and an output schema, the description covers all needed aspects: what it lists, the masking behavior, the source of destination_id, and even the route. 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?

With zero parameters, the description doesn't need to explain any. The schema is trivially covered, and the description doesn't attempt to document parameters. Baseline for 0 params is 4, which is appropriate.

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

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

The description clearly states it lists payout recipients and destinations, and explicitly mentions account numbers are masked. It distinguishes itself from other list tools like list_payment_recipients by specifying the banking domain and the destination_id source.

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 this is where destination_id values come from, giving clear context for when to use it (to obtain destination IDs). It doesn't explicitly mention when not to use it or compare to alternatives, but the context is strong enough for most agents.

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