metalend

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

The description adds substantial behavioral context beyond the annotations, including the deliberate caching behavior for repeated walletAddress calls, the one-pending-challenge-per-wallet invalidation effect, the cosmetic nature of chain, and the rate limits. This is exactly the kind of non-obvious runtime behavior an agent needs to avoid misinterpreting repeated same-message responses as a bug.

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

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

The description is dense but every sentence carries essential information: purpose, prerequisite role, signing flow, non-authentication clarification, idempotent caching semantics, chain behavior, and rate limits. It is front-loaded with the core purpose and then layers critical caveats without redundancy.

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

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

Given the tool's central role in an authentication precondition flow, the description covers all invocations-critical facts: what to do with the returned message, how to proceed next, the caching behavior that could otherwise confuse agents, rate limiting, and parameter nuances. The lack of an output schema is mitigated because the description clearly references the returned message and its intended use.

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 both parameters. The description adds meaningful extra nuance: chain is cosmetic and need not match the chain passed to submit_auth_verify, and walletAddress casing is normalized to EIP-55. This goes beyond the baseline schema descriptions and helps the agent use the parameters correctly.

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

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

The description clearly states the specific action: obtaining a Sign-In-With-Ethereum challenge message for a wallet. It also differentiates itself from submit_auth_verify by explicitly noting that this tool does NOT authenticate and only issues the message to sign, making its role unmistakable among the sibling 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 description gives explicit when-to-use guidance: it is required before any deposit/withdrawal/config-update tool. It also explains the exact follow-up flow—sign the message with personal_sign and pass it to submit_auth_verify—and clarifies that the tool itself does not perform authentication, so an agent knows not to treat it as the final auth step.

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 it read-only and non-destructive, and the description adds useful behavioral detail beyond that: it fails when no rebalancer exists, is rate limited to 5 calls/minute, and its balances already deduct on-behalf gas fees so the total may be lower than lifetime deposits. This is exactly the kind of contextual 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?

The core purpose is front-loaded in the first sentence, and subsequent sentences each carry a distinct caveat, routing rule, or behavioral note. It is wordier than strictly necessary, but the tool is complex and the added sentences all earn their place.

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

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

For a read-only tool with no output schema, the description supplies all the context an agent needs: return content (including rebalancerAddress and withdrawRequest data), exclusions, failure mode, rate limit, and the gas-fee/funds semantics. Nothing critical to selecting or calling the tool 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% and the schema already documents walletAddress as the user-owned address and tokens as an optional comma-separated filter. The description repeats the rebalancerAddress caveat but does not materially add parameter meaning beyond the structured input schema, so the high-coverage 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 opens with a specific verb and resource: 'Get a wallet's deployed rebalancer balances' and then scopes the result by token, chain, protocol/pool, net earnings, and blended APY. It explicitly contrasts itself with get_config and list_pools, so an agent can distinguish it from sibling tools without opening their schemas.

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

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

It gives explicit routing guidance: use get_config for rebalancingManagerAddress, list_pools for pool catalog data the wallet isn't in, and get_default_config when the wallet has no rebalancer yet. It also states a hard failure condition and rate limit, leaving little ambiguity about when to call this tool.

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 the operation as read-only and non-destructive, and the description adds substantial behavioral context beyond that: sourcePool null vs populated semantics, isForSpending meaning, absence of trackingId and correlation limits, and rate limits. These details materially shape caller expectations.

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

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

The description is long but every sentence earns its place: it front-loads the core purpose, then adds exclusions, token scope, field semantics, tracking limitation, and rate limits. No wasted wording or redundant restating 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?

Despite lacking an output schema, the description tells the agent what to expect: in-transit balances, estimated completion time, entry-level fields (sourcePool, isForSpending), the lack of trackingId, and rate limiting. For a read-only one-parameter tool, this is a complete operational picture.

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 fully documents walletAddress, including format and EIP-55 normalization. The description adds no additional parameter-level semantics, but the baseline of 3 is appropriate because the schema does the heavy lifting.

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

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

