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

Annotations cover the safety profile (readOnly, openWorld, non-destructive), so the bar is lower, and the description goes beyond them with a concrete quota (1,000 scans per caller per UTC day), the payment endpoint, price, and the required X-Scan-Pass header. That is genuine operational context an agent cannot see in the schema. It stops short of describing error or failure behavior when the quota is exhausted or the pass is missing.

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 rate-limit and pricing detail is useful and specific, but the 'free half / paid half' marketing framing occupies the front of the text and delays the actual description of outputs. Several words are spent selling the paid tier rather than helping invocation. It is not bloated, but the structure is narrative rather than action-first.

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 carries the burden of explaining returns, and it does list the three measured quantities, plus quota and payment mechanics. The only meaningful gap is what happens at or past the quota boundary and how a missing or invalid pass is surfaced. For a single-parameter read tool, that is close to complete.

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?

There is a single parameter with 100% schema description coverage, so the schema already explains that it is a BEP-20 token address. The description reinforces the scope ('any BSC token's pool') but adds no format, validation, or edge-case detail beyond that baseline. Baseline 3 is appropriate when the schema carries the semantics.

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 states the concrete measurements returned for any BSC token pool — depth, price impact at sizes, and transfer tax measured from executed trades — which tells an agent what the resource and payload are. It also implicitly separates itself from the sibling by describing 'the paid half' as adding grid-cycle cost and break-even spacing. The framing as 'the free half' rather than a clean verb+resource statement keeps it 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?

Usage is only implied: the 'free half' vs 'paid half' framing suggests this tool for raw pool economics and grid_plan for cycle/break-even analysis, but the sibling is never named and no explicit when-to-use/when-not-to-use rule is given. The rate limit is stated operationally rather than as a selection guideline. An agent can infer the split but must do work the description could have done.

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