modify_order

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

With no annotations, the description discloses an important behavioral constraint: all identifying fields must match the original order. It also restricts modifications to open orders. Still, it does not mention permission requirements, what happens to the original order, or rejection/failure behavior, so transparency is only partial.

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?

Two short sentences with no filler. The action is front-loaded, and the second sentence adds a necessary constraint that directly affects invocation. Every part of the description earns its place.

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 11 parameters, 9 required fields, no annotations, and no enum values, the description is not sufficient for reliable invocation. The only contextual guidance is the identifying-fields constraint; required domain fields such as variety, ordertype, and producttype are undocumented, so an agent would still face significant ambiguity.

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%, and the description compensates for only three of eleven parameters by saying tradingsymbol, symboltoken, and exchange must match the original. The meaning of domain-specific parameters like variety, ordertype, producttype, duration, and triggerprice is left entirely to inference from field names.

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 names a concrete action and target ('modify an existing open order') rather than just restating the tool name. The 'open order' scope distinguishes it from siblings like place_order, cancel_order, and convert_position, making its purpose immediately actionable.

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 implies when to use it: when an existing order is open and needs to be changed. However, it does not explicitly state when not to use it or point to alternatives such as cancel_order for closed or filled orders, leaving some usage inference to the agent.

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