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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds only that the created account is returned, but given non-idempotency it should warn that repeated calls may create duplicate accounts, and it says nothing about auth/permission requirements.

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

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

Two short sentences plus a compact parameter note; the core action and scope are front-loaded and nothing is 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?

This is an open-world, non-idempotent mutation with an opaque nested payload and no output schema. The description covers the gist and gives payload hints, but omits required-field expectations, validation/error behavior, and tenant-vs-customer scope, which an agent needs to invoke it safely.

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 `body` parameter is typed only as an unconstrained object (`additionalProperties: {}`), so the schema itself conveys no field structure. The description compensates by enumerating example fields (pix_key, bank_name, holder name/document, account details), which is genuinely additive, though it stops short of stating which fields are required or the PIX-vs-TED branching.

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 ('Register a PIX/TED bank account for the tenant'), which is clear on its own. However, it does not distinguish this tenant-level tool from the very similar sibling `ashar_create_customer_bank_account`, leaving the agent to infer scope from the name alone.

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

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

There is no explicit guidance on when to use this versus `ashar_create_customer_bank_account` or when a bank account must already exist before a payout/transfer. Usage is only implied by the word 'Register'.

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

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

Annotations already disclose readOnly=false, destructive=false, openWorld=true and idempotent=false, so the safety profile is covered. The description adds only 'Returns the created customer'. It misses the behavior that matters most given idempotentHint=false: that retrying on a timeout can create duplicate customer records, and what a duplicate email or invalid tax_id does. Adequate but thin for a write tool that hits an external KYC provider.

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

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

The purpose sentence is front-loaded and wastes nothing. The following Args block restates all eight schema properties and their descriptions, which is largely redundant given 100% schema coverage, so a meaningful share of the text earns no additional 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 create-mutation with no output schema, the description covers the required/optional split and states that the created customer is returned, which is the key return-value fact. Remaining gaps are error/duplicate behavior and the individual-vs-business field dependency, which are real but secondary for correct invocation.

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

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

Schema description coverage is 100%, so baseline is 3. The description does add value with examples the schema lacks ('light' for kyc_type, 'BR' for country, CPF/CNPJ for tax_id) and marks which fields are optional. However, it labels the pass-through parameter 'additional fields' while the schema property is named 'extra', and does not clarify whether first_name/last_name become effectively required when type='individual'.

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 plus the domain purpose: 'Create a customer (individual or business) for KYC/KYB.' That clearly separates it from ashar_update_customer, ashar_get_customer and ashar_list_customers. It never names those siblings, so differentiation is implied by the verb rather than stated.

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 create versus update a customer, no prerequisites (credentials, KYC tier availability per country), and no note that this is the gating step before the customer wallet/bank-account/offramp tools can be used. The only context is the phrase 'for KYC/KYB', which hints at purpose but not at selection or sequencing.

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 performs its role by confirming the tool is an addition/creation operation ('Add a bank account'). However, since the annotations provide critical operational hints (`readOnlyHint: false`), the description adds no significant new behavioral traits (like error handling or rate limiting) beyond these hints.

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

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

The definition is extremely concise, stating the action and necessary arguments in just two sentences without any wasted words, and follows a direct functional structure.

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?

While it provides all necessary input parameters, the description is incomplete regarding the output. Since there is no output schema, the agent relies solely on the implicit promise of the verb 'Returns the created bank account,' which is a minimal level of completeness for a mutation 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?

Given that schema description coverage is 100%, the input parameters are well-documented in the schema itself. The description merely re-iterates the standard names 'customer id' and 'bank account payload,' providing no added semantic value beyond the structured data.

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 defines the action as adding/creating a bank account for a customer. While the tool name is highly specific, it doesn't explicitly differentiate its scope from related tools like 'create bank account' sibling tools, making the purpose clear but not maximally precise.

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 zero guidance on when this tool should be used relative to other existing banking or customer tools (e.g., should this be used when `ashar_create_bank_account` exists?). It offers no contextual usage scenarios.

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

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

Annotations already state that this is a non-read-only, open-world, non-idempotent, non-destructive creation operation. The description adds little beyond that: it does not warn that duplicate calls may create multiple wallets, nor does it describe permissions, side effects, or failure 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 short and front-loaded with the action. However, the Args section largely duplicates the input schema, which already has full parameter descriptions, so it is not maximally economical.

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 four-parameter creation tool with full schema coverage and annotations, the description is adequate for invocation. It still leaves important context gaps around sibling selection, idempotency behavior, and customer/network prerequisites.

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

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

Schema description coverage is 100%, so all parameters are already documented in the input schema. The description repeats the same meanings and notes that external_id is optional, but adds no further semantics such as expected network formats or external_id constraints.

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

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

The description gives a specific verb and resource: create a custodial wallet for a customer. It is clear what the tool does, but it does not distinguish this from close siblings like ashar_create_customer_wallet, ashar_create_wallet, or ashar_create_customer_offramp_wallet.

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 versus the other customer-wallet creation tools. It also omits prerequisites such as whether the customer must already exist or what network values are acceptable.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the description's only added behavior is 'Returns the created offramp wallet'. It says nothing about duplicate handling on retry (non-idempotent), what networks are accepted, or whether the call fails if the bank account is missing.

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

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

Front-loaded one-sentence purpose followed by a short Args list and a return line. The Args block duplicates the schema and costs some space, but nothing is bloated or buried.

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

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

For a mutating, non-idempotent, open-world creation call with no output schema, the description tells the agent almost nothing about the created resource (no id/status fields, no error conditions, no network constraints). It is minimally callable 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 baseline is 3. The Arg block merely restates the schema types ('customer_id (string): the customer id') without adding format, source, or constraint information (e.g. valid network values or where external_id surfaces).

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: 'Create an offramp wallet' scoped to 'a customer's bank account'. That bank-account linkage distinguishes it somewhat from create_customer_wallet / create_customer_custodial_wallet, but the description never names those siblings or explains the difference 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?

No indication of when to use this versus ashar_create_customer_wallet, ashar_create_customer_custodial_wallet, or ashar_create_wallet, and no preconditions such as whether the bank account must already exist or be verified before an offramp wallet can be created.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the description adds little beyond confirming that a virtual account is returned — useful since no output schema exists. It never explains what the payload must contain, whether the call hits an external provider with rate limits or async settlement, or what happens on duplicate requests despite idempotentHint=false.

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 prose is short and front-loaded, but the Args block duplicates the schema verbatim without adding information, so a third of the text earns no place. The first sentence and the return sentence are the valuable parts.

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 non-idempotent creation call with an opaque nested payload and no output schema, the description leaves the single most important question unanswered: what goes in body. It should also mention required customer state or external provider interaction; the return-value hint is the one complete piece.

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 nominally 100%, but the schema descriptions merely restate the property names ('Customer id', 'Virtual account payload'), and the description does exactly the same. The 'body' parameter is a nested object with additionalProperties {} and receives no field-level explanation anywhere, so the agent has no idea what keys to supply for a create operation.

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 ('Create a virtual account for a customer'), which is distinguishable from sibling resources such as wallets, custodial wallets, and off-ramp wallets. It does not explicitly name the related siblings (ashar_list_customer_virtual_accounts, ashar_create_customer_wallet) to sharpen the boundary, so a 4 rather than a 5.

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

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

There is no guidance on when to use this tool, what prerequisites are needed (e.g. the customer must exist and be verified), or which sibling to use for listing or deleting virtual accounts. The agent must infer the entire usage context from the name alone.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the safety bar is lower. The description only adds 'Returns the created wallet'; it says nothing about non-idempotency risk (retries may duplicate wallets) or any validation/permission behavior, which would be genuinely useful for a create operation.

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

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

