Arcadia Finance

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

Annotations provide safety hints (destructiveHint=true, readOnlyHint=false), but the description adds critical operational context: it uses a 'PK env var' (local key storage risk), it submits 'onchain' (external effect), and it chains from write.* tools (input dependency). Does not contradict annotations.

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

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

Three sentences each earning their place: first establishes purpose and dev-only scope, second provides production alternatives, third explains input chaining. Critical warning ('DEV ONLY') is front-loaded. No redundant or wasteful text.

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 existence of output schema (per context signals) and comprehensive annotations, description adequately covers the tool's purpose, security model (env var), environment constraints (dev vs prod), and input source without needing to describe return values. Could hint at chain_id defaults but schema covers this.

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 has 100% description coverage (to, data, value, chain_id all documented). The description adds semantic context that these parameters form a 'transaction object' typically returned by write.* tools, but does not need to describe individual fields due to complete schema 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?

Description clearly states the specific action ('Sign and broadcast an unsigned transaction'), the mechanism ('using a local private key'), and the resource ('transaction'). It strongly distinguishes itself from siblings by stating it 'Takes the transaction object returned by any write.* tool,' positioning it specifically after the write-prefixed tools in the sibling list.

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

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

Provides explicit when-to-use ('DEV ONLY'), when-not-to-use ('For production, use... instead'), and names specific alternatives ('Fireblocks, Safe, Turnkey, etc.'). Also clarifies input prerequisites by stating it takes output from 'any write.* tool.'

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

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

Annotations cover safety profile (readOnly, non-destructive, idempotent). The description adds valuable behavioral context beyond annotations: it details the exact return structure (snapshots with timestamp, collateral_value, debt_value, net_value), specifies units (USD), and notes human-readable formatting vs raw units.

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 well-structured sentences with no waste. Front-loaded with purpose ('Get historical...'), followed by return value specification, and closing with use case. 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 presence of an output schema (per context signals), the description appropriately focuses on input context and high-level return semantics. It adequately covers the tool's purpose, return format interpretation, and intended use case for a 3-parameter historical data retrieval 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?

With 100% schema description coverage, the baseline is 3. The description mentions 'Arcadia account' which implicitly contextualizes the account_address parameter, but does not add semantic details about the days or chain_id parameters beyond what the schema already provides.

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

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

The description uses specific verbs ('Get') and identifies the exact resource ('historical collateral and debt values for an Arcadia account'). It distinguishes from sibling read_account_info by emphasizing 'over time' and 'time series' vs current state, and clearly scopes the domain to Arcadia accounts.

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 implied usage context ('Useful for charting account performance over a period'), indicating when to use it (historical analysis). However, it lacks explicit when-not-to-use guidance or direct contrast with read_account_info or read_account_pnl for current state vs historical data.

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

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

Despite readOnlyHint=true in annotations, the description adds substantial behavioral context: the health factor calculation formula and interpretation thresholds, Base-chain specific return fields, numeric unit handling (raw vs. USD, decimals), and internal-to-external key mappings for automation protocols. It also documents the relationship between output fields and input requirements for write_asset_manager.* tools.

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?

While lengthy due to the complexity of DeFi account states, the description is information-dense and logically structured: purpose statement first, followed by health factor math, chain-specific variations, data format specifications, and cross-tool mappings. Every sentence provides necessary interpretation logic that cannot be inferred from the schema alone.

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 returns complex nested financial data (implied by the detailed field explanations), the description comprehensively documents output interpretation: mathematical formulas, enum value mappings, decimal handling, and automation status decoding. This compensates appropriately for the complexity even though an output schema exists.

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

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

With 100% schema description coverage, the schema adequately documents both parameters (account_address, chain_id). The description provides contextual clues about these parameters (referencing 'On Base' for chain_id=8453, discussing account-specific numeraires), but does not significantly augment the parameter semantics beyond what the schema already provides. Baseline 3 is appropriate given the complete schema coverage.

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

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

The description opens with a specific verb ('Get full overview') and resource ('Arcadia account'), then enumerates the specific data points returned (health factor, collateral value, etc.). It explicitly distinguishes itself from sibling tool 'read_wallet_accounts' by stating 'To list all accounts for a wallet, use read_wallet_accounts', clarifying this tool requires a specific account 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 explicit cross-tool guidance by naming 'read_wallet_accounts' as the alternative for listing accounts vs. getting specific account details. It lacks explicit guidance distinguishing it from other account-scoped reads like 'read_account_history' or 'read_account_pnl', though the detailed output schema description implicitly clarifies its domain.

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. The description adds valuable behavioral context beyond these: it explains data semantics (negative cost_basis indicates net profit withdrawn) and clarifies units (USD vs raw token units), which helps the agent interpret the returned financial data correctly.

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 the purpose front-loaded in the first sentence, followed by specific details about return fields and units. Every sentence provides distinct value (return structure, unit clarification, data interpretation) with minimal 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 existence of an output schema and comprehensive annotations, the description appropriately supplements rather than replaces structured documentation. It provides crucial domain-specific context (unit types, interpretation of negative values) that makes the financial data usable, though it could briefly acknowledge the chain_id parameter's role in the first sentence.

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 has 100% description coverage, clearly documenting account_address and chain_id. The description appropriately focuses on return value semantics rather than repeating parameter documentation that the schema already covers, meeting the baseline expectation.

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

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

The description clearly states the specific action ('Get') and distinct resource ('PnL', 'cost basis', 'yield earned' for an Arcadia account). It effectively differentiates from siblings like read_account_info (general metadata) and read_account_history (transaction logs) by specifying financial calculation outputs.

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?

While the description clearly defines the tool's domain (profit/loss and yield analysis), it does not explicitly state when to use this versus siblings like read_account_info or read_account_history. The usage is implied by the specific financial terminology but lacks explicit guidance or named 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 cover safety (readOnlyHint, destructiveHint, idempotentHint). The description adds valuable behavioral context by detailing return structure: 'compact list (address, symbol, decimals, type)', giving agents visibility into data shape beyond the boolean annotations.

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

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

Four sentences, zero waste. Front-loaded with purpose ('List supported collateral assets'), followed by return value, parameter guidance, and sibling distinction. 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 high-quality annotations covering safety profile and the existence of an output schema, the description appropriately focuses on domain-specific context (Arcadia platform, return fields) and sibling relationships rather than restating safety properties.

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%, establishing baseline 3. The description adds actionable usage semantics: 'Use search to filter by symbol substring' provides imperative guidance on parameter application beyond the schema's declarative description.

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 explicitly states 'List supported collateral assets on Arcadia'—specific verb, resource, and platform. It distinguishes from sibling 'read_asset_prices' by stating 'For USD prices, use read_asset_prices', clearly delineating 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?

