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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses the mutation, protected/disabled-by-default status, whole-adjustment refusal cases, bound-as-policy-outcome behavior, no-op non-recording, duplicate id conflict, reserved id prefixes, and operator-vs-agent differences. This is unusually detailed disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the description is an extremely dense, semicolon-heavy paragraph that is difficult to parse. Much of the content is substantive, yet the run-on structure reduces readability and would benefit from tighter organization.

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

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

Given a complex nested mutation tool with no annotations and an output schema already present, the description is sufficiently complete. It covers mutation scope, refusal cases, policy-bound outcomes, no-op behavior, default protection, and return expectations without needing to restate output fields.

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 already 100%, so the schema does most parameter documentation work. The description still adds meaning beyond the schema, notably the agent-only lowering constraint, the exact-decimal-string expectation, bound semantics as applying to resulting values rather than changes, and the special realizedPnl and averageEntryPrice restrictions.

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: apply an adjustment to an account's balances of one asset through the engine and return the recorded adjustment. It does not explicitly differentiate this tool from adjacent mutation tools like update_account, but the purpose is clear from the first clause.

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 sets explicit usage constraints: an agent may only lower available, held and incoming balances of the account's own currency, and it lists many refusal conditions. It does not name alternative tools or say when another mutation tool should be used instead, so it stops short of full alternative 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?

