Arcadia Finance

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

Annotations already indicate destructive and non-read-only. Description adds that signing uses a local private key from an environment variable and submits onchain. This goes beyond annotations but could mention gas or failure 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?

Two sentences with a front-loaded 'DEV ONLY' marker. Every sentence adds value; no fluff.

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

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

Given schema coverage and annotations, description is nearly complete. Could mention what the output is (e.g., transaction hash), but not essential.

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 covers all 4 parameters with descriptions. The description adds context that these parameters come from write.* tools, but schema already explains each field adequately.

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

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

Clearly states it signs and broadcasts unsigned transactions using a local private key for dev only, and distinguishes from production wallet MCP servers. The action ('send') and resource ('transaction') are specific.

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

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

Explicitly says 'DEV ONLY' and directs production use to dedicated wallet servers. Also explains it takes transaction objects from write.* tools, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by specifying that values are in human-readable USD and that the result is a time series, which is not in the annotations. 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?

The description is concise with two sentences, front-loading the purpose and immediately describing the output. No redundant 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?

Given that an output schema exists (though not shown), the description does not need to explain return values in depth but still provides useful context about human-readable USD. It could mention pagination or limits, but for a read tool with good annotations and schema, it is mostly complete.

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%, meaning each parameter already has a clear description in the schema. The tool description does not add additional semantic meaning beyond what is in the schema, so baseline 3 is appropriate.

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

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

The description clearly states it retrieves historical collateral and debt values for an Arcadia account over time, returning a time series of snapshots. It differentiates from sibling tools like read_account_info (current values) and read_account_pnl (profit/loss) by specifying the temporal aspect and the specific data fields.

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 mentions the tool is 'useful for charting account performance over a period', which implies when to use it. However, it does not explicitly state when not to use it or mention alternatives like read_account_info for current data, leaving some ambiguity.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description goes far beyond by disclosing the health factor calculation, the automation detection spanning all versions, the mapping of internal keys to user-facing names, and the exact units for numeric fields. 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?

The description is detailed but well-structured: it starts with the main purpose, then explains health factor, automation detection, unit conventions, and finally references a sibling tool. Every sentence serves a purpose, though it is relatively long. Slightly more conciseness could be achieved, but it remains focused and 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?

Given the complexity of the tool (health factor, multi-chain automation detection, multiple field units), the description covers all necessary context. It explains edge cases (older versions still reported), mapping conventions, unit transformations, and even references write tools. The output schema exists but is not shown; nevertheless, the description standalone is sufficient for correct agent invocation.

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

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

Schema coverage is 100%, providing clear descriptions for chain_id and account_address. The description adds value by explaining chain-specific protocol support (e.g., Slipstream V2 is Base-only) and the meaning of chain IDs, which enriches the parameter semantics beyond the schema alone.

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

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

The description opens with 'Get full overview of an Arcadia account' and enumerates the specific data points (health factor, collateral value, debt, etc.), making the tool's purpose crystal clear. It also explicitly distinguishes from the sibling tool read_wallet_accounts by directing users to that tool for listing all accounts, ensuring no ambiguity.

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

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

The description provides explicit guidance: use this tool for a single account overview, and for listing all accounts use read_wallet_accounts. It also explains the health factor formula and the automation detection behavior, which informs the agent about the returned data's semantics and limitations, helping it decide when to call this tool.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds value by explaining return field semantics (e.g., negative cost_basis means net profit withdrawn, per-token fields are in raw units), providing helpful behavioral context beyond annotations.

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

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

The description is a single, coherent paragraph of four sentences, efficiently conveying purpose and return details. It is front-loaded with the primary action and avoids unnecessary words, though minor restructuring could improve scanability.

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 annotations and an output schema present, the description is largely complete: it explains return fields, units, and key concepts. However, it could be clearer about whether the data covers all-time or a specific date range, and whether it applies to any account or just the caller's.

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

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

Schema coverage is 100%, with descriptions for both chain_id (including default and enum values) and account_address. The description does not add additional parameter-level details beyond what the schema provides, so it meets the baseline without exceeding.

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

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

The description clearly states the tool 'Get PnL (cost basis) and yield earned for an Arcadia account,' specifying a unique verb-resource combination. It details what is returned (lifetime totals, cost basis vs current value, per-token fields), distinguishing it from sibling read tools like read_account_history or read_account_info.

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 no explicit guidance on when to use this tool versus alternatives (e.g., read_account_info for general account details or write tools). It only describes the output, leaving the agent to infer appropriate use from context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. Description adds valuable operational details: returns compact list with specific fields, supports search filtering. Does not mention rate limits or auth, but annotations cover safety profile adequately.

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

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

Two sentences plus cross-reference. No wasted words. Front-loaded with purpose and return format. Highly efficient.

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 adequately explains return shape ('compact list of address, symbol, decimals, type') and filtering. No gaps for a read-only list tool with good annotations and schema.

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

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