Provides explicit guidance: 'Use search to filter by symbol substring' explains when to use the parameter. Critically names an alternative tool: 'For USD prices, use read_asset_prices', establishing clear boundaries between this and the sibling price-fetching tool.

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

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

Annotations establish safety (readOnly/idempotent), while the description adds critical behavioral context: that intent tools return 'encoded args', that they can be combined by merging arrays, and that they accept 'enabled=false'. This explains the system mechanics beyond what annotations provide.

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

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

Six information-dense sentences cover purpose, usage workflow, and system mechanics with minimal waste. Front-loaded with purpose. Slightly verbose regarding the 'enabled=false' detail (which applies to other tools), but structure is logical and readable.

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?

Excellent completeness for a discovery tool with output schema. It explains not just the single optional filter parameter, but the entire multi-tool orchestration pattern (discovery → intent calls → application), which is essential for successful use.

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

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

Schema coverage is 100% for the single 'chain_id' parameter, which is fully documented in the schema. The description mentions 'supported chains' in the context of output data but adds no new syntax or format details for the input parameter itself, warranting the baseline score.

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

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

Description clearly states it 'List[s] all available automation intents' with specific output details (tool names, parameters, chains), and distinguishes itself from the write_asset_manager.* siblings by defining its role as discovery/read-only.

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 workflow: use this for discovery, then call specific write_asset_manager.{id} tools (named explicitly), combine results, and pass to write_account_set_asset_managers. It clearly maps when to use this vs the write 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 cover safety profile (readOnly, non-destructive, idempotent). The description adds valuable behavioral context: specifies the currency (USD), documents the output structure ('price map keyed by address'), and reinforces the comma-separated input format. No contradictions 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?

Three efficient sentences: purpose first ('Get USD prices...'), input format second, output format third. No waste words, perfectly front-loaded, 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?

Appropriately leverages the existing output schema and rich annotations. Mentions USD unit and return format. Minor gap: does not mention the chain_id parameter or its default (Base/8453) in the description text, relying entirely on schema for this required parameter 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% with both parameters fully documented (chain_id options, asset_addresses format). The description reinforces the comma-separated format but does not add substantial semantic meaning beyond what the schema already provides, warranting the baseline score.

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

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

The description uses a specific verb ('Get') and resource ('USD prices') with clear scope ('asset addresses'). It effectively distinguishes from siblings like read_asset_list (which lists assets, not prices) and read_wallet_balances (which returns balances, not market prices).

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

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

Provides clear input format guidance ('Pass a single address or comma-separated addresses') but lacks explicit when-to-use guidance versus alternatives like read_asset_list or read_wallet_balances, and does not specify prerequisites or rate limit considerations.

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 cover safety profile (readOnly, idempotent, non-destructive). Description adds value by disclosing content types returned (addresses, tool catalogs, step-by-step templates, strategy parameters) which helps the agent anticipate what knowledge it will receive. No contradictions 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?

Three sentences, zero waste: Sentence 1 defines resource, Sentence 2 gives usage trigger, Sentence 3 maps parameter values. Front-loaded with action verb. No redundancy with structured metadata.

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?

Complete for a documentation retrieval tool. Describes the four topic domains clearly. Given presence of output schema (per context signals), description appropriately omits return value details while covering the complex Arcadia domain sufficiently.

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 has 100% coverage (baseline 3). Description adds semantic grouping by listing topics with parenthetical explanations that map to the enum values, reinforcing the domain-specific meanings (e.g., 'automation' relates to rebalancer/compounder, 'selection' to pool evaluation). Adds context beyond raw 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?

Excellent clarity: 'Get Arcadia workflow guides and reference documentation' provides specific verb+resource. Clearly distinguishes from siblings like read_strategy_info or read_account_info by specifying these are guides/templates/documentation versus live operational 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?

Strong positive guidance: 'Call this before multi-step workflows' and 'when you need contract addresses...' provides explicit temporal/contextual trigger. Lacks explicit 'when-not' or named alternatives (would need to say 'instead of read_pool_info' etc. for 5), but workflow positioning is 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 annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), reducing the description's burden. The description adds value by disclosing the pagination behavior ('(paginated)'), which is not mentioned in annotations, but does not disclose additional behavioral details like rate limits or caching behavior.

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

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

The description consists of exactly two efficient sentences with zero redundancy. The primary purpose is front-loaded in the first sentence, while the second sentence immediately addresses the sibling distinction without extraneous verbiage.

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 (removing the need to describe return values), comprehensive annotations covering safety hints, and 100% parameter schema coverage, the description is complete. It successfully covers the tool's scope, pagination nature, and relationship to siblings for this simple read operation.

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

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

With 100% schema description coverage, the baseline score is 3. The description implies pagination behavior which contextualizes the 'limit' and 'offset' parameters, but does not add syntax details, validation rules, or semantic meaning beyond what the schema already provides for these two optional parameters.

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

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

