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

With no annotations, the description carries the full behavioral burden; it does add one genuine detail — that P&L excludes flows — which is real context beyond structured fields. However, it says nothing about whether the summary is a point-in-time snapshot, whether the call is read-only, or any rate/permission constraints, leaving the safety profile unstated.

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 fragment with zero filler, and the most decision-relevant item (equity, P&L) is front-loaded. It is arguably under-specified rather than bloated, which is a different flaw already captured elsewhere.

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 a zero-param read tool needs little documentation. Still, in a trading-agent toolset with siblings covering limits, approvals and order status, the description should say what question this tool answers and when to prefer it, which it does not.

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 schema baseline of 4 applies and there is nothing for the description to compensate for. No parameter meaning is lost.

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 noun phrase enumerating returned data (equity, day P&L, positions, open orders, agent budget) rather than a verb+resource statement. It implies a read-only account snapshot and is roughly consistent with the name account_summary, but it never states the action, and offers nothing to distinguish it from siblings like policy_limits or order_status.

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 says whether this should be called before preview_order/submit_order, or how it relates to policy_limits and order_status. The agent must infer usage purely from the listed fields.

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 it does add real value by enumerating the state machine outcomes (pending, approved, rejected, expired, executed, failed), which implicitly tells the agent that pending is non-terminal and the others are terminal. It does not state that the operation is a read-only lookup, whether the result can change on re-poll, or what happens for an unknown or expired approval_id.

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 short sentence, front-loaded with the resource and immediately followed by the value list. Every word earns its place; nothing is padded or repeated from the title.

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 is simple, and the presence of an output schema removes the need to explain return values, so the short description is close to sufficient. It still leaves the agent without a source for approval_id and without confirmation that this is a non-mutating lookup.

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 parameter approval_id has 0% schema description coverage and the description says nothing about it — not its format, nor where the agent obtains it (e.g. from a prior submit response). With low schema coverage the description was expected to compensate, and it does not.

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 the exact information returned ('state of a queued approval') and enumerates the possible values, so an agent can tell this is a status lookup rather than a mutation like submit_order or cancel_order. It lacks an explicit verb (e.g. 'returns'/'checks') and never mentions the sibling order_status, so differentiation is implied by the resource name 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?

There is no when-to-use guidance: nothing says to call this after submitting an approval, to poll while status is pending, or when to prefer order_status or get_quote instead. The only usage hint is implicit in the word 'queued'.

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 does disclose two useful behaviors: an authorization-like ownership restriction (same client name) and a cascading effect on resting children. It does not say whether cancellation is irreversible, what happens to partially filled intent, what error occurs if the intent belongs to another client, or whether the call is idempotent — significant gaps for a destructive 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?

A single tight sentence with the ownership constraint front-loaded and no filler. Slightly undermined by unexplained internal jargon ('resting children') that costs an agent a beat to interpret.

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 described, but for an unannotated destructive mutation the description is thin: no irreversibility, failure modes, or idempotency, and it leaves the sole required parameter undefined.

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 parameter with 0% schema description coverage, so the description must compensate. It refers to 'an intent' generically but never explains what intent_id is, its format, or where the agent obtains it, leaving the only required argument undocumented in both places.

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 an intent and its resting children, with the scope qualifier that only intents created by this agent (same client name) qualify. That ownership qualifier helps separate it from kill_switch, though the description never names the sibling or clarifies the jargon 'resting children'.

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 ownership constraint (this is for your own intents, not everything), but there is no explicit when-to-use vs. when-not, and no pointer to alternatives such as kill_switch for a global stop or order_status for checking what remains.

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 supplied, so the description carries the burden, and it does add real context: data age signals staleness and 'within the policy band' implies the returned depth is filtered by policy limits. However, it never states that the call is a read-only operation, what happens when the coin is not agent-allowed, or any rate/latency characteristics.

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 dense sentence that front-loads the returned fields and ends with the scoping constraint; nothing is redundant. As a sentence fragment it reads slightly terse, but every clause 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?

An output schema exists, so return field semantics are already covered, and the tool takes only one parameter. What remains missing is the accepted coin identifier format and the failure mode for disallowed coins, which for a pre-trade pricing call an agent will likely hit.

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% for the single 'coin' parameter, so the description should clarify identifier format. 'Agent-allowed coin' usefully hints at a whitelist constraint on valid values, but it does not say whether a symbol, exchange-qualified pair, or internal ID 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?

The description names concrete data fields (top of book, mid, data age, depth) so the agent knows exactly what is returned, and 'for an agent-allowed coin' scopes the resource. It stops short of an explicit verb and does not distinguish itself from preview_order, which plausibly returns overlapping pricing 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?

There is no when-to-use guidance, no mention of prerequisites, and no comparison to siblings such as preview_order or policy_limits. The agent must infer that this is a pre-trade read rather than a validation step.

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 disclose the two facts that matter most: the action is destructive (cancels resting orders) and irreversible for agents (cannot be switched off). It omits the blast radius — whether it is account-wide or global — and whether open positions or fills are affected.

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, front-loaded with the effect and followed by the constraint. Every clause adds information and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the core effect and irreversibility are covered. For an irreversible destructive halt with no annotations, however, the description leaves out scope, human override, and what exactly 'resting ones' covers.

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 needs to explain the single required 'reason' parameter, and it says nothing about it. The name is largely self-explanatory, which prevents a 1, but there is no guidance on format, whether it is logged, or why it is required for an already-irreversible action.

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 plus resource and scope: 'Stop all new orders and cancel resting ones.' That clearly separates it from the single-order sibling cancel_order and from submit_order, even though no sibling is named 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?

