webquik_send_order

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

No annotations are provided, so the description carries the full behavioral burden for a real-money exchange mutation. It never states that this executes a live MOEX trade, that it is irreversible, that a session/authentication is required, or what happens when price is left at its default of 0 with order_type=market.

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 action is stated first, followed by a compact field legend with no filler. It is terse rather than bloated, though the legend reads more like schema documentation than guidance.

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?

An output schema exists, so return values need not be explained. But for a 5-required-parameter trading mutation with no annotations, the description omits authentication prerequisites, order lifecycle context, and four parameters' semantics, leaving an agent without enough context to call it safely.

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 description coverage is 0% across 8 parameters, so the description must compensate; it defines side (buy|sell), order_type (limit|market), account format, and client_code, which is genuinely useful since the schema declares no enums. However, it omits sec_code, class_code, quantity, and the price/order_type interaction (price defaults to 0), leaving half the parameters undocumented.

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?

States a specific verb and resource ('Place a new order on MOEX via webQUIK'), which is clearly distinct from sibling read tools like webquik_get_orders and from webquik_cancel_order. It does not explicitly name the alternative to use for modifying or cancelling, but the action itself is unambiguous.

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 no conditions for when to use this tool versus alternatives, no prerequisites (login/submit_pin/session_status siblings suggest a session is required), and no note that it is the only way to open a position versus cancelling an existing one. Usage is only implied by the verb 'Place'.

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