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

With no annotations, the description carries the full burden. It discloses the core risk model — losing risk_percent of balance on stop — but does not clarify that the tool is purely computational, whether it places any order, what account or market data it depends on, or what the return value looks like.

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 single sentence is front-loaded and contains no filler. It states the calculation and the sizing condition efficiently.

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 three required, undocumented parameters, no annotations, and no output schema, the description is under-specified. It does not explain data dependencies, output format, or parameter conventions needed to invoke the tool correctly.

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 must compensate for all three parameters. It mentions risk_percent and stop-loss indirectly, but does not explain symbol at all, nor clarify units for risk_percent (fraction vs percent) or the expected relationship of stop_loss_price to current price.

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 calculation: position size in lots based on risk_percent of balance and a stop loss. It clearly distinguishes this calculator from all sibling order/manipulation and read-only tools, none of which perform lot sizing.

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 explains what the calculation achieves but gives no guidance on when to use it versus alternatives, nor any prerequisites such as needing account balance or current market price. It leaves the agent to infer the workflow context.

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?

No annotations are present, so the description carries the full burden. It says 'Delete,' implying a destructive mutation, but does not disclose reversibility, required permissions, behavior if the order has already filled, or what is returned. For a mutation tool with zero structured behavioral coverage, this is a significant gap.

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 no wasted words. It is appropriately sized for the amount of information it attempts to convey.

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 no annotations, no output schema, and 0% parameter coverage, the description is incomplete: it omits parameter semantics, error conditions, and comparison to sibling tools. The core action is stated, but an agent lacks enough context to invoke 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 0% for the single required `ticket` parameter, and the description never explains what the ticket is, its format, or how to obtain it. It only refers to 'a pending order' generically, adding no meaning beyond the schema's property 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 names a specific verb ('Delete') and resource ('a pending order') and adds the temporal condition 'before it fills,' so an agent can tell it targets unfilled orders. It does not, however, distinguish itself from siblings like modify_pending_order or close_position; that sibling differentiation is absent.

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?

Usage is implied: cancel a pending order when you don't want it to execute. There is no explicit when-to-use/when-not guidance, no named alternatives, and no prerequisites (e.g., needing an order ticket). Score 3 for implied usage only.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that closing can be partial, but omits critical trading semantics: whether the close executes at market, what happens if `volume` exceeds the open size, error behavior for an invalid ticket, and whether the action is irreversible.

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 action and mechanism front-loaded and zero filler. Nothing in it could be cut without losing information.

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?

The description covers the minimum an agent needs to call the tool, but for a financial mutation with no annotations, no output schema, and two undocumented parameters, more operational context (execution style, failure modes, ticket source) should have been supplied.

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 must compensate, and it partially does: it clarifies that `volume` triggers a partial close and that its absence implies a full close. It never explains where `ticket` comes from (e.g., get_positions) or the units of `volume`.

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 gives a specific verb and resource ("Close an open position") plus the two operating modes, so the agent knows exactly what the tool does. It does not name or contrast itself with siblings like modify_position or cancel_pending_order, so it falls short of a 5.

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?

Usage is implied by the phrase "Close an open position by ticket" — the agent can infer it is the tool for exiting an existing position. However, there is no explicit when-not guidance (e.g., use modify_position to change SL/TP instead, or when a partial close is preferable to a full one).

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?

No annotations are provided, so the description carries the full burden. It does disclose the return payload (balance, equity, margin, free margin, margin level, leverage), which is meaningful given there is no output schema, but it says nothing about read-only nature, latency, units/currency of the values, or what happens if no account is connected.

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?

It is a single terse sentence fragment with zero waste, appropriately sized for a zero-argument snapshot tool. It is front-loaded with the most important field (balance), though the absence of any verb phrase slightly weakens the lead.

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 trivial zero-parameter read, the main missing piece is the return-value framing, and without an output schema the field enumeration does useful work there. However, it omits units, whether margin level is a ratio or percentage, and any condition under which the call fails or returns empty, so it is only minimally complete.

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 per the rubric the baseline is 4. There is no argument surface to document, and the description does not need to compensate for anything here.

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 enumerates the data the tool exposes (balance, equity, margin, free margin, margin level, leverage), which makes the resource identifiable, but it is a bare noun phrase with no verb and no differentiation from siblings like get_terminal_info or get_positions. An agent can infer it returns account state, but the purpose is stated as a field list rather than an action.

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 when-to-use guidance at all. Nothing tells the agent when to call this instead of get_terminal_info for account-adjacent data, nor whether it is a snapshot or requires a prior login/connection. The field list implies usage but does not state 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the sort order (oldest first) and that data is "recent" (implying a bounded lookback), but says nothing about permissions, rate limits, data source, or how the default count/timeframe behave.

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, zero filler, with the key ordering guarantee front-loaded. It is efficient, though the terseness leaves the gaps noted in other dimensions.

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-annotation, low-coverage, no-output-schema tool, the description is under-specified: an agent cannot tell the maximum count, symbol conventions, or timeframe semantics. The content that exists is correct but insufficient for confident invocation.

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 all three parameters (symbol, count, timeframe) are undocumented anywhere. The description only hints at the data shape via "OHLCV"; it adds no meaning for symbol format, count limits, or the timeframe enum, failing to compensate for the coverage 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?

