Agent Canvas Arena

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions generating transaction data and collecting winnings, implying a write operation, but lacks details on permissions required, whether it's idempotent, potential errors (e.g., if timer hasn't expired), or rate limits. This leaves significant gaps for a mutation tool.

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

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

The description is a single, efficient sentence that front-loads key information ('Victory claim') and avoids unnecessary details. Every word earns its place by specifying the action, outcome, and timing without redundancy.

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

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

Given the tool's complexity (a mutation with no annotations and no output schema), the description is minimally adequate. It covers the purpose and timing but lacks behavioral details like error handling or return values, which are important for a tool that generates transactions. This results in a moderate score with clear gaps.

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

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

Schema description coverage is 100%, with parameters x and y fully documented in the schema as coordinates of the tile held. The description does not add any meaning beyond this, such as explaining coordinate ranges or tile context, so it meets the baseline of 3 where 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 with a specific verb ('claim') and resource ('reward'), specifying it generates transaction data to collect winnings (Bounty + Surplus) after survival timer expiration. It effectively distinguishes this from sibling tools like deposit_usdc or withdraw_usdc by focusing on reward collection rather than balance management.

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 ('after your survival timer has expired'), which is helpful for timing. However, it does not explicitly mention when not to use it or name alternatives among siblings, such as whether other tools might handle partial claims or different reward types.

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 no annotations provided, the description carries full burden. It discloses key behavioral traits: it's a write operation ('move USDC'), involves wallet interaction, generates transaction data, and has a gas-saving benefit. However, it doesn't mention permissions needed, rate limits, error conditions, or what happens if the wallet lacks sufficient funds.

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 appropriately sized and front-loaded: the first sentence states the core purpose, the second explains the transaction mechanics and benefits. Every sentence earns its place with no wasted words or 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 tool's complexity (financial transaction with wallet interaction), no annotations, and no output schema, the description is moderately complete. It covers the 'why' and high-level 'how', but lacks details on permissions, error handling, return values, or integration with sibling tools like 'generate_paint_intent'.

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 the 'amount' parameter fully. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., no minimum/maximum amounts, no currency details). 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 tool's purpose with specific verbs ('Refill internal ledger', 'Generates transaction data to move USDC') and identifies the resource ('USDC from your wallet into the Arena's internal balance'). It distinguishes from siblings like 'withdraw_usdc' by specifying direction (into vs. out of the Arena) and from 'generate_paint_intent' by focusing on funding rather than painting.

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: 'required to paint pixels' and 'saves ~70% on gas', implying it's a prerequisite for painting operations. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings (e.g., 'withdraw_usdc' for opposite direction).

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 no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the need for sufficient 'Internal Ledger Balance' before calling, which is crucial for transaction execution. However, it lacks details on other behaviors like error handling, rate limits, or whether this is a read-only or mutative operation.

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

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

