Arcadia Finance

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

Annotations already signal destructive/non-read-only behavior, so the bar is lower. The description adds useful context: it uses a local private key from an environment variable, is dev-only, and performs onchain broadcast. This goes beyond the annotation flags without contradiction.

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

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

Three sentences, no fluff. The most important warning ('DEV ONLY') is front-loaded, followed by a production alternative and input-source guidance. 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?

Given the output schema exists and the input schema is self-explanatory, the description covers the essential contextual gaps: dev-only scope, production alternative, local signing method, and relationship to write.* tools. No critical operational details are 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 clear parameter descriptions, so baseline is 3. The description adds meaningful extra semantics by stating that the tool takes the transaction object returned by write.* tools, clarifying how 'to', 'data', and 'value' should be sourced.

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 'DEV ONLY — Sign and broadcast an unsigned transaction', specifying a concrete action and resource. It clearly differentiates itself from sibling write.* tools by explaining it consumes their transaction objects and submits them onchain.

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 states this is for development only and directs production users to dedicated wallet MCP servers like Fireblocks, Safe, or Turnkey. It also explains that it accepts transaction objects from any write.* tool, giving clear when-to-use context relative to 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 declare readOnlyHint, idempotentHint, and openWorldHint, covering safety. The description adds valuable behavioral context by specifying the return format (time series of snapshots) and clarifying that values are human-readable USD amounts, extending 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?

The description is two sentences, front-loaded with the primary purpose, followed by return format and an example use case. No redundant or extraneous wording.

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 comprehensive annotations, fully described parameters, and existing output schema, the description covers purpose, return details, and use case adequately. It is complete for a read-only historical tool, with no critical 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?

Input schema coverage is 100%, with all three parameters fully described. The tool description does not add any parameter-specific guidance beyond the schema, so the baseline score 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?

The description clearly states 'Get historical collateral and debt values for an Arcadia account over time,' specifying a specific verb, resource, and time scope. It distinguishes itself from sibling tools by focusing on time-series snapshots, though it doesn't explicitly name an alternative tool for current data.

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

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

The phrase 'Useful for charting account performance over a period' provides a clear context for when to use the tool. It lacks explicit exclusions or named alternatives, but gives a concrete applicable use case, placing it above merely implied usage.

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 readOnly and non-destructive, but the description exceeds the bar by explaining internal behaviors: the health factor formula, automation detection across all asset-manager versions, the AM key-to-dex_protocol mapping, unit/decimals conventions, and chain-specific availability. This is rich, non-redundant context that helps the agent interpret results and avoid mistakes.

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 each sentence carries essential information. It is front-loaded with the core purpose, then logically progresses through formula, automation details, chain support, mappings, and units. Some redundancy exists (e.g., repeating 'raw token units' twice), 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?

Given the tool's complexity and that an output schema exists, the description still provides comprehensive guidance: health factor interpretation, automation status semantics, chain-specific protocol support, field mappings, and unit conversion. It even references sibling tools and write operations. The description fully equips the agent to use 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?

The schema already fully describes both parameters (chain_id with allowed values, account_address as an address), so the baseline is 3. The description adds value by detailing how chain choice affects results (e.g., Slipstream V2 Base-only, Unichain limitations) and explaining that output fields use raw units vs. USD, which indirectly clarifies parameter meaning. This goes beyond the schema without needing to restate 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?

The description opens with 'Get full overview of an Arcadia account' and lists specific data points (health factor, collateral, debt, assets, liquidation price, automation), clearly distinguishing it from sibling tools like read_account_history or read_wallet_accounts. It also explicitly points to read_wallet_accounts for listing accounts, reinforcing its unique scope.

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

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

The description provides an explicit alternative: 'To list all accounts for a wallet, use read_wallet_accounts.' It also instructs how to use the returned dex_protocol field as input for write_asset_manager.* tools, giving clear when-to-use vs. when-not-to-use guidance. The detailed caveats about chain-specific support further help the agent choose correctly.

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, and idempotentHint annotations, the description adds valuable behavior: it explains that results are lifetime totals, that negative cost_basis means net profit withdrawn, and that fields are in USD vs raw token units. This provides meaningful context beyond safety, though it does not mention auth requirements or rate limits, which annotations already imply are not concerns.

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: the first states purpose, the second details return fields, and the third clarifies units. There is no fluff or redundancy, and it is appropriately sized for 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?

Given the output schema exists, the description doesn't need to detail all return fields. It does add crucial semantic context (units, negative cost_basis meaning, lifetime totals) that complements the schema. Combined with strong annotations (readOnly, idempotent), the tool is fully specified for an agent to invoke 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% for both parameters (chain_id and account_address). The description does not add parameter-specific semantics beyond what the schema already provides; it focuses on return fields instead. Baseline of 3 is appropriate when the schema carries full 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?

The description clearly states it retrieves PnL (cost basis) and yield earned for an Arcadia account, with specific output fields and units. This distinguishes it from sibling tools like read_account_history or read_account_info by focusing on profit/loss and yield rather than historical transactions or account details.

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 clear context that this tool is for querying account PnL and yield, but it does not explicitly mention alternatives or when not to use it. The purpose is unambiguous, and the tool's read-only nature in annotations implies it is safe to invoke when needed, but exclusions are absent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds that the returned list is compact and includes specific fields (address, symbol, decimals, type), which is useful context beyond the annotations. No contradictions exist.

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 zero waste. The first sentence states the core purpose and return format, the second sentences covers filtering and the key alternative. Information is front-loaded and every phrase 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 simple read-only list tool with extensive annotations, a full output schema, and fully documented optional parameters, the description is complete. It covers what, how to filter, and when to use an alternative, leaving no critical 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?

Schema description coverage is 100%, with both parameters (search and chain_id) already documented in the schema. The description lightly references search functionality but does not add new meaning beyond what the schema provides. 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 uses a specific verb "List" and clearly specifies the resource "supported collateral assets on Arcadia". It also distinguishes from sibling tools by directing price searches to read_asset_prices, making the tool's scope 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?

Explicitly states when to use this tool (list assets) and when to use an alternative ("For USD prices, use read_asset_prices"). Also mentions the search parameter as a way to filter, providing clear usage 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?

Annotations already mark it as read-only and idempotent, and the description adds extra behavioral nuance: the relationship to write_asset_manager.{id} tools, the enabled=false option to disable, and the ability to merge arrays into a single set_asset_managers call. This goes beyond what annotations alone 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?

