Laso Finance

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

With no annotations, the description carries the full behavioral burden. It adds useful facts: the operation attaches an account/address, returns a destination ID, and is free. However, it does not disclose side effects such as whether calling it repeatedly creates multiple destinations, whether it replaces existing ones, or what auth setup is required.

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

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

The text is short and front-loaded, but the first sentence 'Attach bank details to a recipient' is redundant with the second sentence. 'Free.' is informative but abrupt; a single tighter statement would be better.

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 nested five-parameter mutation with no output schema, the description covers the core purpose and the key return value but omits operational context such as needing an existing recipient and the `recipientAddress` caveat for name-only recipients. The schema fills some of these gaps, making the definition adequate but not complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds only high-level context about the destination type and the returned ID's role; it does not add per-parameter meaning beyond what the schema already provides.

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

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

The description states a concrete action and resource: it attaches a bank account or crypto address to a recipient. It also names the meaningful output (`destination_id`) and the downstream consumer (`/send-bank-payment`), which makes the tool's role distinct from siblings like `update_banking_destination` or `create_banking_recipient`.

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 the main usage context: call this before `/send-bank-payment` because the returned `destination_id` is what that payment tool pays out to. It does not explicitly state when not to use it or contrast it with alternatives such as `update_banking_destination`, so the guidance remains inferential.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('transfer') but omits critical behavioral aspects such as irreversibility, balance requirements, fees, or any side effects. For a financial mutation tool, this is a significant gap—an agent cannot anticipate risks or preconditions.

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

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

The description is two sentences with zero fluff. The primary action and scope are front-loaded in the first sentence, followed by a clear purpose in the second. It is appropriately concise and easy to parse.

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 absence of annotations and an output schema, the description should compensate with cautionary notes (e.g., irreversible transfer, sufficient balance needed). It does not mention any errors, limits, or prerequisites. For a financial transfer tool, this is under-specified—an agent might not know to check balance or verify the destination before invoking.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters clearly. The description adds no extra parameter meaning beyond saying 'transfer USDC' (implicitly covering destination and amount). Since the schema does the heavy lifting, a 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 states a specific verb ('Transfer'), a specific resource ('USDC out of your managed agent wallet'), and a target ('any Solana address'). It also adds a use case ('recover funds or move them to another wallet you control'). This clearly distinguishes it from siblings like 'withdraw' or 'send_payment' which deal with different contexts.

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 context for use: 'to recover funds or move them to another wallet you control.' It implies the tool is for agent wallet transfers only, but does not explicitly mention when not to use it or name alternative tools. However, the context is unambiguous enough that an agent could select it correctly.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains what the tool does (resolves screen, names agent, starts session) and that it returns wallet funding state. It doesn't mention error conditions or side effects beyond session creation, but for a simple announcement tool this is adequate. No contradictions with annotations (none provided).

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

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

The description is a single paragraph with no wasted words. The most critical instruction ('Call this FIRST') is front-loaded, and every sentence contributes new information: what it does, what to provide, and what it returns. It is concise and well-structured.

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

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

For a tool with only 3 parameters, all documented, no output schema, and no nested objects, the description is complete. It covers the purpose, the exact timing (first), the parameters to use, and the return value (wallet funding state). No additional information is needed for an agent 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 coverage is 100% for all three parameters, so the baseline is 3. The description adds value by explicitly instructing to use agent_name and message for the introduction, and it frames auth_token as conditional on the absence of an Authorization header. This goes beyond the schema's dry descriptions and helps the agent select the right parameters.

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

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

The description clearly states a specific purpose: it is the initialization tool that resolves a connection screen, names the agent in the dashboard, and starts a session. It explicitly says 'Call this FIRST, before any other Laso tool,' which distinguishes it from all sibling tools. The verb is clear and the resource is the session/connection state.

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 usage guidance: 'Call this FIRST' establishes when to use it, and it tells the agent to introduce itself with agent_name and message. It also notes that it doubles as a setup check, covering both primary and secondary use. No ambiguity about when to invoke it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds meaningful context: only queued orders can be cancelled, the order is non-reloadable, and the charged amount is credited back to the account balance. This goes well beyond a bare 'cancel order' statement.

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, with the core action front-loaded in the first sentence and the key behavioral details in the second. Every sentence earns its place and there is no redundant filler.

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

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

For a simple one-required-parameter cancel operation with no output schema, the description covers the essential details: what can be cancelled, the state requirement, and the refund behavior. It is complete enough for an agent to invoke the tool correctly, though it could mention the expected failure mode for already-fulfilled orders.

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

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

Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no new parameter meaning beyond what the schema provides, which matches the baseline for high schema coverage.

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

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

The description names a specific verb ('Cancel') and a specific resource ('queued international non-reloadable card order'), and adds the state precondition (`state=queued`). This clearly distinguishes it from siblings like order_intl_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 gives a clear condition for use: the order must be previously queued and not yet fulfilled by an admin. It does not explicitly name alternatives or state when not to use the tool, but the precondition makes the intended usage unambiguous.

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

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

With no annotations provided, the description carries the full burden and does so excellently: it discloses that the raw key is shown only once, that only the hash is stored, and that the key cannot be retrieved again. It also notes the key is durable and free.

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

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

The description is compact and front-loaded with the main purpose, then delivers critical behavioral caveats. Every sentence earns its place, though the trailing 'Free.' is minor extra information that does not reduce 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 simple two-parameter tool with no output schema, the description covers the essential behavior including the one-time visibility of the key and the durable nature of the credential. Nothing critical is missing for correct invocation.

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

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

Schema coverage is 100%, so the input schema fully documents both parameters. The description does not add parameter-specific meaning, which is acceptable given the schema already provides adequate 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 action: issuing a durable `lasoak_` API key for the account. It uses a specific verb and resource, and the context is distinct from siblings like get_auth_link or refresh_token.

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 this is normally a human dashboard action, which gives contextual guidance, but it does not explicitly state when an agent should use this tool versus alternatives or when not to use it. The guidance is present but indirect.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses idempotency, the one-per-account constraint, the returned Solana address, and the need to fund the wallet with USDC. It does not mention auth requirements or failure modes, but for an idempotent creation call these are minor gaps.

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

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

The description is two concise sentences with no filler. It front-loads the primary action and constraint, then gives the return value and practical funding purpose. Every sentence contributes useful 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 simple, idempotent creation tool with no output schema and no annotations, the description is mostly complete: it states the result, return value, uniqueness constraint, and follow-up funding need. It does not state prerequisites such as account existence, but 'one per account' implies the account context and the optional auth_token is covered by the schema.

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

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

Schema description coverage is 100%, so the schema fully documents the optional auth_token parameter, and the description adds no parameter-specific meaning. Baseline 3 applies because the schema does the heavy lifting.

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

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

The description uses a specific verb and resource: 'Create your managed agent wallet.' It clarifies scope with 'one per account', notes idempotency, states the returned value ('Solana address'), and its purpose ('pay for the paid tools'). This clearly distinguishes it from siblings like get_agent_wallet and agent_wallet_transfer.

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: create a wallet before using paid tools, one per account, and idempotent behavior if called again. It does not explicitly name alternative tools or state when not to use it, but the context is specific enough that callers know the intended scenario.

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

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

With no annotations provided, the description carries the full behavioral burden. It meaningfully explains what happens when an on-ramp or off-ramp is opened, notes the automatic off-ramp creation path, and discloses that the operation is 'Free.' It does not cover prerequisites like KYC or what the response contains, but it provides substantial behavioral context beyond a mere creation statement.

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 front-loaded: the primary purpose is in the first line, followed by bolded explanations of on-ramp and off-ramp. The 'Free.' note is economical. Minor redundancy exists between 'Open an on-ramp or off-ramp account' and 'Opens a banking rail,' but overall it is tight and scannable.

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 moderate complexity, 8 parameters, and the absence of annotations and output schema, the description covers the key context: what the two account types do, when an off-ramp is unnecessary, and default behavior like the managed wallet. It could mention prerequisites such as a banking profile or KYC status, but the provided guidance is sufficient for most agents to decide whether and how to call it.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful conceptual context about on-ramp vs off-ramp behavior, but it does not clarify ambiguous parameters such as 'rail' or 'capabilities' beyond what the schema already states. It is adequate but does not go further than 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 opens with a specific verb and resource: 'Open an on-ramp or off-ramp account.' It then explains what each account type does, and the second sentence, 'Opens a banking rail,' reinforces the core resource. This clearly distinguishes the tool from siblings like create_banking_profile or add_banking_destination.

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 NOT to use this tool for off-ramps: it 'is opened automatically by /send-bank-payment, so most agents never call this for one directly.' It also implies the correct on-ramp use case: receiving dollars as USDC in the managed wallet. This gives concrete routing guidance relative to a named sibling.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It discloses the human-in-the-loop requirement, the kycRequired/kycUrl response condition, and that this is the only step the agent cannot complete itself. It could add idempotency or success behavior, but it covers the critical operational details.

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

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

The description is compact, front-loaded, and actionable. The minor redundancy between 'Create the banking profile' and 'Opens the banking profile' plus the stray 'Free.' line keep it from 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 one-parameter tool with no output schema, the description explains the key failure response and the human handoff, which is the core operational knowledge an agent needs. Success-side details are minimal but inferable from the tool's role as the foundation for other banking calls.

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

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

Schema description coverage is 100%, so the optional auth_token parameter is already fully documented. The description adds no further parameter-specific meaning, which matches the high-coverage baseline.

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

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

The description clearly identifies the tool as creating/opening the banking profile that all other banking calls depend on. This distinguishes it from sibling tools like create_banking_account and create_banking_recipient by establishing it as the foundational prerequisite.

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 provides strong usage context: identity verification must happen first, the agent should hand the kycUrl to the human if needed, and then retry after they finish. It does not explicitly name alternative tools or when-not-to-use situations, so it stops short of the highest 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Free' and the creation action, but does not disclose side effects, permission requirements, reversibility, or what happens on duplicate creation. The mention of 'Free' is a minor behavioral note but insufficient for a mutation tool with no annotation safety coverage.

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

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