The description provides a specific verb ('Get'), resource ('Arcadia points leaderboard'), and scope ('paginated'). It clearly distinguishes this tool from the sibling 'read_wallet_points' by explicitly contrasting the global leaderboard against specific wallet queries.

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 the alternative tool ('read_wallet_points') and specifies when to use it instead ('For a specific wallet's points balance'), providing clear guidance for tool selection. This creates an unambiguous decision boundary between the two related point-reading 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 declare safety profile (read-only, non-destructive, idempotent, open-world). Description adds valuable behavioral context by specifying the data includes APY history over time and explaining the analytical use case, complementing the annotations 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 efficiently structured sentences covering core functionality, use case, and prerequisite workflow. Front-loaded with the specific action and resource; every sentence earns its place with zero 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?

Complete for a read tool with rich annotations and output schema available. Description successfully addresses the discovery prerequisite (pool addresses via read_pool_list) and explains analytical purpose without needing to document return values.

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 has 100% description coverage with clear definitions. Description implicitly reinforces the pool_address parameter by referencing 'single lending pool' and temporal context for days, but baseline 3 is appropriate given complete schema 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?

Description clearly states the specific action (Get), resource (lending pool), and scope (detailed info including APY history). It effectively distinguishes from sibling read_pool_list by noting this is for a single pool versus list discovery.

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 context ('analyzing rate trends and comparing pools') and explicitly references sibling tool read_pool_list for discovering pool addresses, establishing clear workflow prerequisites.

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 cover operational safety (readOnlyHint, idempotentHint), so the description focuses on domain-specific data interpretation: it defines rate semantics (decimal fractions, 1.0 = 100%) and clarifies field meanings (interest_rate = borrow cost, lending_apy = lender yield). This provides essential context for correctly rendering output values that structured fields don't 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?

Four tightly constructed sentences: purpose/return values, field definitions, data format specification, and sibling cross-reference. No redundancy; every clause adds distinct value regarding either functionality or data interpretation.

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 complete input schema coverage, the description appropriately focuses on domain semantics (rate formats, field definitions) rather than repeating structural metadata. Comprehensive for a read-only list tool with these annotation hints.

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 has 100% description coverage on chain_id. The description adds no parameter-specific guidance, but baseline 3 is appropriate since the schema fully documents the single optional parameter without gaps requiring compensation.

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-resource combination 'List all Arcadia lending pools' and enumerates exact return data (TVL, utilization, available liquidity). It explicitly distinguishes from sibling 'read_pool_info' by stating 'For APY history on a specific pool, use read_pool_info,' clearly delineating the list-snapshot use case from detailed historical queries.

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 negative guidance by naming the sibling alternative 'read_pool_info' for APY history use cases, effectively establishing scope boundaries. Lacks explicit positive 'when to use' framing (e.g., 'Use this for current market overview'), though this is implied by the opening 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?

Adds significant value beyond annotations by explaining data interpretation ('All APY values are decimal fractions') and business logic (range width vs APY/cost trade-offs). Annotations cover read-only/idempotent safety, but description explains what the data actually represents and how to consume it correctly.

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

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

Three tightly constructed sentences: purpose with content details, sibling cross-reference, and data format specification. Zero redundancy. APY fraction example (1.0=100%) is necessary precision, not verbosity. Information density is ideal.

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?

Comprehensive given no output schema. Explains return data structure (APY ranges, pool info, configuration), data formats (decimal fractions), domain concepts (LP strategies, range width implications), and prerequisite workflow. Rich annotations cover safety properties, freeing description to focus on data semantics.

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 has 100% description coverage ('Chain ID: 8453...', 'Strategy ID'), so baseline applies. Description mentions 'by ID' and references the discovery workflow, reinforcing the required parameter nature, but doesn't add syntax details beyond the well-documented 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?

Excellent specificity: states exact action ('Get full detail'), resource ('LP strategy'), and scope ('APY per range width, pool info, configuration'). The range width trade-off explanation ('narrower range = higher APY but more rebalancing cost/risk') provides crucial domain context that distinguishes this from simple data retrieval.

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

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

Explicitly references sibling tool 'read_strategy_list to discover strategy IDs,' establishing the correct workflow sequence. However, it lacks explicit contrast with related strategy tools like 'read_strategy_recommendation' or 'read_pool_info' to guide selection when multiple options exist.

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

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

Annotations declare readOnly/idempotent status. Description adds valuable return-value semantics: paginated nature, 7d avg APY metric, and crucially documents the APY data format (decimal fractions where 1.0=100%). Does not mention rate limits or error states, but covers the essential data contract.

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 with zero waste: purpose, recommended parameter usage, return structure, pagination mechanics, data format note, and sibling reference. Front-loaded with clear intent. Excellent density.

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 output schema exists, description appropriately highlights key return values (7d APY) and their semantics without replicating full schema. Covers DeFi-specific context (LP, APY calculation method) needed for correct interpretation.

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

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

With 100% schema coverage, baseline is 3. Description adds usage guidance: 'recommended first call' for featured_only, and explains the pagination relationship between limit/offset. This operational context exceeds raw schema definitions.

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

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

Description opens with specific verb 'Get' and resource 'Arcadia LP strategies'. Explicitly distinguishes from sibling read_strategy_info by stating when to use each: this tool for lists, read_strategy_info for 'full detail on a specific strategy'.

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

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

Provides explicit 'when-to-use' guidance: 'Use featured_only=true for curated top strategies (recommended first call)' and explicit alternative: 'For full detail... use read_strategy_info'. Also documents pagination pattern (increase limit or use offset).

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

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

While annotations cover safety profile (readOnly, idempotent), the description adds crucial behavioral context: APY values are decimal fractions (not basis points/percentages) and weekly_earning_difference is denominated in USD. It also clarifies the calculation methodology uses 1-day APY, which affects result interpretation.

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 states purpose, second differentiates from sibling with technical detail, third clarifies data formats. Information density is high and front-loaded appropriately.

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

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

No output schema exists, but the description compensates by documenting units and formats for key return values (decimal fractions for APY, USD for earnings). Missing only structural details of the recommendation object, which would be nice-to-have but not critical given the safety annotations.

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% (both account_address and chain_id have descriptions). The description adds no additional parameter details beyond the schema, meeting the baseline expectation for high-coverage schemas.

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

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

Specific verb+resource combination ('Get a rebalancing recommendation for an Arcadia account') clearly states the tool retrieves optimization suggestions. The scope is well-defined (asset changes to optimize yield) and distinguishes from read_strategy_list by noting the account-specific nature of rebalancing vs general strategy listing.

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

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

Explicitly names sibling tool read_strategy_list and contrasts methodologies (1d APY vs 7d APY), explaining why results may differ. This provides clear decision criteria for choosing between the two tools based on desired time horizon for yield calculations.

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 safety annotations (readOnly/destructive), it discloses return structure (summary with address, name) and workflow chaining to read_account_info. Misses edge cases like empty wallet results but covers primary behavioral traits well.

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 their place: purpose statement, return value summary, and sibling tool reference. No redundancy, well front-loaded.

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

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

Appropriately complete for a 2-parameter list operation with 100% schema coverage, full annotations, and output schema. Briefly summarizes output content without needing to replicate the full output schema definition.

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 descriptions for both wallet_address and chain_id. The description implies wallet_address is the owner but doesn't augment parameter semantics beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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

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

States specific verb 'List' with resource 'Arcadia accounts' and scope 'owned by a walletaddress'. Distinguishes from sibling read_account_info by clarifying this returns summaries (address, name) versus 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 call read_account_info for 'full details like health factor, collateral, and debt', creating clear workflow guidance for when to use each tool in the sibling set.

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 cover safety profile (readOnly, idempotent, non-destructive). Description adds valuable workflow context about optimization patterns (avoiding redundant approvals) and sufficiency checking that is not present in 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?

Two tightly-constructed sentences. First establishes purpose, second delivers usage guidelines. Zero redundancy - every word earns its place. Efficient front-loading of critical information.

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

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

Complete for its complexity level. Rich annotations cover behavioral safety hints, input schema has full coverage, and output schema exists (per context signals) so return values need not be described. Workflow integration with sibling tools is documented.

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 has 100% description coverage for all 4 parameters (chain_id, owner_address, spender_address, token_addresses). Description implicitly references spender_address and token_addresses in the context sentence but does not add additional semantic detail beyond what the schema already documents.

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

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

Specific verb 'Check' + resource 'ERC20 token allowances' + scope 'for a spender address'. Explicitly distinguishes from write_wallet_approve by describing the read-only checking function vs the write operation.

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 ('before write_wallet_approve') and the value proposition ('avoid redundant approvals'). Names the sibling tool directly and provides clear workflow logic ('skip approving if the current allowance is already sufficient').

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?

Adds valuable context beyond annotations: explains RPC multicall methodology (complementing openWorldHint) and clarifies dual-format output structure (raw wei + human-readable) despite existence of output schema. Correctly aligns with readOnly/idempotent annotations.

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

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

Four sentences, each earning its place: purpose declaration, technical methodology, usage guidance, and output format. Front-loaded with core function, no redundancy, appropriate density for a read operation.

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?

Comprehensive given rich annotations (4 hints) and 100% schema coverage. Addresses purpose, prerequisites, data source, and return format. No gaps for a standard balance inquiry 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?

While schema coverage is 100%, description adds crucial semantic detail that 'native ETH' is returned separately from ERC20 tokens, implying ETH should not be passed in token_addresses array. This clarifies parameter intent beyond raw schema definitions.

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?

Clear specific verb (Get) with explicit resource scope (native ETH and ERC20 token balances). Distinguishes from siblings by noting 'Reads directly from chain via RPC multicall,' indicating live on-chain data vs. cached reads like read_account_history.

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?

Excellent explicit guidance: 'Use before write_account_add_liquidity or write_account_deposit to verify the wallet has sufficient tokens.' Names specific prerequisite workflow and sibling write tools, clarifying exactly when to invoke this tool.

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

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

Annotations already disclose read-only, idempotent, non-destructive, and open-world traits. Description adds domain context ('Arcadia points') but doesn't address error cases (e.g., invalid wallet format), rate limits, or response structure. 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?

Single sentence, nine words. Front-loaded with action and object. No redundant phrases or filler content.

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

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

Adequate for a simple read operation with rich annotations and complete schema. Minor gap: doesn't explain what 'Arcadia points' represent (loyalty/rewards mechanism) or the return value structure, though this is partially mitigated by the tool's narrow scope.

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 has 100% description coverage for the single 'wallet_address' parameter. The description references 'wallet address' but adds no syntax details (e.g., checksum format, chain specificity) beyond the schema 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?

Clear verb ('Get') and resource ('Arcadia points balance') with specific scope ('for a specific wallet address'). Distinguishes from sibling read_wallet_balances by specifying 'points' versus token balances, though it doesn't explicitly contrast with read_point_leaderboard.

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

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

No guidance on when to use this versus alternatives like read_point_leaderboard (global view) or read_wallet_balances (token balances). No prerequisites or conditions mentioned.

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 (readOnlyHint:false, idempotentHint:true), the description discloses atomic flash-action mechanics, time-sensitive calldata expiration (30s), price movement revert risks, and detailed response semantics (expected_value_change units, tenderly_sim interpretation). No contradictions 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?

At 10+ sentences it is lengthy, but every sentence conveys essential information for a complex multi-step financial operation. Well-structured with the atomic action definition front-loaded and critical warnings (sibling exclusion, time sensitivity) prominently placed.

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?

Comprehensive coverage of a complex 8-parameter operation: explains the composite transaction flow, account type variations (margin vs spot), error handling (revert behavior), and response interpretation (raw units, simulation URLs) without needing to duplicate output schema details.

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

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

While schema has 100% coverage (baseline 3), the description adds crucial relational semantics: capital source logic ('wallet tokens (deposits array), existing account collateral (use_account_assets=true), or both'), leverage constraints ('Margin accounts only'), and the interaction between deposits and collateral flags.

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 compound verb phrase ('atomically combines...') listing all five sub-operations (deposit, collateral use, swap, mint LP, borrow) and explicitly distinguishes from sibling tool write_account_deposit with the warning 'Do NOT call write_account_deposit separately.'

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 prerequisites ('Check allowances first...then approve'), names alternative tools (read_wallet_allowances, write_wallet_approve, read_guides), specifies time constraints ('sign and broadcast within 30 seconds'), and prescribes retry logic ('retry at least once before giving up').

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 (idempotentHint, readOnlyHint), the description adds validation behavior (will reject spot accounts), unsigned transaction nature, and prerequisite checks (free margin verification). Could explicitly mention idempotency, but annotations cover binary safety properties while description covers domain logic.

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

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

Four sentences with zero waste: sentence 1 defines purpose, sentence 2 distinguishes siblings, sentence 3 states account constraints, sentence 4 lists prerequisites. Perfectly front-loaded with critical distinctions early.

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

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

For a complex DeFi borrowing operation, the description comprehensively covers: transaction type (unsigned), account prerequisites (margin accounts only), collateral requirements (positive free margin), sibling interactions, and validation behavior. Output schema exists, so return values needn't be described.

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

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

With 100% schema coverage, the description adds semantic relationships between parameters: pool_address relates to lending, account_address relates to collateral, and amount/to relate to borrowing. Explains 'against account collateral' linking account and amount semantics beyond schema definitions.

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

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

The description clearly states the specific action (build unsigned transaction), resource (Arcadia lending pool), and mechanism (borrow against collateral). It explicitly distinguishes from sibling write_account_add_liquidity by noting when NOT to use this tool (for leveraged LP).

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?

Excellent guidance includes: explicit when-NOT-to-use case (leveraged LP handled by sibling), prerequisite verification via read_account_info, and account type constraints (margin vs spot accounts). Names specific alternative tool and required pre-check.

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 indicate mutation (readOnlyHint:false) and idempotency, but description adds critical execution context: calldata is 'time-sensitive — sign and broadcast within 30 seconds,' requires immediate rebuild on reversion, and includes simulation URLs (tenderly_sim_url) for validation. Also clarifies token custody behavior post-execution.

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?

Lengthy but information-dense and well-structured with clear sectioning: atomic purpose, fallback guidelines, mode specifications, and time-sensitivity warnings. Every sentence provides actionable guidance. Front-loaded with the core atomic value proposition before detailing edge cases.

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

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

Comprehensive for a complex 6-parameter DeFi operation. Covers atomicity guarantees, failure recovery workflows, parameter interdependencies, time constraints, retry behavior, and integration with sibling withdrawal tools. Output schema exists, so detailed return value explanation is unnecessary, though calldata nature is mentioned.

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?

While schema coverage is 100% and adequately documents field formats, the description adds essential workflow semantics connecting the parameters: explaining the temporal sequence of close_lp_only modes ('Use as step 1...then call again'), distinguishing NFT position handling ('amount=1, decimals=1') from ERC20, and noting the dependency between close_lp_only and receive_assets.

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

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

Description explicitly states the tool performs an 'Atomic flash-action that closes an Arcadia account position' combining three specific steps (burn LP, swap, repay). It clearly distinguishes from siblings by naming the four individual tools to use as fallbacks (write_account_remove_liquidity, write_account_swap, write_account_deleverage, write_account_withdraw) if this atomic operation fails.

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 triage logic: 'ALWAYS try this tool first when closing/exiting a position' with clear fallback conditions ('Only fall back to individual tools...if this tool fails'). Details the two-step recovery workflow using close_lp_only=true then false, and mandates the follow-up action 'use write_account_withdraw to send them to your wallet' since tokens remain in the account.

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?

Adds crucial behavioral context beyond annotations: explains deterministic address generation via CREATE2, clarifies that creditor parameter is conditionally ignored, and details the unsigned transaction nature. Complements idempotentHint=true by explaining the deterministic outcome.

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

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

Three tightly constructed sentences with zero waste. Front-loaded with main action, followed by version logic, ending with return value specification. Every clause conveys necessary constraint or behavioral detail.

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?

Excellent coverage for a complex creation operation involving contract versions, deterministic addresses, and chain-specific deployment. Explains return value sufficiently given output schema exists; documents critical version/creditor interactions preventing user error.

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?

Despite 100% schema coverage, adds significant semantic value by explaining relationships between parameters (account_version determines creditor validity and borrowing capability) and the CREATE2 dependency on salt/wallet_address.

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

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

Specific verb+resource ('Build an unsigned transaction to create a new Arcadia account') clearly distinguishes from sibling read tools and other write_account_* tools that modify existing accounts. Specifies the mechanism (Factory contract) and return value (predicted 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?

Provides explicit guidance on selecting account_version (3 for margin/borrowing vs 0/4 for spot) and creditor usage (ignored for V4). However, it omits the workflow relationship with sibling dev_send which presumably executes the built transaction.

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?

Adds significant operational context beyond annotations: time-sensitivity ('sign and broadcast within 30 seconds'), retry logic ('retry at least once before giving up'), simulation validation ('if tenderly_sim_status is false, do NOT broadcast'), and mechanism details ('flash-action,' 'atomic transaction'). These behavioral specifics are absent from the boolean annotations.

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

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

Four dense sentences covering: (1) core function, (2-3) sibling alternatives with decision criteria, (4) operational constraints and output handling. Information is front-loaded with zero redundancy. Every clause conveys distinct critical information (time limits, retry requirements, validation checks).

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

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

For a complex DeFi mutation tool with atomic transactions and 7 parameters, the description comprehensively covers execution constraints, failure modes, validation requirements, and sibling selection logic. The output schema existence absolves the need for detailed return value documentation, yet the description still explains the critical tenderly_sim_status field.

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 ('Collateral token to sell,' 'Debt token address'). The description offers semantic context ('sells account collateral to the debt token') mapping parameters to their functional roles, but does not add syntax/format details beyond the comprehensive schema. Baseline 3 is appropriate given high schema coverage.

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

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

Explicitly defines the tool as a 'multi-step flash-action' that 'sells account collateral to the debt token and repays in one atomic transaction.' The description distinguishes from siblings by specifying 'no wallet tokens needed' (vs. write_account_repay) and identifying it as 'standalone repayment while keeping the position active' (vs. write_account_close).

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

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

Provides explicit when-to-use guidance with named alternatives: 'To repay from wallet tokens instead, use write_account_repay' and 'If you are closing a position... prefer write_account_close... Only use this tool for standalone repayment while keeping the position active.' This creates clear decision boundaries for the agent.

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 indicate idempotent, non-destructive, non-read-only. Description adds that it builds an unsigned transaction (clarifying it doesn't submit), discloses collateral purpose, and explains auto-detection behavior. Output schema exists so return value description is unnecessary.

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 tightly constructed sentences with zero waste: purpose first, asset support second, sibling differentiation third, prerequisites fourth, version behavior fifth. Every sentence adds unique guidance not found in structured fields.

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?

Comprehensive for a complex multi-asset deposit tool: covers ERC20/ERC721 handling, prerequisites, sibling relationships, version detection, and approval workflows. Output schema exists so return values need no description; annotations cover safety hints.

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. Description adds valuable semantic context: explains account_version is 'auto-detected on-chain' with override instruction, clarifies asset_ids semantics (0 for ERC20, NFT ID for ERC721), and asset_types inference logic.

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

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

Specific verb 'Build' with clear resource 'unsigned transaction to deposit assets into an Arcadia account as collateral.' Explicitly distinguishes from sibling write_account_add_liquidity by stating it is 'NOT needed before' that tool and explaining the atomic deposit difference.

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?

Excellent explicit guidance: states when NOT to use (vs write_account_add_liquidity), provides prerequisite workflow (check allowances with read_wallet_allowances, then write_wallet_approve), and explains account_version auto-detection override pattern.

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?

Adds critical lifecycle context beyond annotations: 30-second time sensitivity for calldata, mandatory retry logic ('retry at least once'), and simulation details (tenderly_sim_url). Annotations cover safety (destructive=false, idempotent=true) but description adds execution constraints and validation workflow. No contradictions 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?

Well-structured 4-sentence flow: (1) action definition, (2) alternative comparison, (3) time/retry constraints, (4) response utilities. Each sentence carries distinct semantic weight. Could be slightly tighter but avoids redundancy with schema.

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

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

Comprehensive for complex DeFi operation. Acknowledges output schema existence by documenting specific response fields (tenderly_sim_url/status). Covers full transaction lifecycle: building, signing urgency, failure handling, and pre-broadcast validation. Complete despite complex domain.

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%, establishing strong baseline. Description implicitly reinforces the 'adjustment' parameter's partial nature through 'PARTIALLY decreases' and references to remaining liquidity, though doesn't explicitly document parameter syntax beyond schema definitions.

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?

Excellent specificity: 'Flash-action: PARTIALLY decreases liquidity from an LP position' provides exact verb, resource, and scope. Critically distinguishes from sibling write_account_close by contrasting partial reduction (position remains open) vs full exit, ensuring correct tool selection.

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

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

Explicit when/when-not guidance: clearly states 'For FULL position exit... use write_account_close instead' and explains that tool batches multiple operations. Also clarifies token custody behavior ('underlying tokens stay in the account'), guiding users on state outcomes.

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 establish write/idempotent status. Description adds critical ERC20 allowance requirement (authorization context) and clarifies the wallet-token vs account-collateral distinction. Could further clarify success confirmation or gas implications.

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

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

Four sentences with zero waste: 1) Core action + requirement, 2) Alternative path, 3) Pre-call approval workflow, 4) Data verification. Front-loaded with action, well-structured for agent parsing.

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?