With no annotations, the description carries the full burden and does deliver real behavioral context: the order must be untouched, the operation is protected and disabled by default, and the SDK uses the order's own recorded reservation remainder rather than the caller's value. It stops short of stating what happens to holds/reservations on success, what errors arise on a touched order, or the auth requirements behind 'protected'.

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 core purpose is front-loaded, but the body is a single dense run-on of internal terminology ('signed hold approval Officer', 'SDK receives the order's own recorded reservation remainder') that requires re-reading. The important gating fact, 'Protected and disabled by default', is buried in the final clause instead of being surfaced early.

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 3-parameter mutation tool with no annotations, the description covers preconditions, the confusing leavesQuantity semantics, and the availability gate, and an output schema exists so return values need not be explained. It leaves gaps on failure modes for non-untouched orders and on what 'protected' requires operationally, but an agent has enough to decide whether to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all three parameters are already documented — and the schema text for leavesQuantity is nearly verbatim the description text, so little new meaning is added. The description does clarify the caller-reported vs SDK-recorded distinction, but that same clarification already appears in the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Cancel') and resource ('workflow order') plus a precondition ('untouched') that separates it from check_order/confirm_execution/report_fill siblings. The qualifier 'from the signed hold approval Officer recorded at submit' is domain jargon that an unfamiliar agent cannot decode, so the purpose is clear but the scope is not fully self-explanatory.

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?

'Cancel an untouched ... order' implies the when (order exists but has not been touched), and 'After execution-report activity, submit an explicit report' implies a boundary with report_fill, but neither names a sibling tool nor states an explicit exclusion. 'Protected and disabled by default' hints at an availability gate without explaining how to satisfy it. Usage is inferable but not directed.

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

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

With no annotations present the description carries the full burden and does so: it declares the operation non-mutating, enumerates what does not happen (no order placed, no funds reserved), and describes the response shape for both pass (would-be lock prices) and reject (structured rejects, possible account block).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the dry-run nature and non-mutation guarantee front-loaded before the result detail. Every clause contributes either scope or outcome 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?

For a 7-parameter validation tool with a full output schema, the description supplies the one thing structured fields cannot: the no-side-effects guarantee and the pass/reject result semantics. Nothing needed to call it correctly 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?

Schema description coverage is 100%, so every parameter is already documented, and the description adds no parameter-level meaning beyond the order concept and the implication that a limit price drives lock-price estimates. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('run a non-mutating pre-trade dry-run for an order') plus the exact output content (pass/fail, lock prices, structured rejects). The closing clause 'no order is placed, no funds are reserved' implicitly separates it from the submit/send siblings without needing to name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly frames the context of use: validate an order before actually sending it, with the explicit exclusion that nothing is submitted. It never names the alternative tools (submit_order, send_live_order, send_paper_order) an agent should pick when it does want execution, so the routing is inferred rather than stated.

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 does carry useful safety context by declaring the operation read-only and that credentials are never exposed — an important disclosure for a trading system. However, it says nothing about what happens with an invalid or disabled connection, what 'status' values can be returned, or any permission 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?

Two short sentences with the purpose first and the safety caveat second; no filler and nothing an agent must wade through.

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, and the read-only/no-credential-exposure note covers the main behavioral concern. The only real gap is the absence of guidance on error or invalid-connection behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'connection' parameter is documented in the schema as 'Trading connection id'. The description adds no further syntax, format, or sourcing detail beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb ('Check') and resource ('trading connection') plus the exact attributes inspected: venue identity and status. That clearly separates it from mutating siblings like update_trading_connection or set_trading_connection_enabled, though it never names a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no stated when-to-use guidance, no prerequisites, and no mention of alternatives such as get_trading or list_trading_destinations. The agent must infer that this is for validating a single connection by ID from the imperative verb 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, the description carries the full burden and does well: it discloses the refusal error code (loosening_refused), the consequence (changes where future venue fees are debited), and the governance posture (mutates Officer control-plane config, protected and disabled by default). It stops short of saying what the resulting state is or how to enable the operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences with the core action front-loaded and no filler. The middle clause ('The clear is refused with loosening_refused, as it moves where future venue fees are debited') is slightly tangled in phrasing but carries real 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?

Output schema exists, so return values need not be explained, and the single required param is fully documented in the schema. The description supplies the safety and refusal context an agent needs for a protected, disabled-by-default mutation. It could say more about what state remains after a successful clear.

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?

Single parameter with 100% schema description coverage ('Trading connection id'), so the schema already does the work. The description adds no meaning about the connection parameter or its scope, which is acceptable at high coverage but earns no extra credit.

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 (clear) and a specific resource (the Officer account receiving unlinked venue fees), which is enough to distinguish it from generic account tools. It does not explicitly name the inverse sibling set_trading_fee_account, so the pairing must be inferred from the shared 'trading_fee_account' naming.

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 rather than stated: the agent learns the operation undoes fee-account linkage, and that it will be refused with loosening_refused. There is no explicit 'use this instead of X when Y' guidance and no statement of prerequisites the caller must satisfy before the call can succeed.

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

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

With no annotations, the description carries the full burden, and it does disclose two real traits: the tool is disabled/protected by default and is rejected once execution-report activity exists. Those are useful operational facts, but the prerequisite ('signed hold approval Officer... at submit') is ungrammatical and the failure mode is described only obliquely.

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?

Only two sentences, but they are dense with ungrammatical, non-actionable fragments ('from the signed hold approval Officer recorded at submit') and the more decision-relevant fact — disabled by default — is buried at the end.

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

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

For a one-parameter tool with an output schema present, the description need not explain return values, and the id documentation is complete. It also flags the enablement/state constraints an agent would otherwise miss, so nothing critical to calling it correctly is absent — though clarity of the phrasing is the weak point, scored elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter already documents itself as 'Order id returned by submit_order'. The description's mention of submit does not add syntax, format, or validation detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause gives a verb and resource ('Record confirmation history for a workflow order'), which is more than a tautology, but the trailing modifiers ('from the signed hold approval Officer recorded at submit') are garbled and don't resolve what a 'workflow order' is. Nothing in the text distinguishes it from siblings like submit_order or check_order, and an agent would need to infer that this is a post-submission bookkeeping step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit statement of when to call this instead of submit_order, check_order, or get_order. The fragments 'rejected after execution-report activity' and 'protected and disabled by default' hint at preconditions but are too cryptic to act on reliably, leaving the agent to guess at sequencing.

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 so well: it discloses currency inheritance chain, the no-tier/no-P&L rule, the specific refusal error (loosening_refused) and its rationale, and that the operation mutates Officer control-plane config and is protected/disabled by default. It stops short of stating required permissions or reversibility, so 4 not 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause and every subsequent sentence adds behavioral information (inheritance, refusal, mutation/protection). The prose is dense and slightly run-on but not wasteful.

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 needn't be explained, and the description covers the mutation/refusal/default-disabled semantics thoroughly. The main remaining gap is authorization requirements for a protected, disabled-by-default control-plane mutation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description restates the currency inheritance semantics already present in the schema and adds little new parameter-level detail beyond what the schema documents.

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 opens with a specific verb and resource ('Create an account') and enumerates the inputs (code, optional title, optional currency), so the agent knows exactly what it produces. It does not explicitly contrast itself with siblings like create_group or update_account, keeping it at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the verb and the mention of inheritance/refusal behavior, but the description never states when to prefer this over update_account or create_group, nor any preconditions for calling it. Guidance is inferable but not explicit.

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 zero annotations, the description carries the full burden, and it does disclose two meaningful traits: this mutates control-plane config and the tool is protected/disabled by default. It stops short of saying what that means in practice — whether the call errors, requires enabling first, or needs specific permissions — and says nothing about duplicate-code behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the creation semantics first and the operational caveat second. Nothing is redundant or 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 and the parameters are fully documented, so the remaining gaps are behavioral. For a mutation tool with no annotations, the description should clarify the practical impact of "protected and disabled by default" and how failure modes surface, which it leaves ambiguous.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all three parameters are already documented in the schema, including the "omitted leaves untitled/unclassified" behavior. The description mirrors that and adds only the mild constraint that assetClass must reference an existing class, so it adds little beyond the structured data.

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 ("Create an asset") and enumerates the three inputs it accepts, so the agent knows exactly what gets produced. It does not explicitly differentiate itself from update_asset or delete_asset, relying on the name alone for that distinction.

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 call this versus update_asset (e.g., if the asset may already exist) or what prerequisites are needed. The sentence about being "protected and disabled by default" hints at a constraint but never says what the caller should do about it.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the tool mutates Officer control-plane config, is protected and disabled by default, rejects the reserved '-' code with validation, and explains currency inheritance behavior. It does not mention auth requirements, rate limits, or response behavior, but the output schema covers returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and stays to four sentences. It is efficient, though the reserved-code sentence partially repeats the schema description and could be tightened.

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

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

Given four parameters, full schema coverage, and an output schema, the description is largely complete. It covers mutation semantics, protection defaults, validation, and inheritance, though it lacks explicit guidance on choosing this tool over update_group.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: the currency inheritance chain ('inherits the group's, then the default group's') and the validation refusal for the reserved code.

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 opens with a specific verb and resource: 'Create an account group', then enumerates the creatable fields. This clearly distinguishes it from sibling tools like update_group, delete_group, and list_groups.

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 'Create', and the description notes the tool mutates control-plane config and is protected/disabled by default. However, it never explicitly says when to use this instead of update_group, nor does it state prerequisites or required permissions.

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 meaningful work: it discloses that credentials are write-only, that the operation mutates control-plane config, and that a create may be refused with the specific error code loosening_refused because it widens outbound capability. Ambiguity remains around 'protected and disabled by default' – unclear whether the tool, the connection, or both are disabled – which conflicts with the required 'enabled' parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with the core action front-loaded and no filler. The middle sentence ('The create is refused with loosening_refused, as a new connection widens what can be sent') is grammatically awkward and slightly harder to parse than necessary.

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 and the params are fully documented, so the main missing piece is prerequisite/permission context and disambiguation of 'disabled by default' versus the required 'enabled' flag. For a mutation tool with no annotations, that gap matters more than it would elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and already documents provider values, credential shapes per provider, and mode. The description only restates 'write-only credentials', adding essentially no parameter semantics beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Create a trading connection'. It distinguishes itself from update_trading_connection by being the creation path and adds that credentials are write-only, but it doesn't explicitly contrast with the sibling update/set_trading_connection_enabled tools.

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 explicit when-to-use or when-not guidance, and no mention of the obvious alternative (update_trading_connection) for an existing connection. The 'protected and disabled by default' note hints at prerequisites but leaves the agent to infer them.

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 so well: it discloses that the tool mutates Officer control-plane config, is protected and disabled by default, names the exact refusal codes, and warns that force-deleting strips venue-fee adjustments so fees may be rebooked on restart. That is precisely the destructive side-effect an agent needs before calling.

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?

Front-loaded with the action, which is good, but the middle sentence is a dense run-on enumerating barrier types and refusal codes, and the force/rebooking content overlaps heavily with the force parameter description. Every clause is informative, yet readability and non-redundancy suffer.

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 no explanation, and the description covers refusals, force semantics, and side effects thoroughly for a two-parameter mutation. It stops short of explaining what 'protected' means operationally or how protection is lifted, which would close the last gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the force parameter already documents dependents, venue-fee adjustments, and barrier refusals in detail. The description largely restates that, adding only the 'conflict' refusal for a trading connection's fee account beyond what the schema says. Baseline 3 for a fully documented schema.

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 precise verb+resource ('Delete an account') and immediately scopes it as a control-plane mutation. It never names a sibling, but the operation is distinct enough from delete_group/delete_asset/update_account that confusion is unlikely. Clear, though not explicitly differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Lays out concrete conditions of use: dependents require force, a trading connection's fee account is always refused, and a long list of barrier/rate-limit/blocked states cause loosening_refused even with force. It gives no positive guidance on alternatives (e.g., clearing a barrier first), so it is strong context without full 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?

With no annotations, the description carries the full burden and does so well: it discloses that the tool mutates Officer control-plane config, is protected and disabled by default, that force is unconditionally refused for agents, and that a forced delete would cascade through balances, orders, trades, adjustments, barriers and referencing market-data/trading instruments. It also names the two concrete error signals, has_dependents and loosening_refused.

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 purpose is front-loaded in three words, but the remainder is a pair of long, hard-to-parse clauses ("The delete is refused with loosening_refused while a rate-limit or order-size barrier references the asset or a Spot Funds P&L bound is denominated in it"). The content earns its place but the packaging makes conditions difficult to extract.

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 mutation tool with no annotations, the description covers cascade semantics, refusal reasons and the protection/disabled state, and an output schema exists so return values need no explanation. What is thin is the authorization model and the recovery path after a refusal (e.g. remove dependents first), which would round it out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description does explain what force would destroy, but that content is already fully duplicated in the force property's schema description, so it adds little beyond structured data; the asset parameter's meaning (asset code) is left entirely to the schema.

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?

"Delete an asset" gives a specific verb and resource that is unambiguously distinct from siblings such as update_asset, create_asset or delete_trading_instrument. The scope of the operation is further sharpened by naming the two refusal outcomes, but the description never explicitly contrasts itself with those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description spends its words on refusal conditions (has_dependents, loosening_refused), which implicitly tells the agent when this call will fail, and it warns that force is always refused for an agent. However, there is no explicit when-to-use framing, no prerequisites (permissions, enabled state) and no pointer to an alternative tool for the dependent-row case.

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 exist, so the description carries the full burden and does so well: it discloses that member accounts retain trading/compliance history, that trading access grants are deleted while members keep their own, the precise refusal semantics of force, and that the operation mutates Officer control-plane config and is protected/disabled by default. This is unusually rich for a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and keeps each sentence earning its place despite being dense. The force behavior is repeated between the body and the schema, a minor redundancy, but the paragraph remains coherent and purposeful.

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, unannotated operation the description covers consequences, refusal paths with error codes, scope of deleted grants, and default protection. An output schema exists so return values need not be explained; nothing essential 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?

Schema description coverage is 100%, so both parameters and the nuanced force semantics are already fully documented in the schema. The description largely restates the force behavior rather than adding parameter meaning beyond it, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delete an account group') immediately, and the surrounding sentences distinguish it from siblings like update_group, create_group, and list_groups by scoping it to destructive removal. An agent can tell exactly what this does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides strong when-not guidance: default group cannot be deleted, refusal conditions for blocked groups, P&L bounds, rate-limit barriers, and protected-state currency changes, each with named error codes. It lacks an explicit alternative pointer (e.g. 'use update_group to rename'), so it stops short of a 5.

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 reasonably well: it discloses that the call mutates 'Officer control-plane config', that it is protected and disabled by default, and names the refusal code loosening_refused along with the rationale (a mapping governs what can be sent and fee booking). This is substantive beyond what the schema offers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with the action front-loaded and the refusal/mutation caveats following. The clause about fee booking is slightly dense but earns its place by justifying the refusal behavior.

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 needn't be explained, and both params are fully documented in schema. The description supplies the key missing behavioral context (protected, disabled by default, refusal semantics). Only the enabling/auth path is left 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?

Schema coverage is 100%, with both `connection` and `externalSymbol` already documented, so the baseline is 3. The description adds no meaning about either parameter (e.g., how externalSymbol relates to the venue symbol or whether it must match an existing mapping).

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+resource: 'Delete a trading instrument mapping.' This is unambiguous and distinguishable from siblings like set_trading_instrument or delete_asset. It does not explicitly name a sibling, but the resource noun is precise enough that an agent won't confuse it.

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 hints at preconditions ('protected and disabled by default') and states the operation will be refused (loosening_refused), which implies the tool only succeeds under a specific configuration state. However, it never says when to use this versus set_trading_instrument or how to enable the protected operation, leaving the agent to infer usage.

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 disclosure burden and does so: declares read-only, states it exposes no secrets, and excludes order-flow control. The windowMs unit disclosure is a genuine behavioral detail an agent couldn't get elsewhere; only return-shape details are left implicit.

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 dense sentences, front-loaded with what is returned and immediately followed by the safety qualifier. The phrase "the fields set_limit takes" is slightly awkward but earns its place by anchoring the output shape.

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 and a fully-described single parameter mean the description needn't explain return values, and it still adds the read-only scope and unit semantics. Nothing essential to calling it correctly 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?

Schema coverage is 100% and the sole parameter "account" is already documented as an account code. The description adds nothing about the parameter itself, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Return account row and its account-scoped risk barriers") and clarifies the payload shape relative to set_limit. It does not distinguish itself from the sibling get_limits, so an agent comparing the two must still infer the difference.

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: the tie to set_limit suggests this is the read-before-write path, and "no order-flow control" hints at what it can't do. There is no explicit when-to-use, prerequisites, or contrast with get_limits.

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 usefully discloses that the tool is read-only, returns no secrets, and does not control order flow. It also states default and maximum result sizes. It does not mention permissions, ordering, or retention behavior, but the core safety profile is clear.

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 no wasted text. The main purpose and row limits are front-loaded, followed by the safety scope.

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 and fully described parameters, so the description need not explain return values. It covers the key scope, safety, and size constraints. Minor gaps around ordering or time range are acceptable given the structured schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents limit, account, and category. The description repeats the default and max limit but adds no additional meaning for account or category beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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: return recent control-plane audit entries. It also gives default and max row counts, making the operation concrete. It does not explicitly name sibling alternatives, but the control-plane scope helps distinguish it from order-flow tools.

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 this is for audit inspection and clarifies it is read-only with no secrets or order-flow control. However, it does not explicitly say when to use this versus related tools such as get_trading or list_orders, nor does it state exclusions beyond the control-plane scope.

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 must carry the behavioral burden, and it does the most important part: 'Read-only - credentials are never exposed' discloses both the non-mutating nature and the guarantee that no secret material is returned. It stops short of stating required permissions or what a negative finding looks like, but the safety profile is clear.

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 core check, followed by the safety guarantee. No filler or restatement of the tool name.

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

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

A zero-parameter, read-only diagnostic with an output schema that documents the return shape. The description supplies the purpose and the non-exposure guarantee, which is everything an agent needs to decide to call it.

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 has nothing to explain and the description needn't compensate. Baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Report') and a precise resource ('stored credentials ... sealed under the master key'), then narrows scope to trading connections and market-data sources holding plaintext keys. No sibling tool (health, get_audit) does this, and the description makes that distinction evident.

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 a security-posture check, but the description never says when to call it versus siblings like health or get_audit, 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 burden and does disclose the key traits: it is read-only, exposes no secrets, and cannot affect order flow. It also documents the time unit (windowMs in milliseconds). Missing are permission/auth requirements, but the safety profile is genuinely informative.

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, front-loaded with the resource and followed by the optional filter and safety note; nothing is padded. The clause 'each barrier has the fields set_limit takes, the rate window as windowMs in milliseconds' is slightly compressed but each part 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 and only one parameter is in play at full coverage, so the description need not enumerate return fields. It adds the conceptual shape of the result and the read-only guarantee, which is sufficient for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'account' parameter is already documented as an optional filter whose omission returns all barriers, so the description largely restates the schema. It adds no syntax or format detail for the account code itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: 'Return risk barriers and P&L-bound currencies'. Naming set_limit as the write counterpart gives implicit sibling differentiation, though it never directly contrasts with other read tools like get_account_state or get_spot_funds_limit_mode.

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?