The opening sentence is front-loaded and tight, but the following Args block is pure duplication of the input schema and earns no place. The 'Returns the created wallet' line is a useful closer, but the middle section wastes space.

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

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

For a non-idempotent creation tool with an untyped nested payload and no output schema, the description is too thin: it leaves the caller guessing what to put in `body` and what a duplicate-call would do. The one sentence about the return value is the only real added context.

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

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

Schema coverage is 100%, so the baseline is 3, but the description's Args block merely restates the schema text verbatim ('the customer id' / 'the blockchain wallet payload') and adds zero meaning. Critically, `body` is an opaque nested object with additionalProperties: {} — the description is the only place the required payload fields (chain, address, label, etc.) could be explained, and it omits them entirely.

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 ('Add a blockchain wallet to a customer'), which is clear enough to invoke. However, it does not distinguish itself from closely related siblings such as ashar_create_wallet, ashar_create_customer_custodial_wallet, or ashar_create_customer_offramp_wallet — a distinction that matters a lot in this API.

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

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

There is no guidance on when to use this tool versus the custodial-wallet or offramp-wallet creation siblings, or what prerequisites exist (e.g., does the customer need to exist first?). The agent must infer everything from the name alone.

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

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

Annotations already declare non-readOnly, non-idempotent, open-world, non-destructive, so the safety profile is covered. The description adds that the created object is returned, which matters given no output schema, but says nothing about validation behavior, duplicate-name handling, or whether fees are later mutable.

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

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

Purpose is front-loaded in one sentence, which is good, but the Args block re-lists all six parameters already fully documented in the schema. Only the percentage-unit example and the return statement carry information not already in structured fields.

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

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

With no output schema, "Returns the created partner fee" is a placeholder rather than a description of the return shape, and there is no mention of tenant scoping or how virtual_account_set constrains applicability. Adequate for invocation, thin for understanding consequences.

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, and the description earns an extra point by clarifying the unit convention for percentage fees ("0.5 for 0.5%"), which the schema does not state and which is the most likely source of an incorrect call.

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

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

States a specific verb and resource: "Create a partner fee schedule for the tenant." An agent can tell this is the creation counterpart to get_partner_fee/list_partner_fees/delete_partner_fee, though the description never names those siblings 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?

There is no guidance on when to use this versus get_partner_fee, list_partner_fees, or delete_partner_fee, nor on prerequisites or whether an existing schedule with the same name is allowed. The agent must infer everything about selection context.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, and the description usefully reinforces this by framing the call as a pre-step to ashar_execute_payin (funds move at execution, not here). It also discloses that quotes expire ('expires_at') and that the platform fee is folded in, but it does not address auth/credential requirements or rate limits. Note the mild tension between 'Create' and readOnlyHint=true; the quote is ephemeral, so this reads as preview rather than a true contradiction.

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

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

Front-loaded summary sentence, then compact Args and Returns blocks — easy to scan and nothing is padded. The Args list duplicates the schema verbatim, which is a small waste, but it does not hurt usability.

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

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

With no output schema, the description compensates by naming the return fields (quote_id, request_amount, estimated_receive, fx_rate, expires_at, platform_fee). Combined with the sequencing hint this is nearly complete; the only real gap is that the optional destination-wallet parameters are left unexplained in combination.

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 Args block is largely a restatement of the schema. It does add a little meaning ('what the client receives' for token, 'to safely retry' for idempotency_key), but never explains how wallet_id and blockchain_wallet_id interact or whether one is required — the one genuinely ambiguous pairing.

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

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

States a specific verb+resource+flow: 'Create a deposit (PIX -> USDC/USDT) quote', plus what is baked in (platform fee markup). The payin direction is unambiguous, though it never explicitly contrasts itself with the sibling quote tools (ashar_create_payout_quote, ashar_create_transfer_quote) beyond the name.

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 final line 'Use before ashar_execute_payin' gives clear lifecycle context and an explicit next step. There are no when-not conditions or mention of when to prefer a payout/transfer quote instead, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with that: it produces a quote only, and actual movement is deferred to ashar_execute_payout. Beyond annotations it adds genuinely useful behavior: the quote carries a platform fee markup, has an expires_at (so quotes go stale), and supports an optional idempotency key. It does not mention rate limits or any balance/permission preconditions, which keeps it below a 5.

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

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

It is front-loaded: the core action and the fee-markup caveat come first, then parameters, then the return shape, then the sequencing instruction. The Args block duplicates the schema almost verbatim, which is some wasted space, but the size stays proportionate to a 5-parameter tool.

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

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

With no output schema, the description helpfully enumerates the return fields (quote_id, request_amount, estimated_receive_brl, fx_rate, expires_at, platform_fee) and flags expiry, which an agent needs in order to use the quote in time. What remains unstated is what an agent should do on expiry or how idempotency_key affects replays, but nothing critical to making a correct call is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented in structured form, and the description's Args block largely restates that (cents, >=500, default 'polygon'). The one added constraint — the amount is expressed in stablecoin cents — is already in the schema example, so there is no semantic value beyond the structured fields. Baseline 3 applies.

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

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

The first sentence names a specific verb (create), a specific resource (payout/withdrawal quote), and the exact direction and rails involved (USDC/USDT -> PIX), including that the platform fee markup is baked in. This is enough to separate it from siblings like ashar_create_payin_quote, ashar_create_transfer_quote and ashar_get_fx_rate without opening any schema.

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

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

The final line, 'Use before ashar_execute_payout,' explicitly names the downstream tool and establishes the required call order, which is the key routing decision for an agent. It stops short of stating when-not-to-use conditions (e.g. insufficient balance, KYC, or tenant prerequisites), so it is clear context rather than full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=false, openWorldHint=true, so the safety profile is covered. The description does add value by disclosing the return payload (quote_id, estimated_receive, fx_rate, expires_at, platform_fee) and implicitly flagging that quotes expire, but it never explains the expiry window, cost model, or why 'create' is non-destructive — which an agent might need since the verb suggests a mutation.

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 one-line purpose is well front-loaded, but the bulk of the body is a bulleted restatement of the input schema, which duplicates structured data the agent already receives. Roughly half the text does not earn its place beyond what the schema and annotations provide.

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?

Because there is no output schema, the description's return-value summary is genuinely useful and covers the result shape. However, for an 8-parameter, 6-required cross-chain tool it omits prerequisites, the quote lifecycle/expiry semantics, and how it relates to the payin/payout quote and execute_transfer tools, leaving meaningful gaps.

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

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

Schema coverage is 100%, so all eight parameters are already documented with enums and a default in the schema. The Args list largely restates those same definitions ('amount in cents', "'USDC' or 'USDT'") without adding syntax, unit nuance, or the interaction between request_amount and amount_reference. Baseline 3 is appropriate when the schema carries the weight.

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 ('Create a crypto -> crypto (cross-chain) transfer quote') and scopes it to the tenant, which distinguishes it conceptually from create_payin_quote and create_payout_quote. It stops short of naming those siblings explicitly, so an agent must infer the routing rule.

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

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

There is no statement of when to use this versus create_payin_quote, create_payout_quote, or ashar_execute_transfer, and no prerequisites (wallet balance, funded source wallet) are mentioned. The only implied usage is that a quote precedes an execution, which the reader has to supply.

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

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

Annotations already declare the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true). The description adds the meaningful custody detail ('custodial', i.e., tenant-held keys) and that the created object is returned, but says nothing about key custody implications, whether repeated calls create duplicate wallets, or network-specific constraints.

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

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