Schema coverage is 100% with each parameter described (search: case-insensitive substring match; chain_id: default and possible values). Description repeats 'search by symbol substring' but adds no new meaning beyond schema. Baseline 3 is appropriate as schema does the heavy lifting.

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

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

Description clearly states verb 'List' and resource 'supported collateral assets on Arcadia', specifying return fields (address, symbol, decimals, type). It also distinguishes itself from sibling read_asset_prices by directing users to that tool for USD 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 explicit when to use (list assets) and when not ('For USD prices, use read_asset_prices'). Mentions filtering via search parameter. Does not elaborate on alternatives like read_pool_info but context is sufficient given sibling count.

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 already declare read-only, idempotent, and non-destructive behavior. The description adds the return format ('a price map keyed by address'), which provides useful behavioral context beyond the annotations.

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

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

The description is two sentences long, front-loads the purpose, and provides essential usage details without any redundant 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?

Given the low complexity, complete schema coverage, presence of output schema, and annotations covering behavioral traits, the description is fully adequate. It specifies the return format and input format, leaving no gaps.

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

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

The input schema covers both parameters with descriptions, achieving 100% coverage. The description adds extra semantic value by explaining how to pass multiple addresses (comma-separated), which goes beyond the schema's 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 clearly states the tool gets USD prices for asset addresses, specifying the input format and output structure. It distinguishes itself from sibling read tools by focusing specifically on 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?

The description provides clear context for when to use the tool (to get prices) but does not explicitly mention when not to use it or compare with alternatives. However, the single-purpose nature makes it straightforward.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the APY history inclusion, which is useful but not a major behavioral disclosure beyond what annotations imply. 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?

The description is two sentences long, with no unnecessary words. It front-loads the core action and then adds context and a sibling reference efficiently.

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 good annotations, the description is complete enough for a straightforward read operation. It could optionally mention the return structure, but the output schema compensates.

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

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

The schema has 100% coverage on parameter descriptions, so the baseline is 3. The description provides no additional parameter semantics beyond what the schema already offers, e.g., 'Number of days of APY history' for the 'days' parameter is already in the schema.

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

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

The description clearly states 'Get detailed info for a single lending pool including APY history over time,' using a specific verb ('Get') and resource ('lending pool'). It distinguishes itself from siblings like 'read_pool_list' by focusing on a single pool with APY 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?

The description explicitly states when to use ('useful for analyzing rate trends and comparing pools') and provides a clear alternative: 'Use read_pool_list to discover pool addresses.' This helps the agent decide between sibling tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds context about decimal fraction interpretation of rates (0.06 = 6%), which is valuable for agents. 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?

Three sentences, each contributing value: first states core function, second lists key fields, third clarifies rate format and points to alternative. No wasted words, 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?

Given the tool's simplicity (one optional parameter, output schema present), the description covers everything an agent needs: what the tool returns, important field meanings, and rate interpretation. No gaps.

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

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

Schema has 100% coverage for the single parameter (chain_id) with a description of chain IDs. The tool description does not add additional semantic meaning beyond the schema's coverage. Baseline 3 is appropriate.

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

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

Clearly states verb 'List' and resource 'all Arcadia lending pools' with specific fields (TVL, utilization, available liquidity). Distinguishes from sibling read_pool_info which provides APY 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?

Explicitly tells when to use this tool (get pool list with key fields) and when to use an alternative (read_pool_info for APY history). Also provides important note about rate decimal format.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds context about APY values being decimal fractions and the relationship between range width and APY/rebalancing cost/risk, but does not disclose other behaviors beyond annotations.

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

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

Two sentences, front-loaded with the main action, followed by essential notes. Every sentence adds value; no redundancy.

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

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

For a simple read tool with an output schema and thorough annotations, the description is mostly complete. It explains the return format (APY decimals) and how to get IDs. It lacks error handling details, but that is acceptable for this 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 description coverage is 100%, so the schema already documents both parameters (chain_id and strategy_id). The description adds no additional parameter-specific meaning; it only mentions APY format, which is not parameter-related. Baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves full detail for a specific LP strategy by ID, listing included items (APY per range width, pool info, configuration). It distinguishes from sibling read_strategy_list by recommending that tool for discovering IDs.

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 advises using read_strategy_list to discover strategy IDs, indicating when to use this tool. However, it does not explicitly state when not to use it, though the context 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?

With annotations already declaring readOnlyHint, openWorldHint, and idempotentHint, the description adds value by explaining that the tool returns a paginated list with 7d avg APY and that APY values are decimal fractions. 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?

Four concise sentences, each adding essential information without redundancy. Front-loaded with purpose, followed by usage tips, pagination details, and a helpful note on APY format.

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, the description covers the return format (paginated list with 7d avg APY) and explains key behaviors (pagination, decimal fractions). Context about chain_id and other parameters is fully covered in schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context for featured_only ('recommended first call') and pagination, but the schema already describes each parameter adequately, so the description does not significantly enhance parameter understanding.

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

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