'Optionally filtered by account; omit to return all barriers' gives a usage condition, and pairing the barrier fields with set_limit implies a read-before-write workflow. But there is no explicit statement of when to reach for this tool versus its many read 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 provided, the description carries the full burden and does well by stating that the tool is read-only, exposes no secrets, performs no order-flow control, and never exposes the opaque pre-trade lock. It does not mention error behavior for missing ids, permissions, or rate limits, but its safety and exposure disclosures are substantial.

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 and appropriately short for a simple retrieval tool. The final sentence slightly restates the display-price and hidden-lock point, but the content remains tightly focused.

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 the description need not explain return values in full. For a one-parameter read tool, it covers the key behavioral constraints and hidden-data guarantees, though it could mention missing-order behavior or access requirements.

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 and schema description coverage is 100%; the schema already says the id is 'Order id returned by submit_order.' The description adds only that the order is 'addressed by its id,' without extra format, validation, or sourcing detail beyond the schema.

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 action and resource: return one order by id, and it enumerates the returned parts (status, approval, fills with display prices). This clearly separates it from list-style siblings like list_orders, but it does not explicitly distinguish itself from check_order.

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 phrase 'addressed by its id.' The description does not say when an agent should choose get_order over list_orders or check_order, nor does it state any exclusions or 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?