Five sentences, each earning its place: purpose, discovery rationale, relationship to write tools, disable option, and combination mechanism. The main point is front-loaded, and there is no redundant 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 a simple optional parameter and an output schema (as indicated), the description covers discovery, integration, disabling, and combining intents. It gives an agent everything needed to use this tool correctly within the larger automation workflow.

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 only parameter chain_id is fully described in the schema (filter by chain, omit for all). The main description adds no further parameter syntax, but since schema coverage is 100%, 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?

The description begins with 'List all available automation intents,' a specific verb and resource, and enumerates exactly what is included (tool names, required parameters, supported chains). This clearly differentiates it from sibling write_asset_manager_* tools and other read_* tools, so an agent can immediately know its purpose.

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

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

It explicitly says 'Use this to discover which automations can be configured' and describes the follow-up workflow: call intent tools then pass the combined result to write_account_set_asset_managers. While it doesn't name alternatives to exclude, it provides clear situational 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds beyond annotations by specifying the return format ('price map keyed by address') and the address input format, which is useful behavioral context. It does not mention edge cases like unknown addresses, but that is not required given the annotations and simplicity.

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, front-loaded with the core purpose, and every word adds value. It avoids redundancy with the schema and 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?

Given the tool's low complexity, the presence of an output schema, and full annotations, the description covers all necessary aspects: what it does, how to specify inputs, and what output to expect. It is complete for an agent to select and invoke 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% for both parameters, so the baseline is 3. The description's mention of 'comma-separated addresses' mirrors the schema's parameter description without adding new semantic detail. The chain_id parameter is well-documented in the schema (enumerated chain IDs), so the description does not need to compensate.

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 tool's function: 'Get USD prices for one or more asset addresses.' The verb 'Get' and resource 'USD prices for asset addresses' are specific, and it distinguishes itself from sibling tools like read_asset_list by focusing on price data keyed by address.

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 clear usage context: pass a single address or comma-separated addresses. It does not explicitly mention alternatives or when not to use this tool, but the instructions are straightforward and sufficient for the intended use case.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds context about what content the guides contain (topics) but does not disclose additional behavioral traits such as return size, formatting, or any limitations. With annotations present, the added context is useful but not extensive.

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 concise (about four sentences) and front-loaded: it starts with the purpose, then usage, then topic details. Every sentence earns its place, with no fluff or redundancy. It is well-structured and easy to parse.

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 simplicity (one optional parameter, output schema present), the description covers all necessary context: when to use, what topics are available, and what each topic covers. The output schema handles return-value details, so no further description is needed. The tool is fully contextualized relative to its sibling read/write tools.

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

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

The input schema already provides 100% parameter coverage, including a description for each enum value of 'topic'. The description restates the topics and adds brief clarifications (e.g., 'overview = addresses + tool catalog') but does not add meaning substantially beyond the schema. Baseline 3 is appropriate since 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?

The description clearly states the tool's purpose: 'Get Arcadia workflow guides and reference documentation.' It specifies the resource (Arcadia workflow guides) and differentiates from sibling tools by being the documentation resource. It also enumerates specific topics, making the scope 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 when-to-use guidance: 'Call this before multi-step workflows (opening LP positions, enabling automation, closing positions) or when you need contract addresses, asset manager addresses, or strategy parameters.' It does not explicitly mention when not to use or alternatives, but the context is clear enough to distinguish from operational tools.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds the pagination behavior, which is a key operational detail beyond annotations. This is sufficient contextual disclosure for a read operation with an output schema.

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

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

The description is two sentences with minimal waste: the first states the primary action, the second gives a clear alternative. It is front-loaded and easy to parse.

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 leaderboard tool with schema-documented parameters and an output schema, the description covers the core purpose, pagination, and an alternative for a related use case. No additional context is necessary.

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 provides full descriptions for both limit and offset, including defaults and meanings. The description's mention of 'paginated' reinforces parameter usage but adds no new semantics beyond the schema, so a baseline score 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 clearly states the tool gets the Arcadia points leaderboard, a specific resource. It also distinguishes itself from the sibling tool read_wallet_points by indicating that tool is for wallet-specific balances, eliminating 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?

Explicitly states when to use this tool (leaderboard) and when to use the alternative read_wallet_points for a specific wallet's balance. This provides clear differentiation and guides correct selection among sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral context by specifying that it returns APY history over time, which is useful for trend analysis, without contradicting annotations. It stops short of describing return format or error behavior, but the output schema covers that.

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, front-loaded with the use-case intent, and includes a pointer to a sibling tool. No wasted words, all sentences 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?

With a complete input schema, output schema, and annotations, the description covers the essential purpose, use case, and alternative. For a read-only info tool, this is complete and doesn't require additional detail.

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 each parameter fully described (days, chain_id, pool_address). The description adds no parameter-specific meaning beyond the schema, so the baseline 3 applies.

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

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

The description clearly states the verb ('Get') and specific resource ('detailed info for a single lending pool including APY history over time'), distinguishing it from the sibling read_pool_list which discovers pool addresses.

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 when to use the tool ('useful for analyzing rate trends and comparing pools') and points to an alternative for discovery ('Use read_pool_list to discover pool addresses'), giving clear 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, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds meaningful behavioral context by specifying the rate format (decimal fractions, 1.0 = 100%) and emphasizing 'all' pools (no filtering). It does not contradict annotations and provides extra value beyond them.

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: the first states purpose, the second explains key field names, the third clarifies rate format and points to an alternative. It is front-loaded and highly concise without wasted 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?

The tool has a simple output (list) with an output schema present and rich annotations. The description covers the main purpose, key fields, rate format, and an alternative. However, it does not explicitly clarify how the optional chain_id parameter interacts with the phrase 'List all', leaving a minor ambiguity about whether it lists all chains or filters by chain. Overall adequate but not perfect.

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 for the single parameter (chain_id), including its default and allowed values. The description does not add any additional parameter semantics, relying on the schema. Baseline of 3 is appropriate since the schema carries the 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 uses a specific verb ('List'), identifies the resource ('all Arcadia lending pools'), and lists the key returned fields (TVL, utilization, available liquidity). It also explicitly distinguishes from sibling read_pool_info by noting that APY history is handled there. This clearly states what the tool does and differentiates it.

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 an explicit alternative: 'For APY history on a specific pool, use read_pool_info.' This tells the agent when to use this tool versus a sibling, and the context of listing all pools is clear. It effectively guides tool selection.

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 the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond these: the tradeoff between range width and APY (narrower range yields higher APY but more rebalancing cost/risk), and the decimal fraction format for APY. This helps the agent reason about the returned data and the domain, going beyond the safety hints.

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 concise at three sentences, with each sentence serving a distinct purpose: core function and content, discovery guidance, and data format clarification. It is front-loaded with the primary verb and contains 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?