The description clearly states 'Get Arcadia LP strategies' and distinguishes from the sibling read_strategy_info by noting the latter provides 'full detail on a specific strategy (APY per range width)'.

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

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

Provides explicit guidance: recommends using featured_only=true as a first call and refers to read_strategy_info for detailed information on a specific strategy. Also explains pagination with limit and 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that APY values are decimal fractions and weekly_earning_difference is in USD, which is useful context beyond the schema. 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?

Three sentences, each efficient and front-loaded: the first states the purpose, the second distinguishes from sibling, the third explains value formats. No redundant or extraneous 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 the input schema fully describes parameters and output schema exists, the description provides necessary context about APY period and value formats, making the tool complete for an agent.

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

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

Input schema has 100% coverage with descriptions for both parameters, so the description adds no new info about parameters. Baseline 3 is appropriate; the schema does the heavy lifting.

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

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

The description clearly states it gets a rebalancing recommendation for an Arcadia account to optimize yield. It explicitly distinguishes from the sibling read_strategy_list by noting the different APY period (1d vs 7d), making the tool's specific role clear.

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 guidance on when to use this tool: it uses 1d APY instead of 7d like read_strategy_list, explaining that recommendations may differ. This directly tells the agent when to choose this over the alternative.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds that it returns a summary of address and name, and points to read_account_info for more detail, which is useful context beyond 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 concise sentences with the primary function first, followed by a helpful next-step reference. No unnecessary words.

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

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

With an output schema present, annotations covering safety and idempotency, and schema fully documenting parameters, the description sufficiently completes the picture by indicating what the summary contains and how to get further 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?

Schema coverage is 100% with descriptions for both parameters. The description adds no additional semantic information about the parameters beyond what the schema 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 clearly states the tool lists all Arcadia accounts for a wallet address and returns a summary. It distinguishes from the sibling read_account_info by noting that tool provides full details.

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

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

The description explicitly tells when to use this tool (to list accounts) and directs to read_account_info for full details, providing clear alternative usage.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no contradictory information and reinforces the safe, non-destructive nature by explaining the purpose.

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

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

Two sentences with no waste. The first sentence states the purpose, and the second provides usage guidance. Front-loaded and efficient.

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

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

Given the presence of annotations and output schema, the description is complete. It explains the tool's function and usage context, requiring no further information.

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

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

Schema coverage is 100%, with each parameter already described. The description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states it checks ERC20 token allowances for a spender address. It uses specific verbs and resources, and distinguishes itself from sibling tools like read_wallet_balances by focusing on allowances.

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 advises using before write_wallet_approve to avoid redundant approvals, and to skip approving if the current allowance is sufficient. This provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context: 'Reads directly from chain via RPC multicall' and notes it returns both raw and formatted balances, which is not covered by annotations.

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

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

The description is three sentences long, front-loading the purpose, followed by a technical note and usage guidance. Every sentence adds value without redundancy.

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

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

The tool has an output schema (not shown but present), annotations covering safety, and the description covers purpose, technical method, and usage context. It is fully complete for a read-only balance-checking tool.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well. The description does not add significant parameter-specific details beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states it gets native ETH and ERC20 token balances for a wallet address, using specific verb 'Get' and resource 'wallet balances'. It distinguishes itself from sibling tools like read_wallet_accounts by specifying it reads directly from chain via RPC multicall.

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 usage context: 'Use before write_account_add_liquidity or write_account_deposit to verify the wallet has sufficient tokens.' This helps the agent decide when to invoke this tool, though no exclusions or alternatives are 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds minimal context beyond 'balance', which is implied. It does not contradict annotations, but also doesn't provide meaningful additional behavioral disclosure.

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

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

The description is a single concise sentence that immediately conveys the tool's purpose with no unnecessary words. It is front-loaded and efficient.

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

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

For a simple read-only tool with one parameter and an output schema, the description is adequate. It doesn't cover error handling (e.g., invalid or missing wallet), but the output schema likely clarifies return format.

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%. The description merely restates the wallet_address parameter's purpose ('specific wallet address') without adding new meaning or format details beyond the schema.

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

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

The description clearly states the action (get), the resource (Arcadia points balance), and the scope (specific wallet address). It distinguishes itself from sibling tools like read_wallet_balances by focusing on 'points' rather than general balances or other metrics.

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 no guidance on when to use this tool versus alternatives such as read_wallet_balances or read_point_leaderboard. It doesn't specify prerequisites or exclusions.

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

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

Adds significant context beyond annotations: time-sensitive calldata (30s), retry guidance, response includes tenderly simulation and expected_value_change, atomicity details. Complements idempotentHint=true with retry advice.

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 serves a purpose: main action, usage hints, behavioral notes, response details. Front-loaded with the core purpose, no redundancy.

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

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

Given the tool's complexity (multi-step, 8 params, output schema), the description covers purpose, prerequisites, capital sources, leverage, slippage, time sensitivity, retry, and response features. References sibling tools for allowances and strategies. Very thorough.

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 detailed parameter descriptions. The main description adds value by explaining relationships (e.g., deposits vs use_account_assets, leverage only for margin accounts), going beyond individual schema entries.

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

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

