azeth_deposit

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

With no annotations provided, the description carries full disclosure burden. It covers critical security behavior ('verifies ON-CHAIN that the target is a real Azeth smart account owned by you'), return values ('Transaction hash and deposit details'), and default fallbacks ('deposits to your first smart account'). Missing only gas/confirmation details.

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

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

Information-dense and front-loaded with the core action first. Structure follows logical progression: purpose → usage → security → parameters → examples. Lengthy but justified by the complexity of ETH vs ERC-20 handling and security requirements; no sentences are wasted.

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 (multi-chain, multi-token, cryptographic ownership verification), the description adequately covers prerequisites, security constraints, and return values despite lacking an output schema. Sibling differentiation is implicit but sufficient for selection.

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

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

Despite 100% schema coverage, the description adds substantial value through conditional logic: 'omit the token parameter' for ETH, 'provide... AND decimals' for ERC-20, and the amount format clarification ('human-readable units'). The concrete JSON examples provide syntax clarity beyond schema descriptions.

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

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

The description opens with a precise action statement: 'Deposit ETH or ERC-20 tokens from your EOA wallet into your own Azeth smart account.' It specifies the exact resource types (ETH/ERC-20), source (EOA), and destination (Azeth smart account), clearly distinguishing it from sibling tools like azeth_transfer (likely inter-account) or azeth_pay (payment 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?

Provides explicit 'Use this when' clause linking to specific downstream operations ('funding for transfers, x402 payments'). Includes clear security exclusions ('You cannot deposit to someone else's smart account'). Does not explicitly name sibling alternatives, though the context sufficiently differentiates it from payment/transfer tools.

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