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?

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 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?

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 already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that it returns 'total deposits' in addition to balance, which is useful context beyond annotations. However, it doesn't disclose any other behavioral traits like authentication requirements or rate limits, which is acceptable given the simple read-only nature.

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

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

The description is extremely concise, using two short sentences. The primary action and return details are front-loaded, with no wasted words.

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

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

The tool has an output schema (not shown) and zero parameters, so the description only needs to convey the tool's purpose and scope. It states it's for the 'authenticated user' and covers the key outputs. It might have been clearer to specify 'banking account balance' to avoid ambiguity with wallet or card balances, but this is a minor gap given the sibling 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?

There are no parameters, so the baseline is 4. The description doesn't need to elaborate on parameter semantics since none exist, and the schema coverage is trivially 100%.

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

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

The description clearly states the tool's purpose: 'Get account balance' and specifies it returns 'current account balance and total deposits for the authenticated user.' This is specific and distinguishes it from other get_* tools that target different resources like wallets or cards, though it doesn't explicitly name alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_agent_wallet or get_card_deposit_address. It simply states what it does without context on selection criteria or exclusions, leaving the agent to infer usage.

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

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

Annotations already mark it read-only and idempotent, but the description adds substantial behavioral value: the default and allowed range, universal applicability to all payment routes, fee-inclusive comparison, owner-only modification, and the explicit 'do not split' guidance. This is exactly the kind of context an agent needs beyond the annotation 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 more verbose than the shortest possible definition, but nearly every sentence adds operational value: bounds, applicability, fee handling, access restrictions, and the no-split rule. Slight redundancy exists with the title in the first sentence and the standalone 'Free.', so it earns a 4 rather than 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?

Backed by an output schema and no parameters, the description fully covers what the agent needs to know: return values, numeric bounds, payment scope, pre-payment checks, ownership, and failure behavior. Nothing necessary for correct invocation or interpretation is left to inference.

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 and 100% schema description coverage, there is nothing for the description to add about inputs. The baseline of 4 applies; the description correctly avoids inventing parameter details and instead focuses on explaining the read-only output and decision context.

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 the specific verb-resource pair 'Read the per-payment spend limit' and then explains exactly what is returned: maxPerPaymentUsdc plus min/max/default bounds. This clearly distinguishes it from wallet-balance or account-status siblings in the tool list.

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

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

The description gives explicit operational guidance: check this limit before attempting a payment, compare the fee-inclusive total, and never split an over-limit payment. It also states who can change the limit, making it clear this is a pre-payment consultation tool rather than something that can alter limits.

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?

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 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 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.

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 behavioral context: it lists both incoming and outgoing money and returns normalized statuses and amounts. It does not go into pagination, ordering, or how the account is determined, but with annotations and an output schema present, this is adequate.

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 main purpose stated immediately. The opening 'List transactions' is slightly redundant with the body, and 'Free.' is terse but informative. Overall, every sentence contributes to understanding the tool's scope and behavior.

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

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

For a no-parameter, read-only list operation with annotations and an output schema, the description is complete enough. It explains what kind of transactions are included and what normalization to expect. It does not mention alternatives or limitations, but those are not required for this simple 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?

The tool has zero parameters, so the baseline is 4. There is no parameter semantics for the description to add, and the schema correctly reflects an empty input. The description focuses on the output scope instead, 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 states a specific verb and resource: it lists banking transactions for the account, including both incoming and outgoing movements. It also clarifies scope by mentioning on-ramp and off-ramp flows, which distinguishes it from card-transaction or single-transaction siblings like list_card_transactions and get_banking_transaction.

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

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

The description gives clear context about what the tool does and what it covers: banking transactions for the account, with normalized statuses and amounts. It does not explicitly name alternatives or state when not to use it, but the context is specific enough for an agent to know this is the right tool for listing account-level banking transactions.

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 false. The description adds that results are newest first, include specified fields, and returns an empty list with a setup note when no issuer account is linked. No contradiction; the added detail complements 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?

Five tight sentences: main action, return shape, parameter usage, scope boundary, and empty-edge-case. No filler; the most important scoping and routing constraints are prominently positioned.

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, return fields need no further explanation. The description covers card scoping, filtering, pagination, scope boundary, and the no-issuer edge case, so an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100% and the description largely restates the schema in natural language. It adds minimal new meaning beyond the schema's existing parameter descriptions.

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

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

