Wagyu

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

Annotations already flag non-idempotent, non-read-only, open-world behavior; the description adds real value by spelling out the retry hazard ('another call creates another order') and the duplicate-order consequence, plus the mutation is durable. It stops short of covering auth/permission needs or timeout handling details.

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

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

Three short sentences, action and return information front-loaded, and the two safety caveats placed at the end where they read as warnings. 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 correctly covers the return values (deposit address and exact amount). Combined with the retry and confirmation guidance and fully documented parameters, an agent has what it needs, though prerequisites like quote retrieval are not addressed.

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 each parameter carries a description (including the native-token and non-atomic-amount nuances), so the schema does the heavy lifting. The description only echoes `amount` and `fromToken` by name without adding syntax or format 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 ('Create a durable order that spends `amount` of fromToken') and even summarizes the return ('deposit address and exact amount to send'), which separates it from get_quote and get_swap. It does not explicitly name those siblings, so it falls just short of 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?

Gives two concrete operating rules: 'Confirm with the user first' and 'Never retry after a timeout or error.' That is well above implied usage, though it omits the natural prerequisite of obtaining a quote via get_quote before creating the order.

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 safety profile is covered. The description adds genuine context beyond that: a quote is an estimate and not a funding instruction, and it discloses the default behavior of the side parameter. No rate-limit or freshness caveats are given.

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

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

Three short sentences, front-loaded with the core purpose, then the parameter nuance, then the critical caveat. Every sentence earns its place 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 7-parameter read tool with 86% schema coverage and annotations covering the safety profile, the description supplies the one behavior that matters most (estimate vs instruction) plus the side semantics. It stops short of describing what a quote returns (amounts, route, fees), which would help since no output schema exists.

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 86%, so most parameters are self-documenting, giving a baseline of 3. The description goes beyond the schema by explaining side semantics, which the schema leaves as a bare enum: "from" (default) quotes spending amount, "to" quotes receiving amount.

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

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

The description opens with a specific verb+resource ("Estimate a swap") and immediately clarifies the estimation nature of the operation. It implicitly distinguishes itself from create_swap and get_swap by stating it is not a funding instruction, though it never names those siblings.

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

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

It tells the agent what the tool is for (estimating) and what it is not for (funding), which is a useful when/when-not split. It does not explicitly route to create_swap for execution or explain ordering within a quote-then-swap workflow, so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety and side-effect profile. The description adds the atomic-amount and scale-field convention, which is useful behavioral context about the response data. It does not contradict annotations, but it fails to note anything about error behavior, freshness, or authentication beyond what annotations imply.

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 only two short fragments and lacks a clear subject-verb structure ('Current status and customerState of an order'). While brief, it is under-specified rather than concise, and the amount/scale note is tacked on without 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?

With no output schema, the description should explain the return shape and pagination or error behavior, but it only mentions two fields and an amount convention. It omits the relationship to create_swap, the meaning of customerState, and any indication of what happens if the order does not exist. For a read tool returning swap state, this is incomplete.

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 50%: sessionId is documented in the schema as coming from create_swap, while orderId is not described anywhere. The description adds no parameter-level detail, so it neither compensates for the gap nor adds meaning beyond the schema. Baseline 3 applies given partial schema coverage.

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

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

The description states the tool returns order status and customerState, which is somewhat specific, and the title 'Read a swap order' anchors the resource. However, the phrasing is fragmentary ('Current status and customerState of an order') and does not distinguish this tool from siblings like create_swap or get_quote beyond the implicit read-only nature.

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 alternatives such as get_quote or create_swap. The description does not state prerequisites (e.g., that a swap must have been created first) or exclude any scenarios, leaving the agent to infer usage 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 readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered without the description. The description adds some behavioral context by implying a dynamic, up-to-the-moment dataset and by scoping the return content to source/destination ids and featured tokens, but it says nothing about caching, rate limits, or refresh 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?

A single front-loaded sentence with no filler, though it is a noun-phrase fragment rather than a full statement of what the tool does. Every clause earns its place by listing the three things returned.

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

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

For a zero-parameter read-only listing tool with no output schema, the description gives the agent enough to know what comes back: available chains, their source/destination eligibility, and featured tokens. Only a little more on data currency or pagination would make it fully self-sufficient.

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 there is nothing for the description to disambiguate, so the baseline is 4. The description correctly does not invent parameters and instead spends its words on the response shape.

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+resource (list chains) and goes further by stating what the result contains: chain ids usable as source or destination plus featured tokens. It does not name any sibling, but the swap/quote/token siblings are self-evidently different operations, so differentiation is implicit 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 explicit when-to-use statement, no prerequisite, and no alternative named. The phrase 'available right now' hints at freshness but does not tell an agent when to call this versus get_quote or search_tokens, leaving usage 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 this as a read-only, idempotent, non-destructive, open-world operation. The description adds the useful detail that it returns token address and decimals, but it does not cover authentication, rate limits, pagination, or chain-specific 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 a single, front-loaded sentence with no filler. It is appropriately sized for a search tool and immediately communicates the action and search surface.

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 describe the returned fields (address and decimals). However, it omits pagination behavior, chain scoping, and the role of the required direction parameter, leaving meaningful gaps for a five-parameter search tool.

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

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

The description only restates the query semantics already documented in the schema (symbol, name, or address). It does not explain the required direction parameter nor the chainId, limit, or offset parameters, leaving 40% of parameters without descriptive support.

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: find a token address and decimals. It clearly explains what is searched by symbol, name, or address, but does not explicitly differentiate this tool from siblings like list_chains or get_quote.

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 when a token address or decimals is needed and the identifier is a symbol, name, or address. However, it offers no explicit when-to-use guidance, no exclusions, and no alternatives among the sibling 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=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: the destination is immutable once saved, and saving does not trigger a transfer. It still omits whether the write can be rolled back or what happens on a second call with a different address.

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

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

Two sentences, no filler, and the gating condition is front-loaded before the effect. Every clause carries information an agent needs before calling.

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 3-parameter write tool with no output schema and low schema coverage, the description covers the trigger and immutability but leaves the parameters and the post-call outcome unexplained. It is minimally 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?

Schema coverage is only 33% (just sessionId documented as 'returned by create_swap'), and the description adds nothing about any parameter. orderId and refundAddress are undocumented in both places, and for a refund address the agent has no hint about expected format, chain compatibility, or length constraints beyond the schema's maxLength.

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 verb+resource are clear from the title and the second sentence ('Saves one immutable destination'), and the note that it 'does not start a transfer by itself' distinguishes it from create_swap. It stops short of plainly naming the resource (refund address) in the body text, relying on the title for that.

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 opening sentence gives an explicit, machine-checkable precondition: use only when get_swap returns customerState { kind: 'action_required', action: 'refund_address' }. It also implicitly excludes the transfer flow by stating it does not start a transfer, so the agent knows exactly when to reach for it versus create_swap.

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