The description is very short, with the core purpose front-loaded. However, the first two sentences ('Create a payout recipient' and 'Creates a person or company money can be sent to') are somewhat redundant and could be condensed. Still, it is efficient and avoids unnecessary detail, so it earns a 4.

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

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

Given the simple nature of the tool, the description provides enough context for an agent to call it correctly: it states what it creates and flags the need to use addBankingDestination for bank details. The schema covers all parameters, and the lack of an output schema is not a major gap because the creation outcome is straightforward. It is adequate but could benefit from a note about expected response or error cases.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters fully. The description adds no additional parameter-level meaning beyond pointing out that bank details are attached separately, which is already implicitly covered by the address parameter description. Baseline of 3 is appropriate because the schema carries the parameter documentation burden.

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

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

The description opens with 'Create a payout recipient' and clarifies that it creates 'a person or company money can be sent to.' It also distinguishes itself from add_banking_destination by noting bank details are attached separately, which is a clear example of sibling differentiation. The purpose 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 the workflow: create the recipient first, then attach bank details with addBankingDestination. This gives clear contextual guidance on when to use this tool in relation to its sibling. However, it does not explicitly mention alternatives like create_banking_account or create_banking_profile, nor does it state when not to use the tool, so it lacks full exclusionary guidance.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It thoroughly explains the card's reusability, the funding source, the free nature, the 402 error condition, the deposit address retrieval, and the direct availability of card_details for Laso-issued cards. This is comprehensive and exceeds what annotations would typically 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 well-structured with clear paragraphs and bold key terms. It front-loads the main purpose and then covers reusability, cost, error handling, and follow-up actions. While it is somewhat long, each sentence contributes meaningful information, and the structure aids comprehension.

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 is complete for a tool with no output schema. It explains what the tool returns ('returns it'), how to access card data via /get-card-data, and the distinction from other card creation routes. It also covers edge cases like insufficient balance and funding methods, ensuring an agent has all necessary information 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 coverage is 100%, so the baseline is 3. The description adds extra meaning beyond the schema: it clarifies 'usd_amount' is in dollars (not cents) and has a $1 minimum, and elaborates on 'reusable' with the behavior of staying open until limit is spent. This adds value beyond the schema definitions.

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 and resource: 'Create a reloadable card' and explains it is funded from the account holder's balance and returns the card. It distinguishes from sibling tools by noting it is the same card created in the Laso dashboard and contrasts with cards from other apps that require approval. This makes the tool's 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 on when to use this tool: it creates a reloadable card, is free (no x402 payment), and is Laso-issued so no approval step is needed. It also explains the error case (402 when balance is short) and how to fund the card. While it doesn't explicitly name alternative tools to avoid, the context effectively guides 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?

With no annotations, the description carries the full burden and does it well. It states the operation is free, scoped to the own account book, affects only the name mapping, and has no effect on past transfers. It also warns that names are labels and to echo resolved addresses before sending, giving an accurate side-effect 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 front-loaded with the core action and then organized with bolded safety guidance. The name-vs-address warning is somewhat tangential to the delete operation itself, but it supports the address-book mental model and the final sentence directly clarifies the delete's limited 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 simple two-parameter delete operation, the description covers scope, side effects, and cost. It does not mention expected return values or behavior when the address is absent, but the parameter schema is complete and the operational semantics are clear enough for an agent to call it correctly.

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

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

Schema coverage is 100% and both parameters are already described in the schema, so the baseline is 3. The description adds context that no user parameter exists and that an address rather than a name is used, but it does not add meaningful parameter-level detail beyond the schema.

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

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

The opening line 'Remove a saved recipient' states a specific verb and resource, and the follow-up explains this is the dashboard-managed saved recipient book. It is not a tautology and is distinct from the banking/payment recipient delete tools, though it does not explicitly call out those 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 gives useful operational context: it operates only on the authenticated account's own book and there is no user parameter. However, it never explicitly says when to prefer this tool over delete_payment_recipient or delete_banking_recipient, so usage conditions remain mostly implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the operation is irreversible and cascades to destinations and off-ramp accounts, which are critical side effects. It adds a note that the operation is free, though it does not mention authentication requirements or error 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 concise with a header and two short sentences. It is front-loaded with the core action and side effects. The 'Free.' note is an extra detail that may be useful but not essential, and the header is slightly redundant with the first 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 delete operation with two parameters and no output schema, the description covers the essential behavioral context: what gets deleted, irreversibility, and cost. It does not describe return values or error scenarios, but these are less critical for a delete tool and the schema already documents both parameters.

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

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

Schema description coverage is 100%, so a baseline of 3 is appropriate. The tool description adds meaning to recipientId by explaining it triggers cascading deletion of related destinations and off-ramp accounts, which is not stated in the schema. This adds value beyond the structured fields.

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: 'Delete a recipient' and elaborates that it deletes the recipient, its destinations, and any off-ramp account that paid out to it. This goes beyond a generic description and distinguishes the tool from sibling delete tools by describing the scope of deletion.

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 the tool through its clear purpose but does not explicitly mention alternatives or conditions. There is no guidance on when to choose delete_banking_recipient over delete_payment_recipient or other delete tools, though the tool name itself provides some disambiguation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that payment history is kept, only the saved entry is removed, and that the operation is not reversible through the API. It also notes that parameters can be sent in the body or query string. This is adequate though it does not explicitly state success/failure outcomes or idempotency.

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 line, followed by essential behavioral and usage notes. It is appropriately sized, though the '(free)' suffix is cryptic and could be removed. The structure flows logically from purpose to behavior to guidance, with no unnecessary filler.

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

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

For a destructive, irreversible operation, the description covers the key aspects: what is removed, what is preserved, and the recommended alternative. It also addresses the transport flexibility. It does not mention behavior for non-existent recipients or error cases, but given the schema and lack of output schema, it is reasonably complete for an agent to call it correctly.

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

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

The input schema already describes all three parameters with 100% coverage, including the enum for platform and the explanation for recipient_id. The description adds a minor usage note that platform and recipient_id may be sent in the JSON body or query string, which is a transport detail rather than deeper parameter semantics. Given full schema coverage, 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 verb 'Remove' and the resource 'saved recipient' with explicit mention of Venmo or PayPal. It distinguishes from sibling delete tools like delete_banking_recipient and delete_address_book_entry by specifying payment recipients, and from update_payment_recipient which modifies rather than removes. The parenthetical '(free)' is ambiguous but does not undermine the core purpose.

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 provides when to use the tool (to remove a saved recipient) and when to prefer an alternative: 'prefer archiving (`POST /payment-recipients` with `archived: true`) when the account owner may want the recipient back'. It also advises confirming before removing someone not asked to remove, giving clear conditional guidance.

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

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