States a specific verb ('Get') and resource ('a wallet's in-transit USDC bridge balances') with explicit scope ('funds moving cross-chain toward a destination pool'). It also explicitly contrasts with get_balances and get_deposit_status, making the tool's purpose distinct from siblings.

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

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

Provides explicit guidance on when to use this tool versus alternatives: use get_balances for already-settled rebalancer balances, and use get_deposit_status with a trackingId to track a specific deposit. Also states USDC-only applicability, which rules out other tokens.

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 the tool read-only/non-destructive, but the description layers substantial additional behavior: spendingCapRaw is not a spending limit, template entries always exist, hasSignedConfig determines reality, gas-fee drift can occur between polls, and rate limits are stated. This far exceeds 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?

The description is long but densely packed and front-loaded with the core purpose before diving into caveats. Backticked field names and clear warnings keep it navigable; it could be tightened slightly, but nearly every sentence earns its place.

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

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

Despite lacking an output schema, the description tells the agent which fields are returned, how to interpret edge cases, what to do when no config exists, and the rate limit. For a read-only config query, nothing essential 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%; the only parameter, walletAddress, is fully documented in the schema including formatting and normalization. The description adds wallet-level behavioral context but no new parameter syntax, so the baseline of 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 ('Get') and resource ('a wallet's current rebalancer configuration per token'), enumerates the included fields, and explicitly differentiates from get_balances and get_default_config. This makes sibling selection 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?

Directly instructs to use get_balances for live balances and get_default_config for recommended starting values when rebalancerExists is false. Also clarifies what this tool is not, with explicit exclusions and alternatives.

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 this as read-only and non-destructive, so the safety profile is covered. The description adds value by disclosing the rate limit (20 calls/minute, max one per 3 seconds) and by stating that the returned config is a 'recommended default' rather than an authoritative current state. No contradiction 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 sentences, each carrying distinct value: the operation and output, the intended use case and alternative, and rate-limit constraints. The most identifying information is front-loaded and there is no filler or repetition.

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

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

For a simple read-only tool with one parameter and no output schema, the description covers what the call returns, when to use it, when not to use it, and operational constraints. No critical information 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 for the single token parameter is 100%, with the schema already explaining it is a token symbol and providing examples. The description echoes this but does not add new meaning beyond the schema, such as validation rules or supported-token caveats, so 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 ('Get'), a resource ('MetaLend's recommended default rebalancer configuration'), and a target ('given token symbol'), and lists the returned fields. It also explicitly distinguishes itself from the sibling get_config, making its purpose 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?

The description gives a clear when-to-use condition ('Intended for wallets with no existing config yet') and names the alternative tool for the opposite case ('for an existing wallet's current config use get_config instead'). It also adds practical rate-limit guidance, which helps agents avoid throttling.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses key behavioral details: the meaning and terminality of each status, the EMERGENCY_WITHDRAW auto-send-back behavior, the timeframes for BRIDGING and resolution, and the rate limit. This is rich, non-redundant context that materially changes how the agent should act.

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

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

The description is long, but nearly every sentence carries operational meaning—status definitions, stop-polling guidance, and rate limits are all necessary. It is slightly dense as a single paragraph, and a bulleted list would improve scannability, but it remains well front-loaded with the core purpose and does not waste words.

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 full burden of explaining the tool's return values, and it does so exhaustively: all possible status values, their implications, terminality, and the rate limit. For a polling tool with one parameter and a read-only annotation, nothing critical is missing for correct invocation.

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

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

The schema already fully describes the only parameter: 'trackingId returned by submit_deposit.' The tool description merely repeats that same mapping without adding new semantics, such as format expectations or examples. Baseline 3 applies because schema description coverage is 100%.

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

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

The description opens with a clear verb and resource: 'Poll the status of a deposit by trackingId (returned by submit_deposit).' This unambiguously identifies the tool's action and target. However, it does not explicitly differentiate from sibling tools like get_withdrawal_status, relying on the tool name and the word 'deposit' to make the distinction.

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 gives explicit when-to-use (poll a deposit status) and explicit when-not-to-use instructions: 'do NOT keep polling waiting for the bridge to finish' and 'you do not need to wait for it after BRIDGING.' It also adds polling cadence guidance ('Rate limited to 20 calls/minute per caller, no more than one call every 3s'), which helps the agent avoid misuse.

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 adds substantial behavioral context beyond that: no claim endpoint, no RPC access, rate limits (20/min, 1 per 3s), and detailed claimTransaction semantics including the meaning of absence. No contradiction with annotations.

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

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

The description is long but information-dense, covering purpose, exclusions, behavioral caveats, and rate limits. It is front-loaded with the core function and every sentence carries important information, though a multi-paragraph or bulleted structure might aid scannability.

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

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

Given there is no output schema, the description compensates by explicitly explaining the rewards[].rewardItems[] shape, claimTransaction presence/absence semantics, chain-specific behavior, and rate limits. It covers all aspects an agent needs to call and interpret the tool 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?

Input schema coverage is 100%, with both walletAddress and reloadChain fully described. The description adds no additional parameter-level meaning beyond the schema; the rate-limit note is operational context, not parameter semantics. 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: 'Get a wallet's aggregated rewards/earnings across all reward sources (e.g. Merkle)', including claimed/available USD totals. It also explicitly excludes base rebalancer yield/APY and directs that to get_balances, making it easy to distinguish from sibling 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?

Provides clear when-to-use and when-not-to-use guidance: it tells the agent that base rebalancer yield is not included and can be found in get_balances' netEarning field. It also states there is no backend claim endpoint and no RPC access, so the tool cannot be used for claiming. Rate limits are included as operational 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 this as readOnly and non-destructive. The description adds valuable behavioral context beyond annotations by documenting the rate limit (6 calls/minute, max one call every 10s) and the specific role in the deposit-signature workflow. No contradiction exists between the description and annotations.

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

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

The description is only two sentences and every clause earns its place: the core action, the returned metadata, the contextual trigger, and the rate limit. It is front-loaded with the primary verb and resource, and has no fluff.

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 simple two-parameter read-only tool, the description covers what the tool does, what it returns (display name, decimals, EIP-712 version), when to use it, and critical rate-limiting constraints. The lack of an output schema is mitigated because the description names the return fields explicitly.

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 fully documents both parameters (token, chain) with examples. The description adds the metadata fields and EIP-3009 context, but does not significantly extend parameter-level meaning beyond the schema, matching the baseline of 3 for high coverage.

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

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

The description states a specific verb ('Get') with a precise resource ('a token's on-chain metadata') and includes concrete metadata fields (display name, decimals, EIP-712 version). It also ties the purpose to a specific use case (building an EIP-3009 deposit signature), making it clearly distinct from sibling get_* tools such as get_balances or get_config.

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 explicitly says this tool is 'Needed when building an EIP-3009 deposit signature's tokenName/tokenVersion fields', giving clear context for when to use it. It does not compare against alternatives or state when not to use it, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: rate limiting (20 calls/minute, one call per 3s) and the per-chain, constant-cost nature of the data.

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

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

Three sentences, each earning its place: one defines the tool's output, one gives usage context, and one gives rate-limit guidance. No filler or redundancy.

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

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

For a single-parameter, read-only tool with annotations covering safety, the description is complete: it states what data is returned, the per-chain breakdown, when to use it, and rate limits. No critical information 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%, and the token parameter is already well documented with examples. The description adds context about what the costs are used for, but not materially new parameter-level 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 uses a specific verb ('Get') and precisely identifies the resource: constant on-behalf deposit/withdraw gas costs and minimum deposit/withdraw amounts for a token, broken down per chain. This clearly distinguishes it from sibling tools like get_token_info or get_balances.

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 explicitly states when to use the tool: 'Use before a deposit to check the amount meets the chain's minimum.' It gives clear context but does not mention exclusions or alternative tools, so it stops short of a 5.

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

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

The annotations already mark this as read-only and non-destructive, but the description adds substantial behavioral detail beyond that: the meaning of each status value, which states are terminal vs in-progress, and the rate limit (20 calls/minute, one call every 3s). No contradiction with annotations.

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

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

The description is three sentences, each earning its place: purpose, status semantics, and rate limit. It is front-loaded with the action and resource, and contains no fluff or repetition.

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

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

For a one-parameter read-only poller with no output schema, the description conveys the essential operational details: status values, terminality, and rate limits. It doesn't explicitly outline the full response object shape, but the '`status` is one of' phrasing provides enough for an agent to invoke and interpret the call 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% and the single parameter trackingId is already described in the schema. The description repeats the 'returned by submit_withdrawal' origin but adds no new parameter-level meaning, 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?

The description states a specific verb ('Poll'), a clear resource ('status of a withdrawal'), and the key input ('trackingId'). It also differentiates from the sibling get_deposit_status by noting withdrawals have no cross-chain bridging leg, unlike deposits, so an agent can distinguish between the two 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 description gives explicit polling behavior: keep polling while PROCESSING and stop at terminal states (SUCCESS/FAILED). It also provides concrete rate limit guidance. It does not explicitly name get_deposit_status as the alternative for deposits, but the 'unlike deposits' note provides strong contextual 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 the tool as read-only and non-destructive, so the description adds useful behavioral context: the value is rarely changes, cacheable, and rate limited to 10 calls/minute with a 6-second minimum interval. This goes beyond the structured metadata without 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?

Three short sentences, each earning its place: the first states the function, the second gives caching guidance, and the third documents the rate limit. No redundant or filler content.

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

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

For a zero-parameter, read-only getter, this description fully covers what the agent needs to know: what the version is for, that it can be cached, and the rate limit. No output schema exists, but the return value is simply described as a version string, which is sufficient for this tool's simplicity.

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 has zero parameters and the schema coverage is 100%, so there is no parameter ambiguity. The description adds semantic context about what the returned string is used for, which is more than necessary for an empty-schema tool.

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: get the contract signing version string. It also explains what the version is for (EIP-712 domain data when signing a withdrawal), making its purpose clear and distinct from sibling getters like get_config or get_withdrawal_status.

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?

Describes when the tool matters: it is required when signing a withdrawal, and it explicitly says the value rarely changes and is safe to cache client-side. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for a no-parameter getter.

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, openWorldHint, destructiveHint), the description discloses important behavioral traits: the ambiguity of zero TVL/liquidity values, the absence of pool-level paused/capacity flags, and how deposit/withdrawal restrictions manifest only at submission time. It also discloses rate limiting. These are meaningful additions beyond what annotations already provide, 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?

The description is long but every sentence earns its place: purpose and output fields first, exclusions second, data caveats and operational limitations next, rate limit last. It is front-loaded with the core purpose and structured logically. Despite length, there is no filler or redundant restating 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?

Given there is no output schema, the description fully covers return values, filtering expectations, data ambiguity, unavailable flags, and rate limits. An agent has enough information to call the tool correctly, interpret results accurately, and avoid misusing it for wallet-level queries. The combination of annotations and description leaves no material 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?

The tool has zero parameters, so there is no parameter documentation burden on the description. The schema coverage is 100% by virtue of having no properties. The description instead clarifies semantics of returned fields (blacklisted, poolTvl/poolLiquidity) which is useful, meeting the expected baseline for a parameterless tool.

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 ('List all pools MetaLend's rebalancer can deposit into') and enumerates the returned fields (protocol, chain, APY breakdown, TVL, liquidity, signData). It explicitly differentiates from get_balances/get_config by stating what it does NOT return, so an agent can distinguish it from siblings without opening schemas.

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

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

The description provides explicit exclusions and alternatives: use get_balances/get_config for wallet balances/configuration, and notes that pause/withdrawal-blocking states appear only as errors from submit_deposit/submit_withdrawal. It also gives practical usage guidance on filtering blacklisted pools and rate-limit constraints. This is clear, context-rich guidance with no ambiguity.

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

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

The annotations already mark the tool as read-only and non-destructive, and the description adds substantial behavioral detail: exact hash construction, raw-bytes signing requirement, refusal conditions, rate limiting, lack of pre-validation for submit_config 409s, and cross-chain ERC-1271/ERC-6492 verification caveats. No contradiction with the annotations 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?

The description is long, but it is front-loaded with the core action and signing instruction, and every subsequent clause addresses a real validation, edge case, or downstream failure mode. Some ERC-6492 material is also present in the schema, so there is mild repetition, but the density is justified by the tool's complexity.

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 still explains the key return artifact (hashToSign), exactly how to sign it, what to do with the signature, all pre-signing rejection cases, and how to treat downstream 409 responses. An agent has enough context to invoke the tool correctly and interpret its result.

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

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

Schema coverage is 100%, so the parameter descriptions already carry the full load. The description still adds cross-parameter meaning: the tuple relationship between protocolIds, poolAddresses, and domainIds, the collateralExposure/Aave-pool coupling, requiredTvl precision handling, and the exact field order used in the signed hash. This goes beyond a baseline schema-only assessment.

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 action — build a server-side keccak256 signing hash for a wallet's rebalancer config update — and explicitly states it does not sign anything. It also distinguishes itself from submit_config by saying the signature must be passed there, making the tool's role in the flow 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?

The description gives explicit workflow guidance: call this before submit_config, use prepare_withdrawal before retrying when a held pool would be dropped, copy current values from get_config when reconfiguring, and consult list_pools for valid pool tuples. It also warns about the non-prevalidated 409 from submit_config and explains smart-contract wallet domain restrictions.

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 already declare readOnlyHint=true and destructiveHint=false, the description adds substantial behavioral context beyond them: the server has no RPC access and cannot broadcast approvals, smart-contract wallets (incl. ERC-6492) are rejected from the signature flow, a fixed on-behalf gas fee is deducted from amount, the server validates the signed-config prerequisite and minimum deposit before returning, and a 6 calls/minute rate limit applies. No contradiction with the annotations; rather, the description enriches the read-only semantics with concrete constraints.

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?

Every sentence earns its place—there is no filler and the core purpose is front-loaded. However, the content is delivered as one dense unbroken paragraph (~300 words), with the chain caveat partially duplicated between the description and the chain parameter schema. Given the tool's genuine complexity (two flows, wallet-type restrictions, fees, prerequsstes), the length is justified, but bullet-point structuring or paragraph breaks would improve scannability for an agent.

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 tool with no output schema, the description steps up admirably: it describes what each flow returns (EIP-712 payload vs approve() params), names key response fields (fee, expectedCreditedAmountRaw), states preconditions (signed config, minimum deposit validation), covers rate limits, and explains the follow-up call (submit_deposit). An agent has everything needed to invoke it correctly and chain the result into the next step.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning far beyond the schema: it classifies tokens into gasless (USDC, MUSD, PYUSD) vs approval-only (USDT, RLUSD, USDG, USDE) groups, explains that the gas fee reduces the credited amount so expectedCreditedAmountRaw—not amount—is what appears in get_balances, and clarifies the chain parameter's cross-chain nuance and its irrelevance for EOA signatures. These interactions are critical for correct invocation and are absent from 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 opens with a specific verb-resource-scope statement: 'Build everything needed to deposit into MetaLend's rebalancer, without signing anything.' It clearly differentiates from sibling submit_deposit (which consumes the prepared payload) and prepare_withdrawal (opposite direction), and names the two distinct output artifacts (EIP-712 typed-data vs approve() parameters). An agent can tell exactly what this tool produces and what it does not do.

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

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

Explicit when-to-use and routing guidance is abundant: it names prepare_config/submit_config as a prerequisite when get_config shows no signed config, directs the signature payload to submit_deposit, states that the wallet must broadcast the approval itself for approval-only tokens, instructs smart-contract wallets to pass method:'approval', and points to get_transaction_costs and get_balances for related needs. Nothing is left to inference.

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

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

With readOnlyHint=true already declared, the description still adds substantial behavioral detail: it does not sign anything, uses the maxUint256 convention, includes a liquidity guard that prevents useless signatures, deducts a fixed fee, and warns about rate limits. This goes well beyond the annotations and helps the agent understand side effects and failure modes.

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

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

The description is long but every sentence carries decision-relevant information, and the primary purpose is front-loaded in the first sentence. It could be slightly more structured with a visible break between the core function and the caveats, but nothing is redundant and the density is appropriate for a multi-caveat 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?

For a tool with no output schema, the description covers the most important return fields (`fee`, `expectedReceivedAmountRaw`) and the key behavioral edge cases (MAX, chain ambiguity, liquidity refusal, fee deduction). It stops short of fully specifying the returned typed-data envelope, but an agent can still correctly invoke and interpret the result without missing critical information.

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 real value beyond the schema: it explains the MAX/maxUint256 semantics for `amount`, why `chain` is required for shared addresses, and that `poolContract` should be sourced from get_balances. It doesn't add much for `token` or `walletAddress`, but the schema already covers those clearly.

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

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

The first sentence states a specific verb ('Build') and resource ('EIP-712 typed-data payload to sign for withdrawing from a specific pool'), and adds 'without signing anything' to distinguish it from actual withdrawal execution. It also names submit_withdrawal as the follow-up, so an agent can immediately tell this tool prepares rather than submits.

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 explicitly routes the agent to pass the resulting signature to submit_withdrawal, which is the correct next step. It gives concrete conditions for when to omit `amount` (full withdrawal), why `chain` is required despite the schema, and when the tool refuses to build typedData, giving clear 'do/don't' guidance beyond generic context.

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

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

The annotations only indicate non-read-only and non-destructive; the description carries the behavioral detail. It discloses that the server does not cache or store the JWT, that the JWT is wallet-scoped, that expiration comes from the JWT's exp claim, and that the endpoint is rate limited to 5 calls/minute with a 12s minimum interval. This goes well beyond the structured 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?

Four dense sentences, each earning its place: the exchange purpose, downstream consumption requirement, wallet-scoping constraint, and rate-limiting constraint. The most operationally important details are front-loaded after a one-sentence purpose, with no filler.

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

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

With no output schema, the description still names the key return values (jwt and expiresAt) and explains how to consume and reuse them. It also covers relevant failure modes and rate limits, making the tool safely callable with just the provided description and schema.

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 input schema already documents all three parameters at 100% coverage, including chain behavior, address normalization, and signature type. The description reinforces wallet scoping and signature origin but adds no new field-level semantics beyond the schema. A baseline 3 is appropriate because the schema does the heavy lifting.

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

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

States a specific exchange: a signed SIWE challenge message from get_auth_challenge is turned into a JWT scoped to a wallet. This clearly differentiates it from the sibling get_auth_challenge, which produces the challenge rather than consuming the signature.

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

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

Explicitly tells the agent to pass the returned jwt to submit_deposit/submit_withdrawal/submit_config, to reuse the same jwt, and that using it for a different wallet will be rejected upstream. It also states the rate limit, so an agent knows when calls may fail. This is direct, actionable usage 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?

Beyond the annotations, the description discloses important non-obvious behaviors: the tool relies on external signing artifacts, can 409 under conditions prepare_config could not catch, may time out after the backend has accepted the update, and is rate limited. This adds real value beyond the basic readOnly/destructive flags.

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

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

The description is dense but every sentence carries operational value: sequencing, failure modes, retry guidance, timeout consequences, and rate limits. It is front-loaded with the most important prerequisite and avoids filler.

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

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

For a complex 12-parameter write operation with no output schema, the description covers prerequisites, error conditions, rate limits, timeout ambiguity, and post-call verification. Together with the fully described input schema, an agent has enough information 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 the baseline is 3. The tool description briefly restates the jwt and signature relationship but does not materially extend the parameter semantics already present in the schema; the schema itself carries that burden.

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

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

The description opens with a specific verb and resource: 'Submit a signed rebalancer configuration update.' It also distinguishes itself from prepare_config by explicitly stating that this tool does not compute the signing hash, which prevents confusion among the closely related sibling 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 description gives explicit, actionable usage guidance: 'Always call prepare_config first,' and explains the required jwt and signature dependencies. It also covers retry behavior on 409 responses, timeout handling with a get_config follow-up, and rate limits.

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 this as destructive/open-world, but the description adds crucial behavior beyond that: timeout ambiguity, 409 duplicate detection with trackingId recovery, 400 allowance pre-flight rejection, 403/503 error conditions, rate limits, and the rejection of non-ECDSA signatures. There is no contradiction with annotations.

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

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

The description is long and dense, but every paragraph addresses a real prerequisite or failure mode, and the core requirements are front-loaded. It loses one point for being a wall of text that could be more scannable, though no sentence feels like 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?

The description thoroughly covers prerequisites, error handling, retry behavior, rate limits, and the smart-contract-wallet caveat for a high-stakes fund-moving tool. However, since there is no output schema, it would be stronger if it explicitly stated that a successful call returns a trackingId, rather than only implying its recovery after timeouts.

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?

Even though schema coverage is 100%, the description adds meaning the schema cannot convey: the all-or-none grouping of six signature-related parameters, the exact raw ECDSA signature format versus ERC-6492, the amount's role as an allowance check only in approval flows, the origin-chain semantics for chain, and walletAddress normalization.

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

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

The description opens with a specific verb and resource: 'Submit a deposit to MetaLend's rebalancer — moves funds.' It clearly differentiates itself from siblings like prepare_deposit and get_deposit_status by establishing this tool performs the actual fund-moving submission, not preparation or status retrieval.

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 gives explicit usage rules: 'Always call prepare_deposit first,' distinguishes signature-based vs approval-based flows, and directs smart-contract-wallet users to use the approval method. It also provides concrete retry vs escalate guidance with get_deposit_status and support, and warns against re-approving before a terminal status is confirmed.

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?

While annotations carry destructiveHint=true and readOnlyHint=false, the description adds substantial behavioral depth on top: timeout semantics (backend may accept but response may lag), idempotent retry safety ('it cannot double-spend'), the 409 signature-already-used semantics confirming prior success, the Linea Aave USDC funding-cap refill conflict, and rate-limit rules (20 calls/min, 3s spacing). No contradiction with annotations.

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

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

The description is long, but every sentence carries operational value — this is a mutation tool with many failure modes, so the density is justified. Front-loading is strong: purpose first, prerequisites second, then errors. The timeout/error paragraph is a nested wall-of-text that could be restructured into clearer conditional braches, and the rate-limit info is buried at the end, which slightly hurts scannability.

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 high-complexity tool with 8 required params, no output schema, and significant failure modes, the description covers prerequisites, sequencing, all error paths (403, two distinct 409 cases, timeout), recovery procedures with the trackingId, and rate limits. Nothing an agent needs to call it correctly or recover from a timeout is missing. The absence of output schema is compensated by the detailed trackingId recovery 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 coverage is 88%, so the baseline is 3. The description adds genuine meaning beyond the schema: the signature's EIP-712 domain is scoped to the provided chain (smart-contract wallet implications via ERC-6492 vs EOA), the jwt↔walletAddress binding is reinforced by the 403 error semantics, and the replay-safety of reusing the same signature. poolContract remains covered only by its regex pattern, but that is a minor gap against the strong schema coverage.

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

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

The first sentence states a specific verb ('Submit'), resource ('withdrawal from MetaLend's rebalancer'), and effect ('moves funds'). It is clearly distinguished from siblings: prepare_withdrawal is called first (this tool 'does not look up pool data or validate amounts'), and get_withdrawal_status is referenced for tracking. An agent can tell this from the prepare/get siblings immediately.

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

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

Gives explicit when-to-use guidance: 'Always call prepare_withdrawal first' and prerequisite requirements for jwt and signature. It also specifies when NOT to escalate (read trackingId from the 409 error and call get_withdrawal_status directly) versus when to escalate (timeout without trackingId), plus explicit error-code handling for 403 and 409 cases. This is far beyond a typical tool description.

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