Panda Financial

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

With readOnlyHint already declared, the description still adds substantial context: fees (Panda 0.15% + 0x 0.15%), that nothing is sent, that output is unsigned txs to sign in order, an EIP-5792 batch alternative, a wallet-based simulation, and a sign_url for a human owner. This resolves the apparent tension between a 'buy' verb 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 purpose, then constraint, then routing and return behavior. 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?

There is no output schema, yet the description fully describes the return shape (ordered unsigned txs, optional EIP-5792 batch, sign_url) and the safety posture, leaving no material gap for an agent 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 wallet and amount_usdc are already documented. The description adds only a minimum-amount constraint (0.10 USDC) and unit context, so the baseline 3 is 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 verb+resource (buy BNKR with USDC) plus the execution route (0x) and fee split, which clearly separates it from siblings like build_swap or build_bnkr_stake. It also names the natural follow-up tool, so the agent can place it in a flow without opening other 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?

Gives a concrete precondition (minimum 0.10 USDC) and an explicit next step (then stake with build_bnkr_stake), which tells the agent where this fits in the BNKR entry flow. It does not explicitly say when to prefer it over build_swap, so it stops short of full when-not guidance.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, and the description correctly reconciles this by clarifying the tool only builds requests ('Nothing is sent'). It goes beyond annotations by disclosing the 48-hour wait, that the stake stops earning immediately, that transactions are simulated from the wallet, and that a sign_url is produced for a human owner. Return-format disclosure is strong; minor gap on auth/signing requirements.

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

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

Three tight sentences, front-loaded with the action and its consequence ('stops earning now'), followed by the return format and the safety reassurance 'Nothing is sent.' 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 does the work of explaining the return values (ordered unsigned transactions, EIP-5792 batch, sign_url). It covers purpose, side effects, and outputs adequately for a 2-param builder tool; only auth/signing context for the human owner is left unstated.

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

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

Schema coverage is 100%, so both wallet and amount_bnkr are already fully documented in the schema, making 3 the baseline. The description's phrase 'some or all of the stake' loosely signals the 'all' sentinel value, but adds little 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?

