MetaLend

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

Beyond the annotations, the description discloses key behaviors: it does not authenticate, repeated calls return the same cached message by design, chain does not affect the cached message, and there are rate limits. This is rich behavioral context that significantly helps an agent avoid misinterpreting repeated responses as bugs.

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 longer than average, but nearly every sentence carries important operational information or prevents a misunderstanding. It is front-loaded with the core purpose, then flows into signing requirements, caching behavior, and rate limits. A minor redundancy exists with the schema's chain description, but it does not detract significantly.

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

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

Given the complexity of the auth flow, the description is largely complete: it explains the purpose, the required follow-up step, caching semantics, and rate limiting. It mentions the returned message field but does not detail the full response shape or how an agent should handle potential errors or expiry, which would be useful since no output schema is provided.

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 baseline is 3, but the description adds meaningful behavioral context for parameters: it explains that chain does not affect which cached message is returned and reinforces that walletAddress must be the wallet's own signer. This goes slightly beyond the schema descriptions.

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 a specific verb and resource: obtaining a Sign-In-With-Ethereum challenge message for a wallet. It also distinguishes itself by explicitly noting it does NOT authenticate anything and is a prerequisite for other categories of tools, separating it from siblings like submit_auth_verify.

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 explicitly contextualized: it is required before deposit, withdrawal, or config-update tools, and the returned message must be signed and passed to submit_auth_verify. The description also explains when repeated calls are appropriate versus when they might appear surprising, giving clear 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 read-only and non-destructive, and the description adds substantial behavioral context beyond that: it returns rebalancerAddress and withdrawRequest EIP-712 data, fails when no rebalancer exists, explains gas-fee effects on balances, and discloses rate limits. 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 earns its place by conveying a distinct, decision-relevant fact: return contents, exclusions, failure conditions, gas-fee nuance, and rate limits. The core purpose is front-loaded in the first sentence.

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 having no output schema, the description enumerates the main return components (balances, net earnings, APY, rebalancerAddress, withdrawRequest data), handles edge cases (no rebalancer, missing pools), and explains why totals may differ from deposits. An agent has enough context to call this correctly and interpret results.

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 tokens and walletAddress. The description reinforces the critical distinction that walletAddress is the user's own address and must never be a rebalancerAddress, adding practical semantic value for invocation correctness.

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, and scope: 'Get a wallet's deployed rebalancer balances broken down per token, per chain, and per protocol/pool'. It also explicitly differentiates from siblings by naming what it does NOT return (rebalancingManagerAddress, pool catalog) and pointing to the correct alternative 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 explicit when-to-use and when-not-to-use guidance: use get_config for rebalancingManagerAddress, list_pools for pool catalog/APY data, and get_default_config for wallets without a rebalancer yet. It also states failure behavior and rate limits, leaving little to inference.

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

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

Annotations already mark the tool read-only and non-destructive, and the description adds meaningful behavior beyond that: entries lack a trackingId and cannot be correlated to submit_deposit calls, rate limits are 20 calls/minute with a 3s minimum gap, and sourcePool/isForSpending semantics are disclosed. 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 main action is front-loaded, followed by exclusions, data semantics, correlation caveats, and rate limits in logical order. Every sentence adds distinct information relevant to correct selection or invocation, 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?

Given the tool's moderate complexity, full schema coverage, and annotations that establish read-only safety, the description is complete enough for an agent to know what this tool returns, what it excludes, how to distinguish entry types, why it cannot be used for tracking specific deposits, and how often it can be called.

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 has 100% coverage and already fully documents walletAddress, including the 0x-prefix requirement, 40-hex-char length, and EIP-55 normalization. The description adds no additional parameter-level meaning, 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 uses a specific verb and resource: 'Get a wallet's in-transit USDC bridge balances.' It clearly scopes the tool by contrasting it with get_balances for already-settled balances and explicitly states it only applies to USDC, so an agent can distinguish it from siblings even before reading 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 explicitly tells the agent when not to use this tool ('Does NOT include already-settled rebalancer balances — use get_balances for those'), what token scope applies, and which alternative to use for tracking a specific deposit ('use get_deposit_status with the trackingId from that call instead'). This is direct, actionable routing guidance.

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

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