Clearly states the tool atomically combines deposit, collateral use, swap, LP mint, and borrow in one transaction. Distinguishes from sibling write_account_deposit by explicitly saying not to call it 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 instructions: check allowances first, approve if needed, call read_guides for workflows, retry on revert. Lacks explicit when-NOT-to-use but covers prerequisites and alternatives implicitly.

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=true, destructiveHint=false), the description reveals that the tool builds an unsigned transaction (non-executing), performs validation on account type, and may reject invalid input. It could be more explicit about requiring subsequent signing/submission, but adds significant behavioral context beyond the annotations.

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

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

The description is six sentences long, with the purpose stated first, followed by usage distinctions, account-type restrictions, validation, and a prerequisite. There is no redundant or unnecessary information; every sentence contributes value. It is both concise and well-structured.

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

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

Given the complexity (5 parameters, 4 required, output schema exists), the description covers purpose, when to use, account-type restrictions, validation, and prerequisite. It does not explain the output (but output schema exists) or explicitly state that the unsigned transaction needs signing/submission. Overall, it is mostly complete, with minor room for improvement.

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 detailed parameter descriptions. The tool description adds minimal extra meaning: it specifies the actual pool addresses and clarifies the role of account_address. However, since the schema already handles parameters well, the description's additional value is limited, earning a baseline score of 3.

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

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

The description clearly states the tool builds an unsigned transaction to borrow from an Arcadia lending pool against account collateral. It distinguishes from the sibling write_account_add_liquidity by noting that borrowing is handled internally for leveraged LP, making the purpose specific and well-differentiated.

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

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

The description explicitly states when not to use this tool (leveraged LP should use write_account_add_liquidity), defines account-type restrictions (margin accounts only), explains validation (will reject spot accounts), and provides a prerequisite (verify free margin via read_account_info). This covers when, when-not, and alternatives comprehensively.

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 atomicity, time-sensitivity (calldata expires in 30s), retry advice, and includes tenderly simulation URLs. Annotations indicate write, open-world, idempotent, non-destructive; description aligns and adds critical behavioral context. No contradiction.

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

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

Well-structured with clear sections, front-loaded main purpose, then mode details, then usage notes. No redundant sentences, every part adds value.

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 tool with 6 parameters and atomic behavior, the description covers functionality, usage modes, retry logic, and post-close steps. With annotations and output schema present, it is fully complete.

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

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

Schema coverage is 100% with descriptions, but description adds substantial meaning: explains how to format assets for LP vs ERC20, details close_lp_only modes, and explains receive_assets distribution. Goes beyond 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?

Description clearly states it atomically closes an Arcadia account position in one transaction, combining up to 3 steps. It distinguishes from sibling tools by explicitly recommending this tool first and falling back to individual tools only on failure. Two modes are detailed.

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

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

Explicitly says 'ALWAYS try this tool first when closing/exiting a position' and 'Only fall back to individual tools if this tool fails'. Also provides retry guidance if transaction reverts, and follow-up step with write_account_withdraw.

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

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

Annotations already indicate idempotentHint=true and readOnlyHint=false. The description adds context about deterministic address via CREATE2 and version-dependent behavior (creditor usage). However, it does not explicitly state that it only builds an unsigned transaction (not send), which is a key behavioral trait.

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

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

The description is concise with four sentences. Each sentence adds essential information: main purpose, version distinction, and return value. No superfluous content.

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

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

Given the output schema exists (mentioned but not shown), the description covers the key return value. It explains version differences and parameter behavior. It could mention that the result is an unsigned transaction to be sent via another tool (e.g., dev_send), but overall is sufficiently complete for a transaction-building tool.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds value by explaining the semantic meaning of account_version (0/4 vs 3) and how creditor is ignored for spot accounts. This clarifies parameter usage beyond the schema.

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

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

The description clearly states the tool builds an unsigned transaction to create an Arcadia account via the Factory contract. It explains version-dependent behavior (V3 margin vs V4 spot) and mentions the return of a predicted account address. This distinguishes it from sibling tools that perform other operations.

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 version selection guidance (margin vs spot) and implies this is the account creation tool among many write_account_* tools. However, it does not explicitly state when to use it vs alternatives (e.g., that it is a prerequisite for other account operations) or that the unsigned transaction must be sent via dev_send.

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 behavioral context beyond annotations: notes time-sensitivity (30s), retry logic, atomicity, and response fields for pre-broadcast validation. 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?

Concise and information-dense, though a single paragraph. Each sentence adds value, but could benefit from slight structuring (e.g., bullet points).

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?

Covers usage, alternatives, behavioral nuances, retry instructions, and validation steps. Complete for an agent to use the tool correctly, especially with output schema hinted.

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 does not add additional parameter semantics beyond what's already in the schema.

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

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

The description precisely states the tool's action: selling collateral to repay debt in one atomic transaction, and distinguishes from sibling tools like write_account_repay and 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?