With no annotations, the description carries the full burden and does substantial work: it defines both mode values (enforce refuses orders lacking funds; track_only records holds and permits negative balances), states the default is enforce when unset, and explains that P&L bounds, rate and order-size barriers apply in both modes. It also explicitly declares read-only scope. The only real gap is that it doesn't say what the caller needs in order to see 'visible' accounts (visibility/permission scoping).

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 purpose is front-loaded in the first sentence, which is good. But the middle section is a dense run-on that explains output fields (mode, stored, accountsWithoutCurrency) already covered by the output schema, so several clauses restate structured data rather than adding guidance.

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, an agent has everything needed to call it and interpret the response. The description goes beyond the minimum by explaining the operational meaning of each returned value, which compensates for the missing annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4. The description spends its length on return-value semantics rather than inputs, which is appropriate for a no-arg read.

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 opens with a specific verb and resource: 'Return the global Spot Funds limit mode and the accounts a Spot Funds P&L bound blocks for want of a currency.' That is clearly distinct from sibling tools like get_limits or set_limit. It stops short of explicitly naming the nearest sibling to disambiguate against, so it lands at 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the diagnostic framing and the closing note 'Read-only - no secrets, no order-flow control,' which tells an agent this is a safe inspection call. However, it never states when to prefer this over get_limits or when the mode would be changed via set_limit, 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?

With no annotations provided, the description carries the full burden and does disclose two meaningful traits: the operation is read-only and credentials are never exposed. It stops short of describing pagination, scoping, or whether all providers are always returned, but the safety profile is clearly 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?

Two short sentences with zero filler, and the core purpose is front-loaded ahead of the safety caveat. Every sentence earns its place.

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

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

An output schema exists, so return values need not be explained, and there are no parameters to document. The main remaining gap is that 'providers' and 'connections' are not distinguished, nor is this tool's relationship to the many connection-management siblings clarified.

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 and the baseline of 4 applies. The absence of parameters is consistent with a whole-collection read.

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 pair ('Read trading providers and connections'), so an agent immediately knows this is a read operation over trading provider/connection entities. It does not differentiate from nearby siblings such as check_trading_connection or get_credential_storage, which cover overlapping ground.

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 versus check_trading_connection, list_trading_destinations, or get_credential_storage. The only usage signal is the implicit 'read-only' framing, leaving the agent to infer selection 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, the description carries the full burden and does well: it declares the mutation ('mutates Officer control-plane config'), the refusal mode ('refused with loosening_refused, as it widens what can be sent'), and a safety posture ('protected and disabled by default'). It stops short of stating permission requirements or reversibility details, but the crucial guardrails are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action and target, then failure semantics, then safety posture. No repetition of the name and no wasted clauses.

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 explained. For a mutation tool with no annotations, the description covers what changes, the failure mode, and the protected/disabled default; only finer details like idempotency or required caller privileges are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents mutual exclusivity of account/accountGroup plus venueAccount. The description adds only the conditional context that account groups exist 'where the server offers' them, which is a minor supplement rather than new parameter semantics.

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 (grant access to a trading connection) and covers the alternate target (account group) explicitly. The scope ('Officer account access') distinguishes it cleanly from siblings like revoke_trading_access or set_trading_connection_enabled.

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 'where the server offers account groups' clause implies when to choose one mode over the other, and 'protected and disabled by default' hints at a prerequisite. However, there is no explicit statement of when to call this vs. revoke_trading_access or other config tools, 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?

With no annotations provided, the description carries the burden and does so for the most important traits: it declares the operation read-only, discloses that no secrets are exposed, and confirms no order-flow control is affected. It omits auth requirements and any cost/latency notes, but the safety profile an agent needs before calling is present.

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 no filler: the first front-loads the covered health dimensions, the second front-loads the safety guarantee. The enumerated field list earns its space because the agent cannot otherwise guess the scope.

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 parameter schema is empty. The remaining agent questions — is it safe, is it read-only, does it touch orders — are all answered in the second sentence.

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, which sets the baseline at 4. The description correctly implies a no-argument call and adds no misleading parameter claims.

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 ('Report Pit Officer deployment health') and then enumerates exactly what is covered: per-node engine version, build profile, liveness, store reachability, schema version and path. No sibling tool covers diagnostics, so an agent can route here unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Use is implied (a status/diagnostics call) but the description never says when to call it — e.g. before trading operations, when connections look unhealthy, or as a preflight check. It names no alternatives or exclusions, so the agent must infer the trigger condition.

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

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

