Plan a liquidity-safe allocation

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces this by stating the tool never executes a financial action. It also discloses the internal workflow (computed liquidity, scoring, stress-testing) and the three possible returned verdicts, which is meaningful behavioral context beyond the annotations.

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 description is compact and front-loaded: the core process and decision output appear in one sentence, and a second sentence clarifies the tool's non-executing nature. Every phrase earns its place with no repetition of the title or schema.

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?

The tool has high complexity — nested goal/balance/products objects, four top-level parameters, no output schema, and related siblings — but the description only summarizes high-level steps. It omits guidance on required parameter relationships, sourceMode semantics, constraints, or how this planning tool relates to the sibling tools, leaving agents to guess for realistic invocations.

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 0%, and the description provides virtually no parameter-level guidance. It only contextualizes 'products' as Binance earning products and implies an 'allocation,' but leaves goal, balance, sourceMode, and all nested field semantics unexplained. Given the large nested schema, some compensation was needed and is mostly absent.

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 sequence of actions — calculate protected liquidity, score normalized Binance earning products, stress-test the allocation — and states the exact decision output (ALLOCATE, HOLD, or BLOCK). This clearly differentiates the tool from simple crud or execution tools, though it does not explicitly distinguish it from sibling planning/verification tools.

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 description implies use for planning and simulation, especially via 'This tool never executes a financial action,' but it does not state when to choose this tool over lucho_tighten_plan, lucho_verify_stress, or lucho_create_receipt. No when-to-use, when-not-to-use, or alternative routing is provided.

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