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

Annotations already declare readOnlyHint=true, so the safety profile is known and the description need not restate it. The description does add genuinely useful behavior: the response names the wrapped token and that token is chain-dependent (BNB, POL, MON), which prevents the agent from hardcoding WETH. It stops short of describing what 'prepare' emits (calldata vs. a plan), approval prerequisites, or failure modes for unsupported chains.

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 sentences with no filler, and the core action is front-loaded. The second sentence is a return-value note that partially overlaps the existing output schema, which is the only mild 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?

With an output schema present and 75% schema coverage, the description need not explain return shape, yet the one return detail it does give (varying wrapped-token symbol) is a good pick. Gaps remain for a four-required-parameter transaction-preparation tool: no supported-chain guidance, no mention of prior token approvals or allowance setup, and no hint about what the caller must do with the prepared 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 description coverage is 75%, so most parameter meaning is already carried by the schema (amount in base units, sender address, chain_id, direction enum). The description adds no per-parameter meaning and does not clarify whether amount refers to the native or wrapped denomination. Baseline 3 applies when 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?

States a specific verb and resource: 'Prepare a direct wrapped-native deposit or withdrawal.' The word 'direct' and the 'wrapped native token' qualifier separate it from router-based or liquid-staking siblings like prepare_lido_wrap, but the description never names those siblings explicitly, so differentiation requires inference.

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 phrase 'on a chain with a verified wrapped native token' implies a precondition for use, and 'direct' suggests the non-router path. However, there is no explicit when-not guidance (e.g. use prepare_lido_wrap for stETH, or don't use on chains lacking a verified wrapper) and no alternatives are named despite ~80 sibling prepare_* tools.

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