Explicitly states when to use (standalone repayment) and when not to (closing a position, prefer write_account_close), and provides alternative for wallet-based repayment.

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

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

The description adds value beyond annotations by detailing token support and version auto-detection. Annotations indicate idempotentHint true, which aligns with building an unsigned transaction. 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?

The description is concise at four sentences, front-loaded with purpose, and every sentence adds value. No unnecessary words.

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

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

Given the tool's complexity (7 parameters, output schema exists), the description covers purpose, token support, exclusion, prerequisites, and version handling. It is complete for an AI agent to use correctly.

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

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

Schema coverage is 100% with detailed descriptions for each parameter. The description adds context like account approval and version override but does not significantly enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool's purpose: building an unsigned transaction to deposit assets as collateral. It specifies supported token types (ERC20, ERC721) and distinguishes from the sibling write_account_add_liquidity by noting the different use case.

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

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

The description explicitly states when NOT to use this tool (before write_account_add_liquidity) and provides prerequisites: ensure account approval via read_wallet_allowances and write_wallet_approve. It also explains the auto-detection and override of account_version.

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 time-sensitivity, retry advice, and response fields (tenderly_sim_url, tenderly_sim_status). Annotations indicate idempotentHint=true, but description implies calldata may become stale, which is a subtle inconsistency but not a direct contradiction.

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

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

Two short paragraphs with no wasted words. First paragraph immediately states purpose, second covers usage notes.

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 complex tool (Amm liquidity removal), the description explains what it does, when to use it, and important behavioral notes. Parameter descriptions and annotations are present, and 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?

Schema coverage is 100% with descriptions for all 5 parameters. The description adds extra context: adjustment must be less than total liquidity and references write.account.close for full removal.

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

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

The description clearly states the tool's purpose: 'PARTIALLY decreases liquidity from an LP position' with details that the position remains open and tokens stay. It distinguishes from the sibling write_account_close for full exit.

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

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

Explicitly tells when to use this tool (partial removal) and when to use write_account_close (full exit). Also provides retry guidance for time-sensitive transactions.

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

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

Annotations already indicate idempotent and non-destructive mutation. The description adds important context about requiring ERC20 allowance and using wallet tokens, which is beyond what annotations convey. It 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 serving a distinct purpose: main action, alternative, and prerequisites. Front-loaded with the core purpose. No redundant 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?

Given the presence of an output schema (which handles return value documentation), the description adequately covers purpose, workflow, and prerequisites. Minor omission: no mention of potential failure modes or gas costs, but not critical.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions, but also does not omit necessary info.

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

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

The description clearly states the action ('Repay debt'), resource ('Arcadia lending pool'), and method ('using tokens from the wallet with ERC20 allowance'). It also distinguishes from the sibling tool 'write_account_deleverage' by specifying the source of tokens.

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 guidance: when to use this tool (wallet tokens) vs when to use the alternative (collateral), and outlines a preparatory workflow including checking allowances and debt. This is actionable for an AI 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 already declare idempotentHint=true and destructiveHint=false. Description adds that it builds an unsigned transaction (non-destructive, idempotent). No contradiction. It could mention that no state change occurs until the transaction is signed and sent, but that's implicit. Effective overall.

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?

Concise: three sentences covering purpose, usage instructions, and return format. No unnecessary details. Front-loaded with the main purpose. 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 complexity of combining multiple intent tools, the description is complete. It explains the relationships, provides an example, and specifies the return shape. Output schema exists but description still summarizes the return value. Sibling tools are numerous but this tool's role is clear.

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

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

Schema coverage is 100%, so parameters are well-documented. Description adds meaning by explaining that the arrays come from intent tools and must be concatenated for multiple automations. This usage context is valuable 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?

Clearly states it builds an unsigned setAssetManagers transaction from intent args. Distinguishes from sibling intent tools by describing its role as a combiner. Specific verb 'build' and resource 'unsigned setAssetManagers transaction'.

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 says when to use: after obtaining arrays from write_asset_manager.* tools. Provides instructions for combining multiple automations by concatenating arrays. Includes an example (rebalancer + merkl_operator). No explicit 'when not to use', but context 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 description adds critical behavioral traits beyond annotations: 'The returned calldata is time-sensitive — sign and broadcast within 30 seconds,' 'If the transaction reverts due to price movement, rebuild and sign again immediately (retry at least once),' and 'Tenderly simulation may not be available.' These do not contradict annotations (idempotentHint=true supports retry).

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

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

The description is four sentences, front-loaded with the core purpose, and every sentence adds value. It is efficient with no redundant or extraneous content.

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

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

Given the tool's complexity (time-sensitive, retry required, prerequisite verification, and 5 parameters with varying semantics), the description covers all essential aspects: operation details, parameter usage, time constraint, retry logic, and pre-signing checks. The presence of an output schema (not shown) reduces the need to describe 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?