The opening sentence is front-loaded and efficient, but the Args block is pure duplication of the input schema and occupies most of the text. Roughly half the description 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 mutation tool with no output schema, the description notes the created wallet is returned but not what it contains (id, address, network, status), which an agent needs to chain subsequent calls. Annotations cover the safety profile, leaving this mostly adequate but with a real gap.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description's Args block restates them (network, name, optional external_id) without adding format, constraints, or supported-network values, so it adds no 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?

States a specific verb and resource ('Create a new custodial wallet') plus scope ('for the tenant'), which implicitly separates it from the many customer-scoped create-wallet siblings. It does not explicitly name or contrast with those siblings (create_customer_wallet, create_customer_custodial_wallet), so it stops short of full differentiation.

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

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

The 'for the tenant' phrase implies this is the tenant-level variant rather than the customer-level wallet creators in the sibling list, but there is no explicit when-to-use guidance, no prerequisites (e.g., credentials, network support), and no stated alternatives.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is largely covered. The description adds the concrete return payload ({ deleted: true }), which is useful since no output schema exists, but it omits any warning about irreversibility or what happens to linked transfers/customers.

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 tightly written components: a one-line action statement and a compact Args/Returns block. Nothing is wasted, and the action is front-loaded.

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

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

For a simple one-parameter deletion, the description covers the argument and return value, which is adequate. However, it does not clarify whether deleting a nonexistent account errors or silently succeeds (despite the idempotentHint annotation), nor does it mention permission requirements for a destructive operation.

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

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

Schema description coverage is 100%, and the schema already documents bank_account_id. The description's 'the account id' restates the same information without adding format, origin, or validation details. Baseline 3 is appropriate because the schema carries the parameter documentation.

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 (remove a PIX/TED bank account) and names the expected outcome. However, it does not distinguish this tool from the sibling ashar_delete_customer_bank_account, leaving ambiguity about which account type is targeted.

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

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

There is no explicit guidance on when to use this tool versus ashar_delete_customer_bank_account or ashar_list_bank_accounts. The only usage signal is the verb 'remove', which is implied rather than explained.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description's addition of 'Returns 204 No Content on success' is genuinely useful since no output schema exists, but it omits what is actually destroyed (child wallets, bank accounts, virtual accounts) and whether the deletion is reversible — the most important context for a destructive call.

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

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

The core sentence and return behavior are front-loaded with no filler. The Args block duplicates the schema verbatim, which is mild waste but not harmful.

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?

Return semantics for success are covered, which compensates for the missing output schema. However, for a destructive, open-world deletion the description should mention failure modes (unknown id) and the fate of dependent resources; an agent cannot judge the blast radius from what is written.

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% for the single customer_id parameter, and the description only restates 'the customer id'. Baseline 3 is right; no added meaning such as format, prefix, or where to obtain the 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?

States a specific verb and resource ('Delete a customer') and the identifier used, which separates it from siblings like ashar_delete_customer_wallet or ashar_delete_bank_account by resource scope. It does not explicitly contrast itself with ashar_update_customer or the other customer delete variants, but the name plus description are 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?

No guidance on when to use this versus ashar_update_customer, nor any preconditions (must the customer be empty of wallets, bank accounts, virtual accounts?). A line like 'fails if the customer still has active wallets/transfers' would be needed for a 4.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds one useful behavioral fact beyond that: 'Returns 204 No Content on success.' It does not address reversibility, error conditions, or whether the account is merely unlinked, which would be valuable for a destructive operation.

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

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

The purpose sentence is front-loaded and the whole text is short. However, the Args section duplicates information already fully documented in the schema, which is low-value filler rather than earned content.

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

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

For a simple two-parameter delete with full schema coverage and rich annotations, the description supplies the essential purpose plus the success status code, which is what an agent needs since there is no output schema. Only the ambiguity versus sibling delete tools is unaddressed.

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

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

Schema description coverage is 100%, and the Args block merely restates the schema's field descriptions ('Customer id', 'Bank account id') verbatim in spirit. No additional format, provenance, or validation meaning is added, so the baseline 3 applies.

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

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