States the specific resource (OHLCV candles) and the ordering guarantee (oldest first), which distinguishes it from get_tick and get_indicator. It is clear what the tool returns, though it does not explicitly contrast itself with siblings in prose.

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?

"Use for chart analysis" is a thin purpose statement rather than guidance. It never says when to prefer this over get_tick, get_indicator, or get_history, nor 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, the description carries the full burden, and it does disclose the return content (net profit, wins/losses per symbol), which is genuinely useful since there is no output schema. However it omits any auth/permission requirements, whether it is strictly read-only, and whether results are aggregated or per-trade.

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 scope before the payload fields. Efficient, though the colon-list style is slightly telegraphic and leaves the symbol/days_back roles compressed.

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, no annotations and zero schema description coverage, the description should do more. It covers the headline return fields but leaves parameter behavior, timezone/aggregation semantics, and the read-only nature unexplained.

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 must compensate for both parameters. It clarifies days_back as 'the last N days' and hints that the result is broken down 'per symbol', but never says whether symbol filters the output or is merely a grouping key, nor what symbol format is expected.

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 concrete verb+resource ('Closed-trade summary') and scopes it to the last N days. The word 'closed' implicitly separates it from open-position siblings like get_positions, but that contrast is never made explicit.

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?

No statement of when to reach for this tool versus get_positions, get_tick, or the other history-adjacent siblings. The 'last N days' phrase hints at a reporting/history use case but gives no exclusions or alternatives.

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 discloses that output is a single 'latest value' computed over 'recent candles', but 'recent' is undefined (how many candles?), and there is no mention of error behavior with insufficient data or required auth.

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 efficient sentence with the action and result front-loaded and zero filler. It is appropriately sized, though extremely sparse given the tool's parameter surface.

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 4-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. It partially compensates by stating the return shape ('latest value'), but leaves period, symbol, timeframe, and data-window behavior unexplained.

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 must compensate, yet it only names the indicator options already enumerated in the schema. It says nothing about the period, symbol, or timeframe parameters or their defaults, leaving half the parameters undocumented anywhere.

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 ('Compute') and the concrete resources (SMA, EMA, RSI, ATR) plus the returned result. It is distinguishable from siblings like get_candles or calculate_lot_size, though it does not explicitly contrast itself with any of them.

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 gives no guidance on when to use this tool versus get_candles, get_tick, or get_symbol_info, nor any prerequisites. The agent must infer usage entirely from the tool name and schema.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses only that the result set is unfilled pending orders and that symbol is an optional filter; it omits permissions, side-effect profile, pagination or ordering, and return format.

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, front-loaded sentences. Every sentence earns its place and there is 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?

For a simple one-parameter read tool with no output schema or annotations, the description states the returned dataset and the optional filter. It still leaves return fields and scoping details unstated, making it adequate but not fully complete.

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% for the single symbol parameter. The description adds that symbol is an optional filter, which is useful, but it does not define the symbol format or the behavior of omitting it beyond 'optionally'.

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 and state ('pending orders waiting to be filled'), so the purpose is clear. It omits an explicit verb like 'list' and does not distinguish itself from siblings such as get_positions or get_history.

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 only states that symbol is an optional filter. There is no guidance on when to use this tool versus alternatives, no prerequisites, and no when-not-to-use advice.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that results include live profit and swap, but it does not state read-only safety, authentication requirements, pagination, or result 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 short sentences, front-loaded with the tool purpose and followed by the only parameter guidance. 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?

For a simple read tool with one optional parameter and no output schema, the description covers the core purpose and notable return content. It omits symbol format and pagination/result-count behavior, but the small scope makes those minor gaps.

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% for the single symbol parameter. The description adds that it is an optional filter by symbol, but gives no format, examples, or allowed values, so it only partially compensates for the missing schema documentation.

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 and scope: open positions, with live profit and swap. This distinguishes it from siblings like get_pending_orders and get_history, though it does not explicitly name those alternatives.

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 only usage guidance is that the symbol filter is optional. There is no statement about when to use this tool versus alternatives such as get_pending_orders, get_history, or position-modification tools.

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?

