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

No annotations are provided, so the description carries the behavioral burden. It does disclose a meaningful constraint (synthetic/local-only scope) beyond the field list, but says nothing about irreversibility, what state the order ends in, idempotency, or failure behavior when an order is uncancellable. Partial coverage for a irreversible mutation.

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, scope stated first and constraint second — no filler. Slight redundancy: the external-broker exclusion largely repeats what broker_id's const 'paper' already encodes.

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 an output schema present, return values need not be described, and the tool is simple (2 params, flat). Still, for an irreversible cancellation the description leaves open what happens on failure or on an already-filled order, which an agent needs before committing.

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 is expected to compensate and does not: neither order_id nor the broker_id const is explained. The broker_id parameter is self-documenting via its const/default, but order_id's format and expected source (from list_orders or get_order_status) go unstated.

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?

A specific verb (cancel) plus a precisely scoped resource (one synthetic local order). The second sentence rules out a nearby interpretation (external broker orders), so the agent can distinguish it from sibling mutations like confirm_order or the blanket kill_switch.

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 supplies one useful exclusion — external broker orders cannot be cancelled here — which implies a boundary on when to use it. However it never names an alternative path for that excluded case (e.g. kill_switch or a broker-side flow), leaving routing 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that this is a mutation which creates an open synthetic order that never fills, but omits token provenance, idempotency, authorization, and whether confirmation is reversible.

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 immediately followed by the key behavioral effect. 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?

Output schema exists, so return values need not be described, and the sandbox/non-filling behavior is covered. However, for a no-annotation mutation tool, the missing token provenance and usage context leave the definition 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 single required parameter is token with 0% schema description coverage. The description does not explain where the token comes from or that it is the proposal token, leaving a material gap for a required 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?

States a specific verb and resource: confirm a local sandbox proposal, then creating an open synthetic order. This distinguishes it from the sibling propose_order by being the confirmation step, though it does not explicitly name 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?

Implies use after a proposal exists, but does not say when to use this instead of propose_order, cancel_order, or other sibling tools, nor does it state prerequisites such as needing a proposal token.

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 behavioral burden and discloses nothing beyond the bare action: no statement that it is a safe read, no failure behavior for an unknown or unconfigured broker_id, no auth or rate-limit context. A reader can infer read-only from "Get", but nothing about errors or scoping is stated.

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 constraint "one configured broker" is placed where it matters. It is efficient rather than padded, though its brevity leaves gaps addressed under 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?

An output schema exists, so return values need not be explained, but nothing else fills the gap: no annotations, an undocumented required parameter, and no guidance on sourcing broker_id. For a lookup tool in a brokerage domain where identifier provenance matters, this is thin.

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?

One parameter at 0% schema description coverage, so the schema contributes only a type and required flag. The description says "one configured broker", not which identifier format is expected or that broker_id comes from list_brokers, so it does not 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?

A specific verb ("Get") and resource ("capabilities of one configured broker") that clearly reads as a single-broker detail lookup, distinguishing it from the list_* siblings. It stops short of 5 because "capabilities" is never defined (order types? asset classes? feature flags?), leaving the agent to guess what comes back.

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 call this versus alternatives such as list_brokers, get_policy, or get_portfolio_summary, and no prerequisite noted. The only implicit hint is "configured broker", which suggests a broker_id obtained elsewhere, but that is inference, not 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, the description carries the full behavioral burden. It discloses that the operation is a read and that behavior differs by broker, which is useful context. It does not cover permissions, authentication requirements, rate limits, or other operational constraints.

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 two short sentences with no wasted text. The core purpose is front-loaded, followed by the broker-specific distinction.

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 tool has an output schema, so return-value details are not needed in the description. The description covers the basic purpose and broker nuance, but for a tool with no annotations and an undocumented required parameter, it lacks enough guidance on when to use this versus get_positions and what broker_id should contain.

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 one required parameter, broker_id, with 0% description coverage. The description mentions Alpaca and Kite, implying broker-specific behavior tied to broker_id, but it does not name the parameter, explain accepted values, or clarify how broker_id maps to those brokers.

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 ('Read holdings') and clarifies broker-specific semantics: Alpaca holdings alias positions, while Kite holdings are a separate view. This helps distinguish the tool from the sibling get_positions, though the distinction is indirect rather than an explicit 'use this instead of get_positions' statement.

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 through the broker-specific note: Alpaca holdings alias positions and Kite holdings are separate. However, it does not explicitly say when to call get_holdings versus get_positions, nor does it state prerequisites or exclusions.

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 load and does the most important job: it corrects the expectation set by the name 'get_order_status', clarifying that only sandbox-local state is returned and live broker status is unavailable. 'Read' also conveys non-mutation. It omits error behavior for unknown or non-local order_ids, which keeps it out of the top band.

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 with zero redundancy, and the capability statement is front-loaded ahead of the limitation. Every clause carries information an agent needs.

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?