With no annotations present, the description carries the full behavioral burden and does so well: it declares 'Read-only - no secrets, no order-flow control', explains paging defaults and caps, states that invalid values fail with a validation error, and clarifies the returned row shape. These are meaningful behavioral disclosures beyond the schema.

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 return shape and read-only guarantee, and nearly every clause carries information about filters, sorting, or paging. It is somewhat long and run-on as a single dense paragraph, but given 12 parameters and no annotations, the length is largely justified.

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 complex 12-parameter list/filter tool with 100% schema coverage and an output schema, the description supplies the missing operational context: read-only safety, row composition, filter semantics, sort columns, paging defaults/caps, and validation behavior. Nothing critical to correct invocation appears 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?

Schema description coverage is already 100%, but the description adds useful semantics beyond it: group empty-string behavior, code matching code or title, blockReason text matching, venue mode meanings, sortable columns, and total counting before paging. It does not fully explain every nested matching option such as code fragments/anchor fields, but that is already covered by the schema.

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: 'Return one page of accounts', and specifies the row shape as the REST account row joined with its group's block. This clearly distinguishes it from siblings such as get_account_state, list_groups, or create_account.

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 establishes the tool's read-only nature and enumerates the filtering, sorting, and paging surface, so an agent can infer it is the list/search tool for accounts. However, it does not explicitly say when to prefer this over get_account_state or list_groups, so usage guidance is clear but not exhaustive.

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 so well: it declares the tool read-only and explicitly safe (no secrets, no order-flow control), documents paging semantics (limit default 50, cap 500, 1-based page), explains that total counts pre-paging, notes the first-page default-group row that falls outside limit/total, and states that invalid values produce a validation error.

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?

Front-loaded with the return shape, then filters, sort, paging and error behavior in a logical order. It is dense and relies on semicolon-chained clauses, which costs some readability, but nearly every clause carries information the 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?

For a 10-parameter, zero-required, read-only list tool with an output schema, the description covers scope, filtering, sorting, paging edge cases and failure behavior. Since an output schema exists, it correctly does not spend words explaining return field structure beyond row identity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it enumerates the valid sort columns that the schema only gestures at ('one the tool description lists'), clarifies code matches code or title, and spells out the venue mode semantics including the omitted case. Remaining range/count fields are left to the schema.

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: 'Return one page of account groups,' and adds that each row is the group row of the REST group list. That makes it distinguishable from list_accounts, list_orders and the group mutators (create_group, update_group, delete_group) without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the filter/sort enumeration, but the description never says when to reach for this versus alternatives or states prerequisites/exclusions. There is no 'use this when...' routing sentence, so the agent must infer intent from the name and filters.

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

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

With no annotations provided, the description carries the full burden and does well: it declares the tool is read-only, states it exposes no secrets and performs no order-flow control, and specifies that invalid values fail with a validation error. It does not mention auth requirements or rate limits, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense but efficient single paragraph, front-loaded with the core purpose and read-only guarantee. Every sentence carries operational information, though the prose could be split into clearer filter/sort/paging sections for faster scanning.

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 13-parameter list tool with an output schema and no annotations, the description covers the key behavioral and filter semantics: paging, sorting, venue mode, validation failure, and read-only scope. Return-value details are correctly left to the output schema, though permission or rate-limit context is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema by consolidating filter semantics ('account (exact account code)', 'venue mode any/none/connection'), listing valid sort columns, and explaining paging defaults and caps. It is especially useful because the schema's sort.column description explicitly defers to 'the tool description' for allowed columns.

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: 'Return one page of orders' and clarifies that each row is 'the order row of the REST order list.' This distinguishes it from single-order siblings like get_order, but it never names a sibling explicitly, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the detailed filter list and the 'read-only - no secrets, no order-flow control' note, but there is no explicit statement of when to use this versus list_trades, get_order, or check_order. An agent can infer it is for filtered listing, but must infer the boundaries.

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

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

With no annotations provided, the description carries the burden well by declaring the tool read-only, stating that it exposes no secrets and has no order-flow control, and noting that invalid values fail with a validation error. It also describes paging defaults and the total count semantics, though it does not discuss authentication or 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 description is dense but appropriate for a 14-parameter list tool: it front-loads the return shape and read-only nature, then covers filters, sorting, and paging without obvious filler. Every sentence conveys operational information needed to invoke the tool correctly.

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

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

Given the absence of annotations, 14 parameters, and the existence of an output schema, the description is complete enough for an agent to call the tool confidently. It covers return paging, total counts before paging, filter semantics, sort columns, default and maximum limits, and validation failure behavior.

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?

Although schema coverage is already 100%, the description adds meaning beyond the schema by grouping filters and clarifying that account/assets use text match while id is exact, side is buy|sell, and price/quantity/lockPrice are decimal ranges. It also explains the venue filter modes and enumerates the valid sort columns, which the schema explicitly defers to 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?

The description states a specific verb and resource: it returns one page of trades, with each row corresponding to the REST trade list row. It also distinguishes the operation as read-only and explicitly excludes order-flow control, which lets an agent identify it as a query tool rather than an order-submission sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through its filter list and read-only framing, but it does not explicitly state when to choose this tool over sibling tools such as list_orders or get_order. It gives no exclusions or alternative-routing guidance, so the agent must infer the use case.

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

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

With no annotations provided, the description carries the full burden, and it does add one genuinely useful trait: the operation is read-only and never exposes credentials — a meaningful security disclosure given the sibling get_credential_storage. It stops short of covering required permissions beyond "Officer", whether results are paginated, or what a "destination" actually comprises.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences; the scope statement comes first and the security reassurance second. No filler, nothing an agent has to skim past.

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 two-parameter read with an output schema and 100% schema coverage, the description covers purpose, audience, and safety profile. Only the relationship to trading connections and the shape of a "destination" remain unstated, which is a minor gap given the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both the optional mode filter and the required account code are already documented in the schema. The description adds nothing about the account format (e.g., code vs. ID) or the paper/live mode toggle, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ("List") and concrete resource ("trading destinations") scoped to an Officer account, which is clearly distinct from list_accounts, list_orders, and list_trades. It does not, however, explicitly contrast itself with related siblings like get_trading or get_credential_storage.

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?

"available to an Officer account" implies the prerequisite (an Officer-level account code) but never states when to reach for this tool versus get_trading or get_credential_storage, nor any when-not conditions. Usage must be inferred from the resource 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, the description carries the full burden and delivers: it states the tool mutates engine state, is protected and disabled by default, discloses the signing/attestation model (fail-closed signed attestation vs unsigned under eSign-off, drop-copy never attested), names the terminal statuses and that they release the reservation, and enumerates the specific error codes for refusal paths. This is exactly the behavioral context an agent needs before invoking a 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?

The purpose and scoping constraint are front-loaded, and the refusal/attestation sentences each add distinct information. It is dense, long-ish prose, but nearly every clause earns its place; minor tightening (e.g., the attestation and terminal clauses) would make it a 5.

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

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

