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

Annotations only supply readOnlyHint=true, so the description should carry the behavioral burden, and it does: it discloses the approval and allowance-cleanup steps, the two-phase call requirement, the fee-redirect economic tradeoff (trading fee income for emissions), and the dead-gauge failure mode that silently pays nothing. It also consistently frames output as a 'plan' rather than an on-chain execution, which aligns with the read-only annotation.

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?

Purpose and the phased-call mechanic are front-loaded, and every sentence (phasing, fee redirect, dead gauge, amount sizing) carries actionable information. It is dense and clause-heavy, but no sentence 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?

With an output schema and full parameter documentation already present, the description covers the remaining gaps an agent needs: the two-phase invocation, pre-flight gauge liveness check, input sizing source, and the economic consequence of staking. Nothing required to call it correctly is missing.

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, but the description adds real meaning beyond the schema: it explains why lp_token exists as an optional phase selector and warns that amount must be sized from the live LP balance rather than a stale simulation. It does not add anything for gauge, sender, or chain_id beyond what the schema already states.

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 (stake v2 LP tokens into a pool's gauge) plus the yield intent (AERO emissions) and the two side effects bundled in (LP-token approval, allowance cleanup). This clearly separates it from siblings such as prepare_aerodrome_gauge_withdraw, prepare_aerodrome_gauge_claim, and prepare_aerodrome_liquidity_deposit.

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 explicit procedural guidance: call once without lp_token to read the gauge's stakingToken, then call again with the resolved address for the full plan. It also gives a negative rule for sizing (use live LP balance, not a prior deposit simulation two-phase. It never names a sibling alternative for when not to use this tool (e.g. deposit into the pool rather than stake), so it stops short of full when/when-not coverage.

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