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

Annotations already declare destructiveHint=true, so irreversibility is covered. The description adds genuinely new behavioral context beyond that: the TAS Guard human-approval gate, which tells the agent this call will not execute autonomously. It does not spell out the approval workflow or failure behavior if approval is denied.

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 sentence with the guard condition front-loaded in brackets and the action immediately after. Every element — approval gate, scope, object — earns its place; 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, no-output-schema destructive tool, the description supplies the two things an agent most needs: the exact scope of destruction and the fact that human approval is required. Only minor detail (what happens on denial, whether the action is reversible) is left to the destructiveHint annotation.

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 and schema coverage is 100%, so there is nothing for the description to clarify. Baseline 4 applies; no parameter meaning is missing or misstated.

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 ('Cancel') and a precisely scoped resource ('every open demo order'), which implicitly separates it from the sibling cancel_order_by_id (singular). The scope words 'every open demo' do the differentiation work, but no sibling is named outright.

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 scope: this is the bulk variant, to be used when all open demo orders should go, as opposed to cancel_order_by_id or close_all_positions. No explicit when/when-not or named alternative is given, so the agent must infer the routing.

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?

destructiveHint=true already tells the agent this is a destructive operation, so safety is covered by annotations. The description adds nothing beyond that — no irreversibility warning, no permission/auth requirements, no error or partial-failure behavior for a cancel of an unknown or already-cancelled order.

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 padding or filler. It is efficient, though the terseness is under-specification rather than true conciseness.

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 destructive, parameter-taking tool with no output schema and zero parameter documentation, the description leaves an agent without enough to invoke it correctly. It does not identify the order_id source or say what happens on success or failure.

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 order_id parameter, and the description does not compensate at all — no format, source, or example for the identifier. The agent cannot tell where order_id comes from (get_orders presumably) or what shape is valid.

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 ('Cancel one demo order'), and the word 'one' implicitly contrasts with the sibling cancel_all_orders. However, it never names that sibling or explicitly marks the single-vs-bulk boundary, and the stray qualifier 'demo' leaves ambiguity about whether it works on real orders.

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 when-to-use guidance, no conditions distinguishing it from cancel_all_orders or close_all_positions, and no prerequisites stated. The agent must infer the routing entirely from the tool 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?

Annotations already declare destructiveHint=true. The description adds important context beyond that: human approval is required and the operation is on demo positions at simulated prices, which communicates the safety and sandbox profile. It stops short of explaining reversibility or behavior when no positions exist.

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?

One compact sentence with a guard prefix, front-loading the approval requirement before the action. 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 zero-param, destructive tool with no output schema, the description is complete enough: it covers the action, the simulated environment, and the approval requirement. A minor gap is the lack of detail about what happens if no positions are open.

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?

With zero parameters, the baseline is 4. The schema is fully covered (100%) and no parameter details are needed from the description.

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 (Sell), resource (every demo position), and price context (simulated price). It clearly distinguishes itself from siblings like place_stock_order (single order) and cancel_all_orders (orders, not positions).

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?

Implied usage is to close all demo positions, and it notes the human approval requirement as a condition. It does not explicitly say when to choose this over alternatives or when not to use it, so guidance is only partial.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that this is a demo/paper account rather than a live one — but says nothing about auth, latency, or refresh 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?

A single compact fragment with no filler, and the key qualifier ('Demo paper account') is front-loaded. It is not a full sentence, but nothing in it 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?

With no input parameters, no output schema, and a readOnly annotation, the description's enumeration of returned fields (cash, equity, buying power) fills the main gap a caller would have. Only the demo-vs-live caveat and any staleness/refresh behavior remain unstated.

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 of 4 applies. The listed return fields (cash, equity, buying power) add a little value despite not being parameters.

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 (account) and the exact fields returned (cash, equity, buying power), which separates it from siblings like get_all_positions and get_orders. It lacks an explicit verb such as 'retrieve', but the data it exposes makes the purpose unambiguous.

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 call this versus the sibling tools (get_all_positions, get_orders, get_stock_latest_quote). The only contextual cue is 'Demo paper account', which hints at scope but is not framed as usage 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?

readOnlyHint=true already tells the agent this is a non-mutating read, so the description's burden is light. It does add one useful behavioral fact not in the annotations — that the data comes from the demo (sandbox) account, not a live one — but says nothing about ordering, empty-result behavior, or result shape.

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 scope qualifier is front-loaded. It is arguably under-specified rather than verbose, but nothing in it wastes the reader's time.

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 tool with readOnlyHint and no output schema, the description covers the essentials (what, which account). It stops short of describing the returned fields or whether the list can be paginated, which would help an agent decide whether a follow-up call is needed.

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 the baseline of 4 applies. There is nothing for the description to disambiguate beyond the account scope it already mentions.

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 resource ('open positions') and its scope ('the demo account') are stated clearly enough that an agent knows what data comes back. It is a noun-phrase label rather than a verb+resource statement, and it does not explicitly distinguish itself from close_all_positions, which operates on the same resource.

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_account_info, get_orders, or close_all_positions, nor any stated preconditions. The agent must infer that this is the read-side counterpart to close_all_positions purely from the 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?