An output schema exists, so return-value explanation is unnecessary, and with one trivial parameter the description covers the main risk: mistaking this for live broker status. Missing are error/empty-result behavior and order_id validity, minor for a single-argument read.

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 lone order_id field is undocumented, and the description does not define its format. It does implicitly narrow the meaning to a local sandbox identifier rather than a broker id, which is meaningful but thin compensation 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?

'Read one local sandbox order' gives a specific verb (Read), a specific cardinality (one), and a scoped resource (local sandbox order), which cleanly separates it from list_orders. It stops short of naming that sibling outright, so the distinction is inferred 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?

'External broker status lookup is not implemented' is a genuine exclusion that tells the agent this is not a route to live broker state. However, there is no positive guidance on when to pick this over list_orders or how to obtain a valid order_id, so usage is only implied.

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 that the operation is a read and that policy changes are out of scope, but it does not cover authorization needs, whether values are live or cached, 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?

Two short sentences, with the primary read behavior front-loaded and the change restriction immediately after. Every sentence adds value.

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 zero-parameter read tool with an output schema, the description covers the essential purpose and scope. The remaining gaps around return semantics are mitigated by the output schema, though more detail on halt-state meaning would help.

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 zero-parameter tools is 4.

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 uses a specific verb and resource: it reads local paper limits and halt state. This is clear enough to distinguish it from most siblings, but it does not explicitly contrast itself with similar tools such as get_capabilities or kill_switch.

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 sentence 'Policy changes require the local CLI' usefully signals that this tool is not for modification, but it does not state when to use get_policy versus alternatives like get_capabilities or kill_switch. Usage is therefore only implied.

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 behavioral burden. It usefully discloses that results are separate by currency and that no FX conversion or netting occurs, but it does not state read-only safety, permission requirements, or other operational constraints.

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 sentence that front-loads the core operation and adds the key no-FX/no-netting qualifier. No wasted wording.

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 an output schema, the description covers the essential behavioral nuance. It could be more complete by situating the tool against get_positions/get_holdings and stating the read-only nature explicitly.

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. The baseline for a zero-parameter tool is 4.

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 read operation over broker position snapshots and clarifies the per-currency scope. It is clear what the tool does, though it does not explicitly distinguish itself from siblings like get_positions or get_holdings.

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 implies usage for per-currency snapshots without FX conversion or netting, but gives no explicit when-to-use guidance or comparison to the closely related position/holding 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?

With no annotations, the description carries the full behavioral burden. 'Read' clearly signals a read-only operation and the reconciliation warning adds useful domain context, but permissions, freshness, and other operational traits remain undisclosed.

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 two short, front-loaded sentences with no filler. The phrase 'this collection' is slightly ambiguous, but otherwise it is efficiently structured.

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 an output schema, the description covers the basic purpose and a key reconciliation caveat. It is still missing guidance on sibling alternatives and parameter meaning, which leaves it 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?

There is one required parameter, broker_id, and schema description coverage is 0%. The description does not mention the parameter at all, so it fails to compensate for the schema gap, though the name itself is relatively self-explanatory.

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: 'Read broker positions.' That is enough to distinguish it from most siblings, though it does not explicitly contrast with get_holdings or get_portfolio_summary.

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 warning 'Do not add this collection to holdings without reconciliation' provides a usage constraint, but it does not explain when to call this tool instead of get_holdings or how the two relate operationally.

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 behavioral burden, and it does disclose that paper quotes are fixed synthetic fixtures. It also makes clear this is a read operation, but it omits permission requirements, rate limits, and how broker_id affects whether real or paper quotes are returned.

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 two compact sentences with no wasted wording. The core purpose is front-loaded, followed immediately by an important behavioral note about paper quotes.

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 output schema covers return values, and the tool is simple with only two required parameters. However, the lack of broker_id explanation and absence of annotations or usage guidance means the description is only minimally complete for correct 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%, so the description should compensate, but it only indirectly explains symbols as canonical equity symbols. The required broker_id parameter is not explained at all, leaving a significant semantic 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?

The description states a specific verb and resource: read quotes for canonical equity symbols. It is clear what the tool does, but it does not explicitly differentiate from siblings or clarify how broker_id scopes the quote lookup.

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 guidance on when to use this tool, when not to, or which alternative tools might apply. The read-quote purpose implies usage, but the description provides no routing context among the many broker/account/order siblings.

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 add real value: it discloses persistence and scopes the blast radius (existing orders and brokers untouched). It does not say whether the block is reversible, how it is lifted, whether it is global or per-account, or what authorization is needed — significant gaps for a state-changing safety control.

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 positive effect front-loaded and the non-effects immediately after. 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 zero-argument tool with an output schema, the description covers effect, persistence, and blast radius, which is most of what an agent needs. The missing piece is the reversal path — nothing tells the agent how the block is undone or whether it is permanent.

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. The description's 'local paper orders' wording at least frames what the no-argument call targets.

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 (block) plus a precise resource and scope (new local paper orders) and adds the qualifier 'persistently'. It explicitly distinguishes itself from cancel_order by saying it does not cancel orders, so an agent can separate it from the sibling set without opening a 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?

