modify_order

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

With no annotations provided, the description must disclose behavior on its own. It does this well by explaining the expiry auto-cancellation behavior, the Unix timestamp format, and the pending-order scope. It does not mention permissions or error scenarios, but these are less critical for a modification tool and the key behavioral side-effect is explicitly stated.

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 two concise sentences (plus a Korean translation) that front-load the purpose and immediately list the modifiable fields and the critical expiry behavior. Every sentence adds value; no fluff or redundancy.

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 5 parameters, no annotations, and no output schema, the description explains the operation, the modifiable fields, and the expiry side-effect clearly. It does not mention return values or error handling, but the schema covers all parameter semantics and the description gives sufficient context for an agent to select and invoke the tool correctly.

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 100%, and the schema already documents each parameter, including expiry behavior (auto-cancel) and types. The description adds minimal new meaning beyond rephrasing the schema fields, so a 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 uses a specific verb 'Modify', identifies the resource as 'existing pending order', and explicitly lists the updatable fields (price, stop loss, take profit, expiration time). This clearly distinguishes it from sibling tools like modify_position or open_order, which operate on different resources.

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 provides clear context by restricting the operation to 'existing pending order' rather than new or filled orders, and enumerates the fields that can be updated. However, it does not explicitly name alternatives (e.g., 'use open_order for new orders') or state when not to use this tool, so it lacks the full 'when-not/alternatives' guidance for a 5.

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