Comprehensive for a financial transaction tool with output schema. Covers prerequisites (allowance/approval), sibling alternatives, prerequisite data checks, and payment source distinction. Annotations cover safety profile.

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 has 100% coverage (baseline 3). Description adds semantic context by noting the ERC20 allowance requirement for pool_address and explaining the repayment mechanism. References the special 'max_uint256' value already documented in 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?

Specific verb 'Repay' with resource 'debt' and scope 'using tokens from the wallet'. Explicitly distinguishes from sibling 'write_account_deleverage' by clarifying this uses wallet tokens rather than 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?

Explicitly names alternative tool 'write_account_deleverage' for collateral-based repayment. Provides complete workflow: check allowance with 'read_wallet_allowances', approve with 'write_wallet_approve', and verify debt with 'read_account_info' before calling.

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?

Discloses unsigned nature (state-safe preparation), explains the array concatenation behavior, and describes exact return structure { transaction: { to, data, value, chainId } }. Expands on annotations which only cover 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?

Every sentence earns its place: purpose first, then workflow instruction with explicit concatenation logic, concrete sibling tool example, and return value documentation. No redundancy despite 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?

Fully complete for a transaction builder with good annotations and output schema. Explains input provenance, combination logic, and return format. No gaps for its complexity level.

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

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