Specific verb+resource ('Start Bankr's 48-hour unstaking wait') with explicit scope ('some or all of the stake'). It cleanly distinguishes itself from siblings like build_bnkr_stake, build_bnkr_restake, and build_bnkr_withdraw by naming the exact action and its 48-hour wait mechanism.

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 ('start unstaking... stops earning now') but never explicitly states when to choose this over build_bnkr_withdraw or build_bnkr_restake, nor any prerequisites such as needing an existing stake. Usage is inferable but not spelled out.

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 disclosing the exact return contract: unsigned transactions to sign in order, an EIP-5792 batch form, simulation from the wallet, a sign_url for a human owner, and 'Nothing is sent.' This aligns with readOnlyHint=true and clarifies that the tool builds but does not broadcast.

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 action front-loaded and the return/behavioral contract following. 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?

With no output schema, the description correctly carries the return-format burden (ordered txs, EIP-5792 batch, sign_url, no broadcast). It stops just short of noting what must be true before rewards are restakeable or what happens if none have accrued.

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 one parameter and schema coverage is 100%, so the schema already documents 'wallet' including its 0x address pattern and Base ownership semantics. The description adds no format or syntactic detail beyond that, 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 and resource: 'Add the wallet's BNKR staking rewards to its stake,' which an agent can distinguish from plain staking (build_bnkr_stake) or unstaking (build_bnkr_request_unstake). It never names a sibling explicitly, so differentiation relies on the noun phrase rather than stated contrast.

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 scoping ('the wallet's BNKR staking rewards'), which tells the agent this applies only when accrued rewards exist. However there is no explicit when-to-use/when-not guidance and no mention of alternatives such as build_bnkr_stake for fresh deposits.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, consistent with "Nothing is sent." The description goes well beyond that by disclosing rewards denominated in BNKR, the 48-hour unstaking lockup, the fee model, and precisely what is returned: unsigned transactions to sign in order, an EIP-5792 batch form, and a sign_url for a human owner. This is rich behavioral context an agent could not infer from 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?

A single dense paragraph with the purpose front-loaded and zero filler; every clause carries information (rewards, lockup, fee, return shape, no-send guarantee). It is slightly packed, 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?

With no output schema, the description carries the burden of explaining returns and does so well (ordered unsigned txs, batch form, sign_url, simulated, nothing sent). The only gap is the absence of explicit sibling routing, which is minor for a 2-parameter build 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 coverage is 100%, so both parameters (wallet and amount_bnkr, including the "all" option and the 0x address pattern) are fully documented in the schema itself. The description only alludes to "for the wallet" and adds no syntax or format meaning beyond what the schema provides, 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 and resource ("Stake BNKR in Bankr's own staking contract for the wallet"), which cleanly distinguishes it from siblings like build_bnkr_restake, build_bnkr_request_unstake, and build_bnkr_buy. An agent can tell exactly what this builds without opening the schema.

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

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

Usage is implied by the description (staking vs. the 48-hour unstaking it mentions), and the "No Panda fee" note helps selection, but the description never explicitly says when to prefer this over build_bnkr_restake or build_bnkr_buy. No exclusions or alternatives are named.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false; the description goes further, disclosing that it returns unsigned transactions to sign in order, that they simulate from the wallet, that a separate sign_url exists for a human owner, and that nothing is broadcast. That is exactly the behavioral context an agent needs for a 'build' tool whose safety profile is only implicit in annotations.

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

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

Three short sentences, front-loaded with the action and its precondition, followed by return shape and the 'nothing is sent' guarantee. No redundant restatement of 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 no output schema, the description correctly compensates by describing the return payload (ordered unsigned transactions, EIP-5792 batch, sign_url) and confirming no state change. Nothing needed to invoke or interpret the result 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% with a single required 'wallet' parameter fully documented in the schema, so the schema does the heavy lifting. The description adds no format or constraint detail beyond it; 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 ('Send BNKR ... back to the wallet') plus the qualifying condition ('whose 48-hour wait is over'), which cleanly separates it from build_bnkr_request_unstake (starts the wait) and build_bnkr_restake. An agent can identify the operation without opening the schema.

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

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

The 48-hour-wait condition establishes clear context for when this tool is applicable, following an unstake request. It stops short of explicitly naming the sibling it succeeds (build_bnkr_request_unstake) or stating when not to use it, so it is clear but not fully 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?

Far exceeds the annotation bar: it discloses the liquidation LTV cap and refusal behavior, health-factor reporting, absence of a Panda fee, the one-time bundler authorization on first borrow, and that outputs are simulated unsigned transactions returned in order or as an EIP-5792 batch with a sign_url. 'Nothing is sent' corroborates the readOnlyHint rather than contradicting 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?

Front-loaded with what the tool does, then behavioral caveats, then return shape — a logical order with no filler. The parentheticals and stacked clauses make it slightly dense, keeping it just short of a 5.

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 fully carries the return contract (ordered unsigned txs, optional batch, sign_url) and the failure condition. An agent has everything needed to call it and handle the result.

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

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

Schema description coverage is 100%, so wallet, borrow_usdc, and collateral_weth are already documented. The description's 'and/or' confirms both amount params are optional and combinable, but adds no format or unit detail beyond the schema — baseline 3.

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 (add collateral, borrow) and resources (WETH collateral, USDC) plus the exact venue (Morpho WETH/USDC market). An agent can distinguish this from build_repay, build_withdraw_collateral, or build_lend_supply 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?

Usage is implied through the 'and/or' framing and the 86% LTV refusal rule, which tells the agent when the call will fail. However, it never explicitly says when to prefer this over sibling tools like build_repay or build_lend_supply, leaving routing to inference.

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

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

Goes well beyond the annotations by disclosing the approval flow (exact approval of the route's spender), the fee stack (LI.FI 0.25% + Panda 0.15% plus route costs, all returned), that nothing is broadcast, and the exact return shape (ordered unsigned txs, EIP-5792 batch, simulated, sign_url for the owner). With readOnlyHint already covering safety, this is substantial added context.

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

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

Front-loads the action and supported assets, then layers route, fees, direction, and return behavior in a tight sequence with no filler. It is dense and slightly long for one paragraph, but every clause carries information an agent needs.

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 builder with no output schema, the description covers the critical unknowns: directionality limit, fee composition, approval step, non-broadcast behavior, and the returned transaction format. Nothing essential to correct invocation 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 schema already documents all seven parameters including the defaults for to_token and to_wallet. The description restates the token and chain vocabularies but adds no syntax or constraint detail beyond the schema, matching the baseline for full-coverage schemas.

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 ('Send USDC, WETH, ETH or any token from Base to another chain') and enumerates the supported destinations, so the agent knows exactly what the tool does. It is clearly distinguishable from sibling builders like build_swap by its cross-chain scope and explicit 'From Base only' framing.

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 a clear directional rule: bridging out of Base is this tool, while 'a bridge into Base starts on the other chain' — an implicit when-not. However, no sibling alternative is named (e.g., build_swap for same-chain swaps), so the routing guidance is context-rich but not fully exhaustive.

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 disclosing the fee (0.05% once, inside the transaction), the compounding mechanics, the exact return shape (unsigned transactions to sign in order, an EIP-5792 batch, simulated from the wallet, plus a sign_url for a human owner), and the crucial fact that 'nothing is sent'. This resolves the ambiguity created by readOnlyHint=true on a deposit builder.

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 action and target, then layers economics, fees and return format in dense but information-bearing sentences. The parenthetical yield and fee clauses are slightly crammed, but every clause earns its place for a transaction-building tool.

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

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

With no output schema, the description carries the burden of describing returns and does so fully: ordered unsigned transactions, batch format, simulation, sign_url, and the guarantee that nothing is transmitted. Combined with the 100%-covered two-parameter schema, 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?

Schema description coverage is 100%, so the schema already documents both wallet and amount_usdc including format examples and the 1 USDC minimum. The description adds no further parameter-level meaning, 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 and resource ('Deposit USDC into Steakhouse Prime USDC, a Morpho vault curated by Steakhouse Financial'), naming the exact product so it is distinguishable from the sibling build_vault_deposit and build_curated_vault_withdraw. An agent can identify the operation and the target vault 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 context for use: it describes the vault, its yield and that withdrawal is possible 'any time', which implicitly routes to build_curated_vault_withdraw for the opposite action. However, it never explicitly contrasts itself with build_vault_deposit (the non-curated vault) or states prerequisites such as the 1 USDC minimum or wallet funding requirements.

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

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

Beyond the annotations (readOnlyHint, non-destructive, non-open-world), the description discloses fee structure (no Panda fee), a real constraint (subject to the vault's liquidity), and the full output shape (ordered unsigned txs, one EIP-5792 batch, simulated from the wallet, plus a sign_url for a human owner). It also clarifies the critical non-effect 'Nothing is sent', which is exactly the context an agent needs before treating this as read-only.

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

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

Front-loaded with the core action, then each following clause earns its place: fee, liquidity constraint, return format, and the 'nothing is sent' caveat. No filler or redundant restatement of the name.

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

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

With no output schema, the description carries the return-value burden and does so well — it enumerates the returned artifacts and their ordering/batching, notes simulation from the wallet, and provides the sign_url path for human signing. Combined with full schema coverage, an agent has everything needed to call and interpret 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 (wallet pattern, amount_usdc with 'all' option) are already fully documented in the schema. The description only restates destination and source, adding no syntax or edge-case detail beyond the schema. Baseline 3 is 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?

The description states a specific verb (withdraw), resource (USDC), and exact source (Steakhouse Prime USDC curated vault) and destination (the wallet). Naming the specific vault clearly separates this from siblings like build_vault_withdraw and build_old_vault_withdraw 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?

Usage is only implied through the specific vault name; there is no explicit when-to-use framing or named alternative (e.g., why this vs. build_vault_withdraw). The agent can infer scope, but nothing states prerequisites, exclusions, or routing conditions.

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 only declare the safety profile (readOnly, non-destructive, openWorld=false); the description adds what actually happens: a 0.05% one-time fee taken inside the transaction, interest accruing as funds are borrowed, simulation from the wallet, and an explicit 'Nothing is sent.' That is real behavioral disclosure beyond the structured fields, and 'Nothing is sent' is fully consistent with 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 compact sentences, purpose front-loaded, then mechanics (fee, interest), then return shape and the no-broadcast guarantee. The parentheticals carry load rather than padding; nothing is wasteful.

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

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

With no output schema, the description correctly compensates by describing the return shape (ordered unsigned transactions, optional EIP-5792 batch, sign_url, simulation). It omits whether a token approval/allowance must already exist and whether the wallet needs a prior USDC balance, which an agent might need to reason about before calling.

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 (wallet, amount_usdc) are already documented with format rules and the 'at least 1' minimum. The description adds only the fee context, not parameter-level semantics, 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 precise verb (lend), asset (USDC), and venue (Morpho WETH/USDC market), which is enough to separate it from build_lend_withdraw and build_borrow without opening any schema. The market-level specificity is more informative than a generic 'lend USDC' phrasing would 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?

It gives context for when this applies (supplying into the Morpho WETH/USDC market) but never names an alternative such as build_lend_withdraw for exiting a position, nor states any precondition the agent should check first. Usage is implied by the tool name and description rather than explicitly guided.

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

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

Goes well beyond the annotations, which only give the safety profile (readOnly, non-destructive). The description discloses the fee treatment (no Panda fee), the external dependency (market liquidity), and in detail what is produced: unsigned transactions to sign in order, an EIP-5792 batch, simulation from the wallet, and a sign_url for a human owner, plus the key guarantee 'Nothing is sent.'

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: purpose first, then economic/risk modifiers, then the return contract. No filler and nothing important is buried.

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

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

With no output schema, the description carries the return-value burden and does so fully — transaction ordering, batching, simulation origin, and sign_url. Combined with the annotation safety profile and a fully documented 2-param schema, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100% with only two parameters, and the schema already explains that wallet is the Base signer/position owner and that amount_usdc accepts a number or "all". The description adds nothing further about parameter format or constraints, 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 (withdraw), resource (USDC lent), and the exact protocol market (Morpho WETH/USDC), which cleanly separates it from build_lend_supply, build_withdraw_collateral, and the various build_vault_withdraw siblings. 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?

The market and the 'lent USDC' framing imply this is the exit leg of a Morpho lending position, and the liquidity caveat hints at when it may fail, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. build_lend_supply for the opposite direction). Usage is inferable rather than stated.

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

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

Annotations declare readOnlyHint=true, and the description reinforces this with 'Nothing is sent', so there is no contradiction. It goes well beyond the annotations by disclosing the return shape (unsigned transactions in signing order, an EIP-5792 batch form), that they are simulated from the wallet, and that a sign_url is provided for a human owner.

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 compact sentences, front-loaded with the primary action and the batch framing, then the exception rule, then the return/safety note. No filler or repetition of the schema.

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

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

Even without an output schema, the description explains exactly what comes back (ordered unsigned txs, optional EIP-5792 batch, sign_url) and that nothing is broadcast, which is what an agent needs to chain the next step. The $5 threshold and simulation detail round out the guidance.

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 wallet, token_id, and auto_compound are already fully documented. The description only reinforces wallet ownership ('simulated from the wallet') and does not add format or default semantics beyond the schema, matching the baseline for high-coverage schemas.

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 compound action (withdraw an old-vault position and deposit into the new vault) and anchors it to the familiar website Migrate button, so the intent is unambiguous. It does not explicitly name how it differs from the sibling build_vault_move or build_old_vault_withdraw, leaving the agent to infer the routing.

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 a clear use case (the Migrate button flow) and an explicit when-not rule: positions under $5 should use a withdraw path instead. The condition is concrete, though it describes the alternative generically rather than naming the sibling tool to call.

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 past the annotations by disclosing the exact output contract: unsigned transactions returned in order and as a single EIP-5792 batch, simulated from the wallet, plus a sign_url for a human owner, and explicitly that nothing is sent. This confirms and enriches the readOnlyHint/non-destructive profile with concrete consequences the agent can rely on.

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 dense but well-ordered sentence: the action and scope come first, then the return shape, then the safety statement. Every clause carries information an agent needs and nothing is repeated.

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 present, the description steps in to describe the return payload (ordered unsigned txs, EIP-5792 batch, sign_url) and the non-broadcast guarantee. Combined with the fully documented two-parameter schema and safety annotations, an agent has everything needed to call and interpret this 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%, so both parameters (wallet, token_id) are already documented, including that token_id comes from get_wallet_positions. The description adds no syntax or format detail beyond that, matching the baseline for fully-covered schemas.

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 (withdraw) and a precisely scoped resource (a position in Panda's old vault), which distinguishes it from sibling withdraw tools like build_vault_withdraw and build_curated_vault_withdraw. The '(no fee)' qualifier further pins down which vault variant this is.

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 'old vault' scoping implies this is the tool for legacy positions, and siblings build_old_vault_migrate and get_old_vault_positions make the family recognizable. However, it never explicitly says when to prefer this over migrating (build_old_vault_migrate) or over the standard vault withdraw, so routing remains inferred rather than stated.

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

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

Goes well beyond the annotations: explains the permanence, the 1% AERO reward mechanic, that the call originates from the referred wallet, that transactions are simulated and returned unsigned 'in order (and as one EIP-5792 batch)' with a sign_url, and that 'Nothing is sent.' The readOnlyHint=true annotation is fully consistent with this.

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, followed by timing, permanence, reward mechanic, and return shape in a logical order. It is dense and slightly run-on, but nearly every clause carries actionable information.

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

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

For a build tool with no output schema, the description fully explains what is returned (ordered unsigned transactions, EIP-5792 batch, sign_url, simulation, nothing sent), so an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so both parameters (wallet, referrer and its ?ref=/6-char-code formats) are already documented in the schema. The description adds the contextual constraint that the caller is the referred wallet but no new syntax detail, so the baseline 3 applies.

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

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

States a specific verb+resource ('Record a referrer for this wallet') and even names the contract method (PandaReferrals.accept). An agent can distinguish this from siblings like check_referral_eligibility or get_referral_link 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 a clear triggering condition: it must happen 'before its first deposit' and is permanent. It does not explicitly name the alternative sibling tools or state when not to use it, so it stops short of the top band.

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: discloses zero Panda fee, that output is unsigned transactions ordered plus a single EIP-5792 batch, that they are simulated from the wallet, that a sign_url exists for a human owner, and that nothing is sent. The 'nothing is sent' statement is consistent with readOnlyHint=true on a build-only 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?

Three tightly packed sentences, front-loaded with purpose and scope, then economics, then return shape. No filler and 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 no output schema, the description compensates fully by describing the return payload (ordered unsigned txs, EIP-5792 batch, sign_url, simulated) and the no-send/no-fee behavior. An agent has everything needed to call and interpret this 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 coverage is 100%, so both parameters and the "all" pattern are already documented. The description restates the asset and the part-or-all notion in prose, adding only marginal meaning over the schema. Baseline 3 is 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?

Names a specific verb (repay), the exact protocol and market (Morpho WETH/USDC), the asset (USDC), and the scope (part or all). An agent can immediately separate this from siblings like build_borrow or build_lend_supply.

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?

"Repay part or all of the USDC owed" implies when the tool applies, but there is no explicit when-not guidance or routing to alternatives (e.g. how it relates to build_withdraw_collateral for unwinding, or prerequisites like an existing borrow position). Usage is inferable but not stated.

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

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

Despite annotations already declaring readOnly/destructive hints, the description adds substantial undisclosed behavior: the AllowanceHolder approval step, exact fees (Panda 0.15% in the sold token + 0x 0.15%), that output is unsigned and simulated, returned in order and as an EIP-5792 batch, with a sign_url, and 'Nothing is sent.' This is far beyond annotation coverage.

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, front-loaded with the core action, then mechanics, constraints, and return shape. No filler or redundancy; each clause carries actionable 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 no output schema, the description fully carries the return burden: unsigned transactions in order, EIP-5792 batch form, simulation from the wallet, and a sign_url for a human owner. Fees, approvals, and asset limitations are all covered, so nothing an agent needs to call 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 all five parameters (wallet, sell_token, buy_token, amount, slippage_bps) are already documented. The description adds fee/asset context (fees paid in the sold token, ETH not supported) but does not clarify parameter syntax or semantics 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 (swap) and resource (any two ERC-20 tokens) plus the execution venue (0x on Base), scoped to a named wallet. This is clearly differentiable from siblings like build_bnkr_buy or get_swap_price, which reads rather than builds a swap.

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 a concrete constraint that governs use – 'Native ETH is not swapped (wrap it first)' – which steers the agent away from an invalid invocation. It stops short of explicitly naming the alternative for pricing (get_swap_price) or a step-by-step when-to-use, so it is strong context but not full 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?

Goes well beyond annotations: it discloses that the output is unsigned transactions in order plus an EIP-5792 batch, that they are simulated from the wallet, that a sign_url is provided for a human owner, and that nothing is broadcast. The 'nothing is sent' framing also reconciles readOnlyHint=true with a builder tool, so there is no annotation contradiction.

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

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

Three dense sentences with zero filler, front-loading the action and mode choice, then the return shape, then the safety guarantee. 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 no output schema, the description carries the burden of describing returns and does so (ordered unsigned txs, batch form, simulated, sign_url). An agent has everything needed to invoke and to explain the result to the user.

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 schema already documents all four parameters including defaults and enums. The description only restates the receive default (USDC swapped vs AERO) and adds no syntax or format detail 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 — claim AERO rewards for a position — and immediately names the two output modes (USDC via swap, default, vs AERO). This is clearly distinguishable from siblings such as build_vault_deposit, build_vault_withdraw, or build_vault_move, which involve principal rather than rewards.

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?

Implies context ('The position keeps earning', default receive mode) but never states when to choose this over alternatives like build_vault_withdraw or build_vault_move, nor any prerequisites. Usage is inferable but not spelled out.

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?

Despite readOnlyHint already covering the safety profile, the description adds substantial context: about half the USDC is swapped to WETH in the same transaction, USDC approval is bundled when needed, the output is unsigned transactions to sign in order plus an EIP-5792 batch and a sign_url, simulated from the wallet, and 'Nothing is sent.' This is exactly the non-obvious behavior 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?

A single dense paragraph with the action front-loaded and no filler; each clause carries information. It is close to optimal, though the transaction/return details could be slightly more scannable.

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

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

With no output schema, the description carries the return-value burden itself and does so: it explains the unsigned transactions, the EIP-5792 batch, the sign_url, the simulation, and that nothing is broadcast. For a build_* tool with an already complete input 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 all five parameters are already documented, and the baseline is 3. The description does explain the two deposit modes (which maps to amount_usdc alone vs amount_usdc + amount_weth) and gives minimum thresholds, but it says nothing about auto_compound or the vault default, adding only marginal meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Open a new position in an automated vault with USDC... or with both WETH and USDC.' Combined with the name build_vault_deposit, it is immediately distinguishable from build_vault_withdraw, build_vault_top_up and build_curated_vault_deposit.

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 implies usage by describing the two deposit modes (USDC-only with an internal swap, or WETH+USDC) and gives concrete minimums, but it never states when to prefer this over siblings like build_vault_top_up (adding to an existing position) or build_curated_vault_deposit, nor when not to use it. Usage is only implied.

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

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

Beyond the annotations it discloses the fee waiver, single-transaction behavior, that results are simulated from the wallet, the EIP-5792 batching, and the sign_url for a human owner. 'Nothing is sent' reconciles the apparent move/readOnlyHint tension, so there is no contradiction. It stops short of describing failure modes when no counterpart vault exists.

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 dense sentences, front-loaded with the action and its condition, then the return shape, then the safety statement. 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?

No output schema, yet the description explains the return payload (unsigned txs, batch form, sign_url) and that nothing is broadcast. Precondition handling for the missing-counterpart-vault case is the only real gap.

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

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

Schema coverage is 100%, so the four parameters, their patterns, and which are optional are already documented. The description only adds the 'same pair' constraint tying to_vault to vault, which is marginal added value over 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 ('Move a position to another open Panda vault for the same pair in one transaction') and constrains it in a way that separates it from build_vault_deposit, build_vault_withdraw, and build_old_vault_migrate. An agent can tell what the tool 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?

The parenthetical '(only when such a vault exists)' gives an explicit applicability precondition. It does not, however, name the nearest alternative (build_old_vault_migrate) or say what to do when no such vault exists, so routing is implied rather than spelled out.

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/openWorld/idempotent/destructive hints, and the description still adds substantial value: it discloses that it returns unsigned transactions to sign in order, that they can be submitted as one EIP-5792 batch, that they are simulated from the wallet, that a sign_url is provided for a human owner, and that nothing is sent. This is meaningful workflow and safety 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?

Two sentences, front-loaded with the core on/off semantics followed by the return/behavior contract. Every clause earns its place; only minor room to tighten the parentheticals.

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

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

With no output schema, the description carries the return-value burden and does so well, describing unsigned transactions, batch form, simulation, and sign_url. What remains unstated — permissions or ordering caveats — is minor for a transaction-builder 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%, so all four parameters (including optional vault default and token_id source) are already documented in the schema. The description adds no format or semantic detail about the parameters, so the baseline of 3 applies.

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

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

States a specific verb+resource (set auto-compound on/off) and defines both modes inline — on means rewards are added back at each range move, off means rewards are paid out. An agent can tell exactly what the tool toggles and how it differs from sibling build_* tools.

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 two modes are clearly explained, so usage is implied, but there is no explicit when-to-use/when-not guidance, no mention of prerequisites (e.g., owning the position), and no named alternative among the many build_* siblings. Adequate but leaves routing to inference.

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

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

Rich disclosure beyond the annotations: the tool returns unsigned transactions in signing order (also as a single EIP-5792 batch), simulated from the wallet, plus a sign_url for a human owner, and 'Nothing is sent'. This explicitly operationalizes the readOnlyHint=true on what would otherwise read as a transaction-building tool, with no contradiction.

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

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

Two tight sentences, front-loaded with the action and its constraint, then the return/safety contract. No filler, no repetition of the title, and each clause carries information an agent needs.

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 present, the description does the work of describing the return shape (ordered unsigned txs, batch form, sign_url) and the simulation/no-send guarantee. It leaves unaddressed items like token approval prerequisites or gas handling, but the essential contract for calling and reasoning about the result 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?

Schema coverage is 100%, so the baseline is 3, but the description adds a real constraint the schema omits: the amount must be at least $1 and the top-up occurs 'in its current range'. That is meaningful semantic value on top of the already-documented parameters.

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: adding USDC to an existing position, scoped to its current range. The word 'existing' and 'Add to' distinguish it from build_vault_deposit and build_vault_withdraw, but no sibling is named explicitly, so the routing 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 description implies when to use it (topping up an existing position rather than opening a new one) but never names an alternative or states a when-not condition. The '$1 minimum' and 'current range' constraints give some usage context but the agent must infer the boundary against build_vault_deposit.

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?

Even though annotations declare readOnlyHint=true, the description adds substantial context the annotations cannot: it returns unsigned transactions to sign in order, packaged as one EIP-5792 batch, simulated from the wallet, plus a sign_url for a human owner, and explicitly states 'Nothing is sent'. This explains why the readOnly hint is coherent for a build/withdraw tool and discloses return shape, batching, and simulation 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?

Three dense sentences with the core action front-loaded; the payout default, edge case, and return mechanics each earn their place. The third sentence is long but information-dense rather than padded.

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

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

With no output schema, the description compensates by describing the return value (ordered unsigned txs, EIP-5792 batch, simulated from wallet, sign_url) and by noting nothing is broadcast. Combined with 100% schema coverage and clear payout options, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100% and the enums are self-documenting, so the schema already carries the parameter burden. The description reinforces the defaults (USDC/USDC) and the swap consequence of receive=BOTH, but adds only marginal meaning beyond the schema text, so the baseline 3 is 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 verb and resource ('Withdraw a whole position') and scopes it to a Panda vault position with USDC/WETH payout semantics. It is clearly distinguishable from partial-position siblings like build_vault_top_up or build_vault_move, but it never names the other withdraw builders (build_curated_vault_withdraw, build_old_vault_withdraw) it could be confused with.

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 'whole position' and the edge-case note that a closed position's leftovers are collected instead, which tells the agent this handles both open and closed cases. However, there is no explicit when-to-use vs. when-to-use-something-else routing against the many sibling withdraw builders.

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 disclosing the fee model (no Panda fee), the refusal threshold, the return contract (unsigned transactions in order plus an EIP-5792 batch), simulation source (simulated from the wallet), and a sign_url path for a human owner. The 'Nothing is sent' statement resolves the apparent tension between the withdraw name and readOnlyHint=true, confirming this only builds transactions.

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 action and target market, then layers the guardrail, fee, and return format in tight sentences. No filler and no restatement of the tool name or 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?

Although there is no output schema, the description fully specifies the return payload (ordered unsigned txs, EIP-5792 batch, sign_url) and the failure condition, so the agent knows both what comes back and when the call is rejected. Nothing material is missing for a 2-parameter build 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%, so both parameters (wallet, amount_weth, including the "all" sentinel) are already fully documented in the schema. The description adds no parameter-level format or edge-case detail beyond that, 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 (withdraw), resource (WETH collateral), and disambiguating scope (the Morpho WETH/USDC market), which cleanly separates it from siblings like build_lend_withdraw, build_vault_withdraw, and build_borrow. An agent can identify the exact position type being acted on 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 a concrete precondition/refusal rule (refused past 86% LTV) that tells the agent when this call is valid versus when it will fail. It does not explicitly name alternative tools or required prerequisites (e.g., an existing borrow position), so it stops short of full when/when-not/alternatives 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, non-destructive and closed-world, so the safety profile is covered. The description goes beyond that by disclosing the actual evaluation rules the contract applies (no existing referrer, no prior Panda vault deposit, not self-referral, no circular referral), which is real behavioral content an agent cannot get from the annotations. It omits return shape and any failure conditions, keeping it short of 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?

A single sentence that front-loads the answer being produced and then lists the conditions. Every clause earns its place; the only minor cost is the dense trailing enumeration of rules, which is justified by the value it adds.

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

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

With no output schema, the description carries the burden of explaining what the check returns, and it does not say whether the result is a boolean, a reason string, or a reason code for a false outcome. Given two fully documented params and complete annotations, most of the call contract is covered, but the omitted return semantics leave a visible gap for a pure query 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 the schema itself explains that 'wallet' is the signing wallet owning positions and that 'referrer' is a ?ref= value or legacy 6-character code. The description adds no parameter-specific syntax, format, or validation detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific resource and predicate ('whether a wallet may accept a referrer') and enumerates the exact contract conditions that determine the answer. It clearly separates this read-only check from the build_* mutation siblings by describing an evaluation rather than an action. It does not, however, name build_referral_accept or get_referral_link as relatives, so sibling differentiation is implicit rather than explicit.

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

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

There is no explicit when-to-use statement: the description never says 'call this before build_referral_accept' or 'use this instead of attempting the action and reading the revert'. The pre-check intent is only implied by the tool name and the build_referral_accept sibling. No exclusions or alternatives are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. What the description adds is the return payload itself (staked, rewards ready, multiplier, unstaking queue, withdrawable now, balances, BNKR price), which is essential since no output schema exists. It omits edge behavior such as the empty/no-position case, so it falls short of 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?

A single front-loaded sentence with no filler; every listed field earns its place because there is no output schema to carry them. It is a noun-phrase fragment rather than a sentence, which costs a point but does not obscure meaning.

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

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

For a one-parameter read tool with no output schema, the description successfully substitutes for the missing return-value documentation by enumerating the fields the agent will receive. It does not clarify whether a wallet with no position returns an empty object or an error, which is the main remaining 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?

The single wallet parameter has 100% schema description coverage, including the 0x-address pattern and the note that it is the Base wallet that signs and owns the position. The description adds nothing beyond that, so the schema-covered baseline of 3 applies.

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

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

The description names a specific resource (a wallet's stake in Bankr's BNKR staking contract) and enumerates the exact state it reports, so the agent can tell it apart from the build_bnkr_* write builders. It lacks an explicit verb (read/fetch) and never contrasts itself with the broader get_defi_positions or get_wallet_positions siblings, which keeps it short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative, even though get_defi_positions and get_wallet_positions overlap in scope. Usage is only inferable from the resource named in the title.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the return contents in detail (vault deposit, USDC lent, WETH collateral, borrowed, health factor, liquidation price, rates), which is valuable given there is no output schema.

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

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

It is a single dense sentence, but front-loaded on the primary resource and every clause carries substantive return information rather than filler. It could be broken into two sentences for readability, 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?

With no output schema, the description does the heavy lifting of enumerating what comes back, and the sole required parameter is fully documented in the schema. Annotations cover the safety profile. The main gap is routing guidance relative to overlapping sibling read 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?

With a single parameter and 100% schema description coverage, the schema already fully documents the wallet argument (format pattern, Base chain, ownership semantics). The description adds nothing beyond that, so the baseline 3 applies.

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

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

The description names the specific resources returned: the wallet's Curated Vault deposit (Steakhouse Prime USDC on Morpho) and its Morpho WETH/USDC lending position, plus rates and balances. That is far more specific than a generic 'get positions'. It does not, however, distinguish itself from siblings like get_wallet_positions or get_wallet_balances, which an agent must choose between.

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 guidance and no mention of alternatives, despite several sibling read tools (get_wallet_positions, get_old_vault_positions, get_wallet_balances) that overlap in scope. Usage must be inferred from the content list alone.

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

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

Annotations already declare readOnly=true, idempotent=true, openWorld=false, so safety is covered. The description adds genuine domain context beyond them: the vault is legacy, it is withdraw-only from a specific date, and the response includes rewards ready to claim. It does not disclose pagination or empty-result behavior, hence 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?

One densely packed sentence with the identity of the resource first, then the qualifying constraint, then the returned contents. No filler and nothing buried.

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

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

For a one-parameter read tool with no output schema, the description usefully enumerates what comes back (value, tokens, rewards ready) and flags the vault's withdraw-only state. Complete enough to call correctly; only the absence of any empty/zero-position or pagination note keeps it from a 5.

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?

Single parameter with 100% schema description coverage — the schema already documents the address format and that the wallet both signs and owns the positions. The description adds nothing parameter-specific, 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?

Specific verb+resource: reads a wallet's remaining positions in Panda's OLD vault, and the parenthetical 'withdraw-only since 2026-10-04' differentiates it from the generic get_wallet_positions sibling. An agent can tell this is the legacy-vault read path without opening the schema.

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

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

Usage is implied rather than stated: 'still has in ... OLD vault' and 'withdraw-only' signal the legacy-migration context, but the description never says when to call this instead of get_wallet_positions or that build_old_vault_migrate/build_old_vault_withdraw are the follow-up actions. The agent must infer the 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 readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds domain context (fees, minimums, signing flow) but says nothing about return format, freshness, or size, so it earns only moderate credit 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?

Two short sentences, front-loaded with the imperative 'Start here.' and then an efficient enumeration of covered topics. 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?

With no output schema and no parameters, the description carries the burden of setting expectations, and it does so by enumerating the content areas the overview covers. An agent knows what it will get and when to use it; only the actual return format remains implicit, which is a minor 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?

The tool takes zero parameters, so per the baseline this dimension is a 4. There is no parameter semantics to document, and the empty schema is consistent with the description's framing as a parameterless info-retrieval call.

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

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

The description names exactly what this tool returns—an orientation document covering 'What Panda offers on Base, which tool does what, fees, minimums, how signing works and every contract a transaction may touch.' This makes it unmistakably distinct from all the build_*/get_* action siblings, which an agent can recognize 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?

'Start here.' is an explicit, directive when-to-use signal, telling the agent to call this first before acting. It does not name when-not-to-use or specific alternatives, but for an entry-point orientation tool the context 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, destructiveHint=false and closed-world, so the safety profile is covered. The description goes beyond that with genuinely useful economics: 1% of Panda's reward fee, paid in AERO in the same transaction as each fee, by the fee policy contract, with no tiers and nothing to claim. That explains the payout mechanism an agent may need to relay, though it says nothing about result shape or edge cases.

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

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

Two tight sentences: the first front-loads what is returned, the second explains the economics and preempts a likely agent question ('is there anything to claim?'). Some economic detail is arguably beyond selection needs, keeping it from a 5.

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

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

With no output schema, the description carries the burden of describing returns, and it does list the three returned items. It does not specify shape or ordering (e.g., a list of referred wallet addresses), a minor gap, but overall sufficient for a single-parameter read tool whose annotations cover the rest.

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

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

Schema coverage is 100% with a precise pattern and description for 'wallet', so the baseline is 3. The description adds real meaning by revealing that the wallet address itself is the referral code, which is not derivable from the schema. A modest but genuine addition.

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 the exact resource and its payload: the wallet's own Panda invite link, the wallets it referred, and what the fee policy has paid it. That is concrete and distinguishable from generic getters. It does not, however, explicitly distinguish itself from the sibling check_referral_eligibility, so a 4 rather than a 5.

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

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

Usage is only implied: it is a read-only getter of referral state, and 'No tiers, nothing to claim' hints that no action tool is needed. However, it never states when to call this versus check_referral_eligibility or build_referral_accept, nor any prerequisites. Minimum-viable guidance rather than explicit 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 cover readOnly/idempotent/non-destructive, and the description goes further by disclosing the fee structure (0.15% Panda in the sold token + 0.15% 0x), that the price is live ('right now'), and that no wallet is required. Return contents are also enumerated, though the response format itself is not described.

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 with parenthetical asides; the key fact (a live quote through 0x) is front-loaded and every clause adds information. Slightly packed, 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 no output schema, the description must carry the return-shape burden, and it does list amount out, fees, and sources. Missing only edge-case behavior (unsupported tokens, price staleness), which is minor for a read-only quote 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%, so the schema already documents amount, tokens, and slippage_bps thoroughly. The description adds only the detail that the Panda fee is denominated in the sold token, which does not meaningfully enrich parameter semantics beyond the schema.

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

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

The description states a specific verb and resource ('What swapping one token for another on Base would return right now'), names the routing provider (0x), and previews the exact output (amount out, fees, sources). This clearly separates it from the build_* siblings that actually construct swap transactions.

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 wallet needed' implies this is a pre-trade quote, which hints at when to use it relative to build_swap, but no alternative is named and there is no explicit when/when-not guidance or prerequisite statement. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description goes beyond that by disclosing what the result contains (sender token deltas, vault/staking events, position id, rewards, withdrawals), which is genuinely useful since no output schema exists. It does not address pending/failed-verification edge cases.

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

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

One sentence with no filler, and the core purpose ('whether a Base transaction succeeded') is front-loaded ahead of the parenthetical return details. The nested 'and/or' listing makes the second half harder to parse than necessary, 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?

With no output schema, the description must carry the return-value burden, and it does reasonably well by naming the categories of data returned. It also anchors the tool to Base. Missing: behavior for pending, reverted for unrelated reasons, or unrecognized hashes, which is the main remaining gap for a single-parameter lookup 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?

There is a single parameter with 100% schema description coverage (the schema documents 'hash' with a 0x-prefixed 64-hex pattern). The description adds no extra meaning about the hash — no note that it must be a Base mainnet tx hash, even though Base is named in passing — so the baseline 3 applies.

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

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

The description states a specific question the tool answers — whether a Base transaction succeeded — and enumerates the effects it reports (token changes, vault/staking events, new position id, rewards, withdrawals). This clearly separates it from the build_* siblings, which construct transactions rather than inspect them. The sentence is grammatically tangled ('the token changes for its sender and the Panda vault or staking events it emitted'), which slightly blurs what exactly is returned.

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 can infer this is the post-submission lookup to call after a build_* tool, since it takes a tx hash. There is no explicit when-to-use statement, no mention of what to do if the hash is unknown, not yet mined, or on another chain, and no named alternative.

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, closed-world behavior, so the safety profile is covered. The description adds useful content-level disclosure (which tokens, that values are denominated in dollars), but says nothing about what happens for absent tokens, whether balances are live vs cached, or the return shape in the absence of an 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?

A single short sentence with zero waste, front-loading the token coverage and ending with the dollar-value behavior. It is a verbless fragment, which slightly weakens structure but not conciseness.

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

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

With no output schema, the description carries the burden of explaining the return content, and it does list the tokens and dollar values. However, it omits whether zero balances are returned, whether other tokens can appear, and any freshness/chain caveats, leaving the response shape only partially characterized.

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

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

Schema description coverage is 100% and the single wallet parameter is fully documented with a pattern and meaning, so the baseline is 3. The description adds no format or constraint detail 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?

The description names the exact resource (token balances for a wallet), the chain (Base), and the specific tokens covered (ETH, USDC, WETH, AERO, BNKR) plus dollar valuation, which implicitly separates it from generic position tools. It never states the verb explicitly or names get_wallet_positions/get_defi_positions as the alternative, so an agent must infer the boundary.

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

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

There is no when-to-use, when-not-to-use, or alternative routing guidance, despite three sibling position/balance readers (get_wallet_positions, get_defi_positions, get_old_vault_positions) that could plausibly be confused with it. The token list hints at scope but does not tell the agent which tool to pick.

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 closed-world, so the safety profile is covered. The description adds real value by disclosing exactly what the payload contains (value, tokens, price range, earning status, claimable rewards, lifetime earnings, deposits, net result, live APR), which matters because there is no output schema.

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

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

A single sentence that front-loads the scope ('Every open position a wallet has in the automated vaults') before the field list. The enumeration is dense but earns its place given the absence of an output schema; a slightly tighter grouping of the fields would read better.

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

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

With no output schema, the description correctly compensates by enumerating return fields, and 'open position' clearly excludes closed/withdrawn positions. It never states behavior for a wallet with no positions or how stale the 'live' figures may be, which are the remaining minor 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?

Only one parameter and schema coverage is 100%, so the schema fully documents the wallet address, its 0x pattern and the Base-chain signing semantics. The description adds no meaning beyond that, which is the expected baseline when the schema does the work.

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

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

States a clear verb+resource (retrieves every open vault position for a wallet) and enumerates the payload fields. It implicitly scopes to 'automated vaults' and 'open' positions, which separates it from get_old_vault_positions and get_defi_positions, but it never names those siblings explicitly.

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

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

No when-to-use or when-not-to-use guidance is given. With three closely named position tools in the sibling list (get_defi_positions, get_old_vault_positions, get_bankr_position), the description leaves the agent to infer which one applies. The closest thing to guidance is the parenthetical 'the figures the website shows'.

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=false and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about returned data and that fee rates are wallet-specific, but says nothing about pagination, result size, or ordering.

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 with no filler, front-loaded with the resource. The trailing field enumeration is somewhat list-like but each item earns its place given the absence of an output schema.

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

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

With no output schema, the description usefully enumerates what comes back (pair, deposit status, fee rates, deposits, depositors, rewards, reward stream), and annotations carry the safety profile. Missing only secondary read details like pagination or ordering.

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 lone optional wallet parameter is fully documented in the schema, making the baseline a 3. The description reinforces the wallet/fee-rate link ('fee rates (for a wallet when given)'), adding only marginal value beyond the schema.

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

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

The title plus description make clear this returns information about automated liquidity vaults, and no sibling is a competing 'list vaults' tool (the others are build_* mutations or get_* position queries). The description leans on a field listing rather than a crisp verb, but the resource and its scope are unambiguous.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no routing to or away from alternatives. The agent must infer that this is the read-only discovery call preceding the build_vault_* family. Nothing states exclusions or context conditions.

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