创建条件单

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

Annotations already mark the tool as non-read-only and destructive, but the description adds important behavioral context: trigger-direction constraints with the -2021 error, the requirement that closePosition implies existing position and shuts off quantity/reduceOnly, and hedge-mode positionSide requirements. This is exactly what an agent needs to predict side effects.

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?

Every sentence delivers a new usable rule; the typ-to-parameter mapping is fronted, choes have third constraints in short clauses, and there is no filler or schema 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 15-parameter, no-output-schema tool, it covers key decision and edge cases: what differs between order types, closePosition behaviors, direction constraints, and hedging mode. The missing return shape and unexplained option semantics for some optional fields keeps it from perfect 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 low (33%), and the description significantly compensates by explaining the parameter dependencies, required fields for each order type, the trigger-price direction rules, and closePosition/quantity conflict. A few optional params (timeInForce, workingType, priceProtect, clientAlgoId) are not meaningfully expanded on, so it is not a full 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 clearly states a specific operation: creating conditional orders for stop-loss, take-profit, and trailing-stop scenarios. It lists the supported order types, so an agent can distinguish this tool from ordinary order placement siblings such as trading_place_order.

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?

It gives explicit type-driven usage rules: which params are required for STOP_MARKET vs STOP vs TRAILING, and special rules for closePosition and positionSide in hedge mode. It does not explicitly mention 'use trading_place_order instead for immediate orders', so it stops short of a perfect when-not-to-use statement.

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