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

readOnlyHint already covers the safety profile, and the description adds genuinely non-obvious behavior: the response is per-tick net deltas, not cumulative liquidity, and must be accumulated in ascending tick order to reconstruct depth. That prevents a serious misinterpretation. It omits response size/pagination concerns, which matter for tick-level data on a large pool.

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 sentences, no filler, with the resource and scope front-loaded and the interpretation rule immediately after. Nothing is redundant with the structured fields in a wasteful way.

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?

An output schema exists, so return-value documentation is not required, and the description still supplies the one interpretive fact an agent needs (deltas must be accumulated). Only response-volume/pagination guidance is missing, which is minor for a read-only tool whose schema is fully documented.

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 100%, so the baseline is 3. The description reinforces that the three identifiers must designate exactly one pool and must be mutually consistent (chain/core/pool), which is a small addition over the per-field schema text, but it adds no format or validation detail beyond the schema.

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?

Specific verb and resource: 'Return tick-level net liquidity deltas' scoped to 'one exact chain/core/pool ID.' It is clear this returns raw deltas rather than a computed depth figure. It does not name a sibling (e.g., get_uniswap_pool_ticks or get_pool) to disambiguate, so it falls short of a 5.

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 usage via the exact-match scoping ('one exact chain/core/pool ID') and via the instruction to accumulate deltas, which tells the agent what the output is good for. However, it never states when to prefer this over sibling readers like get_pool or get_uniswap_pool_ticks, and no exclusions or prerequisites are given.

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