States a specific verb and resource: list reloadable card transactions. It distinguishes itself from the non-reloadable product history route by explicitly naming /get-card-data as the alternative. This is clear and actionable.

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 when to pass card_id vs omit, how to use status and limit, and clarifies this route only covers reloadable cards. It names the sibling tool /get-card-data for non-reloadable products and describes the empty-list scenario when no issuer account is linked.

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 annotations, the description exposes a subtle behavioral trap: two different id types exist, and using the wrong one silently fails to send to the intended person. It also explains how total_sent and last_sent_timestamp help disambiguate similar entries, adding genuine value not present in annotations or schema.

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, then adds high-value operational warnings and disambiguation guidance. Every sentence contributes meaningful information, and the length is justified by the need to prevent a real misuse of recipient identifiers.

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 to describe return values, the description covers everything else needed for a safe and correct call: the supported platforms, the free nature, the identifier distinction, and how to handle ambiguous names. No critical 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 input schema already documents both parameters with 100% coverage, including enums for platform and a default for include_archived. The description adds context about Venmo/PayPal and the overall purpose, but it does not significantly deepen the meaning of the two input parameters beyond what the schema provides, so the baseline score 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 precise verb-resource pair: 'List saved Venmo and PayPal recipients', and then clarifies the exact scope ('recipients this account has paid before'). It also clearly distinguishes this tool from related operations like GET /send-payment and recipient management endpoints, so an agent can select it accurately.

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 scenario: resolving a spoken name into a handle before calling GET /send-payment. It explicitly contrasts the free listing action with the paid payout and warns against passing the saved-entry id to GET /send-payment, which is an effective when-not-to behavior.

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

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

Goes well beyond the annotations by disclosing that USDC is paid automatically from the managed wallet, that the card starts in a pending status, that getCardData should be polled at callableBaseUrl, and that the card is US-only and non-transferable. This gives the agent a clear picture of side effects and follow-up behavior.

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

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

The description is well organized with bolded sections and front-loaded key information. It is slightly verbose and repeats 'Order a USA prepaid card' near the beginning, but every major paragraph adds relevant operational or routing context.

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

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

Covers the payment side effect, response format options, pending-to-ready status behavior, polling instructions, geographic restrictions, and wallet prerequisites. With an output schema presentanding return-value documentation, nothing essential is missing for an agent to invoke and follow up 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 already fully documents amount and format, but the description adds operational meaning: payment is in USDC via x402, and the format parameter maps to agent-vs-browser flows. It clarifies that amount is expressed in USD but funded in USDC, which is not fully captured in the schema alone.

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

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

States a specific verb and resource: 'Order a USA prepaid card' from Laso Finance, with a clear amount range. It is explicitly distinguished from international card ordering, so an agent can separate it from order_intl_card and other card-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?

Provides explicit routing guidance: use order_intl_card for non-U.S. merchants or non-USD currencies, and notes the endpoint is for the caller's own use. It also gives a prerequisite to ensure the agent wallet exists and is funded via get_agent_wallet. It does not compare against create_reloadable_card or order_gift_card, so it stops short of covering all sibling alternatives.

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

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

The description goes well beyond the annotations: it discloses that this is a paid route, that funds are automatically deducted from the managed agent wallet, that the wallet must exist and be funded, and that pricing involves currency conversion plus fees. It also clarifies the USD min/max applies to converted value, which is critical behavioral context for a destructive purchase operation.

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

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

The description is longer than average but every section earns its place: workflow, pricing, limits, return values, and wallet funding. The bold labels and short paragraphs aid scanning. Minor wording like 'PAID ROUTE (5-9432 USD)' is slightly awkward but does not undermine clarity.

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

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

For a paid, destructive purchase tool, the description covers the full calling context: prerequisite catalog lookup, currency conversion, fee structure, min/max validation, return contents, and wallet funding requirement. The output schema exists, so return details need not be exhaustively repeated. No essential information 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 value beyond the schema with a concrete example ('A 100 SAR card costs roughly $28 USDC, not $100') and explicitly states the fee cap (up to 4.8%), which the schema does not mention. This helps the agent reason about amount 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 action ('Order a gift card'), identifies the payment mechanism (x402 USDC), and clearly distinguishes the workflow from siblings like search_gift_cards by specifying the prerequisite catalog lookup. It leaves no ambiguity about what this tool does.

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 instructs the agent to first browse the catalog via GET /search-gift-cards to obtain laso_server_id, then call this endpoint. It provides clear context for when to use the tool, though it does not explicitly contrast it with alternatives like order_card or order_intl_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?

Annotations declare the safety profile (destructiveHint=true, non-idempotent, openWorld), and the description adds substantial context beyond them: the order is queued and admin-fulfilled, the x402 charge covers amount + 3.8% fee (or promotional rate), the 402 challenge carries the exact total, and placing the order accepts three legal agreements on the account holder's behalf. This is rich behavioral disclosure that goes well past the 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?

Front-loaded with the one-line purpose, then layered detail in digestible paragraphs. Slightly redundant, since the fee and min/max rules are stated twice (description and schema), but every paragraph carries information an agent needs before committing a payment.

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 payment mechanics, prerequisites, queuing, terms acceptance, and cancellation. The only minor gap is expected fulfillment timing, which an agent might want before deciding to order.

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 min/max and whole-dollar constraints are already documented in the schema. The description largely restates them, but adds the useful clarification that the $1,000 maximum is the on-card loaded amount and is independent of the fee rate, which sharpens interpretation of the single parameter.

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 ('Order an international prepaid card') and immediately narrows to 'international non-reloadable prepaid card (USD)', which distinguishes it from siblings like order_card, create_reloadable_card, and order_gift_card. An agent can route to this 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?