With zero annotations, the description carries the full burden, and it does well: it discloses cost ('free'), scope ('calling wallet's' own registration, implying no cross-account effect), partial effect (only webhook deliveries stop, not push/SMS/Telegram/in-app), and the side effect of notifying the account owner. It omits idempotency/error behavior for a non-existent webhook, but this is solid coverage for an unannotated tool.

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

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

Three short sentences with no filler: the headline action and cost are front-loaded, then precise behavioral scope, then the notification side effect. 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 single-optional-parameter tool with no output schema and no annotations, the description covers purpose, scope, side effects, and cost — enough for an agent to call it correctly. The only gaps are edge-case behavior (calling delete when no webhook exists) and return/confirmation shape, which are minor for a tool this simple.

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% — auth_token is fully documented in the schema ('Laso credential. Only if the MCP connection has no Authorization header'). The description adds no parameter-level detail, so the baseline of 3 applies; 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 and resource: 'Delete the notification webhook' / 'Removes the calling wallet's webhook registration.' The line about other channels continuing distinguishes this from broader notification-disable tools, and it is clearly differentiated from sibling register_webhook and get_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?

Usage context is implied rather than explicit: the description makes clear this stops webhook deliveries while other channels continue, so an agent can infer when to call it. However, it never names register_webhook as the reversal path or states when not to use it, leaving the when-vs-alternative guidance entirely 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?

With no annotations provided, the description carries the full burden and does substantial work: it discloses token lifetime, the presence of a human-visible `auth_url`, the durable key prefix, the fact that this is the entry point for all other calls, and that it is free. It does not state whether the API key remains valid after exchange, but the description still provides unusually rich behavioral context.

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

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

The description is front-loaded with the core action and then delivers token details, usage positioning, and acquisition instructions in compact paragraphs. Every sentence earns its place, including the final 'Free.' which adds cost transparency without bloat.

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

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

Despite having no output schema, the description explains the returned values (`id_token`, `refresh_token`, `auth_url`) and their roles. It covers the single parameter fully via the schema, explains the prerequisite for obtaining a key, and gives the call's place in the agent lifecycle, making it complete for such a 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?

Schema coverage is 100%, and the parameter is a single `api_key` string with an example and description already. The tool description adds only the adjective 'durable' and the URL for obtaining a key, which is helpful context but not substantial new parameter-level semantics beyond the schema.

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

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

The description states a specific verb and resource: exchanging a durable `lasoak_` API key for a session containing `id_token`, `refresh_token`, and `auth_url`. It clearly positions this as the first call an agent makes, which distinguishes it from siblings like `create_agent_api_key` and `refresh_token`.

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 this is the first call an agent makes and that the returned `id_token` authenticates every other endpoint, giving clear when-to-use context. It also explains how to obtain a key if the agent lacks one, though it does not explicitly contrast with the `refresh_token` sibling for later sessions.

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

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

With no annotations, the description fully carries the behavioral burden and does so: it discloses payment settlement, CCTP bridging/burning/minting, exact fee behavior, status lifecycle (paid -> bridging -> delivered -> credited), response top_up_id, and failure recovery via withdraw. This is far beyond the minimal 'loads balance' statement.

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 long, the description is front-loaded with the one-sentence purpose and uses bolded section headers (Why this exists, Price, Delivery, Failure) so an agent can scan efficiently. Each paragraph adds a distinct operational fact and none is filler.

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

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

For a payment endpoint with no output schema or annotations, the description explains prerequisites, response behavior, status monitoring endpoints, post-conditions, and failure handling. An agent has enough to decide, execute, and verify the operation successfully.

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

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

Schema coverage is 100% and already documents amount's min/max and x402 price. The description adds the valuable guarantee that the credited balance equals the paid amount and that Laso covers bridge cost by burning slightly more than the requested amount, which clarifies the financial contract 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 opens with a clear verb and resource: 'Load a reloadable card balance' and 'Pay USDC to load the account holder's reloadable card balance at the card issuer.' It also explains the unique cross-chain bridging mechanism, which differentiates it from sibling actions like create_reloadable_card or withdraw_card_balance.

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

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

It gives concrete usage context: a linked issuer account is required, the wallet must exist and be funded (get_agent_wallet), and the correct follow-up is POST /create-reloadable-card. It does not explicitly list when-not-to-use or name an alternative for the same goal, which keeps it just shy 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool returns but does not disclose side effects, authentication requirements beyond the optional auth_token parameter, rate limits, or any limitations. For a tool with zero annotation coverage, this is a significant gap in transparency.

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, consisting of two short sentences. The purpose is front-loaded with 'Get account balance' and the return information follows immediately. There is no wasted wording, making it highly efficient for an agent to parse.

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 tool with one optional parameter and no output schema, the description covers the core return values (balance and total deposits). However, it omits any mention of error conditions, currency, or authentication prerequisites beyond the implied 'authenticated user'. Given the low complexity, the description is minimally adequate but not fully complete.

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

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

The schema describes the auth_token parameter with 'Laso credential. Only if the MCP connection has no Authorization header.' Since schema description coverage is 100%, the schema already documents the parameter fully. The tool description adds no additional meaning about parameters, so 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 verb 'Get' and the resource 'account balance', and specifies that it returns the current account balance and total deposits for the authenticated user. This is specific and unambiguous, though it does not explicitly differentiate from sibling tools like get_agent_wallet or get_card, which is why it falls short of a 5.

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

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

The description implies usage: if you need the account balance, use this tool. However, it provides no explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or exclusions. The usage is implied rather than stated, so it meets the baseline for implied guidance but lacks explicit routing.

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

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

With no annotations provided, the description carries the full burden. It discloses that the operation is read-only, that it applies to all payment types (agentX402Pay, Laso routes, external url endpoints), the default and range, and that fees are added on top. It also explicitly warns against splitting payments. This is transparent and thorough for a read-only tool.

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

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

The description is fairly long but each sentence adds valuable information: the return value, bounds, default, scope, and usage guidance. It is well-structured and front-loaded with the core purpose. It is slightly wordy but not redundant, earning a 4.

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

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

Despite having no output schema, the description fully explains what is returned (maxPerPaymentUsdc plus min, max, default) and provides context (default $1,000, range $1–$50,000). It also covers the operational guidance and the read-only nature. For a read-only tool with a single optional parameter, this is complete; an agent has everything needed to call it correctly.

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

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

There is one parameter, auth_token, which is fully described in the schema ('Laso credential. Only if the MCP connection has no Authorization header.'). The description does not add any additional meaning beyond that. Since schema coverage is 100%, a baseline of 3 is appropriate; the description does not need to repeat 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's purpose: 'Read the per-payment spend limit.' It specifies the exact resource (managed wallet's per-payment limit) and the key returned field (maxPerPaymentUsdc). The name and description are unambiguous, and it is distinct from sibling tools, which are mostly about other banking/payment 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 gives explicit guidance: check the limit before attempting a payment, compare fee-inclusive total, do not split payments that exceed the limit, and stop to tell the human. It also clarifies that the tool is read-only and only the owner can change the limit, which informs when it's appropriate to call. This is more than adequate for an agent to decide when to use it.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly discloses the tool's read-style behavior, the returned fields, and the wallet's role as the funding source for paid tools. It does not explicitly state error/auth failure modes, but the key side-effect expectations are transparent enough for a simple getter.

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

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

Three sentences with no filler: the first sentence front-loads all returned values, the second provides a concrete trigger, and the third gives a follow-up funding action. 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 tool with zero required parameters and no output schema, the description covers purpose, return fields, and the next action (sending USDC to the returned address). It stops short of explicitly saying what to do when no wallet exists, such as using create_agent_wallet, but the 'whether one exists' output makes that branch easy for the agent to infer.

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%, and the only parameter, auth_token, is already fully described in the input schema. The tool description adds no additional parameter-level semantics, so the baseline score 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 concrete verb + resource ('Get your managed agent wallet') and enumerates the exact outputs: existence, Solana address, USDC balance, and funding status. This clearly distinguishes it from siblings like create_agent_wallet, agent_wallet_transfer, and get_agent_spend_limit.

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 an explicit trigger and rationale: 'Paid tools draw from this wallet, so check it before your first paid call.' It does not name alternative tools or state when not to use it, but the call context is clear enough for an agent to route correctly.

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

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

With no annotations, the description carries the full burden, and it does so well. It discloses that the URL embeds a short single-use login code rather than a long-lived token, that it passes through credential filters, and that fetching or opening the URL consumes the human's login. This gives the agent critical behavioral knowledge it could not infer from the 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 tightly organized with a front-loaded purpose, followed by the human use case and then the critical handling warnings. Every sentence adds value: no filler, no repetition of the schema, and no unnecessary context. It is exactly as long as it needs to be.

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 optional parameter, no output schema, and no annotations, the description is complete. It explains what the tool returns, what the human should do with it, what the agent should not do, and why. An agent has everything needed to invoke this tool correctly and relay the result appropriately.

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 the only parameter (auth_token) with 100% coverage: 'Laso credential. Only if the MCP connection has no Authorization header.' The description adds no further parameter detail, but the schema is already sufficient, so the baseline score 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 opens with a specific verb and resource: 'Get a login link for the web dashboard.' It then clarifies exactly what the tool returns: a URL a human can open in a browser to log in as the authenticated user. This is clearly distinguished from sibling link tools like get_kyc_link by focusing on the dashboard and authenticated-user session.

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: 'Useful for humans who want to see what their AI agent has been doing (view cards, transactions, balances, etc.).' It also gives operational guidance: relay the URL verbatim and do not fetch or open it. It does not explicitly name alternatives or state when not to use this tool, but the intended use case is unambiguous.

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

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

No annotations are provided, so the description carries full responsibility. It discloses the return content (ready, applicationStatus, outstanding questions) and adds context about the nature of those questions (non-identity, such as employment status and source of funds). However, it does not state explicitly that the operation is read-only or side-effect free, nor does it mention any auth prerequisites beyond the auth_token parameter, which is already in the 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 reasonably concise but has minor redundancy. The opening line 'Read the banking application' is essentially a title and repeats the tool name. The additional explanation about identity answers and non-identity questions is useful but could be condensed. The trailing 'Free.' is ambiguous and likely unnecessary. Overall, it is well-structured but not maximally 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?

For a simple read tool with a single optional parameter and no output schema, the description adequately covers what the tool returns and the nature of the outstanding questions. It does not mention error scenarios or behavior when no application exists, but such details are not critical for basic invocation. The description is sufficient for an agent to understand the tool's purpose and expected 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?

There is only one parameter, auth_token, and the schema description covers it fully (100% coverage). The description does not add any extra semantic detail about the parameter beyond what the schema already provides, so it meets the baseline but adds no value.

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

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

The description clearly states the verb 'Read' and the resource 'banking application', and specifies the exact returned fields (ready, applicationStatus, outstanding questions). This distinguishes it from sibling tools like get_banking_profile_status or get_kyc_status, which focus on other aspects of the banking 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 description implies usage for checking application progress ('Reads what the application still needs') but does not explicitly mention when to use this tool over alternatives or list exclusions. There is no reference to sibling tools or conditions that would make another getter more appropriate, leaving the routing decision to the agent's inference.

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

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

With no annotations, the description carries the behavioral burden. 'Reads' conveys a read-only operation and 'Free' discloses no cost, which adds useful context. However, it does not describe behavior when a profile does not exist, error cases, or whether any side effect could occur.

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-loads the core meaning in the second sentence. The first sentence mostly restates the tool name, and the standalone 'Free.' is terse, but there is no 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 tool with one optional parameter and no output schema, the description conveys the essential outcome: whether the profile exists and where the application stands. It does not specify the exact return shape, but complexity is low enough that this is not a major gap.

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

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

The single parameter auth_token has 100% schema description coverage, so the schema already explains it sufficiently. The description adds no parameter-specific detail, earning the baseline score of 3.

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

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

Description uses a specific verb ('Reads') and names a concrete resource ('the current state of the banking profile'), clarifying what it reports: existence and application standing. It stops short of 5 because it does not explicitly distinguish itself from sibling tools like get_banking_application or get_banking_profile-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?

No guidance is given for when to use this tool versus alternatives such as get_banking_application or get_signup_status. The word 'Free' hints at a cost property but does not explain usage context, prerequisites, or exclusions.

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

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

With no annotations, the description carries the behavioral burden. It does disclose that the operation is read-only ('Reads'), that statuses are normalized, and that it is 'Free,' which adds meaningful context. However, it does not describe response contents beyond normalized status, error behavior, or auth requirements.

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

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

The description is compact and front-loaded, with a quick lead line followed by a sentence that adds scope, status, and cost. There is slight redundancy between 'Read one transaction' and 'Reads a single banking transaction,' which 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?

