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 explains the analysis inputs and output (rankings + recommendation + warnings), which is useful, but it does not state whether the tool is read-only, how warnings are determined, or any limitations (e.g., venue coverage, data freshness). This is adequate but not thorough.

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 concise and well-structured: a one-sentence value proposition, a sentence listing the key factors used, and a sentence stating the output format. Every sentence earns its place with no fluff or repetition.

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?

For a tool with moderate complexity and no output schema, the description covers the main aspects: inputs, decision factors, and output structure (rankings + recommendation + warnings). However, it lacks details about which venues are compared, what the warnings mean, or how rankings are derived, leaving some gaps for the agent.

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 already provides full descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds meaning by connecting size_usd to 'spot slippage' and 'OI cap headroom', clarifying why size matters beyond the schema's generic 'Position size in USD'. This extra context justifies a 4.

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 opens with a clear value proposition ('Where to trade this market at this size') and specifies the tool's function: compare perps venues using funding, slippage, fees, OI headroom, and entry cost, then return rankings and a recommendation. This distinguishes it from siblings like perps_cross_venue_funding by explicitly extending beyond funding with additional factors.

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 the usage scenario: deciding where to execute a trade of a given market and size. It also hints at being a more comprehensive alternative to perps_cross_venue_funding ('Builds on cross-venue funding...'), but it does not explicitly state when not to use it or name alternative tools for simpler funding-only comparisons.

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