Given the tool's simple signature (2 params, 1 required), the presence of an output schema, and strong annotations, the description is fully complete. It covers the essential semantics including APY interpretation and the relationship with read_strategy_list, without needing to detail output schema fields. An agent can confidently select and invoke this tool based on the provided 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 both parameters are documented in the schema. The description adds significant meaning to the strategy_id parameter by directing users to read_strategy_list to discover valid IDs, addressing a gap where the schema only provides the cryptic 'Strategy ID'. Chain ID is fully specified in the schema, so no additional description is needed there.

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 tool's function: 'Get full detail for a specific LP strategy by ID' and enumerates the included content (APY per range width, pool info, configuration). It distinguishes itself from sibling read_strategy_list by explicitly instructing users to use that tool for discovery, and from other read tools by focusing on strategy-specific detail.

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 names read_strategy_list as the tool to discover strategy IDs, providing a concrete alternative and prerequisite. It also gives essential usage guidance about APY values being decimal fractions (1.0 = 100%), which is critical for correctly interpreting results. This covers both when to use and how to use.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context about pagination behavior and APY decimal format (1.0 = 100%), which goes beyond annotations. No contradictions found.

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 compact, front-loaded with the core purpose, and every sentence delivers actionable information without redundancy. It efficiently covers usage, format, and alternatives in three sentences.

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 output schema exists and all parameters are documented, the description covers the necessary operational aspects: pagination, APY format, featured flag, and guidance for deeper detail. It is complete for a list-type read tool.

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

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

Schema coverage is 100% with descriptions per parameter. The description adds practical usage semantics for featured_only (recommended first call) and explains how to use limit/offset for pagination, enriching the schema's baseline.

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

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

The description clearly states the tool retrieves Arcadia LP strategies, distinguishing it from read_strategy_info by noting it returns a paginated list with APY details for default ranges. It explicitly names the sibling for full strategy detail, 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?

Provides explicit guidance: recommends featured_only=true for a first call, explains pagination with limit/offset, and directs users to read_strategy_info for per-range APY. This gives clear when-to-use and alternative tool 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 description adds valuable context beyond the annotations by explaining that APY values are decimal fractions and that 'weekly_earning_difference' is in USD. It also clarifies the data source (1d APY) and how recommendations may differ from the list ranking. These are useful behavioral details not fully captured by the readOnlyHint and idempotentHint 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 concise and well-structured: three sentences cover purpose, key distinction from a sibling tool, and important unit details. Every sentence contributes information without repetition or 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 presence of an output schema, annotations for read-only/idempotent behavior, and only two well-documented parameters, the description is complete. It covers the main purpose, the differentiator from a closely related tool, and unit semantics, leaving no critical gaps for an agent to select and invoke 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?

The input schema covers both parameters with descriptions, reaching 100% coverage, so the baseline is 3. The description does not add parameter-specific details beyond what the schema already provides, though it does mention output units that indirectly help interpret results.

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 identifies the tool as returning a rebalancing recommendation for an Arcadia account, using a specific verb ('Get') and resource ('rebalancing recommendation'). It explicitly distinguishes itself from 'read_strategy_list' by noting the use of 1d APY versus 7d, which helps an agent select the right tool.

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 clear context for when to use this tool over 'read_strategy_list' by highlighting the APY horizon difference. However, it does not explicitly mention exclusions, such as when to use a write tool for actual rebalancing execution, though the read-only annotation implies this.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that it returns a summary of each account (address, name) and points to another tool for full details. It does not cover edge cases like empty wallets, but for a read-only list this is sufficient.

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 wasted words. The first sentence states the action and scope, and the second sentence points to a more detailed alternative. Perfectly front-loaded and 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?

This is a simple list tool with only two parameters and an output schema. The description explains what is returned (summary of address and name) and directs to read_account_info for deeper details. No missing information for the tool's complexity.

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%: both chain_id and wallet_address have descriptions, including the chain ID options. The description adds no extra parameter context beyond what the schema already provides, 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?

The description uses the specific verb 'List' with the resource 'Arcadia accounts' and scopes it by wallet address. It clearly distinguishes itself from read_account_info by stating that this tool returns only a summary, while read_account_info provides full details.

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 directs users to use read_account_info with a specific account_address for full details like health factor, collateral, and debt. This makes the use case for read_wallet_accounts clear as a summary-level list, and the alternative is explicitly named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds workflow context (checking before approval) but does not disclose additional behavioral traits such as response format or chain-specific behavior, which is acceptable given the annotations.

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

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

Two sentences, front-loaded with the purpose and ending with a practical usage tip. Every sentence earns its place with 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?

This is a simple read-only operation with full parameter documentation and an output schema. The description is sufficient for an agent to understand when and why to call it. It could mention multi-address support more explicitly, but the schema's 'token_addresses' array implies that.

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

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

Schema description coverage is 100% with each parameter clearly described (e.g., 'Token owner address (the wallet granting approval)'). The description itself does not add parameter-level semantics beyond the schema, 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 ('Check') with a clear resource ('ERC20 token allowances for a spender address'), immediately distinguishing it from balance-read tools and write approval tools. It also ties to a sibling tool (write_wallet_approve) for context.

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 instructs to use before write_wallet_approve to avoid redundant approvals, providing a concrete workflow condition. It lacks an explicit when-not-to-use statement or alternative tools, but the 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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing it 'Reads directly from chain via RPC multicall' and returns both raw and formatted balances, which are behavioral traits beyond the annotations. It does not cover error cases or limits, but the addition is meaningful.

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, front-loaded with the purpose, followed by method, usage, and output details. Every sentence earns its place without redundancy or 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 simple nature of the tool, the existence of a full output schema, and comprehensive annotations, the description covers purpose, method, a concrete use case, and return format. It is fully adequate for an agent to decide when and how to invoke it.

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

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

All three parameters have detailed descriptions in the schema, giving 100% coverage. The description adds clarity that native ETH is included alongside the ERC20 tokens in token_addresses, and that returns include raw and formatted values. However, this is supplementary rather than essential, as the schema already specifies parameter meanings.

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 tool's function: 'Get native ETH and ERC20 token balances for a wallet address.' This specific verb+resource distinguishes it from sibling tools like read_wallet_accounts and read_wallet_points. The mention of reading from chain and returning raw/formatted balances adds further precision.

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 context: 'Use before write_account_add_liquidity or write_account_deposit to verify the wallet has sufficient tokens.' This names specific scenarios. However, it does not explicitly state when not to use it or contrast with other read_wallet* tools, 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 the tool read-only, idempotent, and non-destructive, so the description needs limited behavioral disclosure. It adds the resource context (Arcadia points) and the targeting of a specific wallet, but provides no additional behavioral details beyond what the annotations 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 single, direct sentence that immediately conveys the function without wasted words 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 simple read-only tool with one parameter and an output schema present, the description provides sufficient context. It specifies the resource and target, and annotations cover safety, making the tool fully understandable.

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 has full coverage for the single parameter (wallet_address) with a clear description. The main description adds no new parameter-level meaning beyond what the schema already states.

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

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