The tool is simple, but with no output schema and no annotations, the description should carry more weight around return values and edge cases. It explains the core purpose and status normalization, but not what the full transaction response looks like or when this tool is preferred over related siblings.

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 transactionId is already documented as 'The transaction to read.' The description adds no further parameter-level detail beyond transaction type context, so the baseline score 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 uses a specific verb ('Reads') and a precise resource ('a single banking transaction'), further scoped as on-ramp or off-ramp and normalized status. The word 'single' distinguishes it from list-style siblings like list_banking_transactions, so an agent can identify the intended operation 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?

There is no guidance on when to choose this tool over alternatives such as list_banking_transactions, get_payment_status, or get_withdrawal_status. The only contextual hint is the word 'single,' which implies one transaction, but no exclusions or alternative routing are provided.

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

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

With no annotations provided, the description carries the full burden and excels. It discloses that this is a paid route (x402 USDC auto-payment from agent wallet), requires a funded wallet (references get_agent_wallet), returns a pending status, and that card details take 7-10 seconds to become available. It also notes the US-only restriction and non-transferability. No contradictions exist.

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 bolded key sections (U.S. only, PAID ROUTE). It front-loads the core purpose and then logically expands to response handling, restrictions, and payment details. Each paragraph adds distinct value without redundancy, making it thorough yet organized.

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

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

Given the complexity (payment, async status, geographic restrictions) and lack of output schema, the description covers all necessary aspects: payment flow, response format, polling instructions, alternatives, and prerequisites. It explains the return values (JSON with auth credentials and card info, pending status) and the callableBaseUrl for polling, making it 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?

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema: it explains that format=html is for browser-based flows and that auth_token is only needed if no Authorization header, but these are already in the schema descriptions. The description does not add new parameter semantics beyond what the schema provides.

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

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

The description opens with a clear verb+resource: 'Order a USA prepaid card.' It specifies the payment method (USDC), the amount range, and the output format options. It distinguishes itself from siblings like order_intl_card and get_card_data by explicitly naming the alternative for non-U.S. use and the polling mechanism for card readiness.

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 when-to-use and when-not-to-use guidance: 'For non-U.S. merchants or non-USD currencies, use `GET /order-intl-card` instead.' It also instructs to poll getCardData after ordering, and warns that the card is non-transferable and intended for the caller's own use. This gives clear context and exclusions.

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

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

With no annotations to fall back on, the description carries the full burden and fully delivers: it discloses timing windows (7-10 seconds, ~24 hours), polling guidance, the queue-id-to-card-id lifecycle for international orders, the three-way reloadable card result (card_details/details_approval/details_error), and the perpetual null billing_address with AVS implications. It also clarifies that no approval step is involved for Laso-issued reloadable cards, preventing a false assumption.

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 it is organized by card type and front-loads the core behavior before special cases. A few sentences, such as the merchant checkout guidance, are arguably beyond what an API invocation requires, but most paragraphs earn their place given the complex multi-state behavior being documented.

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 there is no output schema and no annotations, the description is notably complete: it names the key response fields, statuses, polling cadence, empty-list behavior with explanatory note, and error/approval states. An agent has the information needed to decide when to call the tool and how to handle the response without additional lookup.

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?

Even though schema coverage is 100%, the description materially enriches the parameters: it explains card_id can be a queue id that resolves after fulfillment, card_type values map to distinct product behaviors, and approval_id is only valid in the specific 'different app' scenario. This goes well beyond the schema's baseline 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 identifies the operation ('Get card details') and resource ('card orders'), and specifies the single-vs-list behavior plus the three card types it covers. However, it does not explicitly differentiate itself from sibling tools like get_card or refresh_card_data, so it stops short of full sibling differentiation.

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

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

Provides very clear contextual guidance: use card_id for a single lookup, list by card_type with a default preserving old behavior, poll every 2-3 seconds for U.S. cards, and pass approval_id only for the described reloadable-card approval flow. It does not explicitly state when not to use this tool or name alternatives such as refresh_card_data, but the usage context is unambiguous.

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

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

Even though no annotations are provided, the description fully discloses the key side effect: simply calling this creates the address at the issuer. It also explains user-funded semantics, the Base-only chain constraint with irreversible loss risk, typical confirmation timing, and that the stable address should only be considered authoritative via this endpoint.

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 sentence earns its place: purpose, funding flow, chain warning, polling behavior, and caching guidance. It is front-loaded with the main purpose and then provides essential operational detail in clearly separated paragraphs.

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

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

For a tool with no output schema and no annotations, the description is remarkably complete. It explains what will be returned (address and balance), the important side effect of creation, chain constraints, expected timing, next step, and why the agent should call this endpoint rather than caching the value.

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 the only parameter, auth_token, with a clear description and 100% coverage, so the baseline applies. The tool description does not add much about the parameter itself, but none is needed because the schema already explains when auth_token is required.

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 gets the holder's USDC deposit address at the card issuer and the current balance. It also clearly positions this as the way an agent funds a reloadable card with crypto, which distinguishes it from sibling tools like get_card or 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?

It explicitly says when to use this: this is how an agent funds a reloadable card balance. It gives critical when-not guidance: USDC sent on another chain is unrecoverable, and agents should not transfer directly from a managed Solana wallet. It also advises polling until balance updates and then calling POST /create-reloadable-card, plus warns against caching the address.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the returned link is one-time, belongs to the calling wallet, and can be opened or handed to the wallet owner. It also describes the intended flow, which helps the agent understand side effects and prerequisites. It stops short of stating auth requirements or error behavior, but is still substantive.

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 and uses bold to emphasize optionality. The flow explanation is useful and earns its place, though a small amount of repetition ('KYC is optional' / 'you can ignore the verification endpoints') could be trimmed. Overall it is well-organized and not bloated.

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 tool with one optional parameter and no output schema, the description explains what is returned (`kyc_url`), when to call it, and how it fits into the broader flow. It does not describe failure modes or what happens if KYC is already verified, but those are less critical given the explicit flow guidance.

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 is only one optional parameter (`auth_token`) and the schema already describes it as the Laso credential used when no Authorization header exists. The description adds no parameter-specific detail, but with 100% schema coverage, 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 names a specific action ('Get'), a specific resource ('KYC verification link'), and clearly distinguishes it from the related `get-kyc-status` sibling by explaining that it returns the link rather than the status. It also clarifies that KYC itself is optional, which prevents confusion about when this endpoint matters.

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 guidance: only needed for certain features like `/send-payment`, and should be called only after `get-kyc-status` shows `kyc_verified: false`. It even says to ignore the verification endpoints when not using those features, which is strong directional 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?

No annotations are provided, so the description carries the full behavioral burden. It clearly states this is a read-only cached lookup: 'reads the cached status,' 'does not start verification or return a verification link,' and 'kept up to date by the verification webhook.' This gives strong non-mutation clarity, though it does not discuss cache freshness limits or rate limiting.

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 strictly necessary, but every section contributes: optionality, when to use, behavioral guarantees, and alternative endpoints. The key information is front-loaded with 'KYC is optional' and the purpose statement before deeper payout-specific details.

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 tool with zero required parameters and no output schema, the description covers the return concept ('kyc_verified'), the side-effect-free nature, the webhook-backed cache, and the alternative verification flow. It is not a 5 because it does not fully specify the exact response shape or possible status values beyond true/false.

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 optional auth_token parameter is already fully documented in the schema. The description adds only the context 'calling wallet's' but no new parameter-specific semantics, 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?

States a specific verb and resource: 'Get KYC verification status' and 'Returns the calling wallet's cached KYC verification status.' It also distinguishes itself from a sibling by explicitly noting it 'does not start verification or return a verification link,' which separates it from get_kyc_link.

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 when-to-use guidance: 'Use this as a free pre-flight check before paying for /send-payment.' It also gives when-not-to-use context and alternatives: 'To start verification when not verified, call /get-kyc-link' and 'If you are not using those features, you can ignore the verification endpoints entirely.'

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

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

With no annotations, the description carries the full burden. It discloses the free nature, enumerates all possible state values and their meanings, notes that state is absent for older payouts, and clarifies that push-to-card transfers have no server-side state. It also flags that in-process over an hour warrants investigation. This is comprehensive behavioral disclosure.

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?

While the description is longer than average, every sentence earns its place: it covers call modes, state meanings, polling guidance, webhook alternative, and exclusions. It is well-structured and front-loads the core purpose, then provides necessary detail without 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 three distinct call patterns and a complex state model. The description fully explains when to use each pattern, what the state field means, and how to handle in-flight states. It also clarifies what is not covered (bank payouts, push-to-card), leaving no gaps for an agent to call it correctly.

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

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

The schema already provides 100% coverage with descriptions for all three parameters. The description adds critical semantics: payment_id takes precedence over recipient_id, and recipient_id must be the ID returned by GET /payment-recipients, not phone/email. It also explains the 'neither' case, which is not in the schema. This adds substantial 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 clearly states the tool checks Venmo and PayPal payout status, naming the specific action and resource. It differentiates from siblings by explicitly noting that bank payouts are not listed here and should be followed via listBankingTransactions, and it distinguishes from push-to-card transfers.

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

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

It gives three explicit invocation patterns (with payment_id, with recipient_id, or with neither) and explains what each returns. It also advises when to poll versus register a webhook, and directs users to the appropriate alternative for bank payouts. This is thorough, actionable usage guidance.

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

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

With no annotations provided, the description takes full burden. It discloses the ~60s hold, the 204 timeout, the terminal statuses with 'terminal': true in the body, the api_key delivered exactly once, and the fact that subsequent polls omit it. This is exceptionally transparent about behavior and edge cases.

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 multi-paragraph and fairly long, but every section adds critical operational detail: retry semantics, terminal codes, api_key delivery, and the announceAgentConnection note. It is front-loaded with the main purpose and uses bold and bullet-like formatting for emphasis, making it scannable despite 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 long-polling tool with no output schema, the description covers all necessary context: return values (204, api_key, terminal statuses), retry loop behavior, and downstream implications (wallet provisioned, agent recorded). 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 both parameters are well-described in the schema (claim_token and claim_code from POST /signup). The description only restates 'the same POST /signup response' without adding new meaning, so it stays at the baseline.

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

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