No annotations are provided, so the description carries the full burden. It partially discharges that by enumerating the returned payload (digits, spread, lot min/max/step, stops level, bid/ask), which is genuinely useful since there is no output schema. It says nothing about read-only nature, behavior on an invalid/unknown symbol, or whether bid/ask are live snapshots.

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 telegraphic sentence with no wasted words, but it is under-specified rather than truly concise. There is no explicit statement of what the tool does, only a list of field names.

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 one-parameter read tool with no annotations or output schema, listing the return fields covers part of the gap. The omission of symbol format expectations and any mention of error behavior on unknown symbols leaves an agent without enough to call it confidently against this large sibling set.

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 sole parameter (symbol) is never addressed in the description. No format, casing, or broker-prefix convention is given, so the agent has no guidance on how to supply the required argument beyond the bare property name 'Symbol'.

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 (symbol) and enumerates the data it exposes (digits, spread, lot constraints, stops level, bid/ask), which makes the retrieval purpose inferable. However it is a noun-list fragment with no verb and nothing that separates it from siblings such as search_symbols or get_tick, so an agent must guess at the boundary.

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 when-to-use guidance, no exclusions, and no pointer to alternatives like search_symbols (to find a symbol) or get_tick (for live pricing only). The agent is left to infer that this is the lookup for static symbol specifications.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the components of terminal state, which tells the agent what kind of read this is, but it does not explicitly state that the operation is read-only, side-effect free, or unauthenticated.

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 compact clause with zero filler, front-loading the resource ('Terminal state') and listing only the key state dimensions. Nothing is wasted.

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 identifies the main return fields an agent needs. It could be slightly stronger by explicitly noting the read-only nature and confirming that these are the complete return values.

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 has zero parameters, so there are no parameter semantics to document. A baseline of 4 is appropriate because the schema and description correctly indicate no input is needed.

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 the resource and the three pieces of terminal state returned: broker connection, algo-trading permission, and MT5 build. This is clear but not a full verb+resource statement and does not explicitly distinguish it from sibling get_account_info.

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 provides no when-to-use guidance, no prerequisites, and no alternatives. The tool name implies a read of terminal status, but the description itself does not help an agent choose between this and other getters.

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?

No annotations are provided, so the description carries the full behavioral burden and discloses almost nothing: it does not state whether this is a snapshot or streaming value, whether it requires an active market session, or how stale the quote may be. The only implicit signal is that it is a read-style lookup, which is not made explicit.

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 short sentence with no filler, and the key resource ('bid and ask price') is front-loaded. It is efficient, though its brevity comes partly from under-specification rather than tight editing.

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 and no annotations, the description at least names the two returned fields (bid and ask), which partially covers return semantics. However, it omits timestamp/precision, symbol format, and session prerequisites, leaving notable gaps for an agent deciding whether the result is fresh enough to act on.

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 0% — the single 'symbol' parameter has no description in the schema — so the description must compensate and largely does not. It confirms only that a symbol is required, without specifying the expected format (ticker, market-qualified name, etc.) or whether it must match search_symbols output.

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 specific resource and verb-equivalent: 'Latest bid and ask price for a symbol.' This is far more precise than a bare 'get tick' and clearly distinguishes it from historical tools like get_candles. It stops short of explicitly contrasting itself with siblings such as get_symbol_info or get_terminal_info, which is why it is not a 5.

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 indication of when to call this versus alternatives like get_candles or get_symbol_info, nor any mention of prerequisites (e.g., needing a subscribed symbol or market connection). The agent is left to infer usage entirely from the one-line purpose statement.

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?

No annotations are provided, so the description carries the full behavioral burden. It says nothing about permission requirements, what happens if the order has already triggered, whether omitted fields are left untouched, or the result of the call 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?

A single front-loaded sentence with zero padding and the actionable fields stated up front. It is terse rather than bloated, though the terseness borders on under-specification.

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 4-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient: it never explains the required ticket, the update semantics of optional fields, or failure conditions.

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 0%, so the description must compensate and it largely does not. It names price/SL/TP but omits the required 'ticket' parameter entirely and gives no units, format, or semantics for null/omitted values, which matters heavily for a partial-update tool.

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 (change/modify) and resource (pending order) and enumerates the mutable fields (price, SL, TP). It implicitly distinguishes itself from modify_position and cancel_pending_order by scoping to pending orders, though it never names those siblings 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?