Explicitly gives prerequisites ('Make sure the wallet exists and is funded first (get_agent_wallet)'), the cancellation alternative ('use POST /cancel-intl-order'), and the follow-up path to retrieve results ('GET /get-card-data'). It names the conditions that select each alternative, which is exactly the routing guidance the dimension asks for.

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, so the description's mention of sending money is consistent. It adds valuable behavior beyond annotations: the fee (4.8% with minimum), the requirement to visit a redemption_url, the manual entry of card details, and the automatic payment from the agent wallet. This gives the agent a full picture of side effects and prerequisites.

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 moderately long but well-structured: it leads with the core action, then covers supported currencies, fee, and the paid route. Each section adds necessary information, and the formatting (bold headers) aids scanning. It could be trimmed slightly, but nothing is redundant.

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

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

For a money-transfer tool with multiple prerequisites and a manual step, the description covers all essential aspects: the transfer mechanism, currency restrictions, fee structure, the redemption_url requirement, the need for a funded agent wallet, and the manual entry of card details. The presence of an output schema means return values need not be described, so this is complete for an agent to execute 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 already describes both parameters thoroughly (amount and currency), with coverage at 100%. The description reinforces this and adds nuance: the amount is a 'face value' that gets converted to USDC with a fee, and the currency restricts card eligibility. This exceeds the schema's detail, particularly around the fee calculation and currency-specific limits.

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

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

The description opens with a clear action verb and resource ('Send money to a debit card') and specifies the currencies and the payment mechanism (USDC). It distinguishes itself from other money-movement tools like send_bank_payment or withdraw by focusing on debit card transfers, 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 strong contextual guidance: it explains the manual redemption step, the wallet funding prerequisite, and the fee structure. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough that an agent can infer appropriate use. A small deduction for lacking explicit 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses async processing, rate limits (5-minute and 12 per 24h), manual handling for international cards, and the 409 conflict behavior. This gives the agent a clear picture of side effects and failure modes 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?

The description is concise, front-loaded with the purpose, and structured into clear paragraphs for U.S. and international behavior. Every sentence adds value, with no redundancy or 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 action, parameters, rate limits, error condition, and async behavior. An output schema is present, so return values are covered. For a refresh tool with this complexity, nothing essential is missing.

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

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

Schema coverage is 100%, so both parameters are documented. The description adds value by explaining the impact of card_type (defaulting to U.S., different processing paths) and the meaning of card_id in context, which goes beyond the schema's terse descriptions.

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

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

The description clearly states the tool triggers a card data refresh and requests an updated balance. It distinguishes itself from siblings like get_card_data by focusing on the refresh action, and the title and description align with the resource and action.

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 the tool: to refresh card data, and it differentiates behavior for U.S. vs international cards, including rate limits and async processing. It also notes the 409 error when a refresh is already pending. However, it doesn't explicitly contrast with get_card_data or other alternatives, leaving some inference needed.

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 annotations, the description adds valuable behavioral context: 'free endpoint — no x402 payment required' and 'standard OAuth2 grant_type=refresh_token pattern.' It does not disclose refresh-token rotation or auth requirements, but the annotations and output schema cover the remaining safety profile.

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, front-loaded with the action, and every clause earns its place. The payment/cost note is a single useful addition, and the protocol reference is concise.

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

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

For a simple token-refresh endpoint, the description plus full parameter schema and output schema covers purpose, parameters, cost, and protocol. There is no significant missing information needed to call 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 both parameters already have descriptive text: grant_type must be 'refresh_token' and refresh_token comes from a previous /auth or /get-card call. The description reinforces their purpose but adds little new parameter-level meaning, 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 gives a specific verb and resource: 'Refresh an ID token' and 'Exchange a refresh token for a new ID token.' It is immediately clear what this tool does and how it differs from auth-related siblings by naming the OAuth2 refresh-token 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?

The intended use is implied: use this when you have a refresh token and need a new ID token. However, there is no explicit 'use when' guidance or mention of alternatives such as exchange_api_key, so the agent must infer the selection context.

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

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

The description discloses rich behavioral detail beyond the sparse annotations: registering replaces the existing webhook, rotates the secret, re-enables disabled registrations, sends a test delivery, notifies the account owner, times out after 10 seconds, and does not retry. It also documents the signing headers and one-time secret return. This fully informs the agent of side effects and operational constraints.

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

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

The description is longer than average but every paragraph adds distinct operational detail: registration semantics, signing format, failure/disabling behavior, and delivery timeout. Small redundancies such as 'free' and repeated HTTPS requirements exist, but the structure is logical and front-loaded with the core 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 tool with one well-documented parameter and an output schema, the description is complete. It explains the returned secret, webhook payload shape, signature verification, replacement behavior, disable condition, timeout policy, and the relationship to status endpoints. An agent has everything needed to invoke and interpret 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?

Schema coverage is 100% and the schema already documents the URL requirements. The description adds context about what kind of URL is acceptable ('your harness's inbound webhook endpoint, or a relay you poll') and reinforces that private/internal hosts are rejected. This goes beyond the schema without being redundant.