reject_trade

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states that the action does not execute the trade, but fails to explain side effects such as whether the decision is permanently discarded, whether it is reversible, or how the 'reason' parameter is used. This is minimal transparency for a state-changing operation.

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, front-loaded sentence with no fluff or repetition. It efficiently captures the primary action, but lacks necessary context. While concise in structure, its brevity leads to under-specification, preventing a perfect score.

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 tool's moderate complexity (two parameters, no annotations, unknown output schema), the description is insufficiently complete. It omits details about the lifecycle of the decision, any state changes, potential errors, or prerequisites. The tool appears part of a trade-decision workflow, but the description does not situate it within that workflow or explain its effects.

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 input schema has two parameters (reason and decision_id) with zero description coverage, and the description provides no additional meaning for either. It doesn't clarify what 'decision_id' refers to, whether 'reason' is required, or how these parameters affect the rejection process. The description completely fails to compensate for the schema's lack of detail.

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 verb 'Reject' and the resource 'pending trade decision', and adds the qualifier 'without executing it' which distinguishes it from approval or execution tools. It effectively communicates the tool's core function and differentiates it from siblings like approve_trade.

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 'without executing it' implies this is the non-executing counterpart to an approval, suggesting when it should be used. However, it does not explicitly mention alternatives, state when not to use it, or reference sibling tools, leaving usage guidance implied rather than explicit.

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