Restart Grid Order

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

Going beyond the annotations, the description explains that without execute the call is only a DRY RUN and nothing is sent to the exchange, that the confirmation code is single-use and expires in 10 minutes, and that a live restarted grid resumes placing orders autonomously. This is highly relevant behavioral context, especially with readOnlyHint=false and openWorldHint=true, and it does not contradict the annotations.

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 action and the mandatory two-step confirmation, and every subsequent sentence adds a safety-relevant detail. Despite the complexity of the protocol, it remains tight and readable.

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 tool with no output schema, the description covers the full invocation lifecycle: dry-run, preview to user, explicit confirmation, execute code scope/expiry, and autonomous order placement afterward. An agent has enough to avoid misuse; the only minor gap is not describing the preview payload shape, which is not essential for correct invocation.

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 schema already documents both parameters completely (order_id and execute, including the full dry-run/confirmation protocol). The main description restates the confirmation semantics but does not add meaning about parameter types or formats beyond the schema, so the baseline 3 applies.

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 opening sentence specifies the action ('Restart (resume)'), the target ('a suspended grid order'), and the identifier ('order_id'), so the agent knows exactly what the tool operates on. It is clear at a glance, but it does not differentiate this from the similarly named sibling grid_resume, so it stops short of a 5.

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 lays out an unambiguous confirmation protocol: invoke without execute first, present the returned preview to the user, and only call again with execute=confirmation_code after explicit user confirmation. It also warns never to quote the code on the agent's own initiative. It does not compare with grid_resume or other grid tools, so four rather than five.

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