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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety bar is low, and the description adds real context beyond them: what the estimate contains (fees per day, per 30 days, IL at three price-move levels) and the flat 100,000 QU cost assumption for adding/removing liquidity. It does not mention rate limits, freshness of the underlying data, or what happens when position_qu is omitted.

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 tight sentences, purpose front-loaded before the estimate details and the cost caveat. Dense but every clause carries information; no 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 no output schema, the description must describe returns and largely does (fees per day, per 30 days, IL at 10/25/50%), plus a cost assumption. Gaps remain: the window parameter's effect on the estimate and the default behaviour when position_qu is not supplied are unaddressed.

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 33%, so the description must carry weight; it does define position_qu as 'the QU value of both sides together', which the schema leaves undocumented. However, the window parameter (7d/30d enum, default 7d) is never explained, and it is unclear from the description whether position_qu is optional or what the output looks like without it.

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+resource: 'one pool's numbers explained' plus a deposit-size estimate of daily/30-day fees and impermanent loss at 10/25/50% price moves. That is a clear, distinctive capability that separates it from generic siblings like qmax_get_liquidity_pool or qmax_list_pools, though it never names a sibling to route against.

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?

Usage is only implied: you gather the estimate when you have a deposit size (position_qu) in mind. There is no explicit when-to-use/when-not guidance, no statement of prerequisites, and no pointer to an alternative tool for a plain pool lookup.

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