Usage is implied by the name and the 'pending order' scope, but there is no statement of when to use this vs. modify_position or cancel_pending_order, and no prerequisites (e.g., order must not yet be triggered).

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses one genuinely non-obvious rule ('Pass 0 to remove one'), but says nothing about permissions, error behavior on an invalid ticket, or whether both SL and TP may be set independently.

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, front-loaded with the action and followed by the one non-obvious rule. No wasted words.

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, no output schema, and 0% schema coverage, the definition is adequate but thin — missing units for sl/tp, whether each is independently optional, and failure behavior on a bad ticket.

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 must compensate. It partially does: it maps sl/tp to stop loss/take profit and explains the 0-as-removal convention, but leaves the required ticket parameter and the price units/format unaddressed.

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: 'Change stop loss / take profit of an open position.' The scope ('open position', only SL/TP) distinguishes it implicitly from sibling modify_pending_order and close_position, though it doesn't name those 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?

Usage is implied by 'of an open position' (requires an existing open position) but there is no explicit when-to-use, no alternative routing (e.g., vs close_position or modify_pending_order), and no prerequisites such as needing a valid ticket.

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 it does disclose a genuinely important trait: DRY-RUN by default and validation/preview without sending. However, it never explains how to actually submit a live order (no dry-run toggle appears in the schema), nor auth, rate limits, or failure behavior.

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 tight sentences with zero waste, and the most consequential fact (dry-run default) is front-loaded after the core action. Every clause 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 6-parameter order-placement tool with no annotations and no output schema, the dry-run disclosure is valuable but insufficient. Missing parameter semantics and any path to live execution leave meaningful gaps for an agent to call this correctly.

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% across 6 parameters, so the description must compensate but adds almost nothing. It does not explain sl/tp (stop-loss/take-profit abbreviations are ambiguous), volume units, symbol format, or the side enum, leaving the schema to carry all parameter 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?

States a specific verb+resource ('Open a position at market price'), which cleanly implies immediate execution and distinguishes it from the sibling place_pending_order. It does not explicitly name that sibling, so sibling differentiation is left implicit rather than stated.

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 'at market price' implicitly signals when to use this versus place_pending_order, but there is no explicit when/when-not guidance. It never names the alternative tool or states conditions for choosing market versus pending execution.

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 full behavioral burden. It discloses the deferred-fill mechanic, which is genuinely the core trait, but says nothing about permission/margin requirements, whether the order can be modified or cancelled afterward, what happens to the optional sl/tp, or any rate 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?

A single tightly-worded sentence with the verb front-loaded and zero filler. It is efficiently sized, though concise to the point of under-specification for a 5-required-parameter tool.

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 order-placement mutation with no annotations, no output schema, and zero schema descriptions, one sentence is far too thin. An agent lacks enough to safely populate stop-loss/take-profit semantics or know the operational constraints.

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% across 8 parameters, and the description only illuminates `price` (the trigger level). Nothing explains `sl`/`tp` (presumably stop-loss/take-profit), `volume` units, `kind`'s limit-vs-stop behavior, or `comment`, so the description fails to compensate for the coverage 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?

States a specific verb ('Place') and resource ('pending limit/stop order') and even explains the fill trigger via `price`. It implicitly contrasts with a market order but never names `place_market_order` or any sibling, so sibling differentiation is left to inference.

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 when-to-use/when-not guidance and no alternatives named. An agent is not told to prefer this over `place_market_order` or when a limit vs stop `kind` applies; only the basic 'fills later' notion is conveyed.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it only reveals substring matching ('by part of the name'). It says nothing about case sensitivity, whether results are ranked, how matches are returned, or the effect of the default limit.

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 no filler; the matching scope comes first and the examples are compact and immediately illustrative.

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 annotations, no output schema, and 0% schema coverage, the description should clarify what is returned (names, IDs, full symbol records) and how it differs from get_symbol_info. It leaves the return shape and the semantics of limit unspecified.

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 must compensate. It usefully disambiguates 'query' as a partial symbol-name fragment with concrete examples ('EUR', 'XAU', 'USD'), but leaves the 'limit' parameter (default 50) entirely unexplained, so compensation is only partial.

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 (search) and resource (broker symbols) plus the matching mode ('by part of the name'), which tells an agent this returns a filtered list rather than a single record. It does not differentiate itself from the sibling get_symbol_info, which is the nearest competing lookup tool.

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 explicit statement of when to use this versus get_symbol_info, nor any prerequisite or exclusion. The query examples hint at usage but the agent must infer when a substring search is preferable to a direct symbol lookup.

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