submit_order

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

With no annotations, the description carries the full burden and does well: it discloses the approval-threshold and daily-budget queueing behavior, the existence of human approval, and the idempotency model including the 'duplicate' status and 'ag-<client_intent_id>' id format. It leaves out permission/auth requirements, whether orders are live or simulated, and rate limits.

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 queueing/approval consequence is front-loaded, followed by the idempotency contract, with no filler sentences. The indentation is cosmetic noise but the content is dense and every clause conveys a distinct rule.

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 output schema means return shape needn't be explained, and the approval and duplicate-response behaviors are covered well. But for a 13-parameter mutation with zero schema descriptions and no annotations, the description is not complete enough: an agent still cannot tell what units size is in, what algo/slices/pov_rate do, or how limit_px vs post_only interact.

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 13 parameters, and the description only documents client_intent_id (format constraints plus retry semantics). Core trading parameters like coin, side, size, algo, slices, pov_rate, limit_px, post_only, reduce_only and max_slippage_bps get no explanation at all, so the biggest gap in the definition remains unaddressed.

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?

Opens with a specific verb and resource ('Submit an intent') and immediately explains the queuing outcome, so an agent understands this places an order intent. It names approval_status as the follow-up tool, though it never distinguishes itself from preview_order or get_quote, leaving sibling routing partly to inference.

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?

Gives explicit operational guidance: check a returned approval_id with approval_status, always supply a fresh client_intent_id, and reuse that id on retry after a timeout or error. What is missing is when to prefer preview_order or get_quote before calling this, so it stops short of full when/when-not coverage.

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