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

With no annotations provided, the description carries the full burden of disclosing behavior. It does this well: it explicitly warns that prizes are 'CONDITIONAL ON BEING FILLED' and that 'No fill probability is estimated anywhere in the response,' it states the output ordering ('sorted widest-first'), explains the effect of providing notional_usd ('prices crossing as the real book walk and adds the best-venue-to-cross comparison per coin'), and notes the API key requirement. This is strong behavioral disclosure, though a few details (e.g., error handling or exact response format) are left to the output schema.

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 efficiently structured: a one-sentence summary of purpose, a clear list of use cases, a direct and emphatic honesty warning, then a compact parameter glossary. Every sentence serves a function, and the most critical constraints (fill condition, no probability) are front-loaded immediately after the purpose. No filler or redundant phrasing.

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 the tool's moderate complexity (4 optional parameters, no annotations, output schema available), the description covers essential context: what the tool returns conceptually, how it sorts, the conditional nature of prizes, the impact of notional_usd, the limit cap, and authentication needs. The output schema covers return shape, so that is appropriately delegated. The only notable omission is the side parameter semantics, which slightly reduces completeness.

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 input schema has 0% description coverage for its 4 parameters, so the description must compensate. It does: 'coins = optional comma-separated list (default: the liquid crypto perp universe by volume)', 'notional_usd = optional; supplying it prices crossing as the real book walk...', and 'limit = how many coins, max 40.' However, the side parameter is not explained at all, leaving a small gap. Despite that, the description adds rich semantics beyond the raw schema, earning a 4 but not a 5.

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 a specific, action-oriented summary: 'Universe-wide maker/taker table: for each liquid crypto perp, the best venue to post on and the round-trip prize, sorted widest-first.' It clearly states the resource (liquid crypto perps), the action (finding the best venue to post), and the sorting logic. It also lists concrete use cases ('where is being passive worth the most', 'which coins should I be quoting rather than taking', 'rank my book by spread capture'), which unambiguously differentiates this tool from the sibling post_value by emphasizing a whole-universe scope.

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 explicit use cases and conditions: 'Use for "where is being passive worth the most"...' and it notes a prerequisite: 'Requires an EnsoTrade Pro API key.' It references the sibling post_value ('Same honesty requirement as post_value') indicating a related alternative, but does not explicitly state when NOT to use this tool versus its siblings. The context is clear enough to guide selection, though exclusions or alternative routing are not spelled out, so it falls just short of a 5.

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