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

Annotations already declare readOnly/idempotent/non-destructive, and the description is consistent with them while adding substantial context: zero network calls, never sees keys or holds funds, relayer fee and gas paid by the user, the platform takes nothing, and rail status (Axelar GMP, Chainflip, Hashport dead). This is exactly the kind of behavioral disclosure annotations cannot carry.

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 lead sentence is front-loaded and states the core action and audience immediately, and the dense middle covers rails, fees, and warnings that all affect whether/how to call the tool. It is long, and the enumerated plan steps (resolve, quote, sign, track, unwrap, verify) lean toward describing output content, so it falls short of perfect economy.

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 no output schema, the description compensates by describing what the returned plan contains step by step, plus preconditions, fee ownership, per-chain minimums, and a dead-rail warning. An agent has everything needed to decide to call it and to interpret the result.

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 baseline is 3; the description adds meaning beyond the schema by tying hedera_destination to 'the exact fund_address from prepare_agent_self_claim' (and noting it auto-creates the 0.0.x account) and by explaining the rationale for the $5 amount_usd floor. The per-chain minimum caveat for Solana further enriches parameter interpretation.

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 names a specific verb (fund) and resource (Hedera wallet) and scopes it to Base or Solana source wallets, immediately distinguishing it from siblings like prepare_agent_self_claim and complete_agent_self_claim. It also makes clear this is a plan-generating tool, not an executor, so an agent can identify its role without opening the schema.

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 states an explicit precondition ('Use this when prepare_agent_self_claim returned a fund_address') and a capability requirement (holding USDC on Base or Solana with spend authority). It adds exclusions ('never use Hashport'), an authorization caveat ('only under your human's standing task authorization'), and per-chain minimum guidance.

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