Beyond the readOnlyHint annotation, the description thoroughly discloses the subtle semantics: spendingCapRaw is a target balance, not a limit; refills happen automatically on a weekly cycle and after deposits; gas fees are deduced on the wallet; balance can drift due to rebalancing moves; and rate limits are specified. This is far richer than the annotation alone.

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 very dense and long, but every sentence adds essential context—semantics, exceptions, rate limits, and sibling relationships. It is not redundant or padded; the verbosity is justified by the tool's complex behavior. Still, it could be slightly trimmed without losing meaning, so a 4 is appropriate.

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 complexity (default entries, spending cap semantics, rebalancing side effects, rate limits) and the absence of an output schema, the description covers all needed aspects: what is returned, what is not returned (live balances, use get_balances), how to interpret edge cases (hasSignedConfig, rebalancerExists), and operational constraints (rate limit). Nothing important 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?

Although the parameter schema already covers 100% of the single input (walletAddress), the description adds crucial semantic detail beyond the schema: it explains that the address is normalized to an EIP-55 checksum before being forwarded upstream. This is non-obvious and not present in the schema, so the description meaningfully enhances understanding.

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'), resource ('rebalancer configuration'), and scope ('per token') in the first sentence, clearly distinguishing it from siblings like get_default_config and get_balances. It also clarifies that the result includes enabled protocols/pools/chains, frequency, lifetime fees, and spending cap, leaving no ambiguity.

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 directs the agent to use get_balances for live balances, get_default_config for recommended values when rebalancerExists is false, and prepare_config for the spending cap's full mechanics. It also warns that a default/template entry always exists and instructs checking hasSignedConfig, making it unmistakable when to call this tool versus its siblings.

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, and the description adds meaningful behavioral context: the rate limit of 20 calls/minute and a minimum 3s interval between calls. It also clarifies that the returned values are recommendations from MetaLend, which is useful beyond the 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?

