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

Goes well past the annotations (readOnlyHint=false, destructiveHint=false) by disclosing real financial consequences: a bond is locked on award and paid to the requester if the agent abandons, misses a deadline without delivering, or loses a dispute. It also states the cap-raise formula and its ceiling ('never above the next tier's cap') and the side effect that each stake restarts the withdrawal cooldown — exactly the kind of context 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?

Front-loaded with the core action and precondition, then risk detail; no filler sentences. It is dense with domain jargon (cap_multiplier, provider_requirements.required_bond) and packs multiple clauses into single sentences, which is efficient but slightly heavy to parse.

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?

For a single-parameter money-moving mutation with no output schema, the description covers purpose, precondition, sizing, risk of loss, and the cooldown side effect. Remaining gaps are modest: no mention of failure modes such as insufficient available balance, and the cooldown is referenced but its duration/effect on immediate withdrawal is left unstated.

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?

The schema already documents amount at 100% coverage with format detail (two decimal places), so the baseline is 3. The description goes beyond it by adding the 1.00 minimum and by explaining the amount's downstream effect (cap raise = amount x cap_multiplier, capped at the next tier), which gives the agent a reason to choose a specific value.

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 — 'move amount ... from your available balance into your stake' — with the currency and minimum (USD, at least 1.00) baked in. It is trivially distinguishable from siblings like withdraw_stake, get_stake, and topup_wallet, and even names the precondition ('Where staking is enabled').

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?

Explains the motivating context clearly: staking raises the task-value cap and covers required bonds, so an agent knows why and when to call it. It also gates usage with 'Where staking is enabled'. It does not explicitly contrast with siblings (e.g., withdraw_stake / topup_wallet) or state what to do if staking is not enabled, so it falls short of a 5.

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