Create Transfer Quote

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.