Rozo Checkout

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

Annotations already declare non-read-only, non-idempotent, open-world, non-destructive, but the description adds substantial behavioral detail beyond them: no keys held, nothing sent by the server, orders expire at no cost if unfunded, exact amount/chain/token must be matched before expiresAt, and price locks are bounded by quoteExpiresAt. It also documents hard limits ($3500 per native invoice, $1 minimum for native ETH) and fee/spread composition.

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

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

Front-loaded with purpose and return contents, and most sentences carry actionable constraints (expiry, exact amount, caps, ZEC exclusion). It is dense and somewhat overpacked — the FX spread and price-lock recital in the native-coin paragraph is longer than an agent needs to invoke the tool correctly.

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

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

There is no output schema, and the description fully compensates by enumerating the return payload: deposit address or Lightning invoice, exact amount in token units and base units, required memo, expiry, rozoPaymentId, and quoteExpiresAt for native coins. An agent has everything needed to call it and interpret the result.

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

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

Schema coverage is 100%, so a baseline of 3 applies, but the description adds real meaning about how chainId and tokenSymbol interact — native coin vs stablecoin behavior, exact-out semantics, and chain-specific native symbols. It does not add anything about the url or email parameters beyond what the schema already documents.

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 ('Creates a one-time deposit order; you pay from your own wallet') and adds the key scope distinction that the server holds no keys and sends nothing. It does not explicitly differentiate itself from sibling order-creating tools such as stellar_wallet_create_order or from its prerequisite quote_invoice, so differentiation is only partial.

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

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

Gives clear operational context and several exclusions: native coins are only offered when quote_invoice lists them, ZEC on Zcash is unavailable here and must go to the external checkout, and unfunded orders simply expire at no cost. What's missing is an explicit statement of the typical call sequence (e.g., quote_invoice first, then this tool) and when to prefer a sibling instead.

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

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

Beyond the readOnlyHint/idempotentHint/openWorldHint annotations, the description adds substantive traits: fees never assumed and always taken from the quote, the receiving address signing exactly one transaction only when new or lacking a trustline, the shared deposit address across four chains, and the 1:1 USDC/USDT rule. These are genuine behavioral disclosures not present in 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 purpose is front-loaded, but the definition then runs long and mixes in flow mechanics that belong to sibling tools (signing, deposit.amountPolicy handling, payBefore timing). For a zero-parameter capability query, several sentences drift beyond this tool's own scope.

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 does important work by enumerating what the response contains — onboarding flag, source chains/assets, Stellar USDC output, usdGas XLM amounts, per-order limits. That covers the return shape well enough for an agent to consume it.

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

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

The tool takes zero parameters and schema coverage is 100%, so the baseline is 4. The description's references to deposit.amountPolicy and usdGas options describe returned content rather than inputs, so no compensation is needed.

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

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

The description clearly states the tool returns current ROZO Funding API capabilities (onboarding status, source chains, USDC assets, gas options, limits) — a specific resource with an implied discovery verb. It does not, however, explicitly differentiate itself from the sibling supported_coins, whose remit overlaps with the chain/asset listing here.

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: 'Read-only, creates nothing' suggests this is the discovery step before create_deposit_order or stellar_wallet_quote, but no when-to-use/when-not or explicit alternative is named. An agent must infer that this precedes the ordering 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the trailing 'Read-only' is largely redundant. However, the description adds genuine behavioral value by disclosing what the check reports (deposit arrival, bridging/payout progress, Coinbase invoice settlement), 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?

One front-loaded sentence carrying the verb, key and return scope, followed by a two-word safety note. Efficient overall, though 'Read-only' repeats what the annotations already say and could be dropped.

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?

Since there is no output schema, the description usefully enumerates the status facets an agent will receive. It does not cover failure modes (unknown/invalid ID, pending vs. failed states) or whether repeated polling is expected, which leaves minor gaps for a status-check 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?

With 100% schema description coverage on the single parameter, the schema already documents rozoPaymentId fully, including its origin from create_deposit_order. The description names the parameter but adds no format, length, 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?

Specific verb (Check) plus resource (Rozo order) and the exact lookup key (rozoPaymentId). It also enumerates the three things it reports on, so the agent knows precisely what the tool answers, which is distinguishable from create_deposit_order and quote_invoice.

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

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

The description implies this is the follow-up check after an order exists, but it never states when to call it versus siblings or whether it should be polled. The link to create_deposit_order appears only in the schema's parameter description, not in the tool description 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 cover readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is largely provided. The description still adds value by disclosing returned fields (merchant, callerPays, expiry, payability, supportedSources) and the constraint that native coins are only valid when listed in supportedSources, plus an explicit 'creates nothing and moves no funds' statement.

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

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

Purpose and return values are front-loaded, and the routing rule plus the create_deposit_order distinction each earn their place. The middle enumeration of returned fields is slightly dense, but there is no filler.

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

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

With no output schema, the description carries the burden of describing return values and does so explicitly. Combined with the annotations and full schema coverage, an agent has everything needed to call this tool correctly and interpret its output.

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

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