With 100% schema coverage, baseline is 3. Description adds crucial semantic context that these arrays originate from 'write_asset_manager.* intent tools' and must be concatenated for combining automations, which pure schema descriptions cannot convey.

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

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

States specific action ('Build an unsigned setAssetManagers transaction') and clearly distinguishes from sibling 'write_asset_manager.*' intent tools by describing its role as the bundler/combiner of their outputs.

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

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

Provides explicit when-to-use guidance ('To combine multiple automations in one tx') and concrete workflow example ('to enable rebalancer + merkl_operator, call both intent tools, merge their arrays'). Names specific sibling tools as prerequisites.

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?

Adds substantial operational context beyond annotations: 30-second time-sensitivity for calldata, retry logic for price reverts, and Tenderly simulation unavailability. Annotations cover idempotency/safety, description covers execution constraints.

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

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

Six dense sentences, zero waste. Front-loaded with core definition, followed by parameter semantics, operational constraints, and prerequisites. Logical flow from what→how→when→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?

Excellent coverage for a complex DeFi operation: addresses time-sensitivity, failure modes, retries, and prerequisites. Acknowledges returned calldata (output schema exists). Could optionally mention gas implications but not required.

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?

Despite 100% schema coverage, adds crucial semantic meaning: `action` maps to three distinct operations, and `asset_address` requires different values (staked vs non-staked PM) depending on action context.

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

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

