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

No annotations are provided, so the description carries the entire behavioral burden, and it discloses almost nothing beyond the verb. It does not say whether cancellation is irreversible, what happens if the order is already filled or partially filled, whether auth/permissions are required, or what the call returns.

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?

A single front-loaded sentence with zero filler — the identifying information comes first. It is perhaps too terse for a mutation tool, but there is no wasted text.

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?

This is a state-changing operation with no annotations, no output schema, and an undocumented required parameter. The description omits failure modes, irreversibility, and required permissions, so an agent lacks enough context to call it confidently in edge cases.

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 67% (orderId and reason are documented inline), and the description only re-frames the orderId concept already covered by the schema. The required 'symbol' parameter has no description in either the schema or the description, leaving a real gap.

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 (cancel) plus resource (resting order) and the keying mechanism (exchange order id). It distinguishes itself from close_position and set_stop_loss by operating on orders rather than positions, but never names or contrasts a sibling explicitly.

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 qualifier 'resting' implies the tool applies only to live/unfilled orders, which is a mild scoping constraint, but there is no stated when-to-use, no alternative (e.g., close_position for filled exposure), and no guidance on what to do if the order is already gone.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the order is reduce-only and crosses the spread (i.e. it will take liquidity rather than rest), and that it is exempt from the loss-limit halt. It does not cover failure modes (e.g. no open position), irreversibility, or what the response contains, which keeps it short of a 5.

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 sentences, zero filler, and the core action is front-loaded ahead of the permission nuance. Each sentence 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?

For a mutation tool with no annotations and no output schema, the description supplies the essentials an agent needs to act safely: the order type, the price behavior, and the halt exemption. Remaining gaps are edge cases (no position to close, partial-fill behavior) rather than core missing context.

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 50%: 'reason' is documented in the schema, but 'symbol' has no description anywhere. The prose clarifies scope ('in one symbol', closing the whole position rather than partially), which adds a little, but it does not compensate for the undocumented symbol parameter.

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 states a specific verb and resource ('flatten the whole position in one symbol') and names the execution mechanism ('a reduce-only order that crosses the spread'), which implicitly distinguishes it from place_order. An agent can tell exactly what this does without opening 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?

It gives a concrete use condition: this is a risk-reducing action, so it remains permitted even when the daily loss limit has halted new trading. That is real routing guidance, though it never names place_order as the alternative for opening/increasing exposure, so the when-not-to-use side is left to inference.

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

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

With no annotations, the description carries the burden alone. It does disclose the return payload (bid, ask, spread, level depth), which is meaningful value given there is no output schema. However, it says nothing about read-only semantics, latency/streaming, ordering, or rate limits, leaving behavioral traits thin for a wholly un-annotated tool.

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?

A single front-loaded sentence that names the primary artifact first and then enumerates contents. No filler, no 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?

Because there is no output schema, describing the returned fields is exactly the right compensation and it is done competently. The remaining gap is the absence of any cue about read-only nature or data freshness for a two-parameter market-data call, which keeps it short of a 5.

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%: 'symbol' is documented as a perp symbol with examples and 'depth' carries its own description plus a default of 5. The phrase 'nearest levels on each side' loosely corroborates the depth parameter but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific resource (order book for a symbol) and enumerates the content: best bid, best ask, spread, nearest levels per side. This clearly distinguishes it from position, limits, and candle getters by subject matter. It stops short of naming a sibling for contrast, so it is clear but not fully differentiated.

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?

There is no guidance on when to call this versus get_candles or get_limits, and no stated preconditions. Usage is only inferable from the word 'book' and the required symbol parameter. No exclusions or alternatives are offered.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the newest candle is usually still forming and that lastCandleComplete signals closure, which is real behavioral context. It says nothing about permissions, rate limits, or whether data older than 'recent' is reachable, leaving notable gaps for a read tool with zero annotation coverage.

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?

Three tight sentences with no waste: the first defines the payload, the second handles staleness, the third defines averageRange. Content is front-loaded and each sentence 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?

There is no output schema, so the description must explain return values, and it does so well (OHLCV per interval, oldest-first ordering, lastCandleComplete, averageRange). Minor gaps remain, e.g. behavior for an unknown symbol or how 'recent' relates to the count cap.

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%, so symbol, count (default 24, max 200) and interval (default 1h, enum values) are already fully documented in the schema. The description only echoes 'for each interval' and adds no syntax or semantic detail beyond that, so the baseline 3 applies.

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?

States a specific verb+resource ('Recent price history for a symbol as candles') and enumerates the returned fields (open, high, low, close, volume), so an agent knows exactly what this fetches. It does not, however, contrast itself with siblings like get_book or get_limits, so the differentiation work is left to the reader.

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?

There is no statement of when to use this tool versus alternatives such as get_book (order book depth) or get_limits, nor any prerequisites or exclusions. Context only weakly implies 'fetch market data', which is not enough routing guidance.

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

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

With no annotations present, the description carries the full burden and does real work: it discloses that the limits are enforced outside the agent and that no tool modifies them, which tells the agent this is a read-only, externally-governed resource. It stops short of describing return shape or freshness/staleness of the limits.

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 sentences, both front-loaded with the operative information (what it reports, then when to call it). No filler or restatement of the tool name.

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 no-parameter read tool with no output schema, the description covers purpose, the key return concept (limits plus remaining headroom), and the critical behavioral fact that limits are externally enforced and immutable. It does not enumerate the specific limit fields returned, which is a minor gap given there is 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the empty input object needs no further explanation.

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?