The definition states a specific verb and resource ('Remove a customer's bank account'), which is distinguishable from most siblings. It does not explicitly contrast with the similarly named ashar_delete_bank_account or ashar_delete_customer_wallet, so sibling differentiation is only implied by the 'customer' qualifier.

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

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

There is no guidance on when to use this tool versus the closely related ashar_delete_bank_account or ashar_delete_customer_wallet, nor any mention of unlink-vs-delete semantics or prerequisites. The agent must infer usage entirely from the 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds the concrete success signal ('Returns 204 No Content'), which is genuinely useful given there is no output schema, but it says nothing about irreversibility, what happens to residual balance, or required permissions.

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

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

The purpose statement and return value are front-loaded and the whole text is very short. The Arg list is redundant with the schema, but it costs little and does not bury the key information.

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

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

For a destructive, no-output-schema mutation, the description covers the happy-path return code but omits failure modes (wallet not found, wallet with balance, authorization errors) and the consequences of deletion. Adequate to call it, but thin given the risk profile; the destructive annotation carries much of the burden.

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 both parameters are already documented in the schema. The Args block merely restates customer_id and wallet_id verbatim, adding no format, ownership, or validation semantics (e.g., whether the customer id must match the wallet's owner). Baseline 3 applies.

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

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

The first sentence gives a specific verb ('Remove') and a precise resource ('customer's custodial wallet'), which separates it from the sibling ashar_delete_customer_wallet and ashar_delete_bank_account. It does not explicitly name an alternative, but the entity naming is distinctive enough that an agent can route on it.

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

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

The description never states when to use this tool versus ashar_delete_customer_wallet or the other delete siblings, nor any preconditions (e.g., wallet must be empty, funds must be swept) or exclusions. The only implied usage is from the name itself.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds the success response ('204 No Content'), which is useful beyond annotations, but says nothing about irreversibility, cascading effects, or whether the wallet must be empty first.

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

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

Front-loaded with the action in one sentence, followed by a compact args list and return note. The args list duplicates the schema, a minor redundancy, but nothing is wasted or 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?

For a destructive, two-parameter deletion tool with full annotations and a documented 204 response, the essentials are present. However, it omits preconditions and side effects (funds, linked wallets), which matter most for a destructive operation, leaving a clear gap.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description merely restates them as 'the customer id' and 'the blockchain wallet id' without adding format, source, or lookup guidance, so the baseline of 3 applies.

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

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

States a specific verb ('Remove') and resource ('customer's blockchain wallet'), which is more precise than a generic delete. It does not explicitly distinguish itself from close siblings such as ashar_delete_customer_custodial_wallet or ashar_delete_customer_bank_account, but the resource noun is specific enough to route correctly.

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

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

There is no statement of when to use this tool versus alternatives (e.g., custodial vs. blockchain wallet deletion), nor any prerequisites such as wallet balance being zero or required permissions. The agent must infer usage entirely from the 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds useful behavioral detail by stating the success response is 204 No Content, though it does not mention permission requirements or not-found 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 short and front-loaded: it states the action first, then the argument, then the success response. Every line adds some useful information with no filler.

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

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

For a simple one-parameter destructive delete, the description covers the action, the required id, and the success response, while annotations cover safety traits. It could be richer about failure or permission behavior, but it is complete enough to call correctly.

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

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

Schema description coverage is 100%, and the single fee_id parameter is already documented in the schema. The description repeats that fee_id is "the partner fee id" without adding format, validation, or sourcing guidance beyond the schema.

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

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

States a specific verb ("Remove") and resource ("a partner fee schedule") plus the identifier used ("by id"). This clearly distinguishes it from sibling tools like ashar_get_partner_fee, ashar_list_partner_fees, and ashar_create_partner_fee.

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 deletion by id but gives no explicit when-to-use guidance, no conditions distinguishing it from get/list/create partner fee siblings, and no note about checking existence first. An agent must infer the use case entirely from the verb and resource.

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

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

Annotations already declare destructiveHint, idempotentHint and openWorldHint, so safety is covered. The description adds real value by disclosing the post-deletion fallback behavior and the admin permission requirement, though it says nothing about irreversibility or error 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?

Two short sentences plus a compact Args/Returns block, with the core action and the ADMIN warning front-loaded. No wasted prose.

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

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

With no output schema, the description supplies the return shape ({ status: 'deleted', count }), the permission level, and the fallback consequence. An agent has everything needed to invoke and interpret the result.

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

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

Schema coverage is 100% and there is only one parameter, whose meaning (tenant_id) is repeated rather than enriched. Baseline 3 is appropriate since the schema already does the work.

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

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

States a specific verb and resource ("Remove the upstream credentials of a tenant") plus an important scope detail (falls back to the global credential) and an ADMIN qualifier. It is clearly distinguishable from siblings like ashar_get_tenant_credentials and ashar_rotate_tenant_credentials.

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?

Signals the ADMIN gating and explains the resulting state (fallback to global credential), which gives an agent clear context for when this is the right call. It doesn't explicitly contrast against rotate_tenant_credentials or state when not to use it, so not a full 5.

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

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

Annotations already declare the mutation/retry profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description builds on rather than repeats them: it explains that idempotency_key exists to 'safely retry without double-charging' and that the client must pay the returned PIX to complete the deposit. Auth requirements and quote-expiry behavior are not covered, but the financial-consequence context is a genuine addition.

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

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

Front-loaded with the verb and resource, then the prerequisite, return values, and the final clarifying sentence about who pays the PIX — all useful. The Args block partially duplicates schema descriptions, which is the only wasted surface, but the whole definition stays short.

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

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

With no output schema, the description correctly enumerates the return fields (payin_id, status, and the PIX payload components including pix_copiacola, pix_qrcode_base64, expires_at), and it names the required upstream call. For a money-moving mutation it could add more on quote expiry or duplicate-execution errors, but an agent has enough 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 baseline is 3; the description earns a bump by adding meaning the schema lacks — the idempotency key is framed in terms of double-charge protection, not just as an 'optional idempotency key'. The payin_quote_id semantics are only restated from the schema, so the gain is modest.

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 ('Execute a PIX deposit') and ties it to a prerequisite artifact ('a previously created payin quote'), which cleanly separates it from ashar_create_payin_quote (prepares the quote) and ashar_get_payin (reads status). An agent can place it in the payin lifecycle without opening another schema.

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

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

The prerequisite is explicit: it must be called with a quote id from ashar_create_payin_quote, which tells the agent when this tool is applicable and which sibling precedes it. It does not state failure modes (expired quote, already-executed quote) or when to re-execute vs. re-fetch, so it stops short of full when/when-not guidance.

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

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

Although annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, the description adds useful behavioral context: crypto is debited from the sender wallet, signed_transaction is required for solana/stellar networks, and idempotency_key prevents double-spending on retries. It does not disclose authorization, quote-expiry, or rate-limit behavior, but it meaningfully supplements the annotations.

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

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

The description is front-loaded with purpose and then structured with Args and Returns sections, making it easy to scan. However, the full parameter list repeats schema information that is already 100% covered, so some of the content does not fully earn its place.

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

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

With no output schema, the description usefully says it returns payout_id and status, and it explains the quote prerequisite, required sender wallet, and network-specific signing requirement. It is complete enough to call correctly, though it could mention quote-expiry or authorization constraints for a high-stakes withdrawal operation.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters and their meanings. The description restates the same parameters with modest added context, such as the crypto-to-PIX flow and network-specific signed-transaction requirement, but does not add enough beyond the schema to raise 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 uses a specific verb and resource ('Execute a USDC/USDT -> PIX withdrawal') and ties it to a previously created payout quote. It clearly distinguishes this execution step from quote creation and from other payout read/list operations, so an agent can identify the tool's role without opening the schema.

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

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

The description gives clear usage context by stating that execution requires a quote from ashar_create_payout_quote and by identifying the required quote_id and sender_wallet_id. It does not explicitly say when not to use this tool versus execute_transfer or execute_payin, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: that a quote is generated and executed atomically (no separate confirmation step) and what the call returns (transfer_id, status, tx_hash, amounts) — valuable given there is no output schema. It stops short of flagging irreversibility of an on-chain send or how fees are applied.

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

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

The first sentence and the Returns line are well front-loaded and earn their place. The seven-line Args block, however, duplicates a schema that is already fully described, adding length without adding meaning.

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-stakes financial mutation with 6 required parameters, the description covers inputs and return fields but omits how the quote/fee is determined, whether request_amount is inclusive of fees, minimum amounts, or whether the sender token must match the destination token's network constraints. Adequate to invoke, not adequate to invoke confidently.

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 three parameters carry enums, so the schema already documents every field including the network and token lists. The Args block largely restates the schema; the only marginal additions are labeling request_amount as cents and idempotency_key as optional, both of which the schema also states.

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 ('Transfer stablecoins from a BlindPay wallet to an external address') and the parenthetical clarifies that quote creation and execution happen in one call, which implicitly separates it from ashar_create_transfer_quote. It does not explicitly name that sibling, so the differentiation is inferred rather than stated.

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 scope ('BlindPay wallet to an external address', crypto-to-crypto per the title) implies when to use it, but there is no explicit when/when-not guidance, no mention of prerequisites such as wallet balance or funding, and no named alternative for the quote-then-execute path.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only "Returns the customer details" — it says nothing about behavior when the id is unknown (error vs. empty), authentication/tenant scoping, or the shape of the returned object.

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

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

The core sentence is front-loaded and the whole description is three short lines. The Args section is largely redundant with the schema, which is minor waste but not 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?

For a simple single-parameter read with full annotation coverage and no output schema, the essentials are present. Still, an agent gets no information about error behavior or what fields the customer details contain, so it is adequate rather than 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?

With a single parameter at 100% schema description coverage, the schema already documents customer_id fully. The Args block merely restates the schema field, adding no format, source, or example detail beyond 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?

States a specific verb and resource ("Get a customer by id"), which distinguishes it from list-oriented siblings like ashar_list_customers and from sub-resource getters like ashar_get_customer_custodial_wallet. It never explicitly names those alternatives, but the resource boundary 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?

No when-to-use guidance, no prerequisites, and no mention of the sibling tools (list_customers, update_customer, get_customer_custodial_wallet) that an agent must choose between. The only implicit signal is that a customer id is required.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the agent knows this is a safe repeatable read. The description adds only the vague phrase "Returns the curated wallet," which hints at a filtered view but never explains what 'curated' means or what happens if the wallet does not exist. Minimal added value over the annotations, but no contradiction.

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

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

The purpose line is front-loaded and there is no filler prose. The Args block duplicates what the schema already provides, which is mild waste, but the overall definition is short 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?

There is no output schema, so the description carries the burden of explaining what is returned, and "the curated wallet" is not informative about the response shape or fields. For a simple two-ID lookup the requirements are modest, but the return value remains underspecified.

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

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

Schema coverage is 100%, so both parameters are already fully documented. The Args block restates the schema descriptions verbatim (customer id / custodial wallet id) and adds no format, provenance, or constraint detail, so the baseline 3 applies.

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

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

States a specific verb+resource combination ("Get a single custodial wallet") with the two identifiers used to locate it. This differentiates it implicitly from the list and balance siblings, though it never names them. An agent can tell it fetches one wallet rather than enumerating wallets.

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

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

Usage is only implied: use it when you already have both a customer id and a wallet id. There is no explicit guidance on when to prefer this over ashar_list_customer_custodial_wallets or ashar_get_customer_custodial_wallet_balance, and no preconditions or failure cases are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the return shape (available/total/pending/token), which is genuinely useful since there is no output schema. However, it does not explain the 'sanitized' qualifier or what openWorldHint implies about external dependencies.

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

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

Front-loaded with the purpose in the first sentence, followed by args and returns. The Args block largely duplicates schema content, which is minor waste, but the description is short and well ordered.

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

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

With no output schema, the description's mention of available/total/pending/token balances fills the main gap. A reader knows what they get back and what to supply; only error/permission behavior and the meaning of 'sanitized' remain unspecified.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description's Args section merely restates the param names and short descriptions, adding no format, source, or lookup guidance. Baseline 3 applies.

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

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

States a specific verb plus resource ('Get the balance of a customer's custodial wallet'), which is narrower than the generic sibling ashar_get_wallet_balance and clearly distinct from the list_* tools. It stops short of explicitly naming which sibling to use instead, but the scope 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?

No statement of when to call this versus ashar_get_wallet_balance or ashar_get_customer_custodial_wallet, and no prerequisites (e.g., whether the wallet must already exist or be provisioned). The agent must infer routing from the name alone.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds only 'Returns the curated offramp wallet' — an undefined qualifier ('curated') that gives no real behavioral detail such as error cases when the wallet is not found or whether all three ids must form a consistent chain.

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

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

The purpose sentence is front-loaded and short. The Args block is a near-verbatim duplication of the schema, which adds length without adding meaning, but the overall size remains small.

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-resource getter with full annotation coverage this is close to adequate, but with no output schema the phrase 'returns the curated offramp wallet' leaves the actual return shape unspecified, and there is no mention of failure 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 description coverage is 100%, so the baseline is 3. The description merely restates the same one-line labels as the schema (customer id, bank account id, offramp wallet id) without explaining their relationship or scoping semantics.

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

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

States a specific verb and resource ('Get a single offramp wallet by id'), which distinguishes it from the list sibling as a single-resource fetch. It does not, however, name the closest alternative (ashar_list_customer_offramp_wallets) or clarify why customer_id and bank_account_id are required to fetch one wallet.

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

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

There is no guidance on when to use this versus the list tool or the other customer wallet getters (custodial wallet, wallet balance). The only implied usage comes from 'by id', which the agent must infer.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds value beyond them by stating there are no arguments and enumerating the returned fields and their breakdown structure, which the annotations do not convey.

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

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

Two short sentences, zero waste. What the tool returns and its scope are front-loaded, and the no-argument note follows immediately.

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

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

With no output schema, the description compensates by naming the return fields (count, volume_brl, platform_fee_brl) and the payin/payout/daily-total breakdown. Minor gap: 'today' is undefined with respect to timezone, which matters for a day-boundary metric.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly and explicitly confirms 'No arguments,' removing any ambiguity for an agent that might otherwise hunt for a tenant or date parameter.

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

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

States a specific verb and resource ('Get today's volume and platform fees') with clear scope: tenant-level, across payins and payouts, for today. 'Today's' implicitly separates it from ashar_get_monthly_stats, but the description never names that sibling, so differentiation is left to inference.

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

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

Usage is only implied by the word 'today's' – an agent can guess this is the daily snapshot versus the monthly one, but the description never says when to prefer this over ashar_get_monthly_stats or whether it is the right tool for a specific date range. No exclusions are stated.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description earns credit on top by stating there are no arguments and enumerating the payload (payin/payout/transfer spreads and fixed fees, user_markup, daily/monthly volume limits in BRL), which the agent would otherwise have to infer since there is no output 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?

Two short paragraphs, front-loaded with the purpose, then the no-argument note and the return contents. Nothing extraneous, though the blank-line break and the short 'No arguments.' sentence could have been folded into the first line without loss.

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

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

For a zero-parameter read tool with no output schema but rich annotations, this is complete: the agent knows the call takes no inputs, what categories of data come back, and that limits are denominated in BRL. Nothing needed 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?

With zero parameters, the baseline is 4, and the description explicitly confirms 'No arguments,' preventing an agent from speculating about optional filters. There is no meaningful parameter detail it could add beyond this.

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 platform fee rates and limits applied to the tenant' — and adds the tenant scoping that distinguishes it from global/partner fee tools. It stops short of naming siblings like ashar_get_partner_fee or ashar_get_user_markup as alternatives, so the differentiation is implicit rather than explicit.

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

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

Usage is implied: an agent reads this when it needs the tenant's fee schedule or limits. There is no explicit when-to-use statement, no exclusion of alternatives such as ashar_get_partner_fee, and no mention that this tool is the authoritative source for current pricing before building a quote.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, and the description adds meaningful confirmation ('without creating a quote' = no side effects) plus the shape of the result (base rate vs. rate after markup, plus fee) in the absence of an output schema. It doesn't disclose auth requirements, markup source (user markup vs. tenant default), or rate staleness/expiry, but it adds real value beyond the annotations.

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

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

The first sentence is front-loaded and carries the whole selection rationale; the Args block is compact and mostly earns its place by decoding direction/currency_type. Some waste in repeating enum values already declared in the schema.

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

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

With no output schema and five parameters, the description supplies the return fields (base_rate, client_rate, platform_fee) and the enum semantics an agent needs. Remaining gaps are modest: nothing on error cases for invalid currency pairs (e.g. USDC -> USDT) or whether direction is required to get a meaningful rate.

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 semantics the schema lacks: 'payin (BRL -> crypto) or payout (crypto -> BRL)' explains the direction enum's meaning, and 'currency_type: who the rate applies to' clarifies an otherwise opaque field. Minor redundancy in restating the from/to enums keeps it below 5.

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

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

States a specific verb and resource ('Consult a quick FX rate') plus the key scope qualifier '(with platform markup) without creating a quote', which separates it from the quote-creation siblings (ashar_create_payin_quote, ashar_create_payout_quote). An agent can pick this tool over those without opening either schema.

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

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

The phrase 'without creating a quote' gives a clear selection rule: use this for a preview/estimate rather than a binding quote. It stops short of naming the alternatives explicitly (create_payin_quote, get_fee_rates, get_partner_fee) or stating when this is insufficient, so it's clear context without exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine context beyond that: the aggregation window is the current month (not arbitrary), the scope is tenant-wide across both payins and payouts, and the metric set is count/volume_brl/platform_fee_brl.

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

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

Two short sentences: the scope and metrics come first, the return shape second. No filler, no restatement of the title, and the 'No arguments' note prevents wasted schema exploration.

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

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

With no output schema, the description correctly compensates by describing the returned fields and their payin/payout + total breakdown. Minor omissions remain — currency semantics of volume_brl, whether the month is calendar or rolling, and timezone — but nothing blocking.

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

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

The tool takes zero parameters, so there is nothing to disambiguate; the description still confirms 'No arguments,' which aligns with the empty schema. Baseline for a no-parameter tool 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?

Names a specific verb and resource ('Get the current month's volume and platform fees') and scopes it to the tenant across payins and payouts. It does not distinguish itself from the sibling ashar_get_daily_stats or ashar_get_fee_rates, which is the only thing keeping it from 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?

'Get the current month's...' implies usage (monthly aggregation rather than a date range), but there is no explicit statement about when to prefer this over ashar_get_daily_stats. The agent must infer the choice from the tool names alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds only that it returns a 'sanitized' schedule, which hints at redaction but never explains what sanitization removes, so added value is modest.

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?

Very short and front-loaded, with the core action in the first sentence and arguments delegated to a compact list. The 'Returns the sanitized fee schedule' line is slightly redundant with the opening but still useful context.

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

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

For a single-parameter read tool with full annotation coverage this is nearly sufficient, but 'sanitized' is unexplained and there is no output schema to clarify what the returned schedule contains. An agent knows how to call it but not exactly what it gets back.

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

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

Schema description coverage is 100% and the single fee_id parameter is documented in both schema and the Args section. The description merely restates 'the partner fee id' with no format, source, or validation detail beyond the schema, so a baseline 3 applies.

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

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

States a specific verb and resource ('Get a single partner fee schedule by id'), which distinguishes it from sibling ashar_list_partner_fees and the create/delete variants. It doesn't explicitly name the alternatives, but the singular-by-id framing makes the distinction inferable.

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 on when to use this versus ashar_list_partner_fees (to discover ids) or when a fee schedule might be absent. The 'by id' phrasing implies a retrieval use case but offers no explicit context or exclusions.

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

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

The annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds useful context beyond annotations by noting that it returns live status and queries BlindPay when possible, plus the fee record.

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 action before listing the parameter and return behavior. The Args section duplicates schema information, but overall it remains efficiently 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 simple one-parameter lookup tool, the description covers purpose, the required id, and a high-level return summary including live status and fee record. Given the rich annotations and complete input schema, this is largely sufficient, though return details are not fully described.

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

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

The input schema has 100% description coverage for the single payin_id parameter. The description repeats that it is the deposit id but adds no format, source, or lookup 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: getting details of a single deposit by payin_id. It implicitly distinguishes from list_payins by specifying a single deposit, but does not explicitly name the sibling 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?

Usage is implied by 'by its payin_id' and 'single deposit,' suggesting it is used when a specific deposit id is known. However, it does not explicitly state when to use this tool versus list_payins or other payin-related tools.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real value on top: it discloses that status is fetched live by querying BlindPay when possible, implying latency and possible staleness, and that the response also includes the fee record. That is genuine behavioral context beyond the structured hints.

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

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

Two short sentences, front-loaded with the core action, plus a compact Args block. The Args section duplicates the schema and is mildly redundant, but nothing is bloated or buried.

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

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

With no output schema, the description usefully pre-announces what comes back — live status plus a fee record — so an agent knows the shape of the result. For a single-parameter read tool this is close to complete; only the empty/not-found case is unaddressed.

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

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

There is exactly one parameter and schema description coverage is 100%, so the schema already documents payout_id fully. The Args block merely restates 'the withdrawal id' with no added format, source, or lookup guidance, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource ('Get details of a single withdrawal') and scopes it to one record via 'payout_id', which clearly separates it from ashar_list_payouts and ashar_execute_payout. It stops short of naming siblings explicitly, so it lands just below the top mark.

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

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

Usage is implied: call this when you already have a payout_id and need that single record. There is no explicit statement of when not to use it or which sibling to prefer (e.g. list_payouts for browsing, execute_payout for creating), leaving routing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real value by flagging that this is an ADMIN operation and that the upstream API key is never exposed (masking behavior). It stops short of stating failure modes or whether an empty result is returned when no credentials 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?

Front-loaded with the purpose and the ADMIN/masking caveats, followed by tight Args and Returns blocks. The tenant_id arg line duplicates the schema verbatim and is the only wasted element; the return-field list earns its place since no output schema exists.

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

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

With one parameter and no output schema, the description supplies the return field list (instance_id, api_key_prefix, receiver_id, is_active), which the structured data does not provide. Missing only edge-case behavior for tenants without credentials.

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 a single parameter at 100% schema description coverage, so the schema already carries its meaning. The description's "tenant_id (string): the tenant id" is a restatement rather than added semantics (no format, prefix, or lookup hint). Baseline 3 applies.

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

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

States a specific verb and resource — list the masked upstream credential metadata for a tenant — which is clearly distinct from the write-side siblings (rotate_tenant_credentials, delete_tenant_credentials). It does not explicitly name those siblings as alternatives, so the differentiation is inferable rather than spelled out.

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?

"ADMIN operation" signals the required privilege level and implies usage context, but the description never says when to reach for this instead of rotate_tenant_credentials or delete_tenant_credentials, nor what to do if the tenant has no credentials. Usage is implied, not guided.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, covering the safety profile. The description adds value by disclosing the return shape ('live status plus on-chain tx_hash when available'), but says nothing about error behavior for missing/invalid ids or eventual consistency of status.

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

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

Two short sentences with the core purpose front-loaded, plus a compact note on return contents. The Args block duplicates the schema and is redundant, costing a bit of tightness but not readability.

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

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

With no output schema, the description appropriately discloses what is returned (live status and tx_hash). For a one-parameter read tool with full annotation coverage this is close to complete; minor gaps are error semantics and any status-field enumeration.

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 single transfer_id parameter is already documented. The description's 'Args' block merely restates the schema, adding no format hints (e.g., id shape or example) or semantics beyond what's structured. Baseline 3 applies.

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

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

States a specific verb and resource ('Get details of a single crypto transfer by its transfer_id'), and the word 'single' implicitly contrasts with the sibling ashar_list_transfers. It doesn't name the sibling explicitly, so an agent must infer the distinction, which keeps it below 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?

Usage is only implied: fetching one transfer is obviously distinct from listing, but the description never says when to use this vs ashar_list_transfers or what happens if the id is unknown. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value beyond that: it discloses the ADMIN auth requirement and explains that this markup is configured locally because the upstream only sees the Ashar partner. That architectural context is not available from any structured field.

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

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

Front-loaded with the core action and the ADMIN flag, then a short explanatory paragraph, then Args/Returns. The Args line is mildly redundant against the schema but overall the structure is 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?

Though there is no output schema, the description compensates by naming the returned field and its components (payin_spread_percent, payout_spread_percent). Combined with the ADMIN and local-configuration context, an agent has what it needs to invoke and interpret the call.

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 a single required tenant_id, so the schema already carries the parameter meaning. The description's Args section merely restates it, adding no format or sourcing detail beyond the schema.

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

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

States a specific verb and resource ('Get the end-user markup ... for a tenant') and clarifies the domain concept (second spread layer on top of the Ashar margin). An agent can distinguish it from ashar_set_user_markup and ashar_get_partner_fee by the read-vs-write and markup-type distinction, though it never names those siblings 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?

Flags that this is an 'ADMIN operation', which implies a permission gate, but gives no explicit when-to-use/when-not guidance or pointers to alternative tools (e.g. set_user_markup for changing the value). Usage is implied rather than directed.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new information by naming the returned fields (available, total, pending, token), which is valuable given there is no output 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 purpose and return fields are front-loaded in one sentence. The Args block duplicates the schema verbatim and could be dropped, but total length is still small and the return-value detail 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 one-parameter read tool with no output schema, the description covers both input and the shape of the response, which is the key gap it needed to fill. Minor omissions remain (error behavior for an unknown wallet_id, currency/units of the balances).

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% for the single required parameter, so the baseline applies. The Args block merely restates 'wallet_id (string): the wallet id' without adding format, source, or lookup guidance.

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

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

States a specific verb and resource with scope ('balance of a single custodial wallet'), which is clearly distinct from list/create wallet siblings. It does not explicitly differentiate from the very similar ashar_get_customer_custodial_wallet_balance, leaving the agent to infer which entity each targets.

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

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

No when-to-use or when-not-to-use guidance; nothing tells the agent to prefer this over ashar_get_customer_custodial_wallet_balance or ashar_get_customer_custodial_wallet. Usage is only inferable from the name and the phrase 'single custodial wallet'.

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

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

Annotations already declare the safe, read-only, idempotent behavior. The description adds useful context by stating there are no arguments and naming the returned array fields (`id`, `bank_name`, `pix_key`, `status`), though it omits pagination or ordering 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 definition is two short sentences, front-loads the action and scope, and includes only useful output context. There is no wasted text.

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

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

For a zero-argument read tool with annotations covering safety, the description gives enough context to invoke it and interpret the basic return shape. It does not explain pagination or ordering, but the simple no-argument scope makes those minor omissions.

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

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

There are zero parameters, so the baseline is 4. The description's 'No arguments' is consistent with the empty input schema and confirms the tool requires no input.

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

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

The description states a specific verb and resource: listing the tenant's PIX/TED bank accounts. The tenant scope helps distinguish it from customer bank-account siblings, though it does not explicitly name `ashar_list_customer_bank_accounts`.

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

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

Usage is implied by 'List the tenant's PIX/TED bank accounts' and 'No arguments,' but the description gives no explicit when-to-use guidance or comparison to customer bank-account tools. An agent can infer the purpose but must resolve alternatives itself.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that it returns an array of bank_accounts, which is useful given there is no output schema, but it says nothing about permissions, pagination, or empty results. With annotations carrying the safety burden, a 3 fits.

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 purpose before the args and return lines. The 'Args:' block slightly duplicates the schema, but overall there is little wasted text and structure is 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 one-parameter read-only list tool with rich annotations and full schema coverage, the description covers what it lists and what shape the result takes. The only minor gaps are pagination and ordering behavior, which are not critical for this simple tool.

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

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

Schema description coverage is 100% for the single customer_id parameter, so the schema already documents it fully. The description's 'Args:' block merely restates the parameter name and type with no added semantics such as format, source, or validation rules, so it earns the baseline rather than more.

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

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

States a specific verb and resource scoped to a customer ('List a customer's bank accounts'), which distinguishes it from the broad sibling ashar_list_bank_accounts. It is clear what the tool returns, though it does not explicitly name the sibling it is contrasted with, so it stops short of a 5.

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

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

There is no guidance on when to use this tool versus ashar_list_bank_accounts or ashar_list_customer_virtual_accounts, and no prerequisites or exclusions are stated. The customer scoping is only implied by the noun phrase in the first sentence.

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 annotations already establish that this is a read-only, idempotent, non-destructive, open-world operation, so the main safety profile is covered. The description adds only that it returns an array of wallets, but it does not clarify the return shape, pagination, or how 'custodial' wallets differ from other wallet 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 definition is short and front-loaded with the core purpose. However, the phrasing 'custodial (wallet) wallets' is awkward and the closing 'Returns an array of curated wallets' appears imprecise, likely a typo for custodial, which slightly weakens 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 one-parameter read tool with annotations and no output schema, the description is minimally sufficient to invoke it. But given the crowded set of wallet-related siblings, it is incomplete because it does not explain what a custodial wallet is in this context or how this list differs from adjacent listing tools.

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% for the single customer_id parameter, and the schema already documents it. The description merely repeats 'customer_id (string): the customer id' without adding format, constraints, or lookup 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 gives a specific verb and resource: 'List a customer's custodial (wallet) wallets.' It is clear enough to identify the operation, but it does not distinguish this tool from close siblings such as ashar_list_customer_wallets or ashar_list_wallets, and the later phrase 'curated wallets' adds ambiguity rather than clarification.

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

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

The description provides no guidance on when to use this tool versus the many other wallet-listing tools. It only documents the required customer_id argument and does not mention exclusions, alternatives, or prerequisites.

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

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

Annotations already declare this read-only, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds domain meaning (what an offramp wallet is) and the required two-ID scoping, but says nothing about pagination, empty-result behavior, or whether wallets are filtered by bank account or customer.

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

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

Front-loaded with purpose, then the parameter block and return type in a few lines with no filler. The Args section largely duplicates the schema, which is the only small inefficiency.

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

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

For a two-param read with no output schema, the description covers purpose, inputs, and the return shape ('array of offramp_wallets'). It is nearly complete; the only gap is the absence of any note on pagination or result limits.

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 both parameters are already documented, and the description merely restates them as 'the customer id' and 'the bank account id'. It adds no format, source, or lookup guidance beyond the schema baseline.

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

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

States a specific verb and resource ('List a customer's offramp wallets') and adds a clarifying gloss that these are crypto settlement wallets tied to a bank account. It implicitly contrasts with the custodial-wallet siblings by naming the resource type, but never draws that distinction 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?

The scoping ('for a bank account') implies when to reach for this list rather than a generic wallet list, but the description gives no explicit when-to-use or when-not guidance. It does not route the agent to ashar_get_customer_offramp_wallet for a single record or distinguish this from ashar_list_customer_custodial_wallets.

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

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

Annotations provide strong behavioral context (readOnly, idempotent, etc.). The description adds valuable context by specifying the data types (KYC/KYB) and the operational scope (tenant's instance), enriching the understanding beyond the structured metadata.

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

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

The description is poorly structured for an AI agent because it explicitly lists every single parameter ('Args (all optional): ...') when the schema already contains this detailed information. This redundancy makes the definition verbose and less efficient.

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

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

Given the 100% schema coverage and rich annotations (readOnlyHint: true), the definition is highly complete. The description provides the necessary semantic context (KYC/KYB) that complements the technical details 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?

With schema description coverage at 100%, the baseline score is 3. The description is primarily repetitive, listing all the parameters again, but does not provide any unique semantic meaning or operational constraints not already present in the structured input 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 resource and action (List customers) and defines the scope (KYC/KYB on the tenant's instance), making it immediately clear what the tool achieves and how it differs from sibling tools like get_customer.

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?

By specifying that the customers are on 'the tenant's instance' and mentioning KYC/KYB status, the description implicitly defines the operational context for its use. While it doesn't explicitly compare it to every sibling, the scope provided is sufficient to guide usage.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds one useful beyond-schema fact — that the result is an array of virtual_accounts — but says nothing about behavior for an unknown customer_id, empty results, or pagination.

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

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

Front-loaded one-line purpose followed by a short arg note and return note; nothing is buried. The 'Args' line is largely redundant with a 100%-covered schema, which is the only real waste.

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

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

For a simple single-parameter read tool with no output schema, the description covers intent and the top-level return container. It does not say what fields a virtual_account contains or how errors surface, which matters since there is no output schema to fall back on.

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% for the single parameter, so the schema already documents customer_id. The description's 'customer_id (string): the customer id' is a near-restatement that adds no format, source, or lookup context; baseline 3 applies.

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

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

States a specific verb (List) and resource (virtual accounts) scoped to a customer, which separates it from ashar_list_customer_wallets and ashar_list_customer_bank_accounts by resource type. It stops short of naming those siblings explicitly, so an agent must infer the boundary from the noun alone.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the alternative list tools (wallets, bank accounts, custodial wallets) that an agent would choose between. Usage is only implied by the tool name and the 'customer_id' argument.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds that the result is an array of blockchain_wallets, which is modestly useful given there is no output schema, but it says nothing about pagination, empty results, or whether unknown customer_id errors.

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

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

The purpose is front-loaded in the first sentence and the whole definition is three short lines with no filler. The Args block duplicates the schema, which is minor redundancy rather than 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?

For a single-parameter read-only list tool with full annotation coverage, the description supplies purpose, the required input, and the return shape, which is enough to call it correctly. The only real gap is disambiguation from the custodial and offramp wallet 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?

There is a single parameter with 100% schema description coverage, and the description merely restates 'customer_id (string): the customer id' without adding format, sourcing, or retrieval guidance. Baseline 3 applies when the schema already documents the parameter.

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

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

It states a specific verb and resource ('List a customer's blockchain wallets'), but the sibling set contains ashar_list_customer_custodial_wallets and ashar_list_customer_offramp_wallets, and the description gives no basis for telling 'blockchain wallets' apart from those two. The purpose is understandable in isolation but ambiguous when several near-identical list tools exist.

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

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

There is no statement of when to use this tool versus the adjacent wallet-listing tools, and no prerequisites or exclusions. The agent must infer the choice entirely from sibling names.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context that it takes no arguments and returns a sanitized list of partner_fees, though it does not elaborate on pagination or what 'sanitized' removes.

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 short sentences and is front-loaded with the core purpose. Every sentence adds useful information: what is listed and that no arguments are required.

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, no-argument list tool with rich annotations and no output schema, the description is largely complete. The only minor gap is that 'sanitized list' is not explained, but the core behavior is clear enough for 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 tool has zero parameters, so the baseline is 4. The description reinforces this by stating 'No arguments,' which matches the empty input schema.

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

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

The description uses a specific verb and resource: it lists the tenant's partner fee schedules, and it clarifies that these are spread/fixed fees applied on payins and payouts. This distinguishes it from sibling operations such as get_partner_fee, create_partner_fee, and delete_partner_fee.

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 stating it lists partner fee schedules and takes no arguments, but it does not explicitly say when to use this tool versus ashar_get_partner_fee or ashar_get_fee_rates. There are no exclusions or routing hints to alternatives.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral detail: default page size 50, hard cap of 1000, offset-based pagination, newest-first ordering, and that the response includes a total count.

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?

One front-loaded sentence states purpose, scope, and ordering, followed by a compact Args block and a one-line return note. Nothing is redundant or 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?

For a three-optional-parameter list tool with no output schema, the description supplies filters, pagination mechanics, ordering, and the shape of the return (list plus total count). The only gap is whether the paginated response carries a cursor/next-page indicator beyond total count.

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

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

Schema coverage is 100%, so baseline is 3, but the description goes beyond the schema by enumerating representative status values ('processing', 'completed', 'pending', 'failed') in a schema that defines no enum, and by restating the default/max in the argument list.

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

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

The description names a specific verb and resource ('List deposit transactions for the tenant') and adds a meaningful ordering guarantee ('newest first'). The resource (payins) is clearly distinct from the neighboring payout/transfer listing tools, so an agent can select it without opening the schema.

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

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

Usage is implied: this is the paginated listing of payins, and the status filter hints at narrowing by lifecycle state. However, it never states when to prefer ashar_get_payin (single record lookup) or how it relates to ashar_list_payouts, so the agent must infer the boundary.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds material behavior not in annotations: the sort order (newest first) and that results are paginated with a total count. It stops short of noting rate limits or the cost of a large limit.

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 opening sentence is well front-loaded and zero-waste, but the following 'Args' block duplicates the schema field-for-field and does not earn its place. Trimming it would leave a stronger description.

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

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

With no output schema, the sentence 'Returns a paginated list with total count' usefully conveys the return shape, and sort order is given. However, the status filter has no enum and the description names no valid status values, leaving the one meaningful filter under-specified.

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

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

Schema description coverage is 100%, so all three parameters are documented by the schema itself. The 'Args' block merely restates limit/default/max and offset/default verbatim, adding no new semantics — the baseline 3 applies.

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

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

States a specific verb and resource ('List withdrawal transactions for the tenant') and adds scope/ordering ('newest first'). It does not explicitly distinguish itself from nearby siblings like ashar_list_transfers or ashar_get_payout, so an agent must infer the difference.

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 no when-to-use guidance, no alternatives, and no exclusions. The only contextual cue is 'for the tenant', which implies this is the tenant-wide listing rather than a per-customer one, but that is left implicit rather than stated.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds useful context: it is an ADMIN operation and returns sandbox_tenants with API key prefixes. It does not discuss pagination or whether API key prefixes are masked, but it adds meaningful behavioral detail beyond the annotations.

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

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

The description is short, front-loaded, and wastes no space. It states the resource, admin restriction, lack of arguments, and return content in three efficient sentences.

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

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

For a zero-argument read-only list tool with rich annotations, the description provides the key missing context: the admin requirement and the shape of the returned items. No output schema exists, so the return summary is especially useful.

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

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

There are no parameters, so the baseline is 4. The description explicitly confirms 'No arguments,' which aligns with the empty input 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 gives a clear verb and resource: list all provisioned sandbox tenants. It is easy to distinguish from general wallet/customer listing tools, but it does not explicitly differentiate itself from related siblings such as provision_test_tenant or get_tenant_credentials.

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

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

It states 'ADMIN operation,' which gives an important prerequisite, but it does not explain when to use this versus related tenant tools like provision_test_tenant or get_tenant_credentials. The usage is implied by the name and description rather than explicitly guided.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so the safety profile is covered. The description adds two genuinely useful behavioral details not in the annotations: results come back newest-first and the response is paginated with a total count. It stops short of describing the shape of an individual transfer or rate-limit 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 purpose and ordering are front-loaded in a single sentence, followed by a compact parameter list and return note. Slight redundancy between the Args block and the schema descriptions keeps it from being 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 small, fully optional-parameter read tool with no output schema, the description covers what it returns (a paginated list with total count) and the ordering. The only meaningful gap is the absent set of valid status values, which no enum supplies.

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 three parameters (status, limit, offset with defaults and max) are fully documented in structured data. The Args block restates the same facts (default 50, max 1000, default 0) without adding meaning such as valid status values or how status filtering interacts with pagination.

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 ("List crypto transfers for the tenant") plus a default ordering ("newest first"), so an agent knows exactly what it retrieves. It does not explicitly differentiate from the sibling ashar_get_transfer for a single transfer, but the list-vs-get distinction is largely self-evident from the name.

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

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

There is no statement about when to use this tool versus ashar_get_transfer or the other list endpoints, and no prerequisites or exclusions are mentioned. Usage is only inferred from the word "List".

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds value by enumerating the returned wallet fields, which matters because there is no output 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?

Two short sentences, front-loaded with the action and scope, with the return shape immediately after. Nothing is padded or redundant.

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

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

With no output schema, the inline field list substitutes adequately, and the annotations handle safety. Minor gap: no mention of whether balances are live, per-token, or whether the list can be long/paginated.

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

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

Zero parameters, so the baseline is 4; the description explicitly confirms 'No arguments', removing any doubt about required inputs.

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

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

States a specific verb and resource (list the tenant's custodial wallets) plus the salient payload attribute (balances). 'Tenant's' scopes it away from the many customer-scoped wallet siblings, though it never names them 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?

Usage is only implied — 'No arguments' signals an unfiltered tenant-wide listing. It does not say when to prefer this over ashar_list_customer_custodial_wallets or ashar_get_wallet_balance for a single balance.

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