The description clearly states the action ('Get'), the specific resource ('Arcadia points balance'), and the scope ('for a specific wallet address'). This distinguishes it from sibling tools like read_point_leaderboard (which provides ranking data) and read_wallet_balances (which likely covers token 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 clearly implies the tool is for fetching points for a single wallet address. However, it does not explicitly mention when to prefer this over alternatives like read_point_leaderboard or read_wallet_balances, though the specificity is evident.

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=false, etc.), the description adds crucial behavioral details: the transaction is time-sensitive (30 seconds), revert-prone with a retry recommendation, and returns tenderly simulation data. It also explains expected_value_change units and the meaning of before/after account values, enriching transparency well beyond structured hints.

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 appropriately so for a complex multi-step tool. It fronts the core purpose, then layers warnings, parameters, and return-value semantics in a logical order. Every sentence provides actionable information with no redundancy or filler, earning 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?

Given the tool's complexity and the rich schema/annotations/output schema, the description is complete. It covers return values (tenderly_sim_url, expected_value_change), operational constraints (time-sensitivity, retry), account types, and references to guides. It leaves no major gaps for an agent to invoke 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?

The schema already provides comprehensive descriptions for all 8 parameters (100% coverage), so the baseline is 3. The description adds a high-level summary of capital sources and leverage behavior, but these largely restate schema details without introducing new per-parameter meaning. It doesn't significantly elevate beyond what the schema already clarifies.

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 tool's function as a multi-step flash-action that atomically combines deposit, collateral use, swap, LP mint, and optional borrow into one transaction. It distinguishes itself from the sibling write_account_deposit by explicitly saying 'Do NOT call write_account_deposit separately', making the scope unequivocal.

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 usage guidance: when to use (to add liquidity), when not to (do not call deposit separately), prerequisites (check allowances first, approve if needed), and alternatives (read_guides for workflows). It also clarifies margin vs. spot account applicability and includes retry advice, giving clear decision-making 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?

Beyond annotations, the description adds critical behavioral context: it only builds an unsigned transaction (not submitting it), it validates and rejects spot accounts, and it requires positive free margin before borrowing. These details align with the idempotentHint and readOnlyHint=false annotations, enriching the agent's understanding without 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 three sentences of dense, high-value information. It front-loads the purpose, then gives an exclusion/alternative, then constraints and a safety check—no wasted 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?

Given the rich schema and output schema, the description covers the primary action, a key alternative, account-type restrictions, and a verification step. This is complete for a transaction-building tool, leaving no critical gaps for the agent.

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 covers 100% of parameters with clear descriptions, so the baseline is 3. The tool description adds general domain context (collateral, borrowing) but does not elaborate on specific parameter details like chain_id or to beyond what the schema already states, so no additional points are warranted.

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 an unsigned transaction to borrow from an Arcadia lending pool against account collateral.' It clearly distinguishes itself from the sibling tool write_account_add_liquidity by noting that leveraged LP handles borrowing internally, so the tool's unique purpose is 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 provides explicit when-to-use and when-not-to-use guidance: 'NOT needed for leveraged LP — write_account_add_liquidity handles borrowing internally when leverage > 0.' It also specifies the account-type prerequisite (margin accounts only), states that spot accounts are rejected, and recommends a pre-flight margin check via read_account_info.

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

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

The description goes far beyond the annotations. It discloses that tokens remain in the account, that the calldata is time-sensitive (30 seconds), advises retry on reverts, and explains the two-mode fallback behavior. The annotations (readOnlyHint=false, idempotentHint=true, etc.) are not contradicted; the description adds significant behavioral context that the annotations cannot 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 structured with a lead sentence stating the core purpose, followed by a fallback note, then clearly delineated mode explanations, and finally time-sensitivity/validation details. Every sentence contributes crucial information without fluff. It is thorough yet efficiently organized.

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 (6 parameters, atomic multi-step action, output schema), the description covers all essential aspects: purpose, modes, token booking behavior, time sensitivity, retry instructions, and even mentions the tenderly simulation URL for validation. The agent is fully equipped to select and invoke 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?

Although the input schema has 100% parameter descriptions, the tool description adds strategic meaning: it explains how assets should be encoded for LP positions vs ERC20 tokens, clarifies when receive_assets is required, and describes the close_lp_only workflow as a step-by-step fallback. This is exactly the kind of semantic enrichment an agent needs beyond raw 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 begins with a specific verb and resource: 'closes an Arcadia account position in ONE transaction.' It clearly distinguishes itself from sibling tools like write_account_withdraw and write_account_remove_liquidity by describing the atomic combination of burn, swap, and repay steps. The purpose is unmistakable and detailed.

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 guidance is provided: 'ALWAYS try this tool first when closing/exiting a position. Only fall back to individual tools... if this tool fails.' It also explains the two modes (close_lp_only true/false) and when to use each, plus the follow-up step of calling write_account_withdraw. This is exemplary 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?

The description adds valuable behavioral context beyond the annotations: it emphasizes this builds an unsigned transaction (not executing it), explains the distinction between V3 margin and V4 spot accounts, and discloses the deterministic CREATE2 address prediction. Annotations already indicate idempotency and non-destructiveness, and the description enriches this with functional details.

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

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

The description is compact and well-structured: a single opening sentence states the main purpose, followed by two sentences clarifying version-specific behavior and the return value. Every sentence contributes meaning without redundancy, making it easy to scan.

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 (5 parameters, output schema, multiple account versions), the description covers all essential aspects: what it does, when to use each version, how creditor is handled, and what is returned. The output schema exists, so the description need not enumerate return fields, and it already mentions the predicted address. This is sufficient for an agent to select and invoke 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?

The input schema already has thorough descriptions for all 5 parameters (100% coverage), including the creditor being ignored for V4 and version meanings. The description largely restates this information, adding only minor context like 'any ERC20 allowed' and 'deterministic via CREATE2'. Since schema coverage is complete, a baseline score of 3 is appropriate; the description provides only marginal added value for 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 clearly states the action: 'Build an unsigned transaction to create a new Arcadia account via the Factory contract.' It uses a specific verb ('Build') and specific resource ('transaction'), and distinguishes from sibling tools by focusing solely on account creation. The version breakdown further clarifies the tool's scope.

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

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