Schema coverage is 100% and the url parameter is fully documented there with examples and maxLength, so the schema does the heavy lifting. The description adds only 'takes the link URL', which restates the schema without new format or edge-case detail — 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 (quoting a Coinbase invoice / payment link) and enumerates precisely what it answers: charges, payability, and payable coins. It also names the sibling create_deposit_order as the source of exact per-coin amounts, so an agent can distinguish the two without opening either schema.

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

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

Clear context for use (inspect a payment link before paying) and an explicit hand-off to create_deposit_order for the exact amount to send. It also encodes a routing rule — offer a native coin only when it appears in supportedSources. No explicit 'when not to use' exclusion is stated, so it falls just short of 5.

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

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

Beyond the annotations (idempotent, non-destructive), it discloses the retry/idempotency model (server derives upstream order id and Idempotency-Key from quoteId+orderId), that no funds move, that unpaid orders expire at no cost, that fees come only from the quote, and that the receiving Stellar address signs one transaction only when new or lacking a USDC trustline. This is unusually rich operational context.

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

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

Purpose is front-loaded in the first sentence and almost every clause carries operational weight (idempotency, expiry, fees, amountPolicy, signing). It is nonetheless a dense wall of text where a short bulleted structure would aid scanning, so it is efficient but not optimally 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 mutation tool with no output schema it covers the full lifecycle: returned handles (fundingId, deposit address, suggested amount, amountPolicy min/max, payBefore, accepted chains/tokens), idempotent retry, expiry, fee sourcing, and the exact-amount vs any_amount policy. Nothing an agent needs to call it correctly appears missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: orderId only needs to be unique among the caller's own orders because the server derives the upstream id and Idempotency-Key from quoteId+orderId, and planDigest must come from the same quote. That is genuine semantics the schema does not carry.

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 states a specific verb and resource plus scope: 'Turn an approved quote into a payable order,' and later clarifies 'Creates an order but moves no funds.' It names the upstream sibling (stellar_wallet_quote) by tying quoteId/planDigest to it, but never explicitly contrasts itself with the closely related create_deposit_order sibling, so differentiation is implied 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?

