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

Annotations already signal destructiveness and non-idempotency, but the description adds crucial behavioral context: real funds are at stake, the tool refuses to execute without a recent matching preview, and explicit user confirmation is mandatory. This goes well beyond the structured annotations and is highly valuable for safe agent behavior.

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 compact and well-structured: the use case is stated first, followed by the mandatory safety workflow and the configuration prerequisite. Every sentence carries essential information with no filler.

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 destructive, real-funds tool, the description covers the critical operational context: the preview requirement, confirmation requirement, preview freshness window, and settings prerequisite. It does not describe the response/return shape, but the schema and the described workflow largely compensate for this omission.

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 documents all 9 parameters with descriptions, enums, defaults, and constraints, achieving 100% coverage. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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 clearly states the tool's purpose: opening a perp position or placing an order on Hyperliquid via MCPify when the user explicitly requests it. It also distinguishes itself from preview_order by emphasizing that place_order is the final execution step.

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 gives explicit when-to-use guidance: only when the user explicitly asks to open a position or place an order. It also provides a precise mandatory workflow: call preview_order first, show the proposal, get confirmation, and only proceed if the preview ran within 10 minutes. It further names the prerequisite of Agent Trading being enabled.

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