The description provides clear context for when to use each account version (3 vs 0/4), including the role of the creditor and borrowing capabilities. It does not explicitly mention alternatives or exclusions relative to sibling write tools, but the purpose is self-evident. Lacks an explicit 'use this instead of X' statement.

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 annotations, the description reveals critical behavioral traits: time-sensitivity ('sign and broadcast within 30 seconds'), retry guidance ('retry at least once before giving up'), and the requirement to validate via tenderly_sim_status before broadcasting. These are non-obvious, actionable disclosures that significantly improve safe usage. 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 moderately long but every sentence earns its place: core purpose, alternative, exclusion, time-sensitivity, retry policy, and simulation validation. It is front-loaded and uses clear formatting (dashes, NOTE, conditional statement). No wasted 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?

Given the tool's complexity (multi-step flash-action, atomic transaction, time-sensitive calldata) and existence of an output schema, the description is fully complete. It covers usage, alternatives, failure handling, and pre-broadcast validation (tenderly sim), leaving no critical gaps for an agent to invoke 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?

Schema description coverage is 100%, so all seven parameters are already documented. The description adds high-level context (e.g., 'account collateral' vs wallet tokens) but does not provide additional per-parameter details beyond what the schema already offers. 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 clearly states the tool's specific mechanism: 'sells account collateral to the debt token and repays in one atomic transaction — no wallet tokens needed.' This distinguishes it from siblings like write_account_repay (wallet tokens) and write_account_close (closing position). The verb+resource+scope is explicit and 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 when-to-use guidance and names alternatives: 'To repay from wallet tokens instead, use write_account_repay' and 'If you are closing a position... prefer write_account_close.' It also states the exact constraint: 'Only use this tool for standalone repayment while keeping the position active.' This is exemplary 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?

The annotations already convey idempotentHint=true and destructiveHint=false, so the burden is lower. The description adds valuable behavior details: it builds an unsigned transaction (not executes), auto-detects the account version on-chain, and supports only ERC20 and ERC721 assets. It does not contradict the annotations.

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

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

The description is three sentences and every sentence delivers key information: the action, supported asset types, an exclusion to a sibling tool, and a prerequisite workflow. It is front-loaded with the primary 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?

Given the tool's complexity (7 parameters), the presence of an output schema, and the annotations, the description covers all essential aspects: what it does, when to use it, the atomic alternative, the approval prerequisite, and supported asset types. No critical gaps remain.

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 adds context about the approval prerequisite and auto-detection of account_version, but it does not add meaning beyond what the schema already provides for each parameter. The schema's own descriptions are clear and sufficient.

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: 'Build an unsigned transaction to deposit assets into an Arcadia account as collateral.' It also distinguishes itself from the sibling write_account_add_liquidity by clarifying that this tool is 'NOT needed' before that one, making its purpose clear and differentiated.

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 provides when to use the tool and when not to, referencing the alternative write_account_add_liquidity. It also gives a concrete prerequisite workflow: check read_wallet_allowances and call write_wallet_approve if needed, which is 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 annotations (non-readOnly, non-destructive, idempotent), the description adds time-sensitivity (30 seconds), retry instructions, and mentions tenderly_sim_url/status for pre-broadcast validation. This enriches behavioral understanding without contradicting 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 compact and front-loaded: the first paragraph states the core purpose, the second names the alternative, and the third covers operational timing. 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?

With an output schema present, the description need not explain return values. It covers purpose, partial-vs-full distinction, time-sensitivity, retry behavior, and validation tools. Given the tool's complexity, this is fully sufficient 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?

Schema description coverage is 100%, so parameters are well-documented. The description reinforces the 'less than total liquidity' constraint but does not add meaning beyond the schema's existing parameter descriptions, leaving the baseline at 3.

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

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

The description clearly states the tool's function: "PARTIALLY decreases liquidity from an LP position," with details that the position remains open and tokens stay. It explicitly contrasts with write_account_close (full exit), making its unique scope 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 provides explicit alternative guidance: "For FULL position exit ... use write_account_close instead" and reiterates in the adjustment parameter that full removal requires close. It also gives practical usage tips: sign within 30 seconds and retry at least once on revert.

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

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

The description discloses the key prerequisite of requiring ERC20 allowance and the fact that it spends wallet tokens. While annotations already indicate a write operation (readOnlyHint: false), the description adds context about the workflow and prerequisites. It does not explicitly mention failure modes or token transfer side effects, but that is partially covered by the allowance requirement.

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: the main purpose, an alternative, and a pre-call workflow. It is front-loaded with the most important information, and every sentence adds value 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?

The description covers the core purpose, the main alternative (deleverage), the necessary prerequisites (allowance), and the recommended pre-flight checks. Since an output schema is present, return-value details are not required. This is a complete and actionable description for a lending repay operation.

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

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

Schema description coverage is 100%, with each parameter (amount, chain_id, pool_address, account_address) already documented. The description does not add additional parameter semantics beyond what the schema provides; it reinforces the allowance requirement but doesn't explain param formats or choices in more detail. 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 opens with a specific verb and resource: 'Repay debt to an Arcadia lending pool using tokens from the wallet.' This clearly distinguishes the tool from write_account_deleverage by explicitly stating the repayment source (wallet tokens vs. account collateral).

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 when-to-use guidance by naming the alternative tool for collateral-based repayment, and gives a concrete workflow: check allowance (read_wallet_allowances), approve if needed (write_wallet_approve), and check outstanding debt (read_account_info).

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

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

The description discloses that the transaction is 'unsigned,' which is a key behavioral trait beyond the annotations. It also explains the merging behavior and the return shape, which adds context about what the tool actually does. Annotations include idempotentHint=true and destructiveHint=false, and the description aligns with these, so no contradiction; it gains credit for the unsigned/return details.

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

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

The description is three sentences: the first states the purpose, the second explains the usage pattern, and the third provides a concrete example and return format. It is front-loaded, directly relevant, and contains no filler. 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?

The tool has moderate complexity, but the description covers the full workflow: it explains the source of inputs, how to combine them, and what the output looks like. The schema enriches this with parameter details, and the return type is specified. It is complete enough for an agent to understand how to invoke and use the result, though it could mention potential prerequisites like needing the account to exist.

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 provides 100% coverage with descriptions for each parameter. The description adds value by explaining that the arrays come from write_asset_manager.* intent tools and by explicitly demonstrating how to concatenate arrays from multiple calls. It also clarifies the output shape, which indirectly helps understand parameter roles. This goes beyond the baseline.

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

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