The negatives ('does not cancel orders or affect brokers') route the agent away from cancel_order and toward this tool when the goal is halting new order creation. There is no explicit statement of when to prefer it (e.g., emergency halt vs. routine maintenance) or of any prerequisites.

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 indicates a read operation and notes that balance types are labelled separately, but it omits permissions, rate limits, pagination, and other operational 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?

The description is a single short sentence with the core verb-resource statement front-loaded. There is no redundant or wasted text, and the extra clause about balance labels is useful.

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?

An output schema exists, so return values need not be fully explained. However, with no annotations and an undocumented required broker_id, the description is not complete enough for an agent to confidently determine scope, prerequisites, or parameter meaning.

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 one required parameter, broker_id, with 0% description coverage. The description never mentions broker_id or explains its meaning, format, or required status, so it adds no parameter semantics at all.

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: 'Read accounts'. It also clarifies that synthetic, broker-paper and live balances are labelled separately, which adds useful scope. However, it does not explicitly distinguish this tool from sibling read tools such as list_brokers or get_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?

The description implies usage by saying 'Read accounts', but it provides no explicit when-to-use guidance, no exclusions, and no alternatives compared with sibling tools. It also does not state any prerequisites such as needing a broker_id.

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 burden, but a zero-parameter enumeration tool has little behavior to disclose. It states what is enumerated, but says nothing about ordering, whether a default/active broker is marked, or whether the list can be empty or require authentication.

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 naming the resource first and its returned attributes second, with zero filler. It is terse to the point of being a fragment, but 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?

With zero parameters and an output schema present, the description needn't explain return values, so what remains is sufficient to call the tool correctly. The only real gap is the unresolved overlap with get_capabilities.

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 no parameters, so the schema-coverage baseline of 4 applies; there is nothing for the description to disambiguate. It correctly avoids inventing filter options that the empty schema does not support.

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 'List' plus a precise resource ('configured brokers'), and it names the returned fields (supported markets, capability flags) so the agent knows what it reveals. It does not distinguish itself from the sibling get_capabilities, which could plausibly return overlapping capability data.

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 only implied by the 'list' verb – an agent can infer this is a discovery call to run before broker-specific operations. There is no explicit when-to-use statement and no guidance on how this differs from get_capabilities, which is the one ambiguity worth resolving.

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 meaningful behavioral scope differences per source — Alpaca returns only open orders while Kite returns a current-day order book — but says nothing about ordering, limits, pagination, or auth requirements.

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. It is efficient, though it spends its words on source enumeration rather than on the disambiguation an agent would find more useful.

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?

An output schema exists, so return values need not be explained, and the tool is a simple zero-required-parameter read. Still, with no annotations and 0% parameter coverage, the description should have spelled out the broker_id value set and default to be fully callable without guessing.

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 single broker_id parameter has no enum in the schema. The description partially compensates by naming the three order sources, but does not enumerate the actual accepted values (paper/alpaca/kite) or note that 'paper' is the default.

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 (read/list) and resource (orders), and enumerates the three distinct order sources it can return. It is distinguishable from get_order_status by being a listing operation, though the description never explicitly contrasts the two.

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 three sources imply that source selection is the key decision, but there is no explicit when-to-use guidance, no mention of when to prefer get_order_status over list_orders, and no statement of which broker_id values map to which source.

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 order is 'synthetic' (nothing real is executed) and that the token 'expires', both non-obvious traits. It omits the TTL, whether the call is idempotent-side-effect-free, and what invalidation looks like, leaving real gaps.

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; every clause (validate, synthetic, BUY limit, expiring token) carries 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 output schema covers the return token, so return values needn't be described, and the synthetic/expiring behavior is stated. But for an unannotated, undocumented-parameter tool, the description leaves idempotency_key and the confirm_order handoff unexplained, which is not enough to invoke confidently.

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 six nested OrderRequest fields are undocumented. The description only implicitly covers side=buy and limit_price; symbol format, quantity limits, broker_id='paper', and especially idempotency_key semantics are left entirely unexplained.

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 ('Validate') plus a precise resource ('synthetic BUY limit order') and states the artifact returned ('expiring confirmation token'). That distinguishes it from the write-side sibling confirm_order, though it never names that 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 two-step intent (validate, then use the token) is implied by 'confirmation token' but never spelled out, and confirm_order is not named as the follow-up. No when-not-to-use or prerequisites are given, so the agent must infer the flow.

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