Three sentences carry all necessary information: what the tool does, what it returns, when to use it versus the alternative, and rate limits. There is no filler or repetition, and the core purpose is front-loaded.

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, the description is fully sufficient: it names the input, describes the output fields, states the usage context, gives the alternative, and discloses rate limits. No critical information is missing for an agent to select and 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 schema already explains that 'token' is a token symbol with examples. The description repeats the token-symbol framing and adds the e.g. 'USDC' example, but it does not meaningfully extend the 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 ('Get'), a clear resource ('MetaLend's recommended default rebalancer configuration'), the target input ('a given token symbol'), and enumerates the returned fields. It also distinguishes itself from get_config, making the tool's purpose unmistakable.

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 for wallets with no existing config yet and points to get_config as the alternative for an existing wallet's current config. This gives the agent a clear decision rule rather than leaving usage to inference.

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

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

Annotations only declare readOnlyHint=true and destructiveHint=false; the description carries the real behavioral burden and delivers. It discloses the rate limit (20 calls/min, max 1 per 3s), the non-blocking BRIDGING semantics, and the subtle EMERGENCY_WITHDRAW resolution where funds return to the caller's own wallet rather than the rebalancer. No contradiction with the read-only annotation.

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 purpose before branching into the five status semantics and rate limit. Every sentence earns its place for a polling tool with complex terminal states; slightly dense but justified. The rate limit is appended at the end rather than prioritized, a minor structural nit.

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, so the description must explain return semantics — it does, exhaustively, via the five status values with actionable interpretations. One parameter at 100% coverage, rate limits, and timing expectations all present. Nothing an agent needs to poll correctly or interpret results 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% — trackingId is already documented as 'returned by submit_deposit' in the schema. The description repeats that linkage but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate since the schema carries the parameter documentation.

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 (poll deposit status) and the key input (trackingId), and ties it to its producer (submit_deposit), which cleanly separates it from sibling get_withdrawal_status. The purpose is unambiguous and distinct.

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 when-to-poll and when-not-to-poll guidance: keep polling on PROCESSING, treat BRIDGING as done and do NOT keep polling, and no need to wait for SUCCESS after BRIDGING. It also sets timing expectations (20-30 min bridge, 30+ min for EMERGENCY_WITHDRAW resolution). The polling contract is fully specified.

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/openWorldHint annotations, the description adds crucial behavior: the server has no RPC access, cannot sign/broadcast claims, is rate limited to 20 calls/minute with min 3s spacing, and claimTransaction absence means nothing is currently claimable. This materially changes how an 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 dense and front-loaded with the main purpose, but it has some redundancy: 'this server cannot claim rewards for you' and later 'cannot do it for you'. Almost every sentence earns its place, but a bit of tightening would make it fully concise.

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 supplies critical output/behavioral context: rewards[].rewardItems[], claimTransaction fields, the distinction between `to` and distributorAddress, and rate limits. An agent has enough information to invoke the tool correctly and understand what the result means.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level meaning beyond the schema; walletAddress and reloadChain are already fully described in the input 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: 'Get a wallet's aggregated rewards/earnings across all reward sources'. It clearly scopes what is included (Merkle, claimed/available USD totals) and explicitly differentiates from get_balances by excluding base rebalancer yield/APY earnings.

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-not guidance: base rebalancer yield is not included and lives in get_balances' netEarning field. It also warns there is no backend claim endpoint, preventing an agent from attempting to use this tool for claiming rewards.

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 flag this as a read-only, non-destructive call; the description adds rate limiting (6 calls/min, 10s spacing) and the precise data fields returned. This is useful behavioral context beyond annotations, though it omits error handling and any authentication 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?

Two sentences with no fluff: purpose comes first, followed by use-case and rate limit. 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?

For a 2-parameter read-only lookup with full schema coverage, the description provides the target metadata fields, the exact use-case, and call constraints. Nothing essential for selecting or invoking the tool 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%, with both token and chain parameters described and exemplified, so the description does not need to repeat them. The description adds context about how the returned values feed into tokenName/tokenVersion fields, but it provides no parameter-format details beyond what the schema already gives.

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 direct object: 'Get a token's on-chain metadata (display name, decimals, EIP-712 version) for a given chain.' This names the exact data returned and the chain dimension, clearly separating it from balance, status, and config 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?

It explicitly says 'Needed when building an EIP-3009 deposit signature's tokenName/tokenVersion fields,' giving a concrete trigger for use. It does not name alternative tools or state when not to use it, so it falls just short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds a valuable rate limit (20 calls/min, no more than one call per 3s) and clarifies the returned values are constant per chain, which goes 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?

Two sentences front-load the core purpose, then provide usage context and the rate limit. Every sentence earns its place with no 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 one-parameter read-only query tool, the description adequately covers purpose, output breakdown per chain, and rate limiting. No output schema exists, but the return values are sufficiently described.

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 already includes a descriptive list of examples. The tool description adds no extra parameter meaning, 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 names a distinct resource — constant on-behalf deposit/withdraw gas costs and minimum amounts per chain — with a clear verb 'Get'. This differentiates it from siblings like get_balances or get_token_info without needing to inspect 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 explicitly says to use the tool before a deposit to verify the amount meets the chain's minimum, giving a concrete decision context. It does not name alternative tools, but the timing guidance is clear and actionable.

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. The description adds substantial behavioral detail beyond that: the meaning of each status value, polling expectations (keep polling during PROCESSING), terminal states, and a specific rate limit of 20 calls/minute with a 3-second minimum interval.

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 scoped sentences with no filler. The core purpose and parameter provenance come first, followed by status semantics and rate limits — each 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 no output schema, the description fully explains the meaningful return values (status enum), what the caller should do for non-terminal statuses, and the rate limiting constraints. This is complete information for a polling tool of this 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?

Schema coverage is 100% for the single trackingId parameter, so the baseline is 3. The description reiterates that trackingId comes from submit_withdrawal, which matches the schema and adds no new information beyond it.

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?

Description states a clear action ('Poll the status of a withdrawal') and the exact resource identifier ('trackingId returned by submit_withdrawal'). It distinguishes itself from deposit-related tools by explicitly noting withdrawals have no cross-chain bridging leg, unlike deposits.

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 context on when to use the tool: when polling a withdrawal's status, with explicit handling guidance for PROCESSING versus terminal states. It doesn't explicitly name an alternative tool for deposits, but the contrast with deposits and the sibling get_deposit_status makes the intended usage clear.

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 adds valuable behavioral context: the value rarely changes, is safe to cache client-side, and is rate limited to 10 calls/minute per caller with a 6-second minimum interval. This is exactly the kind of operational nuance 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 description is two sentences and front-loaded with purpose before behavior. Every clause earns its place: what it returns, why it's needed, caching guidance, and rate limits—no filler.

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

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

For a zero-parameter, read-only, no-output-schema tool, this description is complete. It tells the agent what the value is for, how often it changes, how to cache it, and what rate limit to expect.

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 the description has no parameter semantics to add. With no parameters and 100% schema coverage, the baseline of 4 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 verb ('Get'), a precise resource ('contract signing version string'), and its role in EIP-712 domain data for signing withdrawals. This clearly differentiates it from siblings like get_withdrawal_status, which covers status rather than signing versions.

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

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

It provides clear context: the version string is required when signing a withdrawal, and the caching guidance implies this is a low-frequency lookup. It does not explicitly name when-not-to-use 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?

Annotations already mark this as read-only and non-destructive, and the description adds substantial behavioral context beyond that: it explains that poolTvl/poolLiquidity may read '0' for two indistinguishable reasons, that blacklisted pools must be filtered, that there is no pool-level paused/capacity flag, and that deposit/withdrawal blocking is invisible here. No contradiction with 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?

Every sentence earns its place: the core purpose is front-loaded, the sibling distinction is explicit, the caveats address realistic misinterpretations, and the rate limit is actionable. Though the description is longer than a one-liner, the tool's data ambiguities and absence of pool-level flags genuinely require this much detail. It remains well-structured and not redundant.

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 return semantics, and it does so thoroughly: it names the returned fields, clarifies the meaning of zero TVL/liquidity, identifies what is intentionally not returned, and explains how paused/blocked states manifest elsewhere. Nothing essential is missing for an agent to call this 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?

The tool has zero parameters, so the input schema carries no burden and the description need not explain parameter meaning. The description instead focuses on what the returned list contains, which is appropriate. Since there are no parameters, a baseline score of 4 is warranted, and the description adds no misleading parameter-related claims.

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: 'List all pools MetaLend's rebalancer can deposit into.' It then enumerates the exact returned fields (protocol, chain, APY breakdown, TVL, liquidity, signData). It also explicitly distinguishes itself from get_balances and get_config, so an agent can immediately tell it apart 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?

The description gives explicit when-to-use and when-not-to-use guidance: it says the tool does NOT return wallet balances or configuration and directs callers to get_balances/get_config. It also instructs callers to filter out blacklisted pools and warns that paused/capacity conditions will only surface as submit_deposit/submit_withdrawal errors, not in this list. Rate limits are also 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?

Beyond the readOnlyHint/destructiveHint annotations, the description discloses extensive behavioral traits: it computes the hash server-side and signs nothing, refuses to build configs under many enumerated conditions, enforces a rate limit (5 calls/minute, no more than one per 12s), and explains that later 409s at submit_config are temporary. It also details smart-contract wallet ERC-1271/ERC-6492 cross-chain verification nuance, which is far beyond what annotations state.

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 front-loaded with its core purpose and is information-dense, but it is a single enormous run-on paragraph; the long enumeration of refusal conditions and the smart-wallet discussion are difficult to scan and partly duplicate guidance already present in field descriptions. Every sentence adds some value, but the lack of bullets or clear segmentation makes it less concise and structured than it should be for this 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?

Given there is no output schema, the description clearly identifies the key return value ('the returned hashToSign') and explains how to consume it (personal_sign over raw 32 bytes, not UTF-8 hex text). It covers preconditions, refusal conditions, rate limiting, error semantics, cross-chain verification behavior, and the follow-up 409 handling at submit_config, leaving essentially nothing an agent needs in order to call 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?

Schema description coverage is 100%, so the baseline is 3; the description itself does not restate each field but adds cross-parameter behavioral meaning: spendingCapRaw must match between prepare and submit, collateralExposure requires an Aave pool whose live TVL meets requiredTvl, and (domainId, protocolId, poolAddress) tuples must match real catalog entries. This adds tool-level semantics beyond individual schema field descriptions, though some gaps remain because the schema already carries the per-parameter detail.

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

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

The description opens with a specific verb and resource: 'Build the signing hash for updating a wallet's rebalancer configuration', then clarifies it does this 'without signing anything'. It explicitly names the cryptographic hash (keccak256(abi.encode(...))), the intended consumer (submit_config), and distinguishes itself from signing/submission 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 provides explicit workflow routing: sign the returned hashToSign and pass it to submit_config; use prepare_withdrawal first if a pool would be dropped; copy current values from get_config when reconfiguring; consult list_pools for valid pools. It also gives when-not-to-use signals, such as refusals for blacklisted pools and the 409-at-submit warning, and warns that a cross-chain-incompatible smart wallet must keep domainIds single-chain.

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 annotation, the description discloses major behavioral constraints: the server never signs, has no RPC access, rejects smart-contract wallet signatures, enforces a 6-calls/minute rate limit, validates minimum deposits, and reduces credited amounts by a fee. It also warns about unvalidatable assumptions around cross-chain smart-contract wallet support.

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 information: flow selection, server limitations, prerequisites, validation, fees, and rate limits. It is not tightly structured into sections, but it is front-loaded with the core purpose and contains no filler.

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

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

For a tool with no output schema, the description does a good job of explaining what comes back conceptually (EIP-712 typed-data vs approve parameters), the fee field, expectedCreditedAmountRaw, and the later get_balances impact. It could add a concrete response shape, but the workflow, prerequisites, validation, and failure modes are covered well enough for an agent to proceed.

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 covers all parameters with 100% coverage, so the baseline is 3. The description adds real semantic value by explaining the gasless vs approval classification, the smart-contract wallet workaround via method:'approval', and the fee-and-credit relationship for amount. It does not fully replace the schema's detail on chain semantics, but it meaningfully enriches parameter understanding.

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 pair ('Build everything needed to deposit into MetaLend's rebalancer') and immediately distinguishes the tool from submit_deposit by stating it does no signing. It clearly partitions gasless tokens and approval-only tokens into two concrete output flows, so an agent can tell exactly what this tool produces.

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: use the signature flow for gasless tokens, use approval for others, and force method:'approval' for smart-contract wallets. It names the next-step tool (submit_deposit), the prerequisite flow (prepare_config/submit_config), and the diagnostic tool (get_config), leaving no ambiguity about placement in the workflow.

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 signal read-only/non-destructive, but the description adds substantial behavior beyond that: it refuses to build when liquidity is insufficient, uses the maxUint256 convention for MAX, deducts an on-behalf fee, returns expectedReceivedAmountRaw, and enforces a 5 calls/minute rate limit. This level of disclosure is well beyond what annotations provide.

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?

Though long, the description is front-loaded with the core purpose and every sentence earns its place: withdrawal mechanics, MAX semantics, chain/token disambiguation, failure pre-checks, fee deduction, and rate limits. Nothing is redundant with the schema or annotations.

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 covers what the response contains (EIP-712 domain/types/value, fee, expectedReceivedAmountRaw) and all preconditions needed to call successfully. Sibling relationships are explicitly named, making the tool's role in the broader workflow clear.

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 the schema lacks: amount is optional via omission or the string MAX with a maxUint256 explanation, chain is justified by cross-chain address reuse, and token is explained as a disambiguator for pool addresses serving multiple tokens. This materially improves correct parameter selection.

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 names a specific verb and resource: build an EIP-712 typed-data payload for withdrawing from a specific pool, explicitly noting it signs nothing. It also differentiates from the sibling submit_withdrawal, which consumes the resulting signature, so an agent cannot confuse the two.

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 an explicit workflow: call this tool, then pass the signature to submit_withdrawal. It gives conditional usage rules (omit amount or pass MAX for full withdrawal, chain required due to address reuse across chains, refusal when liquidity is insufficient) and references supporting tools such as list_pools and get_transaction_costs.

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 say the call is not read-only and not destructive; the description carries the real behavioral burden and does so thoroughly: no server-side caching/storage of the JWT, strict per-wallet validity with upstream rejection for mismatched wallets, expiration via decoded exp, and a precise rate limit.

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 genuinely dense, with the key exchange purpose first and operational constraints following. A little repetitiveness around 'same wallet' exists, but each sentence contributes non-obvious information needed to use the tool safely.

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 the lack of an output schema, the description names the two response fields that matter for subsequent behavior (jwt and expiresAt) and covers the preconditions, downstream requirements, and rate limiting. There is no apparent gap that would prevent a competent agent from calling 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?

Though the schema already documents all three parameters (100% coverage), the description adds critical semantics: signature type is personal_sign, chain is irrelevant for EOAs but determines RPC validation for smart-contract wallets via ERC-1271/6492, and walletAddress is normalized to EIP-55 checksum. This materially improves correct invocation.

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 pairing: exchange a signed SIWE challenge message for a JWT scoped to a wallet. It names the related get_auth_challenge and submit_* siblings, making the tool's position in the auth/write 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?

It explicitly ties this to get_auth_challenge as the source of the signed message and spells out that the JWT must be forwarded to submit_deposit/submit_withdrawal/submit_config. It also advises reusing the JWT instead of re-authenticating, and gives rate-limit constraints—clear operational guidance for when to call it.

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 mark destructiveHint=true and readOnlyHint=false, the description adds substantial operational traits: 409 collisions with ongoing rebalance/deposit/funding-cap refill, the ambiguous timeout behavior where the backend may have accepted the update, and a rate limit of 10 calls/minute with at least 6s between calls. These failure modes and side-effect risks go well beyond what the annotation bits convey.

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

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

The description is a dense, front-loaded paragraph that opens with the operation and prerequisites, then packs only high-value operational caveats into the remaining sentences. There is no filler or repeated schema content, and the length is justified by the number of real edge cases it covers.

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

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

Given 12 parameters, 7 required, no output schema, and rich input-schema descriptions, the description covers all the non-obvious context an agent needs: required call sequence, 409/retry semantics, ambiguous timeout result, and rate limiting. The success response is not explicitly described, but the explicit 'check get_config afterward' guidance makes that omission non-critical.

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 every parameter has its own detailed description, so the baseline is 3. The tool description reiterates the jwt/signature provenance and the prepare_config ordering, but does not add new parameter-level meaning 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 an exact action ('Submit a signed rebalancer configuration update') and immediately ties it to required artifacts (jwt from submit_auth_verify, signature over prepare_config's hashToSign). It also explicitly separates itself from prepare_config by noting it does not compute the signing hash or check the balance invariant, so an agent can correctly distinguish this tool from its siblings.

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

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

It gives an explicit order: 'Always call prepare_config first' and states that this tool does not compute the signing hash or check the balance invariant itself. It also tells the agent what to do on a 409 (wait and retry, with a retryAfterSeconds hint) and on timeout (check get_config afterward rather than assuming it didn't happen), which is clear, 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?

Goes far beyond the false readOnly and true destructive annotations by disclosing timeout behavior, retry semantics, double-spend protection via a 409 error, approval-allocation consumption, rate limits, and specific failure modes (400/403/503). This is rich behavioral context that lets an agent predict side effects and handle uncertainty.

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

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

The description is a dense, multi-paragraph wall of prose with many nested conditionals; while every sentence is informative, the sheer length and lack of bullet structure reduce scannability. It is front-loaded with purpose and prerequisites, but not concise.

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 destructive, time-sensitive deposit tool with no output schema, the description covers auth prerequisites, prepare_deposit dependency, error recovery, retry safety, token approval nuances, rate limits, and cross-chain behavior. An agent can correctly decide how and when to call this tool, including handling ambiguous timeout outcomes.

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 crucial semantics: the 'amount' is only an allowance preflight check, 'signature' must be raw 65-byte ECDSA (not ERC-6492), 'chain' refers to the originating chain, and the optional six fields must be all-or-none. This materially clarifies how to fill the 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 and resource ('Submit a deposit to MetaLend's rebalancer — moves funds') and clearly identifies the operation as a fund-moving deposit. It does not explicitly contrast itself with sibling tools such as submit_withdrawal, but the deposit scope and prerequisite references to prepare_deposit make the 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?

Provides explicit when-to-use guidance: 'Always call prepare_deposit first', distinguishes signature-based vs approval-based flows, and directs smart-contract wallets to the approval method. It also spells out the condition to escalate to support instead of retrying, giving clear 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?

Despite annotations already indicating destructive behavior, the description adds extensive runtime behavior: timeout ambiguity, retry idempotence, 409 duplicate semantics, 403 failures, funding-cap conflicts, and rate limits. It even explains the exact recovery path for a timed-out call.

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: prerequisites, failure modes, retry behavior, and rate limits are all operationally critical. It is front-loaded with the core action and call order before moving to edge cases.

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 destructive, multi-parameter submission tool with no output schema, the description covers everything an agent needs: required prior calls, signature dependencies, timeout handling, error recovery, and constraints. No material gap remains.

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 high (88%), so the baseline is already elevated. The description adds crucial parameter-level nuance beyond the schema: the signature must be over prepare_withdrawal's typedData, the EIP-712 domain is chain-scoped, smart-contract wallet signer requirements, and that amounts are not validated. This materially helps correct invocation.

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 verb-resource pair ('Submit a withdrawal from MetaLend's rebalancer') and immediately clarifies the side effect: 'moves funds.' It also distinguishes this tool from prepare_withdrawal by stating that it does not look up pool data or validate amounts.

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 prerequisites: a jwt from submit_auth_verify and a signature over prepare_withdrawal's typedData. It says 'Always call prepare_withdrawal first,' and it explicitly routes the agent to get_withdrawal_status using the recovered trackingId instead of escalating. This is strong when/why/alternative guidance.

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