The description opens with 'Build an unsigned setAssetManagers transaction from encoded intent args,' which uses a specific verb (build) and resource (setAssetManagers transaction) while distinguishing itself from the intent tools by naming the 'encoded intent args' source. It further clarifies the consolidation role by stating it 'builds a single unsigned tx targeting the account'.

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 clearly states when to use this tool: to combine multiple automations into one transaction. It gives a concrete example ('rebalancer + merkl_operator') and explains the necessary prior step of calling intent tools and merging their arrays. While it doesn't explicitly state when not to use it, the usage context is well-defined, so it earns a 4.

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

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

The description richly discloses behavior beyond annotations: the calldata is time-sensitive (30 seconds), the need to rebuild on revert, potential Tenderly simulation unavailability, and the prerequisite of verifying position existence. It also clarifies the atomic, flash-action nature. Annotations provide readOnlyHint=false and destructiveHint=false, but the description adds critical execution context that affects how an agent should use the tool.

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

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

The description is four sentences, each delivering critical information: operation summary, parameter guidance, time-sensitivity, and fallback behavior. It is front-loaded with the core purpose and then details caveats. No filler or redundancy exists, and the structure is easy to scan.

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 multiple actions, conditional address logic, and time-sensitive output, the description covers all important aspects: how to choose actions, how to set addresses, what to do if the transaction reverts, and a pre-signing verification step. It also mentions the limitation of Tenderly simulation. Given the output schema exists and the description explains user-facing behavior, nothing is left ambiguous.

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 descriptions cover all parameters (100%), but the description adds important semantic meaning, especially for `asset_address` ('pass the non-staked PM address when staking, or the staked PM address when unstaking') and clarifies the `action` parameter's options. It provides context that the schema's generic descriptions lack, making it easier to construct correct calls.

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 tool's purpose: 'stake, unstake, or claim rewards for an LP position in one atomic transaction.' It names specific actions and the resource (LP position), and the mention of 'one atomic transaction' distinguishes it from simple tool calls. The tool name 'write_account_stake' is expanded with the full range of operations, and it clearly differs from sibling write tools by focusing on staking workflows.

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 operational guidance: how to use the `action` parameter, which `asset_address` to pass for staking vs unstaking, and a recommendation to verify the position with `read_account_info` before signing. It also advises retry behavior on reverts. However, it does not explicitly state when to use this tool instead of other staking-related tools (e.g., write_asset_manager_compounder_staked), so it misses some alternative exclusions.

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

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

The description goes well beyond the annotations by disclosing that calldata is 'time-sensitive — sign and broadcast within 30 seconds,' advising to retry at least once on price-movement reverts, and warning not to broadcast if tenderly_sim_status is 'false.' These are critical behavioral traits not captured in the structured hints. The annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) are not contradicted by this text.

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 the core purpose and then delivers high-value usage and safety details in a compact NOTE block. Every sentence earns its place—usage alternatives, timing, retry behavior, and sim validation—without padding. It remains readable despite containing essential operational warnings.

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 presence of annotations, a rich input schema, and an output schema, the description still contributes important context: it specifies the standalone-swap scope, the atomic single-transaction nature, and the exact pre-broadcast validation workflow. It covers usage conditions, failure handling, and response-guarded safety, making the tool fully understandable for an agent without external documentation.

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 input schema already documents all six parameters thoroughly. The description adds no novel parameter-specific meaning beyond noting the backend finds the optimal route; it doesn't elaborate on slippage units or amount_in formatting beyond what schema already states. Thus 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 begins with a specific action: 'swaps assets within an Arcadia account in one atomic transaction,' clearly identifying the verb and resource. It also distinguishes itself from the sibling write_account_close by directing closing-position scenarios to that tool, making its purpose unambiguous among many write_account_* 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?

Explicit usage guidance is given: 'Only use this tool for standalone swaps within an active position,' and the alternative for closing positions is named directly: 'prefer write_account_close which batches everything atomically.' Additional operational timing guidance (30-second calldata validity, retry on revert, pre-broadcast sim check) further clarifies when and how to act.

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

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

The description goes well beyond the annotations by disclosing that only the account owner can withdraw, that the transaction reverts if it would make the account undercollateralized, that max_uint256 is unsupported (requiring exact amounts from read_account_info), and that the account version is auto-detected on-chain. These are meaningful behavioral details not present in the annotations.

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

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

The description is four concise sentences, each delivering distinct information: the core action, permission requirement, revert condition, and amount/version handling. It is front-loaded with the primary 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?

The description covers all critical operational aspects: what the tool does, who can use it, failure conditions, a notable limitation (max_uint256), and auto-detection behavior. Given that an output schema exists, the absence of return-value details is acceptable, and the description is fully sufficient for an agent to use 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?

Although the schema already describes all parameters (100% coverage), the description adds key semantic caveats: exact amounts must be passed (no max_uint256) and account_version is an optional override with on-chain auto-detection. This supplements the schema with practical usage guidance for asset_amounts and account_version.

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 'Build an unsigned transaction to withdraw assets from an Arcadia account to the owner's wallet' with a specific verb, resource, and destination. It clearly distinguishes this from sibling write tools such as write_account_deposit, write_account_borrow, and write_account_repay by naming the withdraw action and the owner-only constraint.

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 clearly conveys when to use the tool (to withdraw assets from an Arcadia account) and adds relevant constraints (owner-only, undercollateralization revert). It does not explicitly mention alternatives or when-not-to-use, but the context is unambiguous for an agent selecting this tool among 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, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context: it encodes args rather than directly mutating, clarifies the exact scope of claims (LP fees only), describes the return shape, and notes combinability with other intent tools. 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 concise yet information-dense: it front-loads the purpose, then covers exclusions, alternatives, edge cases (rebalancer interaction), and return value usage in a compact form. Every sentence earns its place; no redundant 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?

Given the rich annotations, complete schema, and output schema, the description covers all necessary context: what the tool does, what it does NOT do, when to use alternatives, how the output integrates with another tool, and behavior relative to rebalancers. It is fully sufficient for an agent to select and invoke confidently.

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

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

Schema description coverage is 100%, so all parameters (enabled, chain_id, dex_protocol) are already well-documented with descriptions and enums. The description adds context about the return value and its downstream use, but does not elaborate on parameter details. Baseline 3 is appropriate since the schema carries 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?