The description opens with 'Wait for your human to finish the signup' and then explains it long-polls until the account is created. It specifies the resource (signup status), the action (long-poll), and the outcome (returns api_key). This clearly distinguishes it from sibling tools like start_signup or get_auth_link.

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 retry guidance: 'Retry on 204 and nothing else' and explains that 401 and 410 are terminal. It also notes that announceAgentConnection is not needed on this path, implying when it would be. It does not name specific sibling alternatives, but the context is clear enough for an agent to decide when to use 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?

With no annotations, the description carries the full behavioral burden and handles it well: it states the call is free, requires no auth or payment header, returns a cacheable content-hash version, and explains the relationship to response headers and the API catalog. No side effects or hidden requirements are left ambiguous.

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 and is organized into logical paragraphs: return value/auth, cache-freshness guidance, and catalog integration. It is slightly verbose for a zero-parameter endpoint, especially the RFC 9727 and Link-header details, but each paragraph contributes meaningful context for an agent deciding when and why to call it.

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 no output schema, the description covers everything an agent needs: what is returned, the specific files involved, cost/auth implications, the stale-cache detection workflow, and an alternative way to obtain the same version from response headers. Nothing required to invoke it correctly is missing.

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

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

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds useful meaning by explaining that the version is a content-hash over a fixed set of documentation files rather than a user-facing release number, which clarifies what the returned value represents.

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 the current docs version' and clarifies it is the content-hash version of the Laso Finance agent docs, listing the exact files covered. This clearly separates it from the many get_* sibling tools by identifying a distinct, concrete deliverable.

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: agents aggressively cache docs, so call this to detect a stale cache when the last-seen docs_version differs. It also mentions that every API response carries the value in the X-Laso-Docs-Version header, providing a context-aware alternative source, though it does not explicitly state when-not-to-call the 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?

With no annotations, the description carries the behavioral burden and does well: it states that the signing secret is never returned, that it is shown only once at registration, and that registrations auto-disable after 50 consecutive failed deliveries. This goes beyond a generic 'get' description and surfaces critical operational 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 compact, well-structured, and front-loaded with the main purpose. Every sentence adds meaningful information: what is returned, what is not returned, and the auto-disable 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?

The tool is simple with one optional parameter and no output schema. The description explains the core return concept, the important exception about the signing secret, and a key failure mode. It could be slightly more explicit about the full set of returned fields, but it is complete enough for safe 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 schema already documents the only parameter, auth_token, at 100% coverage. The description adds nothing about parameters, but since the schema fully covers them, 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 uses a specific verb ('Get') with a clear resource ('webhook registration & delivery health') and scopes it to the calling wallet. It also distinguishes itself from register/delete webhook siblings by clarifying what this endpoint 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 implies when to use the tool: to retrieve webhook registration and delivery health. It explicitly directs users away from expecting the signing secret here and points to POST /register-webhook for secret rotation/re-registration, which is solid alternative guidance.

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

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

With no annotations provided, the description is the sole source of behavioral disclosure. It communicates that this is a read-only operation and clarifies the single-vs-all behavior, which is helpful. However, it does not describe response shape, ordering, error behavior, or authorization details beyond 'authenticated user', leaving some behavioral ambiguity.

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 purpose is in the first line, followed by two short sentences that fully explain the optional parameter behavior. Every sentence adds value, and there is no fluff or repetition beyond what is necessary for 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 simple two-parameter read tool with no output schema, the description covers essential operational details: what resource is accessed, whose data is returned, and how the optional parameter changes the result. The main gap is the lack of information about the returned data structure, but given the tool's low complexity, the description is reasonably complete.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces the withdrawal_id behavior ('If omitted, returns all withdrawals') but does not add meaning beyond what the schema property description already states. This meets the baseline but does not exceed it.

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 tool's purpose: getting withdrawal statuses. It distinguishes itself from sibling status tools (get_payment_status, get_kyc_status, get_signup_status) by naming the specific resource (withdrawals) and the authenticated-user scope. The optional ID behavior is also clearly stated, leaving no ambiguity about what the 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 provides clear context on when to use the tool: when you need withdrawal statuses for the authenticated user. It explains the conditional behavior of providing or omitting withdrawal_id, which functions as usage guidance. It does not explicitly name alternatives or exclusion criteria, 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?

With no annotations, the description carries the behavioral burden and does substantial work: it says the call is free, scoped to the authenticated account, has no user parameter, and warns that names are labels to be confirmed against addresses. It stops short of explicitly stating read-only/no side effects or describing returned fields, but 'List' plus the warning makes the core behavior clear.

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

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

The first line immediately states the action, and the following sentences each add selection or safety value. It is longer than a minimal stub but not padded; the bold label warning is substantively important.

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 one-parameter read-only list with no output schema, the description provides the pricing, scope, and name-resolution purpose an agent needs. It doesn't spell out the exact response shape or read-only guarantee, but enough context is present to call it correctly.

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

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

The only parameter, auth_token, is already fully documented in the schema (100% coverage), so the baseline is met. The description adds meaning by explicitly telling agents there is no user parameter to pass, preventing a likely mis-invocation.

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

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

Opens with 'List saved recipients,' a specific verb and resource, and explains the address-book purpose concisely. The title and references to the human-managed dashboard distinguish it from banking/payment recipient tools, though it doesn't name any sibling explicitly.

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?

Describes an explicit use case: resolving a human's saved label like 'coffee vendor' to an address. Scope is clearly bounded to the authenticated account's own book, and the note that agentWalletTransfer takes an address rather than a name helps the agent choose/sequence the tool. It doesn't mention when to use sibling list tools for bank/payment recipients.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well: it discloses exactly what is returned (routing/account numbers), deliberately withholds the off-ramp deposit address with a reason ('internal payout plumbing'), and discloses cost ('Free'). The withholding note is valuable behavioral context that prevents an agent from expecting the off-ramp address here. It omits response format and auth expectations, but the safety-relevant behaviors are covered.

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?

Extremely efficient. The header states the purpose, one sentence clarifies the return content, one discloses the deliberate omission, and 'Free.' conveys cost. Every sentence earns its place, with the purpose front-loaded and 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?

For a simple list tool with one optional parameter, 100% schema coverage, and no output schema, the description covers the essentials: what the tool does, what data it returns, what it deliberately excludes, and cost. The only gap is the absence of return format details, but since no output schema exists, the content description partially compensates. Nothing an agent needs to decide whether to call it is missing.

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

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