Specific verbs (stake, unstake, claim) and resource (LP position) clearly stated. 'Flash-action' and 'atomic transaction' scope distinguishes this from multi-step liquidity operations like write_account_add_liquidity.

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 guides parameter selection ('Use the `action` parameter'). Critical logic for `asset_address` differentiates staking vs unstaking by address type. Names specific sibling read_account_info for pre-verification when Tenderly simulation unavailable.

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?

Adds critical behavioral context absent from annotations: the 30-second time sensitivity for calldata, transaction revert behavior due to price movement requiring rebuilds, and mandatory pre-broadcast validation via tenderly_sim_status ('if tenderly_sim_status is 'false', do NOT broadcast'). Also notes backend route optimization.

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?

Information-dense structure is properly front-loaded with the core purpose, followed immediately by alternative guidance, then critical operational constraints (30-second window, retry logic, Tenderly validation). Every sentence delivers specific actionable instruction 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?

Comprehensive coverage of a complex DeFi operation includes failure modes (price movement reverts), time-sensitive safety constraints, validation workflows (tenderly_sim_url), and explicit sibling differentiation. Appropriately focuses on operational instructions rather than return values since output schema exists.

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 all parameters fully self-documented (e.g., 'Token address to swap to', 'Basis points, 100 = 1%'). The description provides operation-level context ('Flash-action', 'atomic transaction') but does not augment individual parameter semantics beyond what the schema already provides, which is appropriate for complete schema coverage.

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

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

The description uses a specific verb ('swaps') with clear resource ('assets') and scope ('within an Arcadia account in one atomic transaction'). It explicitly distinguishes from the sibling tool 'write_account_close' by clarifying this is for 'standalone swaps within an active position' versus closing 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?

Explicitly states when to prefer the alternative: 'If you are closing a position (swap + repay + withdraw), prefer write_account_close'. Restricts usage to 'standalone swaps within an active position' and provides specific retry logic: 'retry at least once before giving up'.

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 handle safety profile (destructiveHint: false, idempotentHint: true). Description adds critical behavioral context: transactions are unsigned (requires separate execution), revert conditions for undercollateralization, and auto-detection logic. No contradictions 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?

Four dense sentences covering purpose, auth, failure modes, input constraints, and version handling. Zero redundancy. Front-loaded with the core action, followed by constraints and prerequisites. 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?

With 100% schema coverage, good annotations, and an output schema, the description covers the essential non-obvious aspects: revert conditions, exact amount requirements, and unsigned nature. Could minimally benefit from noting the typical next step (dev_send) but completeness is high given structured fields.

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 has 100% coverage with clear descriptions. Description adds crucial semantics not in schema: asset_amounts must be exact values from read_account_info (no max_uint256 support), and account_version overrides auto-detection. Explains the 'why' for parameter usage.

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

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

Description clearly states the specific action: 'Build an unsigned transaction to withdraw assets from an Arcadia account.' The verb 'withdraw' and context 'to the owner's wallet' sharply distinguish this from sibling write_account_deposit or write_account_borrow 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?