Given 8 parameters, no annotations, and an existing output schema (the attestation result), the description covers the mutation, default protection state, terminal/reservation behavior and error outcomes. Nothing an agent needs to call it correctly is missing, since return-value structure is handled by the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema itself already documents fill price/quantity requirements, lockPrice settlement semantics, commission shape and leavesQuantity. The description adds little parameter-level meaning beyond the schema (it only alludes to 'a commission' and inheriting instrument/account/side from the order), so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a precise verb (apply) and resource (execution report: fill, commission or lifecycle status) scoped to orders returned by submit_order or submit_drop_copy_order, which clearly separates it from siblings like confirm_execution or apply_adjustment. An agent can tell what this tool does and what its inputs must originate from without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It establishes clear usage context: reports apply to orders produced by submit_order/submit_drop_copy_order, with distinct behavior for drop-copy vs ordinary orders, and explicit refusal conditions (terminal_order, venue_order_managed, conflict). It stops short of explicitly contrasting when to choose this over near siblings such as confirm_execution or apply_adjustment, so it is strong but not exhaustive.

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 declares the operation mutates Officer control-plane config, that it is protected and disabled by default, and it discloses a specific refusal path (loosening_refused) with the underlying reason (venue fees skipped). It does not state required permission level or how to re-grant after revocation, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the verb and target, then the refusal edge case, then the safety posture. Dense but every clause adds information; 'Officer' jargon is repeated rather than trimmed.

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 all three parameters are schema-documented. For an unannotated mutation tool the description supplies the mutation/protection/refusal context an agent needs; only auth requirements and post-revocation state are 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?

Schema coverage is 100%, so the two named parameters plus their mutual exclusivity are already documented. The description adds meaning beyond the schema by qualifying when accountGroup is even applicable ('where the server offers account groups'), which the schema does not express.

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+resource: 'Revoke the access of an Officer account to a trading connection'. It also covers the alternate target (account group) and implicitly separates from grant_trading_access by verb, but never names the inverse sibling explicitly, so cross-tool disambiguation relies on the reader noticing the verb pair.

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 clarifies the account-vs-accountGroup choice is conditional on the server offering account groups, which is real usage guidance. But there is no explicit when-to-use/when-not statement and no pointer to grant_trading_access or list_trading_destinations for the preconditions an agent would need before revoking.

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 the important safety trait that the call is read-only and that credentials are never exposed, which is genuine value. It says nothing about result limits, pagination, or whether the search is across one connection only, so the disclosure is partial rather than complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and followed by the security reassurance. Nothing is wasted, though the second sentence is a fragment whose placement is slightly bolted-on rather than integrated.

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 read-only claim covers the safety question. However, for a search tool in a dense cluster of trading-connection tools, the absence of any scoping or routing information leaves a real gap in deciding when to call it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both 'query' and 'connection' are already documented in structured data. The description adds no syntax, format, or matching-behavior detail (prefix vs substring, case sensitivity) beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: search venue symbols for a trading connection. It is distinguishable from the many mutation siblings (submit_order, verify_trading_symbol) by the word 'search', though it never names its nearest alternative (verify_trading_symbol) 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?

There is no when-to-use or when-not-to-use guidance and no mention of sibling tools. The agent must infer from the name alone whether this is a pre-flight lookup before verify_trading_symbol, confirm_execution, or submit_order.

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 meaningful work: it discloses mutation ('Mutating'), gating ('protected and disabled by default'), real-money consequence, and the outcome vocabulary returned (approval, acknowledged/refused/unknown). It stops short of permission or idempotency details, but covers the critical risk profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. The risk-relevant facts (real money, mutating, disabled by default) appear before the return-value note.

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 nested route schema is fully documented. The description supplies the safety and enablement context an agent needs. Minor gap: no mention of preconditions for enabling the tool or of failure/refusal causes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and every field, including the nested destination.route, is documented in-schema with venue-specific requirements. The description adds nothing about parameters, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb chain and resource: 'Check, hold and send an order to a live venue, with real money.' The live/real-money framing separates it from send_paper_order, though the boundary with the sibling submit_order is left implicit.

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?

'with real money' and 'disabled by default' imply when this is appropriate versus the paper variant, but no sibling is named and there is no explicit when-to-use/when-not guidance relative to check_order, submit_order, or confirm_execution.

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

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

With no annotations, the description carries the full burden and does substantial work: it declares mutability ('Mutating'), a protection/enablement gate ('protected and disabled by default'), and the outcome space (approval plus acknowledged/refused/unknown send state). It does not explain what the 'hold' step does operationally or whether a refused order can be retried, which keeps it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the action and then the return contract and safety profile. No filler, though the safety profile ('Mutating, protected and disabled by default') is compressed to the point of being terse relative to its importance.

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 9-parameter, nested-object mutation with an output schema and no annotations, the description covers mode scoping, the alternative tool, the mutation/enablement profile, and the return outcome shape. Remaining gaps (hold semantics, retry behavior after refusal) are minor given the schema and output schema depth.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the deeply nested destination.route venue-specific requirements, so the schema already does the heavy lifting. The description adds no parameter-level meaning beyond what the schema states; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource ('an order to a paper venue') and names the sibling it differs from ('send_live_order is the live counterpart'), so the paper/live split is unambiguous. The 'Check, hold and send' phrasing is slightly murky about whether the tool performs pre-checks, a hold step, or the send itself, which keeps it from a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly points to send_live_order as the live-mode alternative, and 'protected and disabled by default' signals an enablement prerequisite before calling. It offers no guidance on how this differs from other order-submission siblings (submit_order, check_order, confirm_execution), leaving that inference to the agent.

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 so well: it declares this is a mutation of 'Officer control-plane config', that it is 'protected and disabled by default', that the effective-currency change is blocked while specific state exists, and it names the exact error ('currency_change_blocked'). That is precisely the operational context annotations would ordinarily supply.

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?

Front-loads the verb and the empty-string behavior, then the guard conditions. The refusal sentence is dense with comma-separated conditions but every clause is substantive; no filler.

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

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

An output schema exists so return values need no explanation, and the description covers mutation scope, default protection state, inheritance fallback, and blocking conditions. Nothing needed to invoke this tool correctly 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?