While schema coverage is 100%, the description adds essential semantic guidance: '`asset_address` is the position manager contract — pass the non-staked PM address when staking, or the staked PM address when unstaking.' This clarifies how to use the parameter differently for different actions, going beyond the schema's generic 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 starts with 'Flash-action: stake, unstake, or claim rewards for an LP position in one atomic transaction.' It clearly states the specific actions (stake, unstake, claim) and the resource (LP position), distinguishing it from other write tools by being an atomic flash-action.

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

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

The description explicitly says 'use the `action` parameter to select the operation.' It advises to 'verify the position exists with read_account_info before signing' and notes that Tenderly simulation may not be available. It does not explicitly state when not to use or compare to alternative tools, but the context 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 indicate it is a write operation (readOnlyHint=false) and non-destructive, but the description adds significant behavioral context: flash-action atomicity, backend routing, time-sensitivity (30 seconds), pre-broadcast validation via tenderly, and retry logic. Missing mention of idempotency (annotated as true) but overall strong transparency.

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

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

The description is a single paragraph with clear, front-loaded information. Each sentence adds value, though it could be more structured (e.g., bullet points). Still concise for the amount of guidance given.

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 (mentioned but not shown) and full schema coverage, the description provides all necessary context: use case, sibling comparison, retry behavior, and validation steps. No obvious gaps.

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

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

Schema coverage is 100%, so each parameter has a description in the schema. The description does not add extra meaning beyond what the schema already provides. Baseline score of 3 applies.

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

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

The description clearly states it performs a flash swap of assets within an Arcadia account atomically. It distinguishes from the sibling tool 'write_account_close' by specifying that this tool is for standalone swaps, not 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 use (standalone swaps within active position) and when not to (closing position: prefer write_account_close). Also provides retry guidance if the transaction reverts.

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 and destructiveHint=false. The description adds that the tool builds an unsigned transaction (not sending it) and will revert under specific conditions. This provides behavioral context beyond 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?

The description is four sentences long, front-loaded with the primary purpose, and each subsequent sentence adds meaningful constraint or tip without redundancy. No unnecessary words.

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

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

Given 7 parameters and an output schema, the description covers core purpose, owner restriction, revert condition, max_uint256 limitation, and version handling. It does not explicitly mention that the result needs to be sent via a sibling tool like dev_send, which is a minor gap, but overall sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the account_version auto-detection and urging exact amounts from read_account_info, which reinforces schema descriptions and provides practical guidance.

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

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

The description clearly states the verb 'Build an unsigned transaction' and the resource 'withdraw assets from an Arcadia account to the owner's wallet'. It is distinct from sibling write_account_* tools like deposit or borrow, making its purpose unambiguous.

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

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

The description provides key usage constraints: only account owner can withdraw, reverts if undercollateralized with debt, and advises against max_uint256 (recommending exact amounts from read_account_info). It does not explicitly compare to alternatives but gives sufficient context for correct use.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds context: it returns a data structure to pass to another tool and is combinable with other intent tools. No contradictions, and additional behavioral context is useful but not essential.

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

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

The description is concise (3 sentences), front-loaded with purpose, and every sentence adds value. No redundant or missing 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?

Given the tool has 3 parameters, an output schema (not shown but indicated), and the description explains the return shape and combinability, it is contextually complete for an agent to use correctly.

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

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

Schema coverage is 100% and parameter descriptions are already clear. The description does not add new meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool encodes arguments for the standalone compounder automation, claims LP fees and reinvests them. It uses a specific verb 'encode' and resource 'standalone compounder automation', and distinguishes it from the sibling tool for staked positions.

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

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

Explicit guidelines: 'LP fees only — does NOT claim staking rewards like AERO; use write_asset_manager_compounder_staked for staked positions' and explains interaction with rebalancer. Provides clear when-to-use and when-not-to-use.

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

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

The description describes mutation actions (claims, swaps, compounds) and the tool name starts with 'write_', but the annotations declare readOnlyHint=true. This is a direct contradiction, reducing trust in the tool's 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 is well-structured, starting with the core purpose in the first sentence, then detailing the workflow, inputs, and output. Every sentence adds value without redundancy.

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

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

Given the complexity and presence of output schema and annotations, the description covers the process, input semantics, output format, and chain restriction. It lacks only minor details like explicit error handling or what disabling does, but overall it's sufficient.

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

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

All 5 parameters have schema descriptions (100% coverage), and the description adds relevant context: sell_tokens as reward token addresses, buy_token as major pair token, dex_protocol for LP type. This extra detail justifies a score above baseline 3.

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

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

The description clearly states it encodes args for a compounder with CowSwap for staked LP positions, specifying the full pipeline (claim rewards, swap via CowSwap, compound). It distinguishes itself from sibling tools like write_asset_manager_compounder and write_asset_manager_cow_swapper by combining both and focusing on staked positions.

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

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