The description clearly states the tool's function: 'Encode args for the standalone compounder automation' and explains the mechanism ('Claims accumulated LP trading fees and reinvests them back into the position'). It further distinguishes from its sibling by explicitly excluding staking rewards and naming the alternative tool for staked positions.

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 usage guidance: 'LP fees only — does NOT claim staking rewards like AERO; use write_asset_manager_compounder_staked for staked positions earning emission tokens.' Also explains the interaction with rebalancers ('When paired with a rebalancer...') and how to use the return value ('pass to write_account_set_asset_managers').

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

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

The description says the tool 'Sets metadata on BOTH the CowSwapper and the Compounder in a single call', which describes a write operation, while annotations declare readOnlyHint=true. This is a direct contradiction. The description also describes claiming rewards and swapping, but clarifies it's encoding args; still, the metadata-setting action is a mutation.

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 relatively long but every sentence carries information: purpose, reward type, workflow, parameter hints, return shape, chain, and combinability. It is front-loaded and structured logically, not overly verbose for 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?

Given the tool's complexity and that an output schema exists, the description covers purpose, parameter semantics, output format, chain restriction, and how it fits with other intent tools. It lacks explicit error scenarios or prerequisites, but the provided info is sufficient 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?

Schema coverage is 100% so baseline is 3, but the description adds meaningful examples: sell_tokens as reward addresses (e.g., AERO), buy_token as a major pair token (USDC, WETH, cbBTC). This helps an agent pick correct parameter values 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 pins the tool to encoding args for a compounder paired with CowSwap, specifically for staked LP positions. It distinguishes from siblings by emphasizing 'staked' positions and the coupled CowSwapper + Compounder behavior, making it easy to differentiate.

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 strong contextual guidance: use it for staked positions earning emission rewards (not LP fees), and mentions chain restriction 'Base only' and combinability. It implicitly excludes unstaked positions but does not explicitly name alternatives or when not to use.

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 idempotentHint=true, so the encode-only nature is corroborated. The description goes well beyond annotations by disclosing the need for an additional signature per swap, Base-only availability, the exact return shape, and that it is not coupled to other automations. 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?

The description is three sentences, front-loaded with the core purpose, and every clause adds value. It packs in the mechanism, differentiation, constraints, and return usage without fluff. The structure is easy to scan and digest.

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 covers the tool's purpose, return value, downstream usage, and behavior exceptionally well. However, the chain_id contradiction between description and schema leaves a gap: the agent cannot confidently determine which chain IDs are actually valid. This minor incompleteness prevents a perfect score despite the rich context.

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 actively contradicts the schema: it states 'Only available on Base (8453)' while the schema permits chain_id 130 (Unichain) and 10 (Optimism). This creates confusion for the agent when selecting a chain_id value. The description adds no beneficial parameter detail beyond the schema and introduces a direct inconsistency.

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 ('Encode') and resource ('args for standalone direct CowSwap mode'), clearly defining the tool's purpose. It also distinguishes from siblings by explicitly naming compounder_staked and yield_claimer_cowswap and explaining the standalone nature. The output format and downstream target are also mentioned, making the 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 provides explicit when-to-use guidance by contrasting with alternative asset manager tools ('Unlike compounder_staked or yield_claimer_cowswap...'). It also states a key operational requirement ('each swap requires an additional signature') and that it is combinable with other intent tools. The only minor flaw is the chain constraint conflicting with schema, but the guidance itself is actionably 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?

The description clarifies that this tool encodes args rather than directly performing claims, and explains the return value and next step ('pass to write_account_set_asset_managers'). It adds useful context about no conflict with rebalancer and extra yield, complementing the annotations without contradicting them.

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 efficiently structured with each sentence earning its place: purpose, reward context, usage trigger, combination advice, availability, and return value. 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?

Given the tool's moderate complexity, the description covers what it does, when to use it, how to use the result, and compatibility with other tools. The annotations and full schema coverage fill remaining gaps, making it complete for agent 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add significant parameter-level detail beyond what the schema already provides, though it reinforces the purpose of reward_recipient indirectly. It meets the baseline but does not elevate 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?

The description opens with the specific verb 'Encode args' for the Merkl operator automation, immediately distinguishing it from sibling asset-manager tools. It then explains the tool's role in claiming Merkl protocol rewards, making the 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?

Provides explicit guidance: 'Enable when the pool has active Merkl campaigns' and 'Always combine with rebalancer when both are relevant', plus notes it's combinable with other intent tools. This clearly tells the agent when to use it and when to combine with 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?

The description adds substantial context beyond the readOnlyHint/idempotent annotations: it explains that the tool only encodes args (hence read-only), but the resulting automation will reclaim and compound fees, the different trigger modes, and that the return value is intent data for a separate unsigned-tx builder. No contradiction with annotations; it actually clarifies why readOnlyHint is true for a write_* tool.

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

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

The description is longer than some, but every sentence carries meaningful information. It is front-loaded with the core purpose, then proceeds to behavior, integration, and nuanced parameter details. The trigger-ratio paragraph is dense and might benefit from clearer separation, but it remains efficient relative to 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?

Given the tool's complexity (10 params, many siblings, output schema present), the description is remarkably complete. It covers the purpose, automation behavior, strategy modes, return-value integration, combinability with other intent tools, and subtle trigger semantics. The output schema already handles return-field details, so the description does not need to over-explain them.

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?

All 10 parameters are already described in the schema, but the description adds crucial nuance: trigger_lower_ratio and trigger_upper_ratio are independent, asymmetric configurations are valid, and ratios represent tick distance rather than price. The concrete example (-50000 / 0) clarifies behavior beyond the schema's own descriptions, making this a value-add beyond structured data.

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 starts with 'Encode args for the rebalancer automation', clearly stating the verb and resource. It distinguishes this from other write_asset_manager_* tools by focusing on the rebalancer automation, with specific details about LP positions, out-of-range triggers, and fee/reward compounding.

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 explains the two strategy configs ('default' vs 'custom') and how they affect trigger behavior, and explicitly directs the user to pass the returned object to write_account_set_asset_managers. It also notes that results from multiple intent tools can be combined in one transaction. However, it does not explicitly contrast this tool with sibling automation tools or state when not to use it, though this is implied by the name and 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 already indicate read-only, idempotent, and non-destructive behavior. The description adds value by clarifying that the tool only 'encodes args' rather than performing an on-chain side effect, and by revealing the exact return structure. It also notes composability with other intent tools, enhancing transparency beyond the annotations.

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

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

Two compact sentences deliver all essential information: the tool's role, its behavior, its return value, and its integration point. The first sentence is immediately actionable, and there is no redundant or filler content. This is an efficiently structured description.

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

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

