kraken_wallet_transfer

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

No annotations are provided, so the description carries the burden. It discloses the action (initiate a transfer) but does not state side effects (e.g., fees, minimum amounts, whether the transfer is immediate or pending, or that it requires API key permissions). The description is fairly generic and does not add behavioral nuance beyond 'initiate a transfer.' However, it does clarify the wallet-to-wallet context, which is useful.

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 sentence that states the action and provides a concrete example. It is appropriately sized, front-loaded with the verb 'Initiate', and contains no fluff. Every word 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 (4 simple params, all required, with enums limiting from/to), the description covers the essential purpose and an example. It does not explain return values, but an output schema exists, so that's not required. It lacks potential caveats like confirmation or fees, but for a simple internal transfer, the description is sufficiently 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%, so the schema already describes all parameters. The description adds the example 'spot to futures' which clarifies the relationship between from/to enums (Spot Wallet → Futures Wallet). It doesn't add new parameter-level detail beyond schema, but the schema itself is already descriptive. Since schema covers everything, baseline is 3, and the description's example provides a small extra semantic hint, so a 4 is justified.

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 initiates a transfer between Kraken wallets, with an example ('spot to futures') that distinguishes it from other Kraken tools like order placement or withdrawals. However, it doesn't explicitly name sibling alternatives (e.g., kraken_withdraw_funds) for transfers to external addresses, so it's clear but not fully differentiation-focused.

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 the use case: moving funds between internal wallets, which is distinct from withdrawal (external transfer). It doesn't explicitly say 'use this when transferring between spot and futures wallets' or exclude alternatives like kraken_withdraw_funds, but the example serves as a usage hint. No explicit alternatives or exclusions are provided, so it's 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.