It establishes clear preconditions (an approved quote, planDigest from the same quote) and operating rules: pay once before payBefore, and retry with the same quoteId+orderId to get the same order. It stops short of explicit when-not-to-use guidance versus alternatives like create_deposit_order or the quote tool 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 are sparse in the ways that matter (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description carries the rest: side effects on upstream state (creates the account, adds the trustline, claims USDC, delivers XLM), retry/supersede semantics across calls, the 5-minute expiry, and the security posture ('This server never sees your key', 'do not echo fundingId into logs'). It never contradicts the declared 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 opening sentence is well front-loaded, but the remainder is a single dense paragraph of roughly 300 words mixing operation allowlists, fee arithmetic, cryptographic verification steps, and logging policy. Nearly all of it is relevant, yet the absence of structure makes the critical 'allowed operations / refuse otherwise' rule hard to extract on a fast read.

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

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

No output schema exists, and the description compensates fully by enumerating the returned fields (signingRequestId, unsigned XDR, networkPassphrase, operations list, expiresAt) and pointing to Horizon for claimable-balance amounts. Failure modes and the follow-up call are covered, so an agent has everything needed to call it correctly.

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

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

Schema coverage is 100% for both parameters (fundingId, walletAddress), so the schema already documents them. The description only lightly touches fundingId in a logging instruction and never expands on the walletAddress format beyond the schema's 'G...' note. Baseline 3 applies when the schema does the heavy lifting.

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

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

Specific verb+resource ('build the one transaction the receiving address must sign') plus the exact trigger condition ('When an order shows sign_stellar_onboarding') and the full operation set the transaction contains. It names its downstream sibling (stellar_wallet_submit_signed) and the data source (funding_capabilities rozoAccounts), so an agent can distinguish it from stellar_wallet_create_order or stellar_wallet_order_status 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?

Explicit when-to-use ('when an order shows sign_stellar_onboarding'), explicit sequence (check operations, decode XDR, then call stellar_wallet_submit_signed), explicit refusal criteria ('Any other operation type or source: refuse'), and explicit recovery behavior ('Expired, or submit failed: just call this tool again'). No alternatives or exclusions are left 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 read-only/idempotent/non-destructive, but the description adds real behavioral context beyond them: the ~15s polling cadence, the meaning of pendingActions values, and the fact that completion requires every leg to be confirmed. That is substantive disclosure no structured field carries.

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

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

Front-loads the core action and payload, then adds polling guidance in the same breath. Dense and mostly waste-free, though the enumerated field list makes it slightly long for a one-parameter read.

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 enumerates the return shape (status, pendingActions, deposit, per-leg status/amount/tx hash) and the completion criterion. Complete enough to act on; the only gap is that leg status values themselves aren't enumerated.

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

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

Schema coverage is 100% and the single fundingId is already documented as coming from stellar_wallet_create_order, which the description essentially repeats. No extra syntax, format, or edge-case guidance is added, so the schema does all 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?

Specific verb+resource ('Read a funding order by fundingId') immediately followed by the returned payload. An agent can distinguish this read-only status check from stellar_wallet_create_order 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?

Gives operational guidance ('Poll about every 15 seconds') and a completion condition ('completed only when every leg is confirmed'), plus an interpretation hint for 'sign_stellar_onboarding'. It stops short of naming an alternative tool or stating when not to use it.

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

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

Annotations cover safety (readOnlyHint, destructiveHint false), but the description adds rich behavioral context: ~10-minute validity, no deposit address or reservation, signing requirement triggers, server never holds keys, fee handling, and deposit amountPolicy. This is well beyond what annotations provide.

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

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

Dense but front-loaded, starting with purpose and returns. Some repetition (the signing condition and chain list appear twice), which keeps it from 5; still, every sentence carries operational detail needed without an output 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?

Given cross-chain quote complexity and no output schema, the description must convey return values and next steps; it does (quoteId, planDigest, amounts, fees, totals, signature need) plus validity, payment policy, and key custody. 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 coverage is 100%, so baseline is 3. The description adds meaning beyond the schema for usdGas ('0', '0.5', '1' behaviors), amountUsd limits, shared deposit address across chains, and the receiving address's signing role, meriting a 4.

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

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

States a specific verb ('Price sending') and resource (USDC/USDT from Base, Ethereum, Arbitrum or Polygon to USDC on Stellar). It routes to sibling stellar_wallet_create_order by noting quoteId and planDigest are needed there, distinguishing its role as the quote step.

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

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

Provides clear context: the quote is needed by stellar_wallet_create_order and limits come from funding_capabilities. It does not explicitly say when not to use it or compare with quote_invoice, so it stops short of full alternative routing.

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

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

Annotations already declare idempotentHint=true, so the restatement of idempotency is partly redundant. However the description adds genuinely new behavior: 'submitted' is not delivery and requires polling, plus the two named failure strings and the recovery path for each. That is real context not present in annotations or schema.

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

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

Front-loaded with the action, then constraints, then the follow-up flow — good ordering with no filler. Slightly dense as a single run-on block, and the 'This is the claim' sentence is the weakest, most expendable line.

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

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

For a two-parameter submission tool with no output schema, the description covers the essential async contract (submission != delivery), the polling follow-up, the error-string recovery path, and idempotency on retry. Nothing an agent needs to invoke it correctly and react to results 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 both parameters (signedXdr, signingRequestId) are already documented, including 'NOT a secret key'. The description reinforces the signedXdr constraint but adds no syntax, format, or size guidance beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (submit) and resource (the signed XDR for a signing request), and contrasts with the sibling tools it hands off to (stellar_wallet_order_status, stellar_wallet_get_signing_request). An agent can tell this is the final on-chain broadcast step without opening the schema. The one weak sentence ('This is the claim: the account, trustline, USDC and XLM land in that one transaction') is vague but does not obscure the purpose.

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

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

Explicitly routes the agent: poll stellar_wallet_order_status until completed, and on template_expired or failed re-call stellar_wallet_get_signing_request and sign the new XDR. It also states the input boundary (signed envelope only, never a secret key). Nothing about when-to-use or what to do next is left 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 cover readOnly/idempotent/openWorld=false, but the description adds substantive behavior beyond them: no network call, no payment link required, native coins are exact-out with a price that only holds until quoteExpiresAt, a $3500 per-invoice cap and $1 minimum for native ETH on Ethereum. It also discloses the ZEC non-support and redirect, which prevents a whole class of wrong calls.

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 answer is front-loaded in the first clause, which is good. However, a large middle block on native exact-out pricing, FX spread, quoteExpiresAt and per-invoice caps describes ordering behavior that belongs to create_deposit_order/quote_invoice rather than a static coin list, which bloats an otherwise simple lookup 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 parameters and no output schema, the description correctly supplies the coverage and acceptance rules an agent needs before calling. The return value is only summarized in one line ('chain id, token symbol and token decimals'), leaving the actual response shape underspecified, but the usage and limitation coverage are otherwise strong.

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; nothing in the schema can be contradicted or clarified. The description goes slightly beyond by naming what comes back (chain id, token symbol, token decimals), though it does not describe the response's shape or ordering since no output schema exists.

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 — answering which cryptocurrencies and chains can pay an OpenRouter credit top-up or Coinbase payment link through Rozo Checkout — and enumerates the concrete chains/tokens covered. It is immediately distinguishable from siblings like quote_invoice (invoice-specific acceptance) and create_deposit_order (order creation).

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

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

It explicitly says this is a static list that 'needs no payment link and makes no network call,' and names the alternative: 'quote_invoice reports which of these a specific invoice accepts.' It also gives a when-not: ZEC is not available here and callers should be sent to an external URL. That is explicit routing plus an exclusion.

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