'Agents can turn it on, never off' is a strong implicit warning that this is a last-resort action, which guides usage. But it never states the conditions that should trigger it versus cancel_order for a single order, nor any prerequisite such as approval_status or policy_limits checks.

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 supplied, so the description carries the full burden: it never states that this is a read-only lookup, whether results are live or cached, or what happens with an unknown intent_id. The enumerated fields largely restate what the existing output schema already documents, so little behavioral context is added.

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 no padding, which is appropriately sized. However, it is a verbless fragment dense with domain jargon ('cost vs arrival mid', 'block reasons') that an unfamiliar agent cannot parse quickly.

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 is simple (one param) and has an output schema, so return values need not be explained. Still, with zero annotations and zero parameter documentation, the definition should say more about read-only semantics, data freshness, and overlap with approval_status.

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 intent_id, and the description only implies the linkage via 'of an intent'. It does not say where an intent_id comes from, whether order/transaction IDs are also accepted, or what 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?

The description is a noun-phrase list of returned fields ('Fill progress, average price, cost vs arrival mid, fees and block reasons') with no verb, so the agent must infer that this reads status for an intent. The scope cue 'of an intent' is useful, but nothing distinguishes it from the close sibling approval_status. Purpose is inferable but not 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?

There is no when-to-use guidance, no prerequisites (e.g., an intent_id must already exist from preview_order/submit_order), and no routing to alternatives such as approval_status or get_quote. The agent is left to guess the call site from the name alone.

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 supplied, the description carries the full burden and does declare the key safety trait: this is a read-only, non-mutating view. It also discloses the exact content returned (limits, thresholds, fees) rather than being a bare tautology, though it says nothing about permissions, rate limits, or whether limits are account-specific.

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 mode (read-only) and the resource set are packed in without waste.

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 no explanation, and with zero input parameters the description only needs to convey purpose and safety — both of which it does. Nothing an agent needs before calling 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 tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description does not need to compensate for any schema gaps.

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 ('Read-only view') and enumerates the exact resources exposed: policy limits, agent thresholds, and builder fee. This clearly distinguishes it from siblings like account_summary or approval_status, 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?

Usage is only implied — an agent can infer this is the place to look up limits before submitting or previewing an order, but the description never states when to call it versus account_summary or approval_status, nor any 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 supplied, the description carries the full behavioral burden and does disclose the key trait: it sends nothing. It also says the response includes planned child orders, policy decisions, fee bound, and whether human approval is required, though it omits auth or rate-limit details.

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 front-loaded with the core purpose and then gives compact parameter hints. Every sentence carries useful information, with no filler or repetition.

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 exists, so return-value explanation is not strictly required, and the description does state the high-level preview contents. Still, for a complex 12-parameter trading tool with no annotations and zero schema descriptions, the description leaves substantial parameter and interaction detail unaddressed.

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 12 parameters, and the description only explains side values, algo values, and that size is in base units. It adds important enum and unit information missing from the schema, but leaves nine parameters such as slices, limit_px, pov_rate, duration_s, and max_slippage_bps undocumented beyond their titles.

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 phrase, 'Dry run,' with the resource 'order,' and explicitly lists the preview outputs: planned child orders, policy decisions, fee bound, and human-approval need. It distinguishes itself from submit_order by stating 'Sends nothing,' so an agent can select it without ambiguity.

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 'Dry run' framing and 'Sends nothing' clearly imply this is the safe preview path to use before submit_order. However, the description does not explicitly name submit_order as the alternative or state any conditions for when not to use the preview.

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

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

With no annotations, the description carries the full burden and does well: it discloses the approval-threshold and daily-budget queueing behavior, the existence of human approval, and the idempotency model including the 'duplicate' status and 'ag-<client_intent_id>' id format. It leaves out permission/auth requirements, whether orders are live or simulated, and 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?

The queueing/approval consequence is front-loaded, followed by the idempotency contract, with no filler sentences. The indentation is cosmetic noise but the content is dense and every clause conveys a distinct rule.

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 means return shape needn't be explained, and the approval and duplicate-response behaviors are covered well. But for a 13-parameter mutation with zero schema descriptions and no annotations, the description is not complete enough: an agent still cannot tell what units size is in, what algo/slices/pov_rate do, or how limit_px vs post_only interact.

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 13 parameters, and the description only documents client_intent_id (format constraints plus retry semantics). Core trading parameters like coin, side, size, algo, slices, pov_rate, limit_px, post_only, reduce_only and max_slippage_bps get no explanation at all, so the biggest gap in the definition remains 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?

Opens with a specific verb and resource ('Submit an intent') and immediately explains the queuing outcome, so an agent understands this places an order intent. It names approval_status as the follow-up tool, though it never distinguishes itself from preview_order or get_quote, leaving sibling routing partly 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?

Gives explicit operational guidance: check a returned approval_id with approval_status, always supply a fresh client_intent_id, and reuse that id on retry after a timeout or error. What is missing is when to prefer preview_order or get_quote before calling this, so it stops short of full when/when-not coverage.

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