nt_modify_order

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

No annotations are provided, so the description must carry the full behavioral burden. It only states that fields can be changed but does not disclose side effects like order replacement, authorization requirements, validation constraints (e.g., cannot modify partially filled orders), or whether changes are atomic.

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 a single, concise sentence that is front-loaded with the primary action ('Modify an existing working order') and immediately lists the relevant fields. No wasted words or redundant content.

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?

Given the simple input schema (four scalar parameters, no output schema), the description provides a baseline level of completeness by identifying the target resource and editable fields. However, it omits behavior details like return values, error conditions, and side effects, which are not covered elsewhere because there are no annotations and no output schema.

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%, so the description should compensate. It enumerates the three modifiable fields (quantity, limit price, stop price) but merely paraphrases the parameter names without adding constraints, units, or relationships. The required orderId is not mentioned, though its purpose is fairly obvious from the tool name.

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 the tool modifies an existing working order and specifies the modifiable fields (quantity, limit price, stop price). This distinguishes it from sibling tools like nt_place_order (create) and nt_cancel_order (cancel).

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 phrase 'existing working order' indicates the intended context of use—orders that are already active and filled/rejected orders are excluded. However, it does not explicitly name alternative tools or state when not to use it, though sibling tool names provide implicit context.

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