With a rich output schema and fully described parameters, the description need not re-explain those details. It provides the missing workflow context—that this encoder returns data for write_account_set_asset_managers and composes with other intent tools. The only notable gap is the lack of distinction from the cowswap variant, which prevents a perfect score.

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 covers 100% of parameters with descriptions and enums, so the baseline is 3. The tool description adds minimal detail beyond the schema—it merely restates that the fee recipient is a designated address. No additional parameter semantics or relationships are explained, so it neither enhances nor detracts 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 and resource: 'Encode args for the standalone yield claimer automation.' It clearly distinguishes the tool's function from siblings by stating it claims fees/emissions and sends them to a recipient. The unique return payload and downstream use are also documented, making the 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 gives clear context: it is used to encode args for a periodic yield-claiming automation, and the output is passed to write_account_set_asset_managers. It explicitly says 'Combinable with other intent tools,' which implies a workflow. However, it does not explicitly compare against the similarly named write_asset_manager_yield_claimer_cowswap, so some selection guidance is missing.

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

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

Annotations already declare readOnlyHint/idempotentHint, and the description adds valuable behavioral context: it returns { asset_managers, statuses, datas } with 2 entries, sets metadata on both components, and is MEV-protected. While 'Claims LP fees, then swaps' could be misread as execution, the opening 'Encode args' and readOnlyHint clarify it is an encoding tool.

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

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

The description is dense but every sentence earns its place: purpose, flow, parameter examples, return shape, chain restriction, and composability. 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?

Given the tool's complexity (6 parameters, output schema, annotations), the description is thorough: it covers the operational flow, parameter strategy, return shape, chain limitation, and integration with other intent tools. The output schema handles return-value details, so no further elaboration is needed.

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 descriptions cover all parameters, but the tool description adds significant semantic depth: for staked LPs sell_tokens is the staking reward token (e.g., [AERO]); for non-staked LPs it is all fee tokens except buy_token, with a concrete WETH/USDC→USDC example. This exceeds schema-level guidance.

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

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

The description opens with 'Encode args for yield claimer coupled with CowSwap,' which is a specific verb+resource statement. It clearly explains the claim-and-swap flow and provides examples that distinguish it from sibling tools like write_asset_manager_yield_claimer or write_asset_manager_cow_swapper.

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 concrete when-to-use guidance with staked vs non-staked LP examples, states 'Base only,' and notes it is combinable with other intent tools. It does not explicitly name alternatives or exclusions, but the context makes the intended use 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?

Annotations only indicate write and non-destructive behavior, but the description adds crucial behavioral detail: the transaction is unsigned, it requires prior approval, and it describes the deposit flow (underlying asset to tranche shares accruing interest). This goes well beyond the minimal annotation hints and provides exact 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 concise, front-loaded with the core purpose, and every sentence adds value—covering prerequisites, asset types, and related tools. No redundancy or 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?

Despite minimal annotations and a relatively complex ERC-4626 deposit flow, the description covers prerequisites, asset context, and appropriate companion tools. With an output schema present, the description is complete enough for an agent to correctly select and invoke the tool.

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

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds extra semantic value by specifying accepted assets (USDC/WETH/cbBTC) and pointing where to get tranche_address from read.pool.list, which enhances parameter understanding 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?

Clearly states the tool builds an unsigned deposit transaction into an Arcadia lending tranche (ERC-4626), with a specific verb ('build'), resource ('deposit transaction'), and context (depositing underlying assets for tranche shares). This clearly distinguishes it from sibling tools like write_pool_redeem and write_wallet_approve.

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 states a prerequisite (`Requires prior ERC-20 approval to the tranche`) and names the alternative tool for approval (`see write_wallet_approve`). Also provides guidance on checking yield through read_pool_list or read_pool_info, giving clear when-to-use and related-tool 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 description discloses important behavioral traits beyond annotations: it burns tranche shares, returns the underlying asset with accrued interest, and produces an unsigned transaction. This adds context about asset flow and non-execution, which annotations (all false) do not 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?

The description is two sentences with the main action front-loaded and no redundant wording. Every sentence adds value, and it is concise for the complexity of an ERC-4626 redeem transaction.

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 presence of an output schema and full parameter descriptions, the description is complete enough for an AI agent to understand the tool's purpose and effects. It could mention the return value more explicitly, but 'unsigned transaction' implies the output schema covers that. Minor gap: no mention of prerequisites like token approvals.

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 restates the roles of 'owner' and 'receiver' but adds no new details beyond what the schema already explains for each parameter.

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 verb ('Build') and resource ('unsigned redeem transaction to withdraw from an Arcadia lending tranche (ERC-4626)'), and distinguishes it from siblings like write_pool_deposit and write_account_withdraw by specifying the exact action (redeem) and protocol context.

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 clear context for when to use the tool ('withdraw from an Arcadia lending tranche') and explicitly states constraints ('The owner must be the shares holder; receiver is where the underlying asset is sent'). It does not explicitly mention alternative tools, but the unique purpose is evident from the wording and sibling names.

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

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

The description discloses a key behavioral trait beyond annotations: the transaction is 'unsigned' (not broadcast). It also explains that NFT approvals are set to true and that amount is ignored for NFTs. Annotations (idempotentHint=true, destructiveHint=false) are consistent; no contradiction. Slightly more could be said about return format, but the output schema 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 with zero waste. First sentence states purpose, second explains token-type behavior, third gives required prerequisite and tip. All information is essential and logically ordered. Front-loaded with the core function.

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 (5 params, multiple token types) and the presence of an output schema, the description covers prerequisites, parameter nuances, and usage tips. It fully prepares the agent to select and invoke the tool correctly, without needing to infer any important behavior.

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. The description adds meaningful parameter context: 'amount' is ERC20 only and ignored for NFTs, and 'spender_address' should be the Arcadia account address for deposits. It also clarifies the 'asset_type' branches. This exceeds the schema's basic descriptions, enhancing the agent's understanding of parameter interplay.

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 begins with a specific verb+resource: 'Build an unsigned approval transaction.' It clearly distinguishes from siblings by explaining the two token type paths (ERC20 approve vs ERC721/ERC1155 setApprovalForAll) and references related tools like write_account_deposit and write_account_add_liquidity. This is unambiguous and specific.

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 context: 'Required before write_account_deposit or write_account_add_liquidity (when depositing from wallet).' It also provides actionable guidance to first call read_wallet_allowances and skip if sufficient. This clearly tells the agent when to use this tool and how to avoid unnecessary calls, distinguishing it from alternatives.

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