Liquid Agent

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

Annotations already declare readOnly=true, idempotent=true, non-destructive, so the safety profile is covered. The description adds real value beyond that: it confirms no signing/paying occurs, guarantees the recipient receives exactly `amount` at their own address, and describes the two-step GET-with-signature flow. It does not discuss rate limits or failure modes.

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

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

Four tight sentences, each earning its place: what is returned, how to pay it, the amount guarantee, and the scope disclaimer. Front-loaded with the return payload, 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?

Output schema exists so return shape need not be explained, yet the description still summarizes the key payload components helpfully. For a read-only preparation tool with a well-documented schema, nothing an agent needs 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by clarifying that `amount` is what the caller RECEIVES on the destination (not what they pay), which is a critical semantic distinction for a bridge tool. It mentions payTo and EIP-712 domain context without repeating schema text.

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 (prepare) and resource (bridge payment) and describes precisely what is returned: the x402 payment request fields (network, asset, payTo, amount, EIP-712 domain) plus the URL to call. This is clearly distinguishable from siblings like bridge_quote or bridge_routes.

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

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

Gives explicit usage context: pay it with your own x402 client, sign one EIP-3009 authorization, repeat the GET with the PAYMENT-SIGNATURE header. It also states the negative boundary ('This tool does not pay or sign anything'). It stops short of naming which sibling to use for quoting or route discovery first.

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 establish readOnly/idempotent/non-destructive, and the description adds meaningfully: it is free, requires no wallet or payment, and returns exact received amount, fee breakdown, and ETA. It does not repeat the safety traits, so it earns above baseline, though no caveats on route availability or staleness 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?

Two tight sentences with the key qualifier 'Free' front-loaded and no filler. Every clause (cost, output, fee breakdown, ETA, no wallet) conveys distinct 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?

