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

No annotations are provided, so the description carries the full burden. It discloses several important behaviors: a 'refund-honest 409 when nothing clears the floor', a '402 payment envelope' for uncredentialed calls, and a 'descriptive framing until the pre-registered bar'. These give an agent a good sense of what happens in edge cases, though it doesn't cover timing or rate limits.

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 a dense, single block but contains no fluff — every clause adds methodological, output, error, or payment information. The main content is front-loaded with the core purpose, followed by payment details in brackets. It could be better structured with separators, but it is appropriately sized for the complexity.

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?

Given no output schema and no annotations, this description is exceptionally complete. It explains the scan target, pricing reference, output trade specification, error codes (409, 402), payment cost and method, authentication mechanism, and even a 'descriptive framing' mode. It leaves little ambiguity for an agent deciding whether to call and what to expect.

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?

The tool has 0 defined parameters, and the schema defers to the 'instruments' tool for parameter docs. With 0 params, the baseline is 4; the description adds no parameter-specific semantics, but none are required since there are no explicit parameters to document.

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 begins with 'Perps — Polymarket Perps dislocation scan' and clearly specifies the resource (Polymarket perps) and the action (scanning for dislocations). It details the methodology (cross-venue reference, round-trip taker + book walk) and the output (convergence trade with entry/TP/SL, Kelly size, EV, ladder), which distinguishes it from sibling signal tools that cover other asset classes.

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 provides clear context for when to call: it identifies the exact asset class (perps) and the signal generation method. It also specifies payment requirements and authentication (X-API-KEY) and error conditions (409/402), which are essential usage conditions. However, it does not explicitly compare to alternatives or state when not to use this tool, so it misses the exclusion aspect.

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