Excellent guidance including: auth constraint ('Only the account owner can withdraw'), failure mode ('Will revert if... undercollateralized'), and explicit prerequisite ('pass exact amounts from read_account_info') naming the exact sibling tool to call first.

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

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

Annotations indicate readOnly/idempotent/non-destructive behavior; the description adds critical context that this encodes arguments rather than executing on-chain, explains the economic mechanism (claims LP fees and reinvests for compound interest), and documents return value structure with downstream routing instructions (pass to write_account_set_asset_managers).

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?

Six information-dense sentences are front-loaded with core purpose. Each sentence earns its place: mechanism, sibling distinction, rebalance pairing, return values, and composability. Slightly lengthy but justified by complex integration requirements; zero 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 output schema exists and annotations cover safety properties, the description is remarkably complete. It explains the full lifecycle (encoding → passing to write_account_set_asset_managers), sibling relationships, economic effects, and composability patterns—sufficient for correct agent orchestration.

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%, establishing a baseline of 3. The description implies the parameters configure the 'standalone compounder automation' but does not elaborate on individual parameter semantics (e.g., explaining specific DEX protocol options or chain_id implications) beyond the schema definitions.

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 explicitly states the tool 'Encode[s] args for the standalone compounder automation' with a specific verb and resource. It clearly distinguishes this from sibling write_asset_manager_compounder_staked by specifying 'LP fees only' and contrasting with staked positions, and references write_asset_manager_rebalancer to explain pairing behavior.

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

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

Provides explicit when-to-use guidance by naming the sibling alternative 'use write_asset_manager_compounder_staked for staked positions earning emission tokens.' Also explains integration patterns: 'When paired with a rebalancer...' and 'Combinable with other intent tools,' enabling correct orchestration.

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

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

Annotations declare readOnlyHint=true; description aligns by stating 'Encode args' (no execution). Adds crucial behavioral context beyond annotations: explains MEV-protection via CowSwap batch auctions, details the full claim-swap-compound workflow, discloses that it returns 2 entries (cowswapper + compounder), and notes metadata is set on both managers. No contradictions.

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?

Nine information-dense sentences with zero tautology. Front-loaded with purpose, followed by workflow mechanics, parameter guidance, return structure, and constraints. Slightly verbose but every sentence earns its place—none can be removed without losing specific operational guidance (e.g., 'Base only', 'MEV-protected').

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?

Exceptionally complete for a complex multi-protocol tool (CowSwap + Compounder + DEX protocols). Describes output structure despite presence of output schema, covers chain constraints (Base), explains the dual-manager metadata setting, and clarifies the staked position mechanics. Adequately prepares agent for successful 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?

With 100% schema coverage, description adds substantial semantic value: clarifies sell_tokens are 'reward token addresses (e.g. [AERO_address])' and buy_token 'should be a major token in the pair (USDC, WETH, cbBTC).' These examples and semantic constraints (reward vs major pair tokens) are absent from the schema, providing critical guidance for correct parameterization.

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

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

Description uses specific verb 'Encode args' for compounder coupled with CowSwap, explicitly targets 'staked LP positions' and distinguishes from regular LP positions by noting these earn 'staking emission rewards... not LP fees.' Clearly differentiates from siblings write_asset_manager_compounder and write_asset_manager_cow_swapper by stating it handles BOTH in a single call.

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

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

Provides clear context constraints: 'Base only' and 'Combinable with other intent tools.' Explains specific use case (staked positions earning emissions like AERO/OP) and workflow. Could explicitly namedrop alternatives (e.g., 'use instead of separate calls to compounder and cow_swapper'), but the 'single call' benefit and staked-specific context provide clear implicit guidance.

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

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

Annotations declare readOnlyHint=true; description adds crucial behavioral context including MEV-protection detail, signature requirements, return payload structure, and composability with other intents. No contradiction with annotations despite the 'write_' prefix in the tool name.

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?

Six dense sentences each earning their place: encoding purpose, swap capability, sibling differentiation+signature constraint, network limit, return structure+next step, and composability. Front-loaded with the encoding verb and logically sequenced.

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?

Complete for an encoding orchestration tool: explains the CoW Protocol mechanism, return structure with proper nesting mentioned, integration point with write_account_set_asset_managers clarified, and distinguishes from 2 sibling tools. Appropriate given output schema exists and annotations cover safety profile.

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 descriptions for both parameters (enabled, chain_id). Description adds network constraint context ('Only available on Base') but does not need to compensate for schema gaps. Baseline 3 appropriate for high schema coverage.

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

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

Excellent specificity with 'Encode args for standalone direct CowSwap mode' as the core verb+resource. Explicitly distinguishes from siblings by contrasting with 'compounder_staked' and 'yield_claimer_cowswap', clarifying this is standalone versus coupled automation.

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

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

Provides explicit when-to-use guidance through sibling comparison (standalone vs coupled), critical prerequisites (additional signature required), network constraint (Base only), and clear integration instructions (pass return values to write_account_set_asset_managers). Also notes composability.

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?

Strong contextual disclosure beyond annotations: explains the specific return payload structure ({ asset_managers, statuses, datas }), the mandatory chaining pattern ('pass to write_account_set_asset_managers'), and the synergistic behavior with sibling tools. Annotations cover safety (readOnly/idempotent), so description appropriately focuses on integration flow and reward mechanics rather than repeating safety flags.

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

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

Well-structured with zero filler. Front-loaded with action ('Encode args'), follows with purpose, conditions ('Enable when...'), integration rules ('Always combine...'), return value spec, and chain instruction. Each sentence provides distinct actionable information for an agent selecting tools.

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?

Comprehensive for an encoder tool: explains the Merkl campaign context, references the prerequisite read_strategy_list check, documents the specific output fields and their consumer (write_account_set_asset_managers), and addresses sibling relationships. Could be improved by noting error states or chain_id constraints.

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 has 100% description coverage (enabled, chain_id, reward_recipient all self-documented). Description mentions 'Address to receive Merkl rewards' which parallels the schema but adds no additional semantic context (format constraints, validation rules, or examples) beyond the JSON schema definitions.

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?

Excellent specificity: 'Encode args for the Merkl operator automation' identifies the exact verb and mechanism. Distinguishes from other asset_manager tools by naming the specific protocol (Merkl) and explaining its unique value proposition (external token team incentives on top of LP fees).

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?