States a specific verb (report) and resource (risk limits this account trades under) plus the derived value it returns (room left against each). It is clearly distinguishable from siblings like get_positions or get_book, though it never names an alternative explicitly.

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 concrete workflow guidance: check here before sizing an order rather than discovering a limit by being rejected. That establishes when to use it relative to the order-placement siblings, but it does not name place_order or state any conditions for when not to call it.

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

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

With no annotations provided, the description carries the full behavioral burden; it does disclose useful data semantics (negative = short, PnL scoped to today) that the schema cannot convey. However, it never states that this is a read-only operation, nor anything about auth, rate limits, or how positions are scoped to an account.

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?

A single tight sentence with the key field semantics front-loaded; every clause earns its place and nothing is padded.

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 zero-parameter, read-only lookup with no output schema, the description does the essential work of telling the agent what fields come back and how to interpret them. It stops short of covering account scoping or the read-only nature, which matters given the absence of annotations.

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 tool takes zero parameters, so there is nothing for the description to disambiguate — the baseline for a no-parameter tool applies.

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 the resource (open positions) and enumerates the data returned — signed notional in USD, account value, and today's realised PnL — so an agent knows exactly what this tool fetches. It omits an explicit verb and does nothing to differentiate itself from the overlapping get_book sibling.

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?

There is no guidance on when to call this versus alternatives such as get_book or get_limits, and no stated prerequisites or context. The agent must infer usage entirely from the resource name.

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

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

With no annotations, the description carries the full burden and does well: it discloses ordering (most recent first), that risk-limit-refused actions are included, and that exchange_fill records represent exchange-side events rather than agent decisions — a non-obvious distinction that prevents misinterpretation. It stops short of covering auth, rate limits, or truncation beyond the limit parameter.

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?

Three sentences, front-loaded with what is returned before the usage hint and the exchange_fill caveat. Sentence two is slightly conversational but still earns its place as the usage trigger.

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 must convey return semantics, and it does: record contents, ordering, inclusion of refused actions, and the meaning of exchange_fill entries. The only gap is the absence of any mention of volume/pagination behavior beyond the limit cap.

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?

Only one parameter and schema coverage is 100%, with the schema stating the integer type, range, and default of 10. The description adds nothing about the limit parameter, so the baseline 3 applies.

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?

States a specific resource (your own recent actions) and a distinguishing attribute (the reasons you gave), plus ordering. An agent can immediately tell this apart from state-lookup siblings like get_positions, get_limits, or get_book, which report current state rather than a decision log.

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?

"Useful after a restart, when you no longer remember what you already did" gives a concrete triggering context. There is no explicit when-not or named alternative, but the usage context is clear and actionable.

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

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

With no annotations, the description carries the full burden and does well: it discloses that every order is risk-checked first, that a breach causes outright refusal with nothing reaching the exchange, and that both the order and the reason are written to a permanent (irreversible) log even when refused. It does not cover auth/permissions or what happens to partial fills, so it stops short of a 5.

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?

Four short sentences, front-loaded with the core purpose and followed by the most decision-relevant behaviors (risk refusal, marketable order, permanent logging). Slightly redundant with the schema's own wording on price, but no wasted sentences.

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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the critical unknowns: the risk gate, the refusal path, and the logging side effect. The main gap is that, with no output schema, it says nothing about what a successful or rejected call returns, and it does not clarify stopLoss-vs-set_stop_loss interaction.

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 88%, so the schema already documents almost every parameter in depth (price, tif, stopLoss, reason, sizeUsd). The description's 'sized in USD notional' and 'omit price for a marketable order' restate facts already present in the property descriptions rather than adding new meaning, so the baseline 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 first sentence gives a specific verb plus resource ('Place an order') and immediately narrows the semantics with 'sized in USD notional', which distinguishes it from the close_position/cancel_order siblings. An agent can identify exactly what this tool does without opening 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?

It gives in-tool conditional guidance ('Omit price for a marketable order that crosses the spread'), which is genuinely useful. However, it never addresses how this tool relates to overlapping siblings such as set_stop_loss (despite offering a stopLoss parameter) or close_position, so the when-to-use-this-vs-alternatives question is only partly answered.

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

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

With no annotations, the description carries the full burden and delivers: the stop is held exchange-side, fires whether or not the user is running, closes at market (slippage implication), is directional per long/short, replaces existing stops, and is logged with a reason. This is exactly the behavioral context an agent needs for a mutation tool.

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?

Three dense sentences, front-loaded with what the tool does and the exchange-held guarantee. Every clause carries information: mechanism, replacement behavior, directional rule, and audit logging. No filler.

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?

Covers mechanism, side semantics, replacement, and logging, and there is no output schema to explain. It does not say what happens on failure (e.g., missing position, invalid trigger relative to market), which is a minor gap for a mutation tool with no annotations.

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% so the baseline is 3, but the description adds directional semantics for triggerPrice ('below the market for a long, above it for a short') that the schema does not capture, plus the framing of reason as a human-readable rationale. That goes beyond what the schema provides.

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?

States a specific verb+resource (set a stop-loss) and immediately explains the mechanism: an exchange-held stop that closes the whole position at market when triggerPrice is hit. This clearly differentiates it from place_order and close_position, both of which appear as siblings.

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?

Frames the use case ('protect an open position') and adds a critical replacement caveat ('Replaces any stop already on that symbol'), which prevents accidental overwrites. It does not explicitly contrast with place_order/close_position, so an agent must infer that a market order is not the right tool for protective stops.

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