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

On top of readOnlyHint/destructiveHint=false, it discloses that nothing is sent on the agent's behalf, every step including the final Wanchain collect is a transaction the agent signs, the claim must precede any transfer or the transfer does not count, the tool fetches the reward signature itself, and it never offers an invalid step. That is substantial behavioral context the annotations alone do not convey.

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?

Front-loaded with purpose before the loop mechanics, and nearly every clause carries actionable instruction. It is dense as a single prose block and would be easier to follow with explicit structure, but little of the content is filler.

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?

There is no output schema, so the description must describe the response — and it does: the status enum values, the have/need/short requirements shape with the 'null is unknown, never zero' rule, and the next.action semantics. Combined with the loop protocol and the signing constraint, an agent has everything needed to call this iteratively.

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 0% schema description coverage the description must carry parameter meaning, and it does for most: address, task_id, the conditional source_address/dest_address (including the rule about non-EVM chains and the 0x prohibition), and source_tx (add once the bridge tx is sent). The signature parameter is only obliquely referenced ('it fetches the reward signature itself'), leaving its role ambiguous.

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?

States a specific verb and resource: it drives one Bridge to Earn task for an address, returning status, requirements with have/need/short, and a ready-built next action. This clearly distinguishes it from read-only siblings like get_address_bridge_to_earn and list_bridge_to_earn_tasks by positioning it as the step driver.

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?

Gives an explicit loop contract: call with task_id and address, add source/dest_address when the chain is non-EVM (Tron, Solana, Bitcoin, Cardano, XRP Ledger, Sui, never derived from the 0x address), then add source_tx after the bridge transaction is sent. It enumerates every next.action branch (fund, send, wait, done, stop) and exactly what to do in each.

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