Outstanding guidance: explicitly states 'Enable when the pool has active Merkl campaigns' with specific check command 'read_strategy_list', mandates 'Always combine with rebalancer when both are relevant', and notes 'Combinable with other intent tools', giving clear positive and negative conditions for 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 declare readOnly/idempotent hints, while the description adds essential context about what the encoded automation actually does when triggered (repositions, claims fees, compounds rewards), the return structure, and mathematical nuances (tick vs price). No mention of idempotency in text, but substantial behavioral disclosure beyond safety flags.

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

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

Dense information architecture with zero filler. Every sentence addresses a distinct concern: purpose, automation behavior, strategy modes, return values, combinatorial patterns, and mathematical clarifications. Length is justified by complexity, though paragraph density is high.

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?

Comprehensive for a complex 10-parameter DeFi tool. Covers output handling (despite output schema existence), workflow integration with write_account_set_asset_managers, mathematical safety warnings (tick ratios), and configuration modes.

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?

Despite 100% schema coverage, adds critical semantic value: explains the 'default' vs 'custom' strategy configuration logic, clarifies asymmetric trigger configurations (with concrete example), and distinguishes tick distance from price percentages—essential for correct parameterization.

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

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

Description opens with specific verb 'Encode args' targeting the 'rebalancer automation' resource. It clearly distinguishes from sibling tools by detailing the specific LP repositioning mechanics (centering on current price, claiming/compounding fees) and naming the specific protocol (Arcadia).

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 the next step in the workflow ('pass to write_account_set_asset_managers to build the unsigned tx'), clarifies combinatorial usage with other intent tools ('merge arrays'), and explains trigger conditions. Lacks explicit 'do not use X instead' sibling comparisons, but the workflow guidance is 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 already mark this as read-only/non-destructive and idempotent. Description adds valuable execution context: clarifies this is argument encoding (not executing claims), describes the periodic nature of the automation舌尖上的中国, and documents the return structure '{ asset_managers, statuses, datas }'. Missing only auth requirements or rate limit notes.

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

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

Four sentences, zero waste. Front-loaded with encoding purpose. Second sentence describes automation behavior. Third gives return format and next-step instruction. Fourth notes combinability. Every clause delivers essential information 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?

Fully complete for an intent-encoding tool. Explains: purpose, behavioral traits (periodic claiming), output schema structure, downstream integration (pass to setter), and compositionality with other intents. Annotations cover safety profile; description covers 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?

Schema has 100% coverage (baseline 3). Description adds meaningful context beyond schema for fee_recipient: clarifies it can be 'wallet, another account, or any address', expanding on the schema's basic 'Address to receive claimed fees'. Also implies dex_protocol resolves asset manager addresses.

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?

Excellent specificity: 'Encode args for the standalone yield claimer automation' provides exact verb (encode), resource (yield claimer automation), and scope (standalone). The phrase 'Periodically claims pending fees/emissions and sends them to a designated recipient' clarifies the automation's behavior, distinguishing it from immediate execution 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?

Strong workflow guidance: explicitly states to 'pass to write_account_set_asset_managers' indicating the required next step. Mentions 'Combinable with other intent tools' suggesting usage patterns. Minor gap: does not explicitly distinguish when to use this versus sibling write_asset_manager_yield_claimer_cowswap.

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?

Discloses return structure '{ asset_managers, statuses, datas } with 2 entries' beyond annotations. Adds context about MEV-protection via CowSwap batch auctions and metadata setting behavior on both managers. Annotations confirm read-only encoding nature (idempotentHint, readOnlyHint), and description aligns by stating 'Encode args' upfront.

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?

Information-dense but well-structured: purpose → mechanism → parameter examples → return values → constraints. Every sentence earns its place. Examples are specific but concise. 'Base only' and 'Combinable' are critical constraints placed appropriately at the end.

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?

Strong coverage of return values, composability, and parameter relationships. However, the 'Base only' restriction contradicts the schema's explicit support for chain_id 130 (Unichain), creating uncertainty about actual chain support. Without this error, would score 5 given annotations and output schema 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?

Schema has 100% coverage (baseline 3). Description adds significant value: concrete examples for sell_tokens configuration (AERO for staked, excluding buy_token for non-staked), and clarifies dex_protocol resolves 'correct asset manager address'. Examples bridge the gap between abstract schema descriptions and actual usage.

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?

Excellent clarity. Opens with 'Encode args for yield claimer coupled with CowSwap' (specific verb+resource), explains the two-step workflow (claim fees then swap), and distinguishes from simpler siblings by noting it configures BOTH CowSwapper and Yield Claimer and returns 2 entries.

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 concrete when-to-use guidance for staked vs non-staked LPs with specific address examples (e.g., '[AERO_address]' vs excluding buy_token). Explains composability ('Combinable with other intent tools'). Minor deduction: 'Base only' contradicts schema which allows chain_id 130 (Unichain).

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 indicate idempotentHint=true (safe to repeat) and readOnlyHint=false (mutation). Description adds critical behavioral context beyond annotations: clarifies this 'Builds an unsigned' transaction (does not broadcast/submit it), specifies exact contract methods invoked (approve vs setApprovalForAll), and notes the 'from wallet' context distinguishing from internal account operations.

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

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

Four sentences with zero waste: (1) Core purpose, (2) Token-type specifics, (3) Hard prerequisites, (4) Optimization tip. Front-loaded with 'Build an unsigned approval transaction'. No redundancy with schema or annotations. Excellent information density.

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?

Comprehensive for a transaction-building tool with complex multi-standard token logic. Since output schema exists, return values need not be described. Covers ERC20/ERC721/ERC1155 variants, identifies specific sibling dependencies, and includes gas-optimization guidance. Appropriately complete given rich schema and annotations.

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 has 100% coverage (baseline 3). Description adds semantic value by clarifying asset_type behavior (ERC20 vs NFT handling), implying amount usage patterns ('max_uint256'), and contextualizing spender_address ('use the Arcadia account address for deposits'), adding real-world usage guidance beyond raw schema definitions.

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

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

States specific action 'Build an unsigned approval transaction' and distinguishes token behaviors: 'generates approve(spender, amount)' for ERC20 vs 'setApprovalForAll(operator, true)' for NFTs. Clearly identifies this as a transaction builder for wallet-level approvals, distinguishing from account-level write operations like write_account_deposit.

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

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

Explicitly names prerequisite dependencies: 'Required before write_account_deposit or write_account_add_liquidity'. Provides clear when-not guidance: 'skip this if the current allowance is sufficient'. Names specific alternative tool read_wallet_allowances for checking existing state, creating a complete usage workflow.

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