Schema description coverage is 100%, so both parameters are already documented, and the description largely restates the inheritance behavior already present in the currency field. It adds one bit of nuance ('tracks no realized P&L when no tier is set') but no format, casing, or validation detail for the currency code, so the baseline 3 holds.

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 ('Set or clear an account's own realized P&L currency') and immediately defines the clearing semantics, which separates it from sibling mutators like update_account or set_limit. An agent can tell exactly what this tool changes without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear usage context: passing an empty currency clears the override, and the description spells out the inheritance chain that then applies. It also enumerates the preconditions under which a change is refused (non-zero balance, position, cost-basis/P&L, halt, active order, Spot Funds P&L bound). It stops short of naming sibling alternatives such as update_account, so a 4 rather than 5.

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 so: it discloses that the tool mutates control-plane config, that it is protected and disabled by default, that refusals change nothing, the precise no-looser invariants per policy kind, the ordering constraint against the first order-size barrier, and the semantics of the enforce/track_only switch. This is unusually rich behavioral disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The intent is front-loaded and nearly every sentence conveys a distinct invariant, but the body is one dense run-on paragraph with repetitive phrasing ('no looser', 'every current cap kept') that is hard to parse on a first read. Bulleted per-policy invariants would preserve the content with far better scannability.

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

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

Given 14 parameters, an output schema, and a large constraint surface, the description covers refusals, replacement semantics, mode transitions, and the default-protected state. The main residual gap is a pointer to the read-side tool for inspecting current barriers, which an agent would otherwise have to infer from the sibling list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the per-field descriptions already do heavy lifting, but the description adds real cross-field meaning: policy selects the kind and the remaining arguments are that kind's fields, with fields of another kind rejected by validation. That conditional dispatch across 14 params is not derivable from the schema alone. It stops short of mapping each scope value to its axis explicitly in the prose (the schema carries that).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first clause names a precise verb pair (create / make stricter) and the resource (risk barrier), and immediately enumerates the policy kinds it governs. An agent can tell this is the write path for barriers — the counterpart to get_limits/get_spot_funds_limit_mode — without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete routing guidance: no barrier can be removed, so switching Spot Funds back to Check funds means calling this tool with policy=spot_funds_limit_mode and mode=enforce. It also states exactly which calls are refused (loosening_refused, validation) so an agent knows when not to bother. It never names the sibling read tool for inspecting existing barriers, which keeps it short of a 5.

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 real behavior: the specific error code loosening_refused on enable, the reason (widening priced quotes), the blast radius ('Officer control-plane config only'), and the default posture ('protected and disabled by default'). It stops short of stating required permissions/authorization for the mutation or whether a disable is similarly guarded.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with zero filler, and the core operation is front-loaded before the refusal semantics and scope notes. Every sentence carries information the agent could not get from the schema.

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 all three parameters are documented. The description covers the mutation surface, the failure mode on enable, and the default protected state; it could still be more complete about authorization requirements and the disable path's failure behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so id, externalSymbol, and enabled are already fully documented in the schema. The description adds only the framing that exactly one instrument is targeted, with no extra syntax, identifier format, or cross-field constraints.

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 precise verb pair ('Enable or disable') bound to a specific, scoped resource ('one configured market-data instrument'), so the agent knows exactly what state change is offered. It doesn't explicitly name the nearby sibling set_trading_instrument, so the distinction from it is left to be inferred from the 'market-data' qualifier.

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 rather than stated: the tool is for toggling the enabled flag on an existing instrument, and the text warns that an enable will be refused with loosening_refused. There is no explicit guidance on when to prefer a sibling (set_trading_instrument) or what the correct alternative is when the refusal fires.

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

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

With no annotations, the description carries the full burden and does well: it discloses that it mutates Officer control-plane config, that the target is protected and disabled by default, and that an enable is refused with the specific error code loosening_refused because it widens outbound scope. Missing only permissions/auth requirements to reach a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler; the core action is front-loaded, followed by the refusal behavior and the mutation/default-state warning in order of importance.

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 description covers mutation scope, default state, and the failure mode. The one gap is authorization requirements for an Officer control-plane mutation, which an agent would want to know before calling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters (connection id, enabled boolean) are already documented in the schema; the baseline is 3. The description adds a little semantic weight by explaining what enabling means ('widens what can be sent') but says nothing specific about the connection 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: 'Enable or disable a trading connection.' This is unambiguous and clearly a toggle operation. It does not explicitly distinguish itself from update_trading_connection or create_trading_connection, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by 'enable or disable', and the refusal note warns that enabling may fail, but the description never names an alternative (e.g., update_trading_connection for other connection fields) nor states prerequisites. An agent can infer when to use it, but nothing is explicit.

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 does well: it discloses that the tool mutates Officer control-plane config, is protected and disabled by default, and can be refused with loosening_refused. It does not cover authorization requirements or return behavior, but the output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action and followed by the refusal and safety context. There is no wasted text.

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

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

For a mutation tool with no annotations and an output schema, the description provides the key operational context: what changes, that it is protected/disabled by default, and that it may be refused. It could say more about prerequisites, but it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds context about Officer accounts and venue fees but does not add syntax or meaning beyond the schema for the connection parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: setting the Officer account that receives unlinked venue fees. It is clear what the tool does, though it does not explicitly distinguish itself from the sibling clear_trading_fee_account.

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 when the tool is relevant by explaining that it moves where future venue fees are debited, but it does not explicitly say when to use this versus clear_trading_fee_account or other configuration tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this mutates Officer control-plane config, is protected and disabled by default, and can be refused with loosening_refused, though it omits auth/permission requirements and reversibility 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?

Three sentences, front-loaded with the core action and followed by the key safety constraint and refusal behavior. 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?

The output schema exists and the input schema is fully documented, so the description need not explain return values or parameters. It covers the mutation and protection context well, though it could say more about permissions or enabling the protected setting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters. The description does not add per-parameter meaning beyond what the schema provides, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Set a trading instrument mapping.' It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as set_market_data_instrument or delete_trading_instrument.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful context—protected and disabled by default, and refusal with loosening_refused—but it does not explicitly say when to use this tool versus alternatives like set_market_data_instrument or delete_trading_instrument.

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 so well: it discloses the bypass of policy rejects and account/group kill-switches, that policy state changes still apply, that no lifecycle event is signed, that engine state is mutated, and that it is protected/disabled by default. These are exactly the traits an agent must know before invoking a dangerous write.

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?

Five short sentences, front-loaded with the core action and the most consequential behavior (ignoring rejects/kill-switches), then the id default, signing, and gating. Nothing is padding.

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 and the input schema is fully described, so the description needn't explain returns or field formats. It covers the safety/gating profile well; only the enablement path for a 'protected and disabled by default' tool is left 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?

Schema coverage is 100%, so the schema already documents all nine parameters including the id and missingAccount quirks. The description only restates that id is optional, adding no syntax or format detail beyond the structured fields, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Submit') plus a distinct resource ('drop-copy order') and a precise qualifier about the policy pipeline. It does not name the sibling it supersedes (submit_order / send_live_order), but the drop-copy framing plus the bypass semantics makes it functionally distinguishable.

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 use case is implied by the drop-copy concept and by 'protected and disabled by default', but there is no explicit statement of when to choose this over submit_order or send_live_order, nor any prerequisite/enablement steps. An agent must infer the selection rule.

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?

Since no annotations are provided, the description must carry the burden. It successfully discloses critical behavioral traits: that it 'Mutates engine state' and that it is 'protected and disabled by default.' This high-value operational context is not in the schema or 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?

The description is maximally concise, with both sentences adding unique, vital information about the tool's function and operational constraints. It is well-front-loaded.

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?

Despite having 10 parameters and no output schema, the description is comprehensive regarding the nature of the call—it identifies the workflow, the operational state, and the risk profile (pre-trade lock/mutation). This provides a complete enough picture for an agent to decide when and if to invoke it.

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 coverage is 100%, establishing a baseline of 3. The description does not add specific meaning to any parameters, only to the overall operation, which is sufficient given the structured detail.

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 clearly defines the action (submit order intent) and the specific process involved (pre-trade and obtaining an approval envelope). This specific focus differentiates it from standard submission tools like send_live_order.

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?

While it defines its operational status ('protected and disabled by default'), it does not explicitly state when this tool should be chosen over similar submission siblings, which remains an implied context rather than an explicit rule.

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 so well: it discloses the exact failure mode and error code (loosening_refused), enumerates the blocking conditions, and warns that this mutates Officer control-plane config and is 'protected and disabled by default' — a critical privilege prerequisite. Title overwrite/clear semantics are also spelled out rather than left implicit.

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 primary effect, then the guardrails; nothing is padding. The second sentence is long and dense with enumerated conditions, but each clause carries decision-relevant 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 values need no explanation, and the description supplies the rest: required privilege context, default-disabled state, exact refusal code, and all gating conditions. An agent has everything needed to decide whether the call can succeed before issuing it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already says code-equals-account keeps it, empty title clears, and account is the current code, so the baseline is 3. The description adds value beyond that by scoping the block/refusal rule to code changes specifically — implying a title-only change is not gated the same way — which the schema does not convey.

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 ('Change an account's code and title') and immediately clarifies the effect of each field: title replacement and clearing via empty string. The resource (account) is unambiguous against siblings like update_group and update_asset, so an agent can select it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The refusal conditions effectively define when the tool will not work — blocked accounts, blocked groups, group-scoped Spot Funds P&L bounds, or an account carrying its own rate-limit, order-size or P&L barrier. That is strong 'when not to use' guidance. It stops short of naming alternatives (e.g., set_account_currency) or explaining how to unblock an account.

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?

Since no annotations were provided, the description carries the full burden. It details critical behavioral traits like mutation target ('Officer control-plane config'), security status ('protected and disabled by default'), and specific failure modes (e.g., refusal of code change).

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 highly dense but efficient. It front-loads the primary capabilities followed by specific, critical operational constraints, ensuring no time is wasted on irrelevant 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?

Given that there is no output schema, the description is contextually complete. It defines mutation targets, permissions, and key operational success/failure criteria, providing everything an agent needs to execute it safely.

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?

Although schema coverage is 100%, the description explicitly adds semantic meaning to the input parameters by stating that 'the title and the asset class replace the stored ones, and an omitted or empty one clears it.' This is vital behavioral context beyond the schema.

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 clearly identifies the operation (Change) and the resources it acts upon (asset's code, title, and asset class). While specific, it lacks a single differentiating phrase compared to a generic 'update' tool, but its focus on asset management is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit negative usage guidelines by stating when a code change is refused (e.g., rate-limit or P&L barriers). This defines a crucial constraint on when an agent can successfully use the tool.

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

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

With no annotations, the description carries the burden and does disclose mutation of Officer control-plane config, that the feature is protected and disabled by default, and that invalid codes are rejected at validation. The phrase "protected" is left unexplained, and success/failure semantics beyond the output schema are not described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the mutation itself and followed by the two hard constraints. Little waste, though the trailing "protected and disabled by default" clause is vague jargon that could be sharper.

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 3-parameter mutation with full schema coverage and an output schema, the description covers the key operational constraints (default-group protection, reserved code, disabled-by-default feature). Only the meaning of "protected" and post-call behavior remain 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?

Schema coverage is 100% and the schema already documents each parameter, including title replacement/clearing and the reserved '-' code. The description restates the title and '-' semantics rather than adding new meaning, so it sits at the baseline.

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 ("Change an account group's code and title") and enumerates exactly which fields are mutable. It does not explicitly contrast itself with siblings like create_group, delete_group, or update_account, but the operation 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?

It gives a clear exclusion: the default group cannot be changed and its reserved '-' code is refused. That tells an agent when the call will fail, though it never names an alternative tool for the cases it excludes.

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 so well: it discloses a mutation of Officer control-plane config, that credential changes are refused with a named error (loosening_refused), and the non-obvious side effect that the trading runtime restarts and unavailable connections come back. It omits what a successful response contains and whether label-only updates have any runtime impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the action and its two field scopes before the failure/side-effect caveats. Every sentence carries information; the bare token 'loosening_refused' is dropped in unexplained, but as an error code it is plausibly actionable.

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 3-parameter mutation with a rich output schema, the definition covers the risky paths (credential refusal, runtime restart, protected/disabled default) and relies on the schema for return values and credential shapes. Only the post-success behavior of label-only updates is left 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?

Schema description coverage is 100%, so the baseline is 3; the description only echoes the schema by calling credentials 'write-only' and noting omitted fields keep stored values. It adds no shape or validation detail beyond the schema, though the mutation's constraint on credentials is useful context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names the specific verb and the two mutable fields (label, write-only credentials) on a trading connection, which is far more precise than the bare tool name. It implicitly separates itself from set_trading_connection_enabled and create_trading_connection by scoping the change to label/credentials, but it never names a sibling to route against.

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 context is implied rather than stated: 'protected and disabled by default' signals the feature must be enabled first, and the refusal note warns that credential updates fail. There is no explicit when-to-use / when-not-to-use guidance and no named alternative for changing other connection aspects.

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

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

With no annotations, the description carries the burden, and it usefully declares 'Read-only - credentials are never exposed,' which is real behavioral value. However, it does not disclose whether the check hits the provider API (latency/failure modes) or what happens for a valid-but-untradable symbol.

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 core purpose front-loaded and no filler. The second sentence is a compact behavioral note rather than padding.

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 two-parameter read-only tool with a full output schema and complete parameter descriptions, the definition covers what is needed to invoke it. The main gap is sibling differentiation against search_trading_symbols.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (connection, externalSymbol) are already documented in the schema. The description adds no further meaning about symbol format, connection scoping, or required permissions, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Verify whether a venue symbol exists and is tradable.' It is clear what the tool does, but it does not distinguish itself from the sibling search_trading_symbols, which an agent could easily confuse it with.

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 use this versus search_trading_symbols or set_trading_symbol, and no prerequisites are stated. The agent must infer the usage scenario from the purpose sentence alone.

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