The description explains when to use: for staked LP positions earning staking rewards (not LP fees). It also notes 'Base only' and 'Combinable with other intent tools.' It doesn't explicitly list alternatives, but the context and sibling names imply the differentiation.

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, the description discloses that each swap requires an additional signature and is only available on Base. It adds behavioral context beyond annotations, such as the output format and workflow.

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

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

The description is compact (4 sentences), front-loaded with purpose, and every sentence provides 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?

Given the output schema exists, the description covers return structure and integration with write_account_set_asset_managers. It also addresses chain restrictions, signature requirements, and tool combinability.

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 description adds limited new meaning. It mentions chain availability (Base 8453) which aligns with default but doesn't elaborate on 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?

The description states 'Encode args for standalone direct CowSwap mode' with a specific verb and resource, and differentiates from sibling tools by noting it is not coupled to other automation like compounder_staked or yield_claimer_cowswap.

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 explains when to use this tool (standalone CowSwap, requires additional signature, only Base) and what to do with the output ('pass to write_account_set_asset_managers'). It also notes combinability with other intent 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?

The description claims the tool 'claims external Merkl protocol incentive rewards', implying mutation, but the annotations declare readOnlyHint=true, which is a direct contradiction. This seriously undermines transparency.

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

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

The description is concise (four sentences) and front-loaded with the primary purpose. It includes useful combinations and output format without unnecessary verbosity.

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?

It covers the purpose, usage, combination guidance, chain availability, and output structure. It lacks detail on failure behavior or what happens without active campaigns, but overall it is fairly complete given the tool's complexity and existing 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%, so the schema already documents all parameters adequately. The description does not add additional semantic details beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states that the tool encodes args for the Merkl operator automation and claims external Merkl rewards. It distinguishes from many siblings by specifying 'Merkl' and 'additional rewards on top of LP fees', though it doesn't explicitly contrast with other yield claimers like write_asset_manager_yield_claimer.

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

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

It provides explicit when-to-use guidance: enable when the pool has active Merkl campaigns (checkable via read_strategy_list). It also advises combining with rebalancer when both are relevant. However, it does not provide when-not-to-use scenarios or 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 indicate readOnlyHint true (encoding args, not state-changing), idempotent, non-destructive. The description adds significant behavioral context: it claims and compounds fees/rewards, details trigger ratios with examples, explains tick vs price distinction, and notes asymmetric configs. No contradictions; description enriches understanding beyond annotations.

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

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

The description is relatively long with multiple explanatory sentences and an example. While informative, it could be more concise by moving some details to parameter descriptions. The structure is logical (overview, strategy, example, combinability), but verbosity slightly reduces efficiency.

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 10 parameters, 100% schema coverage, and output schema, the description adequately covers purpose, workflow (pass to write_account_set_asset_managers), key behavioral aspects (claiming, compounding, triggers), and combinability. Minor omission: does not detail contents of returned arrays, but 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 detailed parameter descriptions. The tool description adds strategic context: explains how trigger ratios interact, gives concrete example (trigger_lower_ratio=-50000, trigger_upper_ratio=0), and clarifies ratio meaning (tick distance vs price). This goes beyond schema, providing cohesive understanding.

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

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

The description starts with 'Encode args for the rebalancer automation,' clearly specifying the verb (encode args) and resource (rebalancer automation). It distinguishes itself from sibling tools like write_asset_manager_compounder by focusing on rebalancing LP positions when out of range, with specific strategy details and compounding 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?

The description explains when to use: when LP position goes out of range, uses two strategies ('default' vs 'custom') with clear conditions. It mentions combinability and output usage. However, it lacks explicit 'when not to use' or direct comparison with sibling tools, but context and strategy differentiation provide sufficient guidance.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description aligns with these by stating it 'encodes args' and returns data, which is a read-only operation. It adds context about the return schema and the workflow (passing to write_account_set_asset_managers), which goes beyond the annotations.

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

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

The description is extremely concise: two sentences front-loaded with the core purpose. Every sentence provides essential information without unnecessary words.

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

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

For an encoding helper tool, the description sufficiently explains the purpose, return structure, and downstream use. The output schema is not provided but the return fields are mentioned. The description could elaborate slightly on prerequisites or automation setup, but overall it is complete enough given the tool's role.

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

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

The input schema covers all parameters with descriptions (100% coverage). The description does not add significant new meaning beyond the schema; it merely reiterates the role of dex_protocol and fee_recipient. The baseline of 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Encode args for the standalone yield claimer automation. Periodically claims pending fees/emissions and sends them to a designated recipient.' It differentiates from siblings by specifying 'standalone' and mentions the return structure and combination with write_account_set_asset_managers.

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

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

The description gives clear context for when to use (for automating fee claiming) and mentions combinability with other intent tools. However, it does not explicitly exclude cases or name alternatives like the cowswap variant, though the sibling list implies differentiation.

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 include readOnlyHint=true and idempotentHint=true, which align with the tool encoding args (not executing). The description adds value by clarifying metadata setting on both swapper and claimer, and return structure. 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?

The description is structured as a single paragraph but is well-organized: purpose, parameter logic, return format, constraints. It is concise yet comprehensive, though could be slightly tightened.

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

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