Schema description coverage is 100% — the single auth_token parameter is fully documented in the schema ('Laso credential. Only if the MCP connection has no Authorization header.'). The description adds nothing about parameters, which is fine since the schema already covers it. Per the baseline, a 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb ('List') and resource ('banking accounts'), then clarifies the resource as 'banking rails and their details' — routing and account numbers for on-ramp payments. This detail distinguishes it from siblings like list_banking_transactions (transactions, not rails) and create_banking_account (creation, not listing), though it doesn't name those siblings explicitly. The on-ramp vs off-ramp distinction adds useful specificity.

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 the tool — when you need the routing/account numbers to give whoever is paying in — which is clear context. However, it names no alternatives and gives no exclusions (e.g., it doesn't say to use list_banking_transactions when you need transaction history, or get_banking_profile_status for KYC status). Usage is implied rather than explicit.

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

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

With no annotations, the description carries the disclosure burden. It goes beyond the basic purpose by stating that account numbers are masked to the last four digits and that the endpoint is the source of destination_id values, both genuinely useful behaviors. It omits minor details like pagination or response shape, but for a simple list operation the disclosures are sufficient.

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, but it contains redundancy: 'List recipients and destinations' restates the next sentence, and the final 'Free.' is a near-repeat of the earlier cost remark. The phrase 'free paywalled route' is also confusing. It earns a mid score because the core content is still compact.

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 listing tool with one optional documented parameter and no output schema, the description covers the key facts an agent needs: what is returned, the masking behavior, the destination_id use, and cost implications. The confusing route phrasing and lack of explicit sibling comparison are gaps, but they do not make the tool uncallable.

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, auth_token, is fully documented in the input schema with 100% coverage, so the description does not need to add parameter-level detail. There is no extra semantic context in the description, matching the baseline for high schema coverage.

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

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

The description states a specific action and resource ('Lists payout recipients and their destinations') and adds a concrete behavioral detail (masked account numbers). It does not explicitly distinguish this tool from the similarly named sibling list_bank_recipients, so it falls short of a 5.

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

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

The line 'This is where destination_id values come from' implies a clear use case, but there is no explicit guidance about when to choose this tool over siblings such as list_bank_recipients or list_payment_recipients, nor any exclusions. The route/cost remark is tangential rather than decision 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?

No annotations exist, so the description carries the behavioral burden. It discloses that results are normalized and limited to on-ramp/off-ramp banking flows, but it omits pagination, ordering, exact response shape, or any operational constraints. The 'Free.' line adds minor context but not behavioral detail.

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-loads the action ('List transactions') before explaining scope. The standalone 'Free.' fragment is not clearly useful for selection or invocation, which keeps it from a 5.

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

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

For a low-complexity read-only list tool with one optional parameter and no output schema, the description explains what flows are included and that statuses/amounts are normalized. It could mention pagination or response format, but those are not essential 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, auth_token, has 100% schema description coverage ('Laso credential. Only if the MCP connection has no Authorization header'). The tool description adds no extra parameter guidance, but with full schema coverage the baseline applies.

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

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

The description names a specific resource — banking transactions for the account — and clarifies scope with on-ramp/off-ramp money movement and normalized statuses/amounts. This distinguishes it from sibling tools like list_card_transactions and list_banking_accounts without requiring schema inspection.

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

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

It gives clear context (account-level banking transactions) but does not explicitly state when to prefer it over sibling tools such as list_card_transactions or get_banking_transaction. No alternatives or exclusions are named, so routing must be inferred from the resource name.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explains the read-only nature, that listing is free while payouts are paid, and reveals sensitive data handling: account numbers masked to last four digits, routing numbers returned in full. It omits pagination or error behavior, but for this simple list operation the disclosure is solid.

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 sentence, and each subsequent paragraph earns its place: workflow purpose, pricing, output masking, and related operations. There is no fluff or redundant restating.

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

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

Despite no output schema, the description conveys what the response contains: recipients, attached destinations, masked account numbers, and full routing numbers. It also links to relevant sibling operations and a guide. Exact response shape is not specified, but enough context is present 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 single optional parameter auth_token is already fully documented in the input schema, so schema description coverage is 100%. The tool description adds no additional parameter semantics, which matches the baseline of 3.

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

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

The description clearly states a specific verb and resource: it lists bank payout recipients and the destinations attached to each. However, it does not explicitly differentiate itself from the similarly named sibling list_banking_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 concrete usage context: use this tool to find the destination_id that send-bank-payment pays out to. It also frames related create/update/delete tools as complementary steps. It does not explicitly state when not to use it, but the workflow guidance is strong.

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

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

With no annotations supplied, the description carries the burden and covers ordering (newest first), output fields, the empty-list behavior when no issuer account is linked, and the note explaining setup. It does not mention authentication requirements beyond 'authenticated user' or error/rate-limit behavior, but the read-only nature is clear from 'List'/'Returns'.

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 five sentences, all relevant, and front-loaded with the tool's purpose before usage and edge-case detail. It is somewhat repetitive about 'reloadable' and the note about no issuer account could be considered extra, but each sentence adds useful context for selection or invocation.

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

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

Given no output schema and no annotations, the description is nearly complete: it names return fields, ordering, filtering, the card-scope behavior, the non-reloadable alternative, and the empty-wallet edge case with a setup link. It stops short of describing response pagination beyond the limit parameter or error cases, but an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents limit, status, card_id, and auth_token fully. The description mostly repeats that guidance ('Pass card_id... omit it', 'Filter with status', 'cap the page with limit') without adding new parameter-level meaning, so 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 leads with a specific verb-resource pair ('List reloadable card transactions') and immediately states what is returned (amount, merchant, status, timestamps, newest first). It also disambiguates the scope from non-reloadable products and names /get-card-data as the sibling for those, so the agent can distinguish 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?

It gives explicit invocation guidance: pass card_id for one card, omit it for all reloadable cards, use status to filter, and limit to cap page size. It also states the exclusion ('reloadable cards only') and directs non-reloadable history to /get-card-data, making the when-to-use/when-not-to-use decision explicit.

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

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

With no annotations, the description carries the behavioral burden and does so thoroughly. It discloses that the operation is free, that two distinct ids exist, that the saved-entry recipient_id must not be passed to send-payment, and that total_sent/last_sent_timestamp help disambiguate entries.

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

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

The definition is front-loaded, compact, and every sentence earns its place: free call, use case, id warning, and disambiguation guidance. The formatting with paragraphs and inline code makes the trap easy to notice.

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

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

For a list tool with no output schema, the description is complete: it names the output fields an agent needs (recipient_id, handle, total_sent, last_sent_timestamp), explains how they relate to send_payment endpoints, and warns about the common id-misuse failure. The required/enum parameters are already in the schema.

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 all three parameters, so the baseline is 3. The description adds important meaning beyond the schema, especially that recipients are limited to those previously paid and that the entry's handle (not recipient_id) is what send-payment consumes. It doesn't add new detail for auth_token or include_archived, but those were already covered.

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 ('list'), a specific resource ('saved Venmo or PayPal recipients'), and a scoping condition ('this account has paid before'). It distinguishes this tool from banking-address or generic listing siblings by naming both platforms and the downstream purpose.

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

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

It gives clear context: use it before a payment to resolve a human-provided name into the handle that GET /send-payment expects. It doesn't explicitly enumerate alternatives or when not to use it, but the naming and 'so you can' framing make the intended trigger unambiguous.

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

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

With no annotations provided, the description fully carries the behavioral burden. It discloses the material financial behavior: amount is not USD, conversion and fee calculation, the 5–9000 USD minimum/maximum applied to converted value, automatic payment from the agent wallet, and the return shape. This is unusually transparent for a paid action.

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 clear bold labels and front-loaded operational steps. Every section earns its place: workflow, pricing, limits, return behavior, and payment route. Despite its length, it avoids fluff and is easy to parse.

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

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

Given the tool's complexity, the absence of an output schema, and no annotations, the description is remarkably complete. It covers prerequisites, pricing, currency semantics, constraints, return content, and the funding requirement. There is no output schema, but the description compensates by naming the expected redemption details.

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 meaningful behavior beyond the schema by explaining the conversion and fee mechanics with a concrete example (100 SAR ≈ $28 USDC) and reinforcing that the USD limits apply post-conversion. This adds real value to the agent's understanding of both amount and laso_server_id.

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') and clearly differentiates it from related sibling tools like order_intl_card by focusing on gift cards, catalog search, and x402 payment. It also specifies the exact workflow and what the call returns, leaving no ambiguity about the tool's purpose.

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 usage context: first browse GET /search-gift-cards, then call with amount and product ID, and ensure the managed agent wallet exists and is funded. It does not explicitly name or exclude alternative payment/order tools, but the catalog-first workflow and wallet prerequisite give clear actionable 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?

With no annotations provided, the description carries the full disclosure burden, and it does so thoroughly. It discloses that the order is queued and fulfilled by an admin, that payment includes a 3.8% fee, that placing the order accepts legal terms, and that cancellation is possible before fulfillment. This is far more transparent than a generic 'order card' statement.

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

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

The description is dense but organized into clear paragraphs covering fulfillment, fees, legal consent, cancellation, and payment. It loses one point because the opening sentence 'Order an international prepaid card' is redundant and less precise than the following sentence, which repeats and refines the same idea.

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 prerequisites, amount limits, fee structure, legal acceptance, cancellation, and the downstream data retrieval path, which is excellent for an asynchronous order tool. It does not specify the response shape or how an agent should poll for fulfillment, but it does point to get-card-data for accessing the final card details.

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 amount constraints and auth_token, so the baseline is 3, and the description adds real value by explaining the paid route, the automatic wallet payment, and the need to fund the wallet first. The auth_token parameter gains no new context, but the schema already covers it adequately.

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

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

The description names a specific resource type ('international non-reloadable prepaid card'), a concrete verb ('order'), and the currency. It distinguishes itself from siblings by explicitly saying 'non-reloadable' and by describing an admin-queued fulfillment flow that ends with data retrieval via 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?

The description gives clear context for when this tool is appropriate: ordering a non-reloadable international USD card with specific amount constraints and a wallet-funding prerequisite. It explicitly routes to cancel_intl_order for cancellations and get_agent_wallet for wallet checks, but it does not explicitly explain when to prefer create_reloadable_card or order_gift_card instead.

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

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

With no annotations, the description carries the full burden and does well: it discloses the settlement action, USDC asset, returned txHash, and the balance-update delay. It does not cover failure/error behavior, but the core financial side effect is clearly stated.

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

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

Four focused sentences with no filler. The core action is front-loaded, followed by the balance-lag warning, guardrail guidance, and the routing note about Laso's own routes. 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?

Given nine parameters, no output schema, and no annotations, the description is reasonably complete: it explains the return value (response body + txHash), the settlement behavior, and guardrails. It could add error/failure behavior, but nothing critical is missing for selecting and invoking the tool.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds useful context by referring to guardrail arguments, but it does not substantially expand on individual parameter meaning beyond what the schema provides.

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

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

The description states a specific verb and resource: paying external x402-paywalled endpoints from the managed agent wallet, settling in USDC, and returning the response body and txHash. It also differentiates from Laso's own paid routes, making the tool's scope clear against the large sibling 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?

It explicitly tells the agent to use guardrail arguments to pin agreed payment terms and to prefer dedicated tools for Laso's own paid routes. This is a clear when-to-use and when-not-to-use instruction.

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

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

With no annotations, the description carries the full burden. It discloses that the transfer is not automatic, requires opening a redemption_url and manually entering card details, includes a 4.8% fee with minimum, and requires a funded managed wallet for the paid route. This is substantial behavioral disclosure, though it doesn't mention error handling or rate limits.

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

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

The description is detailed and well-structured with headings for currencies and fees, and it front-loads the primary action. It is somewhat long but each section adds necessary context for a complex operation.

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 process, fee, currencies, manual step, and wallet requirement. However, there is an inconsistency between the stated paid route range (11.50-10000 USD) and the schema's max of 9541.98, and the minimum of 10 vs 11.50. This could confuse an agent. Also, it does not describe the redemption_url format or error scenarios.

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 provides detailed descriptions for all three parameters (100% coverage). The description repeats the face value and fee calculation but does not add new parameter-specific meaning beyond what the schema states. It does clarify the auth_token condition, but that is also in the schema.

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

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

The description clearly states the tool sends money to a debit card in USD, EUR, or GBP, and explains the mechanism. It distinguishes itself from sibling payment tools by focusing on push-to-card transfers, though it doesn't name a specific alternative.

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 this is for sending to debit cards, but it does not explicitly contrast with alternatives like send_bank_payment or send_payment. It does not provide 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well: it explains the asynchronous processing via a retrieval queue, the difference between U.S. and international card handling, the manual admin update for international cards, rate limits, and the 409 conflict behavior. This is rich behavioral context beyond what the schema provides. It doesn't mention side effects like whether the refresh mutates stored data, but the async and rate-limit details are substantial.

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

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

The description is well-structured: a one-line summary followed by two paragraphs of behavioral detail. It's front-loaded with the core action. The length is justified by the genuinely important behavioral differences (U.S. vs international, rate limits, 409). Every sentence adds value. It could be slightly tighter, but the structure is clear and scannable.

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

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

For a tool with no output schema and no annotations, the description covers the key operational details: what happens for each card type, rate limits, conflict behavior, and the async nature. It doesn't explain what the response looks like (no output schema), but the description's behavioral detail compensates. The main gap is not stating what the return value indicates (e.g., success vs. pending), but overall it's quite complete for an async trigger tool.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context about card_type behavior (U.S. vs international) which maps to the card_type parameter, and the rate-limit/409 behavior relates to card_id. However, the description doesn't add much detail about the auth_token parameter beyond what the schema says. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states a specific verb ('refresh'), a resource ('card data'), and the core action ('Requests an updated balance for a card'). It clearly distinguishes this from sibling tools like get_card_data (read current data) and fund_card_balance (add funds). The first sentence is a clear, specific statement of what the 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 provides clear context on when to use the tool: when an updated balance is needed. It also gives important usage constraints: rate limits (one request per 5 minutes, max 12 per 24 hours) and the 409 behavior when a refresh is already pending. However, it doesn't explicitly name alternative tools or state when NOT to use this tool (e.g., 'use get_card_data if you just need current data'). The usage context is strong but lacks 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?

With no annotations provided, the description must disclose behavioral traits itself. It does state that this is a 'free endpoint — no x402 payment required,' which is a useful behavioral note. However, it does not mention side effects (e.g., whether the old refresh token is invalidated), rate limits, or error conditions. The disclosure is minimal but not misleading.

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

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

The description is two sentences long, front-loaded with the purpose, and includes a key differentiator (free endpoint) without unnecessary fluff. Every sentence earns its place, making it efficient and easy to scan.

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

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

For a simple two-parameter tool with fully documented schema and no output schema, the description covers the purpose, the OAuth2 pattern, and the free endpoint aspect. It does not describe the response format explicitly, but the phrase 'new ID token' implies the output. Minor gaps like potential errors or token rotation behavior are not critical for a straightforward refresh operation.

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

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

The input schema already documents both parameters thoroughly (grant_type enum and refresh_token description). The description adds no additional parameter-level detail; it only mentions the tool's free status and OAuth2 pattern. Since schema coverage is 100%, 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 clearly states the tool's function: 'Refresh an ID token' and 'Exchange a refresh token for a new ID token.' This is a specific verb and resource, distinguishing it from sibling tools like get_auth_link or agent_auth, which handle initial authentication flows. The purpose is unambiguous.

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

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

The description implies usage by referencing the standard OAuth2 grant_type=refresh_token pattern and the schema notes the refresh token comes from a previous /auth or /get-card call. However, it does not explicitly state when to use this over alternatives, nor does it exclude use cases like initial authentication. The guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses signed delivery headers, the one-time secret, secret rotation on re-registration, auto-disable after 50 failed deliveries, a first test delivery, and 10-second timeout with no retries.

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

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

The description is dense but every paragraph adds essential operational detail: delivery format, secret lifecycle, failure behavior, timeout rules, and URL requirements. The core purpose is front-loaded in the first sentence, and there is 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?

Given there is no output schema and no annotations, the description covers the critical return value (the one-time secret), delivery payload shape, failure policy, replacement semantics, and URL constraints. An agent has enough information to invoke and understand consequences correctly.

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

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

Schema description coverage is 100%, so the schema already documents both url and auth_token. The description reinforces that the URL must be public HTTPS and that private/internal hosts are rejected, but it adds no new parameter-specific semantics 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 opens with a specific action+resource ('Register a notification webhook') and explains that it creates or replaces an HTTPS endpoint for signed notifications. The verb 'register' plus the described behavior clearly distinguishes it from siblings like get_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 frames this as the push-based alternative to polling: 'instead of re-fetching status endpoints, point this at any URL you can receive HTTP on.' It does not explicitly list when not to use it or name specific sibling tools for inspecting/removing webhooks, 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?

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses that saving an already-saved address renames the entry, making the operation safe to retry. It warns that a name is a label, not an instruction, and advises confirming the resolved address before sending. These are meaningful behavioral insights beyond what schemas could convey.

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

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

The description is longer than average but every section adds value: the rename semantics, the safety guidance, and the retry behavior. It is front-loaded with a one-line purpose, then expands into necessary caveats. A few sentences could be tightened, but the structure is logical and not padded.

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

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

Given three parameters, no output schema, and no annotations, the description covers the operation's purpose, usage, key behavioral nuances, and parameter meaning. It does not explicitly mention what the tool returns (e.g., success message or entry), but the emphasis on rename behavior and retry safety largely compensates. This is sufficient for an agent 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 coverage is 100%, so the baseline is 3, but the description adds valuable semantic context: the address is the entry's key (so re-saving renames), the name is capped at 60 characters server-side, and no user parameter exists. It clarifies the auth_token's conditional use better than a plain schema note, tying it to header absence.

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: 'Save or rename a recipient.' It clearly identifies the address book as the target and distinguishes it from sibling tools like delete_address_book_entry and list_address_book by emphasizing the save/rename operation on a single entry.

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

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

The description explains the intended use case: resolving human-friendly names to addresses for later actions. It explicitly contrasts with agentWalletTransfer, stating that transfer takes an address and deliberately does not accept a name. While it doesn't explicitly say 'use this when you need to persist a name', the context and alternative are clear. It also notes that it operates on the authenticated account's own book with no user parameter.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool searches a specific doc set and returns the most relevant sections, which is sufficient to understand it as a read-only lookup. It does not detail pagination or result formatting, but for a docs search tool this is a minor gap.

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

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

Two sentences with no wasted words. The core function and scope are front-loaded, followed by concrete usage guidance and example topics. Every sentence earns its place and the description is immediately scannable for an agent.

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 one-parameter search tool with no output schema, the description covers what is needed: what is searched, what is returned, and when to use it. It also gives practical examples of the kinds of questions it answers, making it complete in the context of the large sibling tool set.

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 one parameter with 100% description coverage, so the baseline is 3. The description itself adds no additional parameter-level nuance beyond naming the search behavior and context; the schema already defines 'query' with an example. This meets the minimum viable bar but does not elevate it.

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 ('Search'), a clear resource ('Laso Finance agent docs (SKILL.md and the full API reference)'), and the expected output ('most relevant sections'). It clearly distinguishes itself from the many sibling tools by being the documentation search fallback rather than a banking, card, or payment operation.

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 use this tool: 'Use this for anything the tool descriptions don't answer' and lists concrete example topics (auth flows, funding, fees, webhooks, error handling). This provides a clear routing rule and implicitly excludes using it for questions already answered by other tool descriptions.

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?

Since no annotations are provided, the description carries the full burden. It discloses that it's a free endpoint (no x402 payment), returns facets computed from the full catalog, and provides the ordering path. It does not mention pagination or rate limits, but for a search tool this is acceptable and adds value beyond a simple 'search' statement.

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. Each sentence adds value: purpose, return contents, ordering path, facets discovery, and free status. No fluff or redundancy.

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

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

The description provides enough context for an agent to use the tool correctly: what it returns, how to order using the results, how to discover filters, and that it's free. With no output schema, it still describes the output and the workflow, making it complete for this search tool.

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

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

Schema coverage is 100% with each parameter having a description. The description adds some context about how facets relate to parameters, but does not substantially expand on parameter semantics beyond what the schema already provides. 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 clearly states the tool searches and browses the gift card catalog, returning a list of products with pricing and catalog info. It distinguishes from siblings like search_merchants and order_gift_card by focusing specifically on gift cards, making its 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 usage context: it explains the workflow of using the returned `laso_server_id` to order via `GET /order-gift-card`, and notes that a single unfiltered request can discover all valid filter values via facets. However, it does not explicitly state when not to use this tool or mention alternatives, so it lacks exclusions.

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

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

With no annotations provided, the description carries the full burden — and it does so thoroughly. It discloses the database's limited coverage (only merchants previously attempted by Laso users), the treatment of banking/money-transfer merchants as always not_accepted with a restriction_note, and the TLD filtering behavior between card types.

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 and front-loaded: core purpose first, then parameter guidance, then critical caveats. Every sentence earns its place, and the markdown formatting makes the important caveat easy to notice.

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 search tool with no output schema and no annotations, the description is unusually complete. It explains what the tool returns, how to interpret each possible status, the database limitation, and the special banking-merchant rule — so an agent can call it and act on the results without guessing.

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 meaningful value beyond the schema by explaining the card_type default, the difference between the two card_type values, and the country-TLD filtering consequence. The q parameter is adequately described in the schema.

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

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

The description opens with a specific verb and resource — 'Search Laso's merchant database' — and states the core output: whether a card was accepted, not accepted, or unknown at each merchant. This clearly distinguishes it from other search-family tools like search_docs and search_gift_cards.

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

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

It explicitly tells the agent which card_type to use, explains the USA vs international behavior, and gives strong interpretation guidance: unlisted or unknown merchants do not mean failure, while accepted and not_accepted have definitive meanings. This equips the agent to decide when and how to use the tool correctly.

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

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

No annotations are provided, so the description carries full burden. It discloses fee structure, settlement timing, the credit-then-debit flow, failure behavior with recovery via withdraw, and wallet funding requirements. This is far beyond a typical description.

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-structured with bold section headers and front-loaded core behavior. It is long and repeats the fee twice, but every section adds operational 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?

For a high-complexity banking payout with no annotations and no output schema, it covers prerequisites, failure recovery, settlement, and follow-up. An agent has enough to invoke correctly and handle outcomes.

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 already covers all 3 params, but the description adds provenance for destination_id (createBankingProfile → createBankingRecipient → addBankingDestination) and fee/price context for amount. The paid-route range '11.50-10025' is slightly inconsistent with the schema max of 50,000, which keeps this from a 5.

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

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

Opens with a specific verb and resource ('Send dollars to a bank account') and clarifies the mechanism ('Pay USDC ... by ACH'). The banking-specific language and references to banking callables distinguish it from generic siblings like send_payment.

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

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

Gives explicit prerequisites (bank destination, identity verification, funded wallet) and a setup sequence, plus follow-up calls. It doesn't explicitly contrast with send_payment or other transfer tools, but the conditions for using this tool are unambiguous.

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

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

With no annotations provided, the description carries the full burden. It discloses that feedback 'lands on their dashboard', requires a completed real action, and has a rate limit of 5 per 24 hours. These are genuine behavioral traits. It does not mention auth details or the response format, but for a feedback submission tool these are less critical and partially covered by the schema (auth_token param).

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 sentences, with the core action stated first, the value proposition second, and constraints third. Every sentence earns its place, and there is zero fluff. It is efficiently front-loaded and easy to parse quickly.

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

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

For a feedback tool with 100% schema coverage and no output schema, the description is fairly complete. It covers the purpose, the target audience, the prerequisite, and the rate limit. It does not explicitly state the response or that it is a write operation, but that is implied and not a critical gap for an agent 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%, so the schema already documents all six parameters with descriptions. The description adds no parameter-specific details beyond what the schema provides; it only frames the overall purpose. This meets the baseline of 3, as the description need not compensate for a coverage gap.

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 'Send feedback' and the resource 'the API', then elaborates with a concrete purpose: telling the humans running Laso what worked, what was confusing, and feature requests. It is immediately distinguishable from all sibling tools, none of which serve a feedback purpose, so an agent can select it without ambiguity.

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

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

The description gives clear context for when to use it ('best channel for API friction and feature requests') and even imposes a prerequisite (at least one completed real action) and a rate limit (at most 5 per 24 hours). It does not explicitly name alternatives or state when not to use it, but given the unique purpose, that omission is minor.

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

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

With no annotations, the description carries the full transparency burden and meets it: it discloses the 4.9% fee with minimum, the on-chain credit/deposit-webhook mechanism, the debit from the callable, and the KYC verification gate with its kyc_required/kyc_url response. It also warns about the wallet-funding prerequisite for the paid route and offers the withdraw alternative. This goes well beyond a generic 'sends money' statement.

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 organized with bold headers and each section earns its place. The main redundancy is the fee being stated twice — once in the intro and again under 'Fee' — which could be consolidated. Overall, the density is justified by the amount of operational detail needed to make a cross-platform payout correctly.

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

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

The description covers the KYC failure path, platform-specific recipient requirements, fee computation, and wallet funding prerequisites. Without an output schema, it leaves the successful response shape unspecified and doesn't mention polling via get_payment_status, but the information provided is sufficient to invoke the tool correctly and handle its main failure mode.

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?

Even with 100% schema coverage, the description adds critical meaning: it explains the per-platform interpretation of recipient_id (phone number vs. email), the conditional requirement of recipient_email, the English-letters-only constraint on names, and the fee formula tied to amount. This transforms schema fields into actionable rules an agent would otherwise have to guess at.

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

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

The opening line, 'Send a payment via Venmo or PayPal,' uses a specific verb and resource, and the platform names immediately differentiate it from send_bank_payment. The description's scope is unambiguous: pay USDC to dispatch a payout on either platform. It also distinguishes itself from siblings like pay_x402_endpoint by explaining the payout 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 description clearly states the payment mechanism, the KYC requirement, and the fallback withdrawal path, telling the agent what to do when kyc_required is true. It names the paid-route dependency on get_agent_wallet for funding. It doesn't explicitly say 'use send_bank_payment for bank transfers,' but the platform-specific framing makes the intended use obvious.

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

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

With no annotations to lean on, the description fully carries behavioral disclosure. It states that no account is created, that Privy creates it in the human's browser, that ownership belongs to the human rather than the agent, that the endpoint is rate limited per IP, and that the status poll holds the connection open until completion. This is exceptionally transparent for an unannotated tool.

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

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

The description is front-loaded with purpose and organized into clear paragraphs covering behavior, workflow, and rate limits. It is slightly redundant in the first two sentences both describing the signup start, but every sentence otherwise earns its place and the structure aids comprehension.

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

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

Given no output schema and no annotations, this description is unusually complete: it covers purpose, auth requirements, side effects, return value, the exact handoff action, the follow-up polling tool, and the rate limit. An agent has everything needed to invoke it correctly and understand the unexpected non-creation behavior.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add new parameter-level detail about label or agent_name beyond what the schema already provides, though the mention of the returned lasoak_ API key subtly reinforces label's purpose.

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

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

The opening line 'Start a signup for a human with no Laso account' states a specific verb, resource, and target user, and the description immediately clarifies what the tool is not: 'This does **not** create the account.' It is clearly distinguishable from siblings like get_signup_status, which it explicitly references as the polling follow-up.

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 concrete when-to-use context: a human with no Laso account, and explicitly says 'Requires no authentication, because the caller has no account.' It also lays out a precise workflow: hand over the claim_url verbatim, do not open it yourself, then poll GET /signup-status, with a cross-reference to message_for_human for uncertain wording.

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 a useful behavioral detail: if the partner rejects as incomplete, the reply indicates what is missing rather than failing opaquely. This goes beyond a generic 'submit' action. However, with no annotations provided, the description carries the full burden for disclosure, and it doesn't mention side effects, idempotency, auth requirements, or what happens on success. It covers one aspect of error handling but leaves other behaviors undisclosed.

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: a one-line summary, a single behavioral sentence, and a trailing 'Free.' No fluff or repetition. The key information is front-loaded in the first sentence. It earns its keep with minimal 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?

Given the tool performs a mutation (submission) with no output schema, the description should clarify what the agent can expect on success (e.g., a confirmation, status change) and any prerequisites (e.g., application must be complete, prior steps). It also omits whether this is a one-time action or if it can be called multiple times. The 'Free.' note is ambiguous and doesn't clarify behavioral context. The description is adequate for the error case but incomplete for the overall operation.

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

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

The schema documents the single parameter auth_token with a clear description ('Laso credential. Only if the MCP connection has no Authorization header.'), so coverage is 100%. The tool description adds no additional meaning about how to use this parameter, so it meets the baseline without adding extra value.

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

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

The description clearly states a specific action: submitting the completed application for review. It distinguishes from siblings like update_banking_application_details and upload_banking_document by its focus on final submission. However, it doesn't explicitly name the resource (e.g., banking application) beyond the tool name, so it's clear but not fully explicit.

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

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

There is no mention of when to use this tool versus alternatives like update_banking_application_details or get_banking_application. It implies submission after completion but doesn't state prerequisites, sequencing, or cases where another tool would be more appropriate. The description offers no exclusions or alternative routing.

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

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

With no annotations, the description must carry behavioral disclosure. It states the tool 'submits' (mutation) and that calls 'merge' – useful context. However, it does not disclose side effects such as whether questions become marked answered, how invalid answers are handled, or what response is returned. The 'Free.' note is ambiguous and adds no behavioral clarity.

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 purpose. However, the 'Free.' line is cryptic and appears to add no value, which prevents a perfect score. Otherwise, it is efficient and free of redundancy.

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

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

For a tool with only two parameters (one nested) and no output schema, the description is adequate. It explains what 'details' contains and references the source tool. It does not mention error handling or response format, but those are not essential for this simple submission tool given the schema's clarity.

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 comments. The 'details' parameter description explicitly ties it to field names from getBankingApplication, adding meaning beyond the bare parameter name. The auth_token is also explained. This exceeds the baseline of 3 for full coverage.

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

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

The description clearly states it submits answers to non-identity application questions sourced from getBankingApplication. This distinguishes it from siblings like submit_banking_application (which likely submits the whole application) and get_banking_application (which reads questions). The verb 'submits' and resource are explicit.

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

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

It provides practical guidance: 'Call as many times as needed; each call merges.' This tells the agent it can be invoked multiple times and that calls combine rather than overwrite. It references the source tool for context, but does not explicitly contrast with alternatives like submit_banking_application, which would make it a 5.

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

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

With no annotations provided, the description carries the full burden and does substantial work: it discloses that the operation is a mutation limited to one field, that bank details are immutable at the partner, and that the operation is free of charge. The 'Free.' note adds a cost-related behavioral trait an agent would not otherwise know, though it stops short of describing the response shape or immediacy of the change.

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: a one-line headline, a clarifying restatement, the key constraint, and a one-word cost disclosure. Every sentence earns its place and nothing is wasted.

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

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

For a simple 3-parameter tool with no output schema and no nested objects, the description covers purpose, scope, the only editable field, the alternative procedure, and cost, while the schema documents all parameters at 100%. The only minor gaps are not naming the sibling delete/create tools explicitly and not stating what the response contains.

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 fully documents nickname (including the empty-string-clears behavior), destinationId, and the conditional auth_token. The description's 'Sets or clears' reinforces the nickname semantics but adds only marginal meaning beyond the schema, which is the baseline-3 situation.

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 pair ('Rename a destination') and immediately clarifies the exact operation ('Sets or clears a destination's nickname'). It differentiates from siblings by stating that the nickname is the only editable field, which is a meaningful distinction from delete/create banking tools.

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

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

The description gives explicit when-to-use guidance (renaming/setting/clearing a nickname) and explicit when-not-to-use guidance ('anything else wrong means deleting the recipient and creating a new one'). This clearly routes the agent to the delete+create alternative instead of attempting edits this tool cannot perform.

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

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

With no annotations, the description must carry behavioral disclosure. It discloses that archiving hides the entry and keeps history, and that it is reversible. However, it does not mention potential side effects of renaming (e.g., impact on history), does not describe what the response looks like (no output schema), and does not note any permission or rate-limit requirements beyond the auth_token parameter already in the schema. Some gaps remain.

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