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

Annotations already cover the readOnly/destructive profile, and the description layers substantial extra context on top: that evalLog holds only the last 30 evaluations, exactly what each eval row contains, and how price source ('broker_candles'/'broker_quote' vs 'feed') and the broker−feed offset drive evaluation. It also flags that engine 'ai' orders are retired, which an agent could not infer from 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?

Front-loaded with a clear 'Get a conditional order:' opener, and most clauses carry real information. But the body is one sprawling sentence with deeply nested parentheses and semicolon chains, which makes it hard to parse for a consuming agent.

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?

With no output schema, the description takes on the burden of explaining the return shape and does so thoroughly: ruleState.lastResults, ruleState.lastPriceSource, ruleState.evalLog contents, and recent checks/trigger results, including FVG 'nearest' semantics. An agent has enough to interpret the response without further documentation.

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 coverage is 100% and the single orderId param is a plain number, so the schema does the work; the description adds nothing about the ID itself. It does reference brokerAccountId, which is not actually a parameter of this tool, a mild source of confusion rather than added param meaning.

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?

Specific verb ('Get') plus resource ('conditional order') with the scope of what is returned enumerated: conditions, action, status, evaluation state, checks. The closing use-case line ('understand why an order has or hasn't fired yet') separates it from the list sibling get_conditional_orders without needing the schema.

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?

Gives an explicit use case for diagnosis of why an order fired or not, which is real guidance. However, it never names an alternative sibling (get_conditional_orders, run_conditional_order, update_conditional_order) or states a when-not condition, so the routing guidance is implied rather than spelled out.

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