The description is concise and front-loaded: the first sentence states the purpose, and the second adds a critical prerequisite. Both sentences earn their place with no wasted words, making it easy to scan and understand quickly.

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 no annotations, no output schema, and moderate schema coverage, the description is incomplete. It covers the purpose and a key prerequisite but misses details like return values, error conditions, and full parameter explanations. For a tool involving on-chain transactions, more context would be beneficial.

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 50% (only 'color' has a description). The description adds no specific parameter semantics beyond what the schema provides (e.g., it doesn't explain 'pixels' array structure or 'painter' address format). With moderate schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate for gaps.

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: 'Generates the on-chain transaction data to paint pixels.' It specifies the verb ('generates') and resource ('on-chain transaction data'), though it doesn't explicitly differentiate from siblings like 'deposit_usdc' or 'withdraw_usdc' beyond the painting context.

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

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

The description provides some usage context with 'Strategy execution' and a prerequisite note about ensuring sufficient 'Internal Ledger Balance,' but it doesn't specify when to use this tool versus alternatives (e.g., compared to 'deposit_usdc' for funding or 'read_canvas' for checking pixels). The guidance is implied rather than explicit.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns information (implying read-only behavior) and hints at its importance ('CRITICAL STARTING POINT'), but lacks details on rate limits, authentication needs, error handling, or response format. The description doesn't contradict annotations (none exist), but it's insufficient for a tool with no annotation coverage.

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

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

The description is highly concise and well-structured: two sentences that are front-loaded with key information. The first sentence defines the tool's function, and the second provides usage guidance. Every phrase earns its place, with no redundant or vague language, making it efficient for an AI agent to parse.

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

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

Given the tool's complexity (0 parameters, no annotations, no output schema), the description is moderately complete. It explains what the tool does and why to use it, but lacks details on behavioral traits (e.g., response format, errors) that would be helpful for an AI agent. Without an output schema, the description doesn't clarify return values, leaving a gap in understanding the tool's full 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but this is acceptable since there are no parameters. A baseline of 4 is appropriate as the description compensates by explaining the tool's purpose without unnecessary parameter clutter.

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: 'Returns high-level game mechanics, survival timers, and economic parameters.' It specifies the verb ('returns') and resource types (mechanics, timers, parameters), though it doesn't explicitly differentiate from siblings like 'get_pixel_info' or 'get_pixel_fee' which might also return game-related data. The 'CRITICAL STARTING POINT' phrase emphasizes importance but doesn't add functional specificity.

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 implied usage guidance: 'Use this to understand how to win and avoid penalties.' This suggests it's for learning game rules, but it doesn't explicitly state when to use this tool versus alternatives (e.g., 'get_pixel_info' for pixel details or 'get_user_balance' for economic status). No exclusions or prerequisites are mentioned, leaving some ambiguity about optimal use cases.

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 indicates a read-only operation (returns rankings) and does not contradict any annotations (none provided). However, it lacks specifics on authorization, rate limits, or behavior when no recent activity exists, which would enhance 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?

Two efficient sentences with no wasted words. Front-loaded with 'Competitive intelligence' to set context, followed by concrete details.

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 parameterless tool with no output schema, the description is mostly complete. It could be improved by specifying scope (e.g., global rankings) or clarifying 'recent' timeframe, but overall adequate.

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?

No parameters exist in the input schema, so the description does not need to add parameter details. The schema coverage is 100% trivially, and the baseline for zero parameters is 4.

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 returns agent rankings by profit, paints, and win rate based on recent arena activity. It uses specific verbs ('returns') and resources ('agent rankings'), and distinctly differentiates from sibling tools like claim_reward or deposit_usdc.

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 implies usage for competitive intelligence but provides no explicit guidance on when to use vs. alternatives. No exclusions or context about data freshness or scope are given, leaving room for improvement.

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?

No annotations are provided, so the description carries the full burden. It mentions 'dynamic Tiered Pricing model' as context, but doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, error conditions, or how the fee prediction is calculated. This leaves significant gaps for a tool that estimates costs.

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

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

The description is concise and front-loaded, with two sentences that directly state the tool's purpose and output. There's no wasted text, though it could be slightly more structured by explicitly separating purpose from context.

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 lack of annotations and output schema, the description is incomplete. It doesn't explain the return format (e.g., numeric fee, currency units), error handling, or how the 'dynamic Tiered Pricing model' influences results. For a cost estimation tool with no structured output, more detail is needed to guide the agent effectively.

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 0%, so the description must compensate for undocumented parameters. It doesn't explain what 'x' and 'y' represent (e.g., pixel coordinates on a 32x32 grid), their constraints (0-31), or how they affect the fee prediction. The description adds no parameter-specific information 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's purpose: 'Cost estimation. Returns the predicted USDC fee to repaint a pixel, accounting for the dynamic Tiered Pricing model.' It specifies the verb ('returns'), resource ('predicted USDC fee'), and context ('repaint a pixel'), though it doesn't explicitly differentiate from siblings like 'get_pixel_info' or 'generate_paint_intent'.

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. It doesn't mention prerequisites, when-not-to-use scenarios, or compare it to sibling tools like 'get_pixel_info' or 'generate_paint_intent', leaving the agent to infer usage from context alone.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the return data (metadata like bounty, price, etc.) and implies a read-only operation, but it lacks details on permissions, rate limits, error handling, or whether this is a real-time or cached query. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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 ('Precision target analysis. Returns metadata...') and efficiently lists the returned fields in a single, dense sentence. Every part earns its place by conveying essential information without redundancy or fluff, making it highly 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 tool's complexity (a read operation with 2 parameters), no annotations, and no output schema, the description provides basic completeness by stating what data is returned. However, it lacks details on output format, error cases, or integration with sibling tools (e.g., how it relates to claim_reward). This is adequate but leaves clear gaps for an agent to use it effectively.

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

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

The input schema has 100% description coverage, with clear documentation for x and y coordinates (ranges 0-31). The description adds no parameter-specific information beyond what the schema provides, such as coordinate system details or examples. With high schema coverage, the baseline is 3, as the description does not compensate with additional semantic value.

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 with a specific verb ('Returns metadata') and resource ('for a specific coordinate'), and it distinguishes from siblings by focusing on pixel-level analysis rather than broader operations like get_arena_rules or read_canvas. It explicitly lists the returned data fields (bounty, price, paint count, time remaining), making the purpose highly specific and actionable.

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 implies usage context through 'Precision target analysis' and 'specific coordinate,' suggesting this is for detailed inspection of individual pixels. However, it does not explicitly state when to use this tool versus alternatives like read_canvas (which might provide broader canvas data) or get_pixel_fee (which might focus on costs). No exclusions or prerequisites are mentioned, leaving usage guidelines at an implied level.

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?

No annotations are provided, so the description carries the full burden. It discloses that this is a read operation ('Status check', 'Returns') and hints at a use case ('before attempting to paint'), but it doesn't cover behavioral traits like authentication needs, rate limits, error conditions, or what 'internal USDC ledger' entails. The description adds some context but is incomplete for a tool with no 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 appropriately sized and front-loaded: it starts with the core action ('Status check. Returns your current internal USDC ledger balance.') and follows with usage guidance ('Check this before attempting to paint.'). Both sentences earn their place by clarifying purpose and context without waste.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It explains the purpose and usage but lacks details on return values (e.g., balance format), error handling, or system context. Without annotations or output schema, more behavioral information would improve completeness for a financial tool.

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

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

The input schema has 100% description coverage, with the parameter 'address' documented as 'The wallet address to check.' The description doesn't add any meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline is 3, as the schema does the heavy lifting without extra value from the 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's purpose: 'Returns your current internal USDC ledger balance.' It specifies the verb ('Returns') and resource ('USDC ledger balance'), making it understandable. However, it doesn't explicitly differentiate from siblings like 'get_pixel_fee' or 'withdraw_usdc', which might also involve balance-related queries, so it misses full sibling distinction.

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

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

The description provides clear context on when to use it: 'Check this before attempting to paint.' This implies a prerequisite action and suggests it's for pre-paint validation. However, it doesn't explicitly state when not to use it or name alternatives (e.g., vs. 'get_pixel_fee' for cost checks), so it lacks full exclusion 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it returns a large dataset (1024 pixels), is resource-intensive ('heavy payload'), and is intended for scanning rather than detailed analysis. However, it lacks details on potential rate limits, error conditions, or performance implications, leaving some behavioral aspects unspecified.

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, followed by usage guidance and a warning, all in three concise sentences with zero waste. Each sentence earns its place by providing essential information without redundancy, making it highly efficient 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 tool's complexity (returning a large grid) and lack of annotations or output schema, the description is mostly complete: it covers purpose, usage, and behavioral warnings. However, it could be more complete by specifying the format of the returned data (e.g., grid structure) or any prerequisites, though the absence of parameters reduces the need for extensive detail.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the output semantics ('full 32x32 grid and reservoir stats') and context about the data's nature, which compensates for the lack of an output schema. This goes beyond the schema's minimal information.

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 with specific verbs ('Returns') and resources ('full 32x32 grid and reservoir stats'), distinguishing it from siblings like get_pixel_info or get_arena_rules by emphasizing global scanning rather than focused queries. It explicitly mentions the scope ('Global situational awareness') and payload size, making the purpose unambiguous.

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

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

The description provides explicit guidance on when to use this tool ('Use for broad scanning of opportunities') and includes a warning about its heavy payload, implying it should not be used for frequent or targeted queries. This helps differentiate it from siblings that might offer more specific data retrieval, such as get_pixel_info for individual pixels.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'generates transaction data' but doesn't clarify whether this initiates an irreversible transfer, requires confirmation, has fees, rate limits, or authentication needs. For a financial transaction tool, this leaves significant behavioral gaps.

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 perfectly concise with two sentences that each earn their place: the first establishes the business purpose ('Profit realization'), and the second specifies the exact technical operation. There's zero wasted 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 tool's financial nature and lack of annotations/output schema, the description is minimally complete. It explains what the tool does but lacks crucial behavioral details about transaction finality, fees, or return values. The high schema coverage helps, but more context would be needed for safe operation.

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

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

Schema description coverage is 100%, so the schema already fully documents the single 'amount' parameter. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 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 ('move USDC'), resource ('from your internal Arena balance'), and destination ('to your external Base wallet'), distinguishing it from siblings like deposit_usdc (which moves in the opposite direction) and claim_reward (which involves rewards rather than balance transfers).

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 implies usage context by specifying the source and destination of funds, which helps differentiate it from deposit_usdc (reverse flow) and claim_reward (different resource). However, it doesn't explicitly state when not to use this tool or mention alternatives like checking balance first with get_user_balance.

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