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

Annotations already include readOnlyHint=true, and the description adds substantial behavioral context: it is an estimate based on Kalshi’s published risk parameters, not the app’s exact figure; it mentions leverage caps and that the estimate reports when the cap was applied; it discloses 'Free, no key' (no auth). These details go beyond the structured hints and materially set expectations for the tool's output and constraints.

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 front-loaded with the core purpose and then layers supporting context (estimate nature, asset list, usage examples). It is longer than the minimal two-sentence ideal but every sentence contributes: the maintenance-margin nuance prevents misinterpretation, the asset list avoids schema lookups, and the examples act as routing cues. It could be trimmed slightly, but it is not bloated.

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?

The tool has 6 parameters and no output schema, so the description must convey what to expect. It states the outputs (liquidation price, % move, fees, funding), notes the estimate caveat, and explains the leverage cap behavior — all essential for correct invocation and interpretation. It does not specify exact output structure or error handling, but given the absence of an output schema, this is a reasonable level of 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?

Schema coverage is 100% — every parameter (asset, side, leverage, entry, margin, hold_days) has a description in the input schema. The description does not add parameter-level detail beyond the schema; it only provides domain background (maintenance margin vs 100/leverage) that is not tied to a specific parameter. Baseline 3 is appropriate since the schema does the heavy lifting.

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 'Estimate where a Kalshi perp position liquidates', specifying a clear verb and resource. It enumerates the exact outputs (liquidation price, % move, round-trip fees, expected funding) and explicitly contrasts itself with Kalshi's app (exact figure), which distinguishes it from any sibling tool. The asset list and example queries further anchor its 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 three concrete usage examples ('where does a 5x bitcoin long liquidate on Kalshi', etc.), which tell an agent exactly when to invoke the tool. It does not explicitly name alternative tools or state exclusion criteria, but the examples cover the typical user intent and the estimate caveat implies caution about treating results as exact. This is clear enough for routing, though not exhaustive.

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