readOnlyHint=true already tells the agent this is a safe read, so the description need not restate safety. It contributes the 'demo account' scoping fact, which is real added context, but says nothing about what orders are returned, ordering, limits, or pagination 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?

It is short and front-loaded, but the brevity comes from under-specification rather than disciplined editing; the whole description is a sentence fragment.

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 and no parameters, so the description is the sole carrier of meaning, and 'Orders in the demo account' leaves an agent unable to tell what the return data covers or how it differs from get_all_positions. Inadequate for even a simple tool.

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 and schema coverage is 100%, so there is nothing for the description to disambiguate. 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 is a bare noun phrase ('Orders in the demo account') that essentially restates the tool name with an account scope qualifier. It contains no verb, and it does nothing to distinguish this from siblings such as get_all_positions or get_stock_latest_quote beyond the word 'orders' and the account scope.

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 guidance on when to use this versus alternatives, no exclusions, and no mention of prerequisites. The only signal is that the scope is the demo account, which is an implicit constraint rather than usage direction.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the quote is 'simulated' with 'demo prices', warning the agent that the data is not real market data. It stops short of describing latency, refresh cadence, or error 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?

A single short sentence that is front-loaded with the verb and resource, with the key caveat in parentheses. Nothing is wasted, though the parenthetical is slightly awkwardly placed relative to the main claim.

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-only tool, the description is adequate to call the tool correctly, and annotations cover the safety profile. It omits any hint of the returned fields or symbol format, which would help an agent validate its call.

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% and there is one required parameter, so the description carries the burden. It only restates that a 'symbol' is required and adds no format, casing, or validity guidance (e.g., ticker format). Since the parameter name is self-explanatory, this is minimally adequate rather than helpful.

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 ('latest quote for a symbol') and adds a meaningful qualifier that it is simulated/demo data, which separates it from any real-market sibling. It does not explicitly distinguish itself from the surrounding trading siblings (get_orders, place_stock_order), but the resource is unambiguous.

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, no prerequisites, and no exclusions. An agent must infer usage purely from the name and the parenthetical about demo prices.

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 only destructiveHint=true from annotations, the description carries the burden and delivers: per-order and per-day notional caps, a human-approval threshold, and the execution semantics of each order type (market fills at simulated price, limit rests until cancelled). This is exactly the kind of risk and lifecycle context an agent needs before a mutating call.

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 with zero waste; the risk guard is front-loaded in brackets ahead of the operational description, so the highest-stakes information is read first.

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 risk limits and order-type semantics are covered, but with six parameters, no schema descriptions, and no output schema, the description leaves the parameter contract substantially undocumented. It is adequate for a simple call but not complete for a tool whose fields are entirely self-describing only by name.

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 six parameters, and the description adds nothing about them beyond order-type behavior. It never explains the relationship between qty and notional, whether either is optional in practice, the string-encoded numeric format, or how limit_price interacts with type.

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 and resource ('Place a demo stock order') and clarifies the simulated nature of the operation, which separates it cleanly from the read-only and cancellation siblings. It also distinguishes market vs. limit order behavior, so an agent knows exactly which operation it is invoking.

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 TAS Guard preamble conveys real constraints (2000 USD/order, 5000 USD/day, human approval over 1000) that imply when an order is permissible. However, it never says when to use this tool versus alternatives such as tas_guard_status (to check limits beforehand) or the cancel tools, so routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description's 'Read-only' is largely redundant. However, it adds genuine value with no output schema present by enumerating what is surfaced (limits, today's usage, kill switch, pending approvals), which is behavioral content beyond the 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?

Two short sentences, front-loaded with the tool name and the exact content shown, with the safety note last. Every clause carries information; 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?

With no parameters, no output schema, and read-only annotations, the only open question is what the tool returns, and the description answers that by naming the four reported areas. It stops short of describing format or freshness beyond 'today's usage', but nothing required for correct invocation is missing.

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 schema has zero parameters, which is the baseline-4 case. There is nothing further for the description to clarify, and it correctly implies the tool operates on the ambient connection rather than taking arguments.

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 ('show') and an enumerated resource set (trading limits, today's usage, kill switch, pending approvals) scoped to 'this connection', which a reader can easily distinguish from get_account_info or get_orders. It does not explicitly name or contrast any sibling tool, which is what a 5 would require.

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 content ('limits that apply to this connection'), so an agent can infer it answers a risk/limits check, but there is no statement of when to prefer it over get_account_info or when it is not appropriate. No prerequisites, timing, or exclusions are given.

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