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

Annotations already cover read-only/idempotent/open-world, yet the description still adds real behavioral context: range_health_status=unavailable rather than a fake 0, ohlcv_status=unsupported, and the auth model (X-API-Key/Bearer or x402 settlement after HTTP 402). It loses a point because 'prefer small limit (3–5)' refers to a parameter that does not exist on this tool, and the pricing paragraph describes meteora_brief rather than this call.

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 output-field inventory is correctly front-loaded and dense, but the trailing block mixes signup URLs, x402 settlement mechanics, and dynamic pricing about a different tool (meteora_brief), which dilutes the signal. The nonexistent 'limit' advice is wasted text an agent cannot act on.

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 does the heavy lifting by naming the returned fields and their degraded-value semantics, which is what an agent needs to interpret results. Remaining gaps are minor: no note on error responses for an invalid pool_address beyond the schema's length bounds.

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 meaning the schema lacks: compact maps to REST ?format=compact or the Accept vendor media type, and commerce surfaces accept ?fields= and ?simple=true. It also explains the derivation behind band_bps (± half-width around active_bin_id) and that window governs fee_velocity via meta.window.

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?

Names the resource precisely (Meteora DLMM pool detail v2) and enumerates the concrete output fields — price_unit, mints, range_health, active_bin_id, fee ratios — so an agent knows exactly what it gets back. It is differentiated from the sibling meteora_brief by the sequencing note, though the wording is a noun phrase rather than an explicit verb like 'fetch'.

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?

'Use after meteora_brief when you have pool_address' gives an explicit prerequisite and predecessor tool, which is strong guidance. It also advises compact=true for abbreviated keys and small limits, but never states when NOT to use it or what to use instead for other pool data.

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