With an output schema present, the description need not document return values, and the annotations cover the safety profile. It is complete enough to invoke correctly, missing only edge-case guidance such as behavior when a route is unavailable.

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 descriptions for all four parameters (including ref's 20% fee share and amount semantics), so the schema already carries the load. The description only reinforces the 'exactly amount received' semantics, which the schema already 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+resource (quote for bridging USDC between Base and Arc) and names the mechanism (Liquid Bridge). Distinguishes it from siblings like bridge_prepare_payment and bridge_routes by clarifying it is a read-only price check, not a payment or route listing.

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?

'Free. No payment, no wallet needed' makes clear this is the safe pre-flight step before committing to a payment, which implicitly routes the agent here before bridge_prepare_payment. It does not explicitly name alternatives or a when-not condition, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds that results are per-chain and describes the payout mechanism, which is genuine extra context, but it omits whether an address with no referrals returns empty, and does not address any auth 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?

Two compact sentences, front-loaded with the resource and its chain scope, then the earning mechanism. Every sentence carries information; the only minor waste is the bare 'Free.' lead-in.

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?

An output schema exists, so return values need not be explained. The description covers scope (per chain), the earning rule, and payout — enough for a single-parameter read tool. It could be strengthened with a note on what an empty result means.

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?

Only one parameter (address), with 100% schema description coverage and a regex pattern documented in the schema. The description's phrase 'for an address' merely echoes the schema, adding no format or semantic detail beyond it, 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 resource — unclaimed Liquid Bridge referral earnings — and scopes it to an address across chains, plus the payout model. It is clearly distinguishable from siblings like bridge_quote or bridge_status, though the opening 'Free.' fragment and slightly clipped phrasing ('and how they are paid out') make the purpose marginally less crisp than it could be.

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

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

The description explains how to earn referral credit (add ref=<your address> to bridge calls, 20% of Liquid's fee), which gives useful context, but it never says when an agent should call this tool versus the other bridge_* tools, nor any preconditions for querying earnings.

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 genuinely useful context beyond that: the call is free, the prices are live, and availability ('whether it is open') is returned. It does not describe freshness/latency or whether the list is paginated.

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 the cost qualifier first and no filler. Slightly telegraphic — 'for 1 USDC' takes a moment to parse as the price denomination — but nothing is wasted.

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

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

A zero-parameter, read-only discovery tool with an output schema, so the description only needs to say what comes back — and it does: routes, price at a fixed size, and open status. Remaining gaps (ordering, pagination) are minor given the output schema carries the field details.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The 'for 1 USDC' phrasing usefully fixes the denomination of the prices returned.

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 resource ('Every Liquid Bridge route') and the payload of each entry: live price for a 1 USDC transfer and open/closed status. An agent can distinguish it from bridge_quote, which presumably prices a specific route, though the description never names that sibling explicitly.

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

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

No when-to-use guidance and no routing to alternatives. The word 'Free' hints that cost is a selection factor against priced quote tools, but the agent must infer that comparison 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds 'Free', which is genuinely useful cost context, but says nothing about latency, whether attestation may be pending, or rate limiting for a status-polling tool.

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

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

A single sentence with the most decision-relevant fact ('Free') front-loaded, then the return content and the input identifier. No padding or redundancy.

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

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

An output schema exists and annotations carry the safety profile, so the description does not need to enumerate return fields — and it usefully names the return content anyway. The one real gap is routing versus the overlapping cctp_status sibling.

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

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

Schema coverage is 100% and both parameters are already documented in the schema, including the enum and the hash pattern. The description's note that the hash is 'returned by the bridge call' restates what the schema already says, adding no new syntax or format detail.

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 resource and scope — 'Circle attestation and mint state for a bridge, by its burn transaction hash' — so an agent knows it returns bridging progress. However it does not distinguish itself from the sibling cctp_status, which plausibly covers the same attestation territory.

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 'returned by the bridge call' implies this tool is called after a bridge/quote operation to track the result, which is useful implied context. But there is no explicit when-to-use, no mention of polling cadence, and no disambiguation from cctp_status.

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, open-world, non-destructive, so the bar is lower. The description still adds real value: it is free to call, it reports attestation and destination-mint state, and it supplies the recovery path (receiveMessage with message + attestation) for stuck transfers. Minor gap: nothing about rate limits or how long attestation takes.

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 cost and purpose before elaborating returns and recovery steps. The trailing chain enumeration is long but matches the enum and is genuinely useful for confirming coverage; it is the only mildly expendable part.

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?

An output schema exists, so return-value documentation is not required, yet the description still names the key outputs (attestation, mint status) and the remediation path. Combined with 100% schema coverage and full annotations, 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 description coverage is 100%, so both parameters are already documented including the 'source chain, if known (faster)' hint and the txHash pattern. The description reinforces that txHash is the source-chain burn hash and lists supported chains, but adds no syntax or format semantics beyond the schema. 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 ('Status of ANY Circle CCTP v2 USDC transfer') keyed to a concrete identifier (burn transaction hash), and its scope claim 'not only Liquid's' immediately distinguishes it from Liquid-specific siblings like bridge_status. An agent can tell what it does 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?

Gives clear usage context: tracking any CCTP transfer and diagnosing/finishing a stuck one via receiveMessage. However, it never explicitly names or excludes the sibling bridge_status, so the routing decision between the two must be inferred.

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 a free read (readOnly, idempotent, non-destructive, openWorld), so the safety profile is covered. The description adds genuine context beyond the annotations: that the sponsor itself is priced from $0.03, that it has price rules and lanes, and which chains are supported.

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 dense sentence (preceded by 'Free.') covering use case, mechanism, price and chains with no filler. Front-loading is slightly off, since 'Free.' leads rather than the core subject, but overall it is 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?

Because an output schema exists, return-value details need not be repeated, and the description covers chains, the USDC-only scenario, pricing and lanes. For a parameterless info tool it is largely complete, though it could name how it relates to the bridge/x402 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?

The tool takes zero parameters, which is the baseline-4 case, and schema description coverage is 100%. The description introduces no parameter concepts that need explaining, so nothing is missing here.

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 makes clear this is an informational tool about the x402 gas sponsor: what it is, how it lets a USDC-only wallet transact on Base/Polygon/Solana, plus its price rule and lanes. The purpose is specific and the resource is named, but there is no explicit verb ('get/read info') and no differentiation from informational siblings such as liquid_guide or payment_readiness.

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

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

Usage is implied via the scenario it addresses ('a wallet that holds USDC but no ETH/POL/SOL'), which tells the agent when the info is relevant. However, there is no explicit when-to-use/when-not framing and no named alternative tool, so the agent must infer 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 this is a read-only, idempotent, non-destructive, closed-world call. The description adds one genuinely useful behavioral fact not in the annotations: the service is free. Beyond that it discloses no pagination, freshness, or scope limits, so it clears the lowered annotation-assisted bar but does not exceed it.

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 sentence with the key qualifier ('Free') front-loaded and no padding. It is slightly dense with the parenthetical service list, but every clause carries 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?

With an output schema present, the description does not need to explain return values, and with zero parameters and full annotation coverage the structural burden is low. What remains is adequately covered: the agent knows it is free, what topics it spans, and that pointers to full docs are included.

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, which is the baseline-4 case; there is nothing for the description to disambiguate. The enumerated coverage list ('bridge, stocks, signals, gas sponsor') substitutes reasonably for parameter semantics by telling the agent what content to expect in the response.

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 concrete resource (an overview of Liquid Agent services) and enumerates what it covers: bridge, stocks, signals, gas sponsor, prices, and docs location. That is enough for an agent to know this is the discovery/help entry point rather than an action tool, though it stops short of explicitly positioning itself against the action 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?

Usage is only implied: an agent infers it should call this first to learn what is available and where the docs live. There is no explicit when-to-use statement, no mention of whether it should be preferred over querying individual service tools, and no 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 cover safety (readOnly, idempotent, non-destructive, openWorld). The description adds context beyond them: it is free, it makes one unpaid outbound call to the endpoint to read its 402, and on failure it returns a computed remedy with exact bridge_quote arguments. Missing any note on rate limits or failure modes, so not 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?

Single sentence, front-loaded with the two most decision-relevant facts ('Free', 'One call'). It is dense but every clause earns its place; slightly long, but 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 an output schema present, the description need not explain return values, yet it usefully names the failure-path output (cheapest fix). It leaves the url/requirement interaction to the schema, which is acceptable given 100% coverage, but a short note on choosing between them would have closed the 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 five parameters including the url/requirement distinction. The description only restates that the endpoint's 402 is read from the url; it adds no format, precedence, or defaulting nuance 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+resource ('know if a wallet can pay an x402 endpoint right now') and specifies the mechanism: reads the endpoint's 402, checks balance per accepted network. This clearly distinguishes it from siblings like x402_check or bridge_quote, which it references as the downstream remedy.

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 the description ('if it cannot pay, returns the cheapest fix') and the 'Free' tag hints at when it is cheap to call, but the description never explicitly says when to use this versus x402_check or bridge_quote, nor does it state exclusions or prerequisites (e.g. that a URL or requirement is needed).

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 usefully adds the critical behavioral fact that this tool returns a payment request but does NOT execute payment. It also discloses the cost and accepted networks, going beyond structured fields.

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 and the key caveat ('This tool does not pay') is isolated for emphasis. Slightly verbose in enumerating return fields that an output schema already covers.

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?

An output schema exists, yet the description nonetheless summarizes the payload and the payment requirement, so an agent knows both what it gets back and what it must do next. Complete for a two-param prepare 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% and both parameters are documented there, so the schema carries the load. The description restates the 'past window official outcome' meaning of start but adds no format or syntax 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?

Starts with a specific verb+resource ('Returns the x402 payment request for Polymarket crypto Up/Down data') and enumerates the assets, timeframes and chains. It is clearly distinguishable from the surrounding bridge_*/stocks_*/x402_check 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?

Gives clear operational context: 'Pass start (unix) for a past window's official outcome' and 'Pay it with your own x402 client. This tool does not pay.' It does not name an alternative sibling tool or state explicit exclusions, but the when-to-use condition is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the cost model ('Free') and signals that it returns dynamic live prices and fees, which is useful beyond the annotations, though no auth or rate-limit details 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?

A single, front-loaded sentence that begins with the free cost and then lists the covered topics. It is tight, though the colon-separated list is dense.

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 an output schema present and zero parameters, the description does not need to explain return values. It sufficiently conveys the tool's scope for a simple informational endpoint, though it could clarify when to use it over sibling 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?

The tool takes no parameters, so the schema is empty and the baseline is 4. The description appropriately does not invent parameter 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 the tool is about the on-chain tokenized US stock index on Base and enumerates the data it surfaces (live prices, fees, how to buy). The purpose is discernible, but it does not explicitly contrast with siblings like stocks_portfolio or stocks_buy_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?

No when-to-use or when-not-to-use guidance is provided. The description does not name alternatives or prerequisites, leaving the agent to infer that this is a general informational endpoint.

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 goes well beyond the annotations by explaining that the tool is free, returns an unsigned transaction, requires external signing, and that Liquid never holds keys or funds. It also clarifies the two-call permit workflow and the result of omitting it, which fully explains the readOnlyHint=true annotation for a 'buy' 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 description is dense but well-structured: it front-loads cost and amount, then the permit flow, then return behavior, then custody. Every sentence earns its place, though it could be slightly tighter given the schema already covers parameter details.

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

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

Given the complexity of a two-call permit flow and the presence of an output schema, the description is complete enough for an agent to understand the transaction lifecycle, the return value nature, and the absence of custody risk. Nothing critical is missing.

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

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

Schema coverage is 100%, so each parameter is already documented. The description adds value by explaining how usePermit, owner, permitDeadline, and permitSignature are used together in a two-call sequence, which is not obvious from the individual field descriptions alone.

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: 'Invest USDC into your vault' for tokenized stocks. It clearly distinguishes this as the actual buy operation from the quote sibling (stocks_buy_quote) by describing a transaction-producing flow, not a price check.

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

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

It provides clear internal guidance: use usePermit=true for a one-transaction flow, otherwise expect two. It does not explicitly name alternative sibling tools (e.g., stocks_buy_quote, stocks_sell) or state when not to use this tool, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context the annotations do not: that the call is free and that it returns a projection (shares received and fee) rather than performing a purchase, which anchors the read-only semantics to a concrete outcome.

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 tight sentence with the cost qualifier front-loaded, followed by purpose and output in order of relevance. No filler; every clause carries 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?

An output schema exists, so the description need not spell out return fields, and it correctly signals what comes back at a high level. For a one-parameter free quote tool with full schema and annotation coverage, this is largely complete, with only the missing explicit sibling routing leaving a small 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 single 'usdc' parameter is already fully documented including the USDC-6 pattern. The description restates the same convention ('2000000' = $2) without adding constraints or edge-case meaning beyond the schema, 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 (preview buying the tokenized stock basket) and names the outputs (shares and fee), so the agent knows it is a non-executing quote rather than the actual buy. The 'Preview' framing implicitly distinguishes it from the sibling stocks_buy, but it never names that sibling explicitly, so 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 leading 'Free.' and 'Preview' wording imply this is the zero-cost step to run before committing to stocks_buy, which is useful implied guidance. However, there is no explicit when-to-use/when-not statement and no alternative tool is named, so the routing logic 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?

Goes well beyond the annotations by describing the return payload ({to, data, value, chainId} on Base), the fact that nothing happens until the caller signs and broadcasts, and the custody model ('Liquid never holds keys or funds'). This is exactly the kind of pre-signing workflow context an agent needs.

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 and information-dense: cost, action, asset scope, return shape, signing requirement, follow-up tool. The one-word 'Free.' opener is slightly clipped but still earns its place as an early decision signal.

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 preparation tool with an output schema and full annotation coverage, the description supplies the missing workflow context (unsigned tx, self-custody, follow-up lookup). Everything needed to call it correctly is present.

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 for the description to clarify; the baseline of 4 applies. No misleading parameter claims are made.

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 (opens) plus resource (your own vault for the tokenized US stock basket), and it even names the covered assets. An agent can distinguish this creation tool from stocks_vault (a lookup) and stocks_basket without opening a 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?

States the cost context ('Free') and gives explicit follow-up routing: 'After it confirms, find the vault with stocks_portfolio.' It does not, however, state when NOT to call it or contrast it with the similarly named sibling stocks_vault.

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 safety is covered. The description adds genuinely new context — 'Free.' (no payment/x402 cost) and the fact that results are per-vault with shares and current USD value — which is not derivable from 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?

A single sentence with no filler and an explicit list of return contents. Slightly awkward that 'Free.' leads ahead of the actual purpose, but nothing is wasted.

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

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

An output schema exists and annotations are rich, so return values and safety need no repetition. The description supplies the one non-obvious behavioral fact (no cost) plus scope. Only the lack of any when-to-use guidance keeps it short of 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?

Only one parameter (address) with 100% schema description coverage, so the schema already carries its meaning. The description's 'an address' adds no format, chain, or validation detail beyond the schema's pattern. 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 retrieval over a specific resource — everything an address owns in the tokenized stock basket — and enumerates the payload (vaults, shares, USD value). That scope cleanly separates it from siblings like stocks_basket (the basket definition) and stocks_vault (a single vault).

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 only usage signal is the cost note 'Free.' There is no statement of when to call this versus stocks_vault or stocks_basket, no prerequisites, and no exclusions. An agent must 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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the exact cost ($0.01 USDC), the accepted chains (Base/Polygon), the 24-hour publish duration, and the explicit warning that it does not itself pay. Return format is left to the 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 tight sentences, front-loaded with the core action and the key constraint ('this tool does not pay') placed last for emphasis. 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?

Output schema exists, so return-value explanation is unnecessary. The description covers cost, chain, duration, and the non-payment boundary, which is everything an agent needs to invoke it correctly for a two-parameter prepare 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%, with both 'vault' (address pattern) and 'label' (optional title, max 60) fully documented in the schema. The description adds no syntax or format detail beyond what the schema already carries, 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 (returns) and resource (the x402 payment request to publish a portfolio page for a vault), plus duration and price. An agent can immediately tell this apart from sibling prepare tools like stocks_signals_prepare or bridge_prepare_payment by the named target artifact.

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 usage: 'Pay it with your own x402 client. This tool does not pay.' That is a clear when-to-use and a when-not-to (this is preparation, not payment). It stops short of naming the sibling that performs payment or the follow-up flow, so it misses the top tier.

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/non-destructive/idempotent, so the description adds the higher-value context: it is free, it returns an UNSIGNED tx, nothing happens until the user signs and broadcasts, and the service never holds keys or funds. That is a meaningful disclosure beyond the annotations, though it omits whether the vault must already have weights set to be rebalanceable.

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 value proposition ('Free') followed by the action, then the safety/return detail. Every sentence carries distinct information with no padding.

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?

An output schema exists, so the return payload needn't be fully explained, yet the description still summarizes it and covers cost, custody, and the signing requirement. For a one-parameter prepare-style tool, an agent has everything needed to call and interpret 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?

There is a single parameter with 100% schema description coverage, so the schema already documents 'vault' fully. The description adds no syntax, format, or constraint information beyond it, which is the expected 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 (rebalance) and resource (vault) plus the exact outcome: 'Brings your vault back to its target weights.' It distinguishes itself from siblings like stocks_set_weights (which changes targets) by describing a return-to-target action, and it names stocks_vault as the check source.

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

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

Gives explicit context for when to call it — after checking stocks_vault: rebalanceNeeded — which is a concrete prerequisite. It does not, however, state when NOT to use it (e.g., to change target weights use stocks_set_weights), so routing guidance is clear but not fully closed.

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 mark readOnlyHint=true on what sounds like a sell, and the description proactively resolves that tension: it returns an UNSIGNED transaction and 'nothing happens until you sign it', plus 'Liquid never holds keys or funds'. That is exactly the context annotations cannot convey. It does not cover rate limits or failure modes, so 4 rather than 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?

Tight and front-loaded: the action, the two payout modes, the prerequisites, and the return shape all land in the first half. It is dense but every clause carries information; no filler or repetition.

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 transaction-building tool with a full input schema, an output schema, and safety annotations, the description supplies the remaining unknowns an agent needs: chain (Base), fee (Free), custody model, and the unsigned-then-sign workflow. Nothing required to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so vault, inKind, shares, and minUsdcOut are all documented in the schema itself; the baseline is 3. The description adds only the general 'no vault needed' framing, which arguably sits oddly against the required vault parameter, and adds no format or units 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 ('redeem basket shares to USDC, or take the raw stock tokens in-kind') and immediately contrasts the two exit paths. An agent can distinguish this from stocks_buy and stocks_send 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?

Gives real context for when this applies: 'works any block, no vault needed, anyone holding shares can sell', which tells the agent this path has no vault-deployment prerequisite. It does not explicitly name a sibling alternative or an exclusion case, so it falls short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the call is free, it returns an UNSIGNED transaction {to, data, value, chainId} on Base, nothing executes until the caller signs and broadcasts, and Liquid is non-custodial. This resolves the apparent tension between a 'send' tool and readOnlyHint=true.

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 tight sentences, front-loaded with the key constraint ('Free') and the non-custodial safety model. 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 three-parameter prepare tool with full schema coverage, annotations, and an output schema, the description supplies everything else an agent needs: cost, custody model, return shape, and the fact that signing is required before any state change.

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 all three parameters (to, vault, shares) are documented with patterns, so the baseline is 3. The description adds no per-parameter detail such as address format or decimal handling beyond what the schema already provides.

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

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

States a specific verb and resource: transfer tokenized stock basket shares to any wallet or agent. It is clearly distinguishable from siblings like stocks_sell (disposal for value) and stocks_buy (acquisition), and the 'no vault needed' clause clarifies scope.

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 context: use it to move basket shares to any wallet or another agent, who may hold, sell, or forward them. It does not name an alternative tool or an explicit when-not-to-use condition (e.g., versus stocks_sell for liquidating), so it falls 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 declare readOnlyHint=true and destructiveHint=false, and the description is consistent, explaining that it returns an UNSIGNED transaction {to,data,value,chainId} on Base and that nothing changes until the caller signs and broadcasts. It also discloses the non-custodial model ('Liquid never holds keys or funds'), which is meaningful context 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?

Front-loaded with the key cost note ('Free.') and the core action, then the mechanics. Dense but each clause carries information; the signing/custody sentence is longer than strictly necessary but earns its place for a transaction-producing 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?

An output schema exists, so the description needn't explain return values, yet it still characterizes the unsigned transaction shape. Combined with the chain and custody notes, an agent has enough to call it correctly; only sibling-routing guidance is absent.

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 (vault, weightsBps) are already fully documented. The description adds only a concrete example array, which is mildly useful but largely restates the schema's sum-to-10000 and ordering 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?

States a specific verb and resource ('Sets your vault's target allocation across the 4 stocks in basis points') with the exact unit and expected sum. An agent can distinguish this from stocks_basket, stocks_rebalance, and stocks_buy without opening schemas.

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

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

It gives the format and the default (equal weight) and implies when the tool is appropriate (rebalancing a vault's target weights), but it never states when to prefer it over close siblings like stocks_rebalance or stocks_basket. Usage is implied rather than routed.

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, so the safety profile is covered. The description adds genuine context beyond that: the price ($0.005 USDC), the supported chains (Base or Polygon), and the crucial fact that it returns a request rather than paying it. It does not mention caching/TTL or what happens if the request expires.

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 dense sentences, front-loaded with the return value and price, followed by the operational caveat. No filler or restated title beyond the price already embedded in the title.

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 annotations covering safety, a 100%-covered single-param schema, and an output schema available for the return shape, the remaining ambiguity an agent needs resolved (cost, asset, chains, and that payment is external) is all present.

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 only one optional parameter exists, so the schema carries parameter meaning fully. The description never mentions the optional vault parameter or what tailoring to a vault implies, so it adds nothing here; 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: it returns an x402 payment request for basket signals, and it enumerates the payload (rebalancing signal, momentum, suggested weights for NVDA/META/AAPL/GOOGL). It does not name which sibling to use instead (e.g., stocks_basket for the data itself), so sibling differentiation is implied 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?

Clear context for use: call it to obtain the payment request, then settle with your own x402 client, and it explicitly does not pay. There is no statement of when NOT to use it or which sibling handles the post-payment data retrieval.

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 non-destructive behavior, covering the safety profile. The description adds the cost trait ('Free') and lists return fields, but does not disclose auth needs, rate limits, or pagination—reasonable given the annotation coverage, yet still limited.

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 sentence that is front-loaded with 'Free.' and then lists the exact outputs. No filler, no repetition—every word 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?

With a rich output schema, full parameter documentation, and annotations covering safety, the description only needs to state the tool's value proposition. It does so succinctly and completely for a simple read operation.

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

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

The schema fully documents the single required 'address' parameter with a format pattern and description. The tool description adds no further meaning about the parameter, so the baseline score of 3 applies.

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

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

The description specifies the resource (basket vault) and the exact data returned: NAV, holdings, weights, and rebalancing need. It lacks an explicit verb (e.g., 'Get') and does not differentiate itself from siblings like stocks_portfolio or stocks_basket, but an agent can still infer its read-only purpose.

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

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

The word 'Free' conveys a clear cost guideline, and the purpose implies when to use it (to inspect vault state). However, there is no explicit when-to-use guidance relative to sibling tools or any when-not-to-use condition, leaving alternatives unaddressed.

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, non-destructive, and open-world, so safety is established. The description adds genuinely new context: that the call is free and that it returns both the USDC balance and the native gas balance, which matters for the stated pre-bridge check use case.

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

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

Three sentences, each doing distinct work: cost, capability and scope, then usage. The cost note and the action guidance are front-loaded and there is no filler.

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

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

With an output schema present, the description need not describe return values, and it fully covers cost, chain coverage, and intended use. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100% and the single address parameter is fully documented with a regex pattern in the schema, so the description has no gap to fill. It adds no format or semantic detail beyond the schema, making the baseline 3 appropriate.

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

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

States a specific resource (USDC and native gas balance of an address) with explicit scope (every CCTP chain at once) and even enumerates the 11 chains. An agent can distinguish this from bridge_quote, bridge_routes, or payment_readiness 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?

"Use it before paying or bridging to see where your money is" gives a clear triggering context, which is exactly the pre-flight check role this tool plays among the bridge/payment siblings. It does not name a specific alternative tool or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely useful context beyond that: it is "Free", every failed check includes a fix, and verification mirrors what a facilitator checks (recipient, amount, time window, EIP-712 domain, nonce reuse, balance). It does not detail rate limits or output shape, but the output schema covers returns.

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

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

Front-loaded with the essential facts ("Free.", the decode action, the optional verify). It is one long sentence but every clause carries information; the only slight cost is density, where the parameter mappings could have been split for 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 an output schema present, return values need not be explained, and the description covers both modes plus error behavior (warnings, fixes). The one implicit gap is that it never states that at least one of url/requirement/payment must be supplied, though the schema hints at this via "Instead of url".

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning on top by mapping parameters to the real protocol artifacts (PAYMENT-REQUIRED header / 402 body for requirement, PAYMENT-SIGNATURE / X-PAYMENT for payment) and by framing url as the called-once-for-402 path, which clarifies the mutually exclusive inputs better than the schema alone.

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 specific verbs and resource: decode an x402 payment request and optionally verify a signed payment. The two input paths (request decoding vs. payment verification) are named explicitly, and none of the siblings (bridge_*, payment_readiness, stocks_*) overlap this debugging role.

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?

"Decode any x402 payment request... optionally verify a signed payment" gives clear context for both operating modes. It does not name exclusions or point to an alternative tool (e.g. payment_readiness) for cases where the caller wants a broader readiness verdict, 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.