Given the complexity (6 params, 4 required, output schema exists), the description covers key parameter logic, return values, and constraints. It lacks error conditions or prerequisites but is sufficient for an AI agent to use correctly.

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

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

Schema description coverage is 100%, so each parameter has a schema description. The tool description adds further meaning, especially for sell_tokens (staked vs. non-staked logic) and buy_token example, enriching the schema.

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

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

The description clearly states the tool's purpose: encode args for yield claimer coupled with CowSwap, involving claiming LP fees and swapping via CowSwap auctions. It distinguishes from siblings like write_asset_manager_yield_claimer (no swap) and write_asset_manager_cow_swapper (no claim) by combining both actions.

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 detailed guidance on token selection for staked vs. non-staked LPs with examples, notes Base-only constraint, and mentions combinability with other intent tools. It does not explicitly state when to use alternatives, but the context 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 indicate this is a non-readOnly, non-destructive operation (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral context: it builds an 'unsigned' transaction (implying it doesn't execute), specifies the financial mechanism (deposit assets for interest-accruing shares), and mentions the prerequisite approval requirement. However, it doesn't detail rate limits, error conditions, or transaction format specifics.

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

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

Three tightly packed sentences with zero waste: first states purpose, second explains mechanism and prerequisite, third provides yield-checking guidance. Every sentence earns its place by adding distinct value (action, context, related 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?

Given the tool's complexity (financial transaction building), rich annotations (readOnlyHint=false, etc.), 100% schema coverage, and existence of an output schema (implied by 'Has output schema: true'), the description is complete enough. It covers purpose, prerequisites, mechanism, and related tools without needing to explain return values or repeat 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?

With 100% schema description coverage, the schema fully documents all 4 parameters. The description adds minimal parameter semantics beyond the schema—it mentions 'underlying asset (USDC/WETH/cbBTC)' which partially relates to 'tranche_address' but doesn't explain parameter relationships or provide additional syntax guidance. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('Build an unsigned deposit transaction'), the target resource ('Arcadia lending tranche (ERC-4626)'), and the mechanism ('deposit the pool's underlying asset... and receive tranche shares'). It distinguishes from siblings like write_pool_redeem (withdraw) and write_wallet_approve (prerequisite).

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 ('Requires prior ERC-20 approval to the tranche') with a named alternative tool ('see write_wallet_approve'), and provides context for checking conditions ('To check current lender yield, call read_pool_list or read_pool_info'). This gives clear prerequisites and related 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 indicate this is not read-only, open-world, idempotent, or destructive, but the description adds valuable context beyond that. It clarifies that the transaction is 'unsigned' (requiring separate signing), specifies it returns underlying assets with accrued interest, and notes the owner-receiver relationship. This enhances understanding of the tool's behavior without contradicting annotations.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by clarifying details. Every sentence adds value: explaining the transaction type, the action (burning shares), the outcome (underlying asset with interest), and constraints (owner and receiver roles). No wasted words.

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

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

Given the complexity of a financial transaction tool with no destructive hint and an output schema, the description is largely complete. It covers the purpose, key behavioral traits, and parameter roles. However, it could better address prerequisites (e.g., needing tranche shares) or error conditions, slightly limiting completeness.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal semantic context beyond the schema, such as noting that shares are burned and the receiver gets underlying assets, but does not provide additional syntax or format details. This meets the baseline 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?

The description clearly states the specific action ('Build an unsigned redeem transaction'), the resource ('Arcadia lending tranche'), and the outcome ('withdraw from an Arcadia lending tranche (ERC-4626)'). It distinguishes this from sibling tools like write_pool_deposit by focusing on redeeming/burning shares rather than depositing.

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

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

The description provides clear context for when to use this tool: to withdraw from a lending tranche by burning shares. It implies usage by specifying the owner must be the shares holder and the receiver gets the underlying asset. However, it does not explicitly state when not to use it or name alternatives (e.g., write_account_withdraw for account-level withdrawals).

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?

Description aligns with idempotentHint (building an unsigned transaction is idempotent) and adds context that it does not execute on-chain, which is not obvious from annotations alone. No contradiction.

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

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

Concise at 4 sentences, front-loaded with main purpose, then specifics, then tip. 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 tool's moderate complexity, annotations cover safety, output schema exists, and the description adds purpose, usage guidance, and behavioral context. No gaps.

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

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

Schema coverage is 100% so baseline is 3. The description adds value by explaining the underlying contract functions (approve vs setApprovalForAll) and how parameters like amount are used, but some parameter details are left to schema.

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

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

The description clearly states the tool builds an unsigned approval transaction, specifies the two behaviors (ERC20 approve vs NFT setApprovalForAll), and distinguishes from sibling tools like write_account_deposit and write_account_add_liquidity by noting it's a prerequisite.

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 (required before deposit/add_liquidity), when to skip (if existing allowance sufficient via read_wallet_allowances), and names the alternative tool to check first.

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