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

With no annotations, the description carries the full burden and largely meets it: it discloses the API-credential requirement, the named failure modes (MarginModeNotIsolated, NoOpenPosition, margin floor breach), and explicitly warns that REAL margin moves on the position. It stops short of describing the resulting position/balance state or whether a removal frees collateral immediately.

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 operation, followed by failure conditions and the funds warning; four sentences and every one carries weight except for the `amount` restatement, which duplicates the schema verbatim. Slightly padded but well ordered.

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

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

There is no output schema, yet the description covers the mutation's semantic danger, auth needs, and error surface, which is most of what an agent needs. The remaining gap is the unexplained overlap with the `adjust_isolated_margin` sibling and no indication of what the call returns on success.

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 all three parameters are already documented in the schema, including the enum for `direction` and the positive-decimal rule for `amount`. The description's restatement that `amount` is a positive decimal string adds no meaning beyond the schema, so baseline 3 is correct.

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 pair and resource: add or remove isolated margin on an open position. That is unambiguous on its own, but it does not distinguish itself from the sibling tool `adjust_isolated_margin`, which sounds like it may cover the same operation, so an agent cannot fully route between them from this text alone.

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 clear preconditions for when the call is valid (position must be in isolated mode, must exist, removal must not breach the floor), which is useful context. However, it never names or contrasts the obvious alternative `adjust_isolated_margin`, and there is no when-not-to-use guidance, 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, the description carries the full burden and does so well: it discloses deprecation, required API credentials, three named failure modes, and the real financial consequence ('This moves REAL margin on the position'). This is far beyond what the schema alone provides.

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 deprecation warning is front-loaded, and the following sentences add useful behavioral detail. Slight redundancy appears in restating the `amount` parameter already documented in the schema, but the description remains well organized and mostly free of waste.

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

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

For a deprecated mutation tool with no annotations and no output schema, the description covers the essential context: replacement, required credentials, failure conditions, parameter type, and real-margin impact. Nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so the schema already defines all three parameters. The description only restates that `amount` is a positive decimal string, which duplicates the schema without adding syntax or constraints beyond it. 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?

States a specific verb and resource: add or remove isolated margin on an open position. It also names the replacement sibling (`add_margin`) due to deprecation, so an agent can immediately distinguish it from alternatives.

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

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

Explicitly says it is deprecated and directs the agent to `add_margin`, which is the key routing guidance. It further lists precise failure conditions (MarginModeNotIsolated, NoOpenPosition, margin floor breach) and credential requirements, leaving little ambiguity about when this call will succeed or fail.

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 atomic cancel-replace semantics, a pre-trade margin check on the replacement, the liquidation-order exclusion, credential requirements, and warns it 'modifies a REAL order on the matching engine'. It does not say what happens to the original order if the replacement is rejected, nor mention 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?

Front-loaded with the deprecation notice, then compressed behavioral facts in tight clauses. No filler and every sentence conveys something operationally relevant.

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 no output schema, the description covers auth, side effects, key exclusions, and the atomicity model. The remaining gap is the response shape and failure semantics (e.g., whether the original order survives a failed margin check), which the absent output schema leaves undocumented.

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 would be 3, but the description adds a constraint the schema omits: the schema requires only `order_id` and `market_id`, while the description states 'At least one of `price` or `size` is required'. That is real value beyond the structured fields.

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 — 'Amend a resting order's price and/or size' — and characterizes the mechanism as 'one atomic cancel-replace operation'. It also flags deprecation and names the replacement sibling `edit_order`, so an agent can distinguish it from `edit_order`/`cancel_order` without opening any 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 leading 'Deprecated: use `edit_order`' is an explicit when-not/routing instruction, and it adds preconditions ('requires API credentials', 'liquidation orders cannot be amended', at least one of price/size). It stops short of contrasting the amend path with an explicit cancel+create workflow, but the alternative is clearly named.

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

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

With no annotations supplied, the description carries the full behavioral burden and mostly does: it flags the operation as destructive, explains the confirm guard's purpose, and states the API-credential requirement. It stops short of saying whether the cancel is irreversible or what happens when there are zero open orders, but the safety profile is well 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 tight sentences with the destructive scope front-loaded, then the safety guard, then the sibling alternative. Nothing is padding and the order matches how an agent needs the 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?

No output schema exists, so the description would need to cover behavior, and it does for the safety-critical parts. The only unwritten item is the result shape (e.g., count of cancelled orders) and empty-state behavior, which is minor for a bulk-cancel tool with a hard confirm gate.

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 both properties are already documented in the schema ('Must be true to actually cancel', 'Scope the cancel to one market'). The description restates that semantics inline rather than adding format or edge-case 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?

Names a specific verb and resource ('Cancel ALL of the authenticated account's open orders') plus the optional scoping dimension via market_id. It also explicitly negates the nearest sibling, cancel_order, so the agent can route correctly without opening either 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 explicit when-to-use ('all open orders, optionally scoped to one market') and the alternative for the single-order case ('To cancel a single order use cancel_order'). The requirement to pass confirm:true is stated as a precondition rather than left to inference.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that API credentials are required (auth need) and clarifies the market_id routing requirement, but does not describe mutation side effects (e.g., whether cancellation is immediate, what happens if the order is already filled, or error behavior).

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

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

Three short sentences, front-loaded with the core action and scope, then routing constraint, then alternative and auth note. No filler or repetition.

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

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

For a two-required-parameter mutation tool with no output schema and no annotations, the description covers auth, scope, routing, and the alternative tool. It omits some failure-mode context, but is sufficient for correct invocation.

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

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

Schema coverage is 100%, so both parameters are already documented. The description reinforces that market_id is required for routing, but adds no syntax or format beyond what the schema provides; 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?

States a specific verb (Cancel) and resource (one resting order by order_id), and explicitly distinguishes itself from the sibling cancel_all_orders. An agent can identify the exact operation 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?

Explicitly states the tool only ever cancels the single named order and names the alternative (cancel_all_orders) for cancelling everything, giving a clear when-to-use-this-vs-alternative 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?

No annotations are provided, so the description carries full burden. It discloses: daily allowance cap (default 500 USDX, resets midnight UTC), optional amount vs. full claim, synthetic nature, and API credential requirement. However, it does not detail side effects like whether repeated calls within the day reduce allowance or how failures are handled.

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, no wasted words. Front-loaded with core purpose and immediate constraints. Highly efficient.

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

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

For a simple one-parameter tool with no output schema, the description covers all necessary aspects: what it does, constraints, parameter behavior, and prerequisites (API credentials). No gaps remain.

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 one parameter. Description adds semantic value: 'positive decimal string' type constraint and 'omit to claim full remaining allowance' usage rule. This fully explains the parameter's purpose and behavior.

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 states the action 'claim synthetic USDX credit from the testnet faucet' and specifies the resource (USDX, testnet) and constraints (daily allowance, default 500 USDX, resets midnight UTC). It distinguishes from sibling 'claim_faucet' by specifying the synthetic USDX nature.

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 indicates when to use (to get testnet USDX) and explains behavior with optional amount parameter. It does not explicitly state when not to use or name alternatives, but the context is straightforward for a faucet 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?

Discloses key behavioral traits: fixed amount, per-wallet cooldown, cumulative cap, testnet context, and authentication requirement. Without annotations, this is adequate, though does not detail cooldown duration or error responses.

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, 72 words, front-loaded with core purpose, no superfluous text. Every sentence adds value.

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

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

For a simple tool with no parameters and no output schema, the description covers purpose, constraints, and differentiation from sibling. No critical gaps given the tool's complexity.

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?

No parameters exist (0 params), baseline is 4. Description confirms no arguments needed, adding clarity beyond the empty 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?

Explicitly states the action (claim), the resource (fixed testnet faucet amount of synthetic USDX), and context (authenticated account, cooldown/cap). Clearly distinguishes from sibling claim_credit by noting the fixed amount server-side.

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?

Directly compares with claim_credit, specifying that the amount is fixed and no arguments needed, guiding the agent when to choose this tool. Also mentions requirement of API credentials.

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 one-time secret visibility, that the server persists the key in the Nexus CLI config for the session, that `secret` returns redacted with `saved_to` naming the file, and the fallback where an unsaved secret is returned in full and must be stored immediately. These behaviors are non-obvious and materially affect correct invocation.

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?

Every sentence earns its place — key purpose, session retention, the two secret-return paths, and auth. It is dense and front-loaded, though the middle sentences are somewhat compressed and require careful reading.

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 no output schema and no annotations, the description specifies the return shape (`secret`, `saved_to`), the two possible secret states, and the authentication prerequisite. An agent has everything needed to call this correctly and handle the response.

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; there is nothing for the description to add or clarify. The schema is empty and consistent with the description's no-argument usage.

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 a new HMAC API key') and the scope ('for the authenticated wallet'), clearly distinguishing it from siblings like list_api_keys and delete_api_key. An agent can identify the operation without reading any 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?

Explains the payoff context — the stdio server keeps the key so account and trading tools work right away — and names the auth source (session token from `login` or NEXUS_EXCHANGE_SESSION_TOKEN). It stops short of explicitly contrasting with create_ws_token or stating when an agent should prefer/avoid creating a key.

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 deprecation/failure mode, idempotency keyed on (account, chain) with the same-address guarantee, the crediting effect of sending assets, and the API-credential requirement. It does not cover rate limits or response shape, but the return contract is largely implied by 'returns the address.'

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 deprecation warning — the single most decision-relevant fact — before the functional description and behavioral notes. Every sentence earns its place and nothing is padded.

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

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

For a one-parameter, no-annotation, no-output-schema tool, the description supplies everything needed: status, purpose, idempotency, side effect, and auth requirement. The deprecation note alone prevents an agent from wasting a call.

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

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

There is one parameter with 100% schema description coverage, including an example value and a pointer to fetch_bridge_assets for discovery. The description's 'get-or-create per (account, chain)' adds the idempotency semantics of the chain argument, but otherwise the schema does the heavy lifting, 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?

The description names a specific verb+resource ('Get or create the authenticated account's cross-chain deposit address on a chain') and immediately qualifies it with a deprecation status. An agent can distinguish it from siblings like list_bridge_deposit_addresses or create_deposit without reading 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 the strongest possible when-not-to-use signal up front: 'no server implements this route ... so every call fails.' It also tells the agent how to find valid inputs ('Use `fetch_bridge_assets` to discover supported chains' via the schema) and that API credentials are required.

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 richly: no state is minted or changed, the challenge is not single-use but harmless because the message is bound to the account and address, message is opaque and must be echoed verbatim, nonce is informational and must not be signed, 503 wallet_registration_unavailable means registration is disabled, and API credentials are required.

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?

Long but almost every clause carries non-obvious operational information (opaque message handling, nonce trap, non-single-use semantics, 503 meaning, auth requirement), and the primary action is front-loaded in the first sentence.

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 single-parameter, no-annotation, no-output-schema tool, the description supplies the return payload (message, expires_at), the downstream call, idempotency semantics, error behavior, and auth needs. Nothing an agent needs to invoke 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% for the single address parameter, and the description reinforces its role ('the message is bound to ... address') without adding format or validation detail beyond the schema. 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 — 'Step 1 of registering a withdrawal wallet' that 'returns the exact message to sign' — and explicitly names its companion step, register_bridge_wallet. An agent can distinguish it from register_bridge_wallet and create_wallet without opening any 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 explicit routing: sign the message and pass it plus the signature to register_bridge_wallet, or, for the wallet create_wallet made, omit the signature and let the server sign. It also states it is safe to call before deciding to register, and that retrying on a 503 is pointless.

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 HTTP endpoint, that credentials are required, that the deposit is persisted and listable, and warns that it 'moves REAL collateral on the account'. It does not address idempotency, failure/error behavior, or reversibility, which is the remaining gap for a mutating financial call.

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

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

Four compact clauses, each earning its place: purpose+endpoint, sibling differentiation, parameter recap, and the credential/real-collateral warning. The most important caveat is placed last for emphasis without burying the primary action.

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 2-parameter mutation tool with no output schema and no annotations, the description covers purpose, routing, credentials, and side effects. What's missing is confirmation of whether the call is idempotent and what the caller gets back, but the essential decision inputs are present.

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 in the schema. The description's restatement of 'amount is a positive decimal string' and 'asset defaults to USDX' adds no syntax, format, or constraint detail beyond it, 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 ('Submit a ... deposit ... via the deposits ledger') and explicitly distinguishes itself from the sibling `deposit` by noting the deposit is recorded and listable with `fetch_deposits`. An agent can separate this from `deposit`, `deposit_collateral`, and `submit_deposit` without opening any 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 clear context for when this tool is appropriate versus the sibling `deposit` (recorded vs unrecorded), and flags the credential prerequisite. It stops short of explicit when-not-to-use guidance among the many other deposit-related siblings, but the routing signal is present.

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 mostly does: it discloses that API credentials are required, warns it submits a REAL order to the matching engine, and explains how each order family fires (adverse vs favorable trigger direction, trailing retracement). Missing only secondary traits like rate limits, cancel/replace behavior, or whether submission is idempotent.

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 sentences, front-loaded with the core action, then order-type coverage, then field requirements, then the credential/real-order warning. Some of the field-requirement text duplicates the schema, but nothing is padded and the highest-value warning is placed last for emphasis.

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 mutation tool with no annotations and no output schema, the description covers order-type semantics, credential needs, and the real-order warning well. A brief note on the returned order representation (since there is no output schema) and on rate limits or error behavior would close the remaining 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 description coverage is 100% and the schema itself is unusually detailed about cross-field requirements, defaults, and enum semantics. The description's consolidation of the field-requirement rules (price for limit-family, trigger_price for stops, trailing_offset_bps for trailing) largely restates the schema rather than adding new meaning, 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?

States a specific verb and resource ('Place an order on a market, buy/sell') and enumerates the eight supported order types, so the agent knows exactly what the tool does. However, it never distinguishes itself from close siblings in the list such as `place_order`, `create_orders`/`place_orders_batch`, or `preview_order`, which is the main thing an agent needs to disambiguate here.

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 'use this when' guidance and no mention of alternatives, even though `preview_order`, `place_order`, and the batch variants sit right beside it. The implicit signal that this is a real single-order submission is present ('submits a REAL order'), but the agent is left to infer routing itself.

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 but does disclose two important traits: credential requirement and that real orders hit the matching engine. It omits batch-specific behavior an agent needs, such as whether the batch is atomic or can partially fail, validation/error semantics, and any rate limits.

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

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

Three tight sentences with the core action front-loaded and the risk/auth caveat positioned at the end for emphasis. The mid-sentence field enumeration is slightly redundant against the schema but is 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?

For a real-money batch mutation with no annotations and no output schema, the description covers the safety-critical basics but leaves gaps on partial-failure/atomicity behavior and what is returned. It is adequate to call the tool, but not complete for an agent weighing the risk of a 100-order batch.

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 fully documents the nested order fields, so the baseline is 3. The description adds only a pointer to the `create_order` arg shape and a field list, which is largely a summary of what the schema already specifies.

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 ('Submit multiple orders in one request'), making the batch nature clear and pointing at the per-order shape of `create_order`. However, it does not distinguish itself from the very similarly named sibling `place_orders_batch`, leaving the agent to guess which batch tool to pick.

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 supplies meaningful context ('Requires API credentials', 'submits REAL orders to the matching engine') that frames the circumstances for use. It never states when to prefer this over `create_order`, `place_order`, or `place_orders_batch`, so routing guidance is only implied.

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

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

No annotations are provided, so the description carries the full burden and does so: key stored 0600 in the network's config section, session-scoped, only the address returned, never the key. It also discloses the destructive overwrite behavior and that the replaced key is unrecoverable.

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 what the tool does and the scope restriction before the operational details. It is dense and one sentence ('so create_wallet, login, create_api_key gets an agent an account...') is grammatically tangled, but nearly every clause conveys a constraint an agent needs.

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

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

For a single-optional-parameter tool with no output schema, the description covers prerequisites, return value (address only), persistence, environment limits, and refusal conditions. Nothing essential to correct invocation is missing.

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

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

Schema coverage is 100% and the confirm property is already documented as required-to-replace. The description nonetheless adds value by specifying that confirm overwrites the old key and keeps it nowhere, reinforcing irreversibility beyond the schema's terse wording.

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 ('Make a new EVM wallet for this server to sign with') plus an explicit scope restriction (play-funds targets only). It is clearly distinguishable from sibling auth tools like login or register_agent, which it positions as consumers of the wallet rather than creators.

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?

Explicit when-to-use (play-funds targets only), when-not-to-use (refused on mainnet or undeclared/real funds), overwrite precondition (confirm: true required if a wallet exists), and environment constraint (stdio server only). It also names the downstream flow (login, register_agent, register_bridge_wallet, create_api_key) that becomes usable afterward.

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 and does well: it discloses the 60s single-use lifetime, the auth requirement, HMAC/registered-agent key support, and the returned ws_endpoint. It omits rate limits, error behavior, and whether minting invalidates prior tokens, which keeps it short of 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 core action and token properties; the endpoint note and credential requirement each add distinct value. No filler, though the ws_endpoint sentence is slightly more verbose than needed.

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

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

With no output schema, the description helpfully explains the key return field (ws_endpoint) and the network-specific URL behavior, plus required auth. An agent has enough to call and consume the tool; only minor operational details (rate limits, failure modes) 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?

The tool takes zero parameters, so the baseline is 4. There is nothing parameter-level for the description to add or omit.

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 ('Mint a short-lived token') plus the exact scope ('authenticated per-account WebSocket stream (order/fill/position updates)'). It implicitly separates itself from the legacy variants by naming the 'current /ws/token endpoint,' but never names get_ws_token or create_ws_token_legacy outright, so an agent still has to infer the routing.

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 prerequisite ('Requires API credentials') and context (per-account authenticated stream), which implies when the tool is appropriate. However, with three closely related siblings (get_ws_token, get_ws_token_legacy, create_ws_token_legacy) no explicit when-to-use/when-not or alternative is given, leaving routing to inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the 60-second lifetime, single-use semantics, required API credentials, and which endpoint it hits. It does not cover failure modes or rate limits, but the key behavioral traits for a token-minting call are 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?

Three tight sentences, front-loaded with what the tool does, then the routing advice, then auth/response details. Every clause carries information; nothing is redundant against 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?

No output schema exists, and the description partially compensates by noting the response carries `ws_endpoint` for the configured network and that credentials are required. That covers the essentials for a no-param token mint; only the fuller response shape and error behavior remain undocumented.

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 is trivially complete and the baseline is 4. The description adds nothing about inputs because there are none to describe, which is the correct handling for a no-arg tool.

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

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

States a specific verb and resource ('Mint a short-lived token'), names the exact endpoint (POST /ws-tokens), and explicitly contrasts with the sibling create_ws_token ('/ws/token'). An agent can distinguish this from create_ws_token and get_ws_token_legacy without opening a schema.

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

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

Explicit when-to-use guidance: 'Prefer `create_ws_token` (`/ws/token`) for new code; this is kept for `/stream` compatibility.' It names the alternative and the exact condition (legacy /stream endpoint) that selects this 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 discloses a critical behavioral trait: 'any caller using that key stops working.' It also states the confirm guard and auth requirement. It stops short of describing irreversibility, error behavior, or the response shape, so it is strong but not exhaustive.

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 tightly packed sentences with zero waste: purpose first, then the destructive consequence, then the confirm requirement, then auth. The agent gets the critical constraints in the order it needs them.

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 with no annotations and no output schema, the description covers the essential behavioral risks and auth mechanics. It could mention permanence or what happens to in-flight requests, but it is sufficiently complete for correct invocation.

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

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

Schema coverage is 100%, so key_id and confirm are already fully documented in the schema. The description repeats 'by its key id' and 'must pass confirm: true' but adds no syntax, format, or edge-case meaning 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 verb ('Delete (revoke)') and resource ('HMAC API key') with scope ('by its key id'). It clearly distinguishes the tool from create_api_key, list_api_keys, and fetch_api_keys by naming the exact action and identifier format.

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 clear context: destructive operation, required confirm flag, and the authentication source (session token from login or NEXUS_EXCHANGE_SESSION_TOKEN). It does not explicitly compare against alternatives or state when not to use it, but the prerequisites are clearly conveyed.

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

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

With no annotations, the description carries the full burden, and it does disclose two useful traits: API credentials are required, and this moves REAL collateral (a genuine mutation warning). It stops short of saying whether the deposit is immediate or pending, whether it is reversible, or what the account balance looks like afterwards.

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 identity, followed by parameter and precondition/warning detail. Efficient, though the amount restatement duplicates the schema wording.

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

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

For a real-funds mutation with no annotations and no output schema, the description covers purpose, auth requirement, and the fund-movement warning. It omits the settlement behavior and any link to deposit-target tooling, leaving an agent without a complete picture of what happens after the call.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema, so the baseline is 3. The description's restatement of 'positive decimal string' adds no meaning beyond the schema's '(> 0)' constraint.

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 ('Deposit USDX collateral into the authenticated account'), which is clear on its own. However, the sibling list contains several near-identical deposit tools (deposit_collateral, submit_deposit, create_deposit, get_deposit_target) and the description makes no attempt to distinguish this one from 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?

It states a precondition ('Requires API credentials') but gives no guidance on when to choose this tool over deposit_collateral, submit_deposit, or create_deposit, nor any when-not-to-use condition. An agent facing these sibling names has nothing to route on.

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 auth requirement ('Requires API credentials') and the real-consequence nature ('moves REAL collateral on the account'). It omits reversibility, confirmation/limits, and any error behavior, so it falls short of full coverage but adds meaningful non-obvious context.

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 clauses, front-loaded with the deprecation warning the agent needs most, then scope, parameter constraint, auth, and risk. Zero filler.

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

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

For a single-parameter mutation with no annotations and no output schema, the description covers purpose, auth, deprecation, and risk. It stops short of describing what the resulting collateral/balance state looks like or failure modes, but nothing essential to invoking 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 schema already documents `amount` as a positive decimal string (> 0). The description's 'positive decimal string' restates that constraint without adding format, precision, or unit detail 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 the specific verb and resource (deposit USDX collateral into the authenticated account) and immediately flags itself as deprecated, redirecting to the sibling `deposit`. An agent can distinguish it from `create_deposit`, `submit_deposit`, and `deposit` without opening schemas.

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 tells the agent when NOT to use it ('Deprecated: use `deposit`') and names the replacement tool. That is exactly the when-not/alternative guidance the dimension asks for.

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 real work: it discloses atomic cancel-replace semantics, a pre-trade margin check on the replacement, a liquidation-order exclusion, credential requirements, and warns that this touches a REAL order on the matching engine. It stops short of stating consequences such as loss of queue/time priority or failure modes.

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 dense sentences, front-loaded with the operation and its mechanism, followed by requirements and constraints. No filler and no repetition of schema content.

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 no output schema, the description covers authentication, atomicity, validation, and exclusions adequately. It omits what a rejected replacement does to the original resting order and does not hint at the response shape, which leaves a small gap given the absence of an 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 the baseline is 3, but the description adds a rule the schema does not encode: only order_id and market_id are marked required, yet the text imposes a conditional requirement that at least one of price or size be supplied. That is genuine added meaning over the structured fields.

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 precise verb and resource ('Amend a resting order's price and/or size') and characterizes the mechanism as 'one atomic cancel-replace operation', which separates it from create_order, cancel_order, and batch siblings. An agent can identify the operation 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 explicit constraints on use: at least one of price/size required, liquidation orders cannot be amended, and API credentials are required. It does not name an alternative tool or say when to prefer a cancel+create over an amend, but the preconditions are clear.

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 richly: fails-closed 502 with reason code, retry guidance, per-field null semantics with companion `<field>_error` codes, the always-null `leverage` caveat, the funding_paid paid-positive convention, and the API-credential requirement. This is far beyond what any structured field provides.

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 purpose and the sibling preference, then dense caveats. Nearly every sentence carries distinct operational value, though the leverage/funding_paid detail is heavy enough that the paragraph is longer than strictly minimal.

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?

No output schema exists, so the description must convey the return contract itself, and it does: the `{ summary, positions }` shape, nullability of derived fields, error-companion fields, and failure mode. An agent has everything needed to call and interpret 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 baseline is 4 per the rubric; there is nothing to disambiguate and the description correctly spends no space on 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 ('Get the authenticated account's full state') and immediately scopes it as a single-call composite returning `{ summary, positions }`. It explicitly differentiates from the two siblings it could be confused with (fetch_account_summary, fetch_positions).

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

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

Gives an explicit preference rule: use this instead of pairing fetch_account_summary with fetch_positions, and explains why (one coherent read so open_positions_count matches positions length). Also specifies retry behavior on 502 and that the error must not be read as an empty 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?

With no annotations, the description carries the full burden and does so well: it discloses the fail-closed 502 `authoritative_margin_unavailable` behavior, instructs a retry rather than misreading the error as an empty account, defines `withdrawable` (engine-authoritative free margin floored at zero, never negative), and notes the API-credential requirement. This is exactly the kind of context annotations would otherwise 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-loaded with the core purpose, then the differentiating detail and the failure-mode warning. The prose is dense and occasionally parenthetical-heavy, but every sentence carries operational value; 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?

No output schema exists, so the description must explain return values — and it does, naming the equity/margin/PnL rollup and precisely defining `withdrawable`. Combined with the 502 failure disclosure and credential note, an agent has everything needed to call and interpret this correctly.

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

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

The tool takes zero parameters, which sets the baseline at 4; there is nothing in the schema for the description to clarify or compensate for. The descriptions of returned fields (`withdrawable`) are a bonus but belong to transparency, not 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 (get) and resource (authenticated account's portfolio summary), enumerates its contents (equity, margin usage, PnL rollup), and explicitly positions it against the sibling `fetch_balance` as a richer view. An agent can select it without opening any 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?

Explicitly names the alternative (`fetch_balance`) and characterizes when this tool wins (richer portfolio view). It stops short of stating when NOT to use it or spelling out a decision rule, but the comparative framing is clear.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one genuinely useful fact: API credentials are required. It does not say whether the operation is read-only (implied by 'history'), how results are ordered, whether the limit paginates, or how far back history extends — gaps that matter for a data-retrieval call with no annotation coverage.

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

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

A single sentence that front-loads the purpose, spends a few words defining ADL accurately, then appends the hard constraint (credentials). Every clause earns its place and nothing is padded.

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

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

For a two-parameter, read-only history lookup with no output schema, the description covers what the data is and the auth requirement. It leaves the relationship to the three sibling ADL tools unresolved and says nothing about result ordering or pagination, which is the main remaining ambiguity for correct invocation.

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

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

Schema description coverage is 100%, with market_id documented (including an example format) and limit documented with its max. The description adds only the 'one market' scoping, which the schema already enforces via the required market_id; 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?

States a specific verb (get) and resource (ADL settlement history) and even explains the domain concept — force-closed positions covering a shortfall — so an agent unfamiliar with ADL still understands the return. The scope phrase 'for one market' implicitly separates it from account-scoped siblings like fetch_adl_history and get_adl_history, but it never names them, which matters given three near-identical ADL tools in the sibling list.

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 'for one market' scope constraint implies when this variant applies rather than the account-wide ones, which is some inferred guidance. There is no explicit statement of when to use this versus fetch_adl_history, get_adl_history, or get_market_adl_events, and no exclusion criteria or prerequisites beyond credentials.

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; it does disclose the authentication requirement, which is genuinely valuable and not derivable from the schema. It still omits any hint of result ordering, pagination semantics beyond the schema's limit field, or whether history is bounded in time.

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

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

Two short sentences, zero waste, with the core purpose front-loaded before the credential prerequisite. Nothing 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?

For a two-parameter account-scoped read tool with no output schema and no annotations, the description covers what it fetches, whom it fetches for, and the auth requirement. Minor gaps remain around result ordering/volume and how it relates to the account-vs-market ADL siblings.

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% (both 'address' and 'limit' are documented with format and bounds), so the schema already does the heavy lifting and the baseline is 3. The description adds no parameter-level meaning 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?

States a specific verb ('Get') plus the exact resource (auto-deleveraging events) and scopes it to 'a given account', which implicitly separates it from the market-wide siblings fetch_adl_events and get_market_adl_events. It does not, however, name those siblings or explain how it differs from the near-duplicate get_adl_history.

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

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

The prerequisite ('Requires API credentials') is disclosed, which is useful context, but there is no explicit when-to-use guidance and no mention of when to prefer fetch_adl_events or get_adl_history instead. Usage is only implied by the account-scoped framing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the auth prerequisite and the shape of the returned data, which is genuinely useful, but it says nothing about pagination, ordering, rate limits, or whether the listing is scoped beyond the authenticated wallet.

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

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

A single sentence, front-loaded with the operation and resource, with the returned fields tucked into a compact parenthetical. No filler text and nothing redundant.

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

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

With no parameters and no output schema, the description appropriately compensates by naming the returned fields (address, label, expiry) and the auth requirement. The one substantive omission is any resolution of its overlap with the sibling `list_agents`.

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

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

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies per the rubric for zero-parameter tools.

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 ('List the delegated agent keys registered for the authenticated wallet') and even enumerates the returned fields (address, label, expiry). It is clear on its own, but it does nothing to distinguish itself from the sibling `list_agents`, which appears to overlap heavily and leaves an agent guessing which to call.

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

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

The only guidance is 'Requires API credentials,' which is a precondition rather than a when-to-use rule. With closely-named siblings like `list_agents`, `register_agent`, and `revoke_agent` present, the description should say when this tool is preferred over `list_agents`; it does not.

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 usefully states that secrets are never returned and how authentication works, but it omits read-only explicitness, pagination behavior, rate limits, and ordering.

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 no waste. The primary listing behavior and security constraint are front-loaded, with authentication details following immediately.

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-only listing tool with no output schema, the description covers scope, returned content, secret exclusion, and authentication. It lacks sibling differentiation and pagination or limit details, but the core invocation needs are addressed.

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 are zero parameters, so the baseline is 4. The empty schema offers no additional parameter semantics to document or explain.

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 (List) and resource (HMAC API keys for the authenticated wallet), and clarifies the returned fields as key ids and metadata. It does not differentiate itself from sibling tools such as list_api_keys, 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?

The description implies usage by scoping the result to the authenticated wallet and supplies an authentication prerequisite (session token from login or NEXUS_EXCHANGE_SESSION_TOKEN). However, it gives no explicit when-to-use guidance or comparison against key-listing siblings like list_api_keys.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the auth requirement, that several fields are derived from mirrored state and may be null with a companion <field>_error, that null means UNKNOWN not zero, that leverage is always null, and that funding_paid is always present and paid-positive. This is unusually rich semantic disclosure that goes well beyond field naming.

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, followed by progressively finer caveats about null handling and sign conventions. Dense but each sentence carries non-obvious information; the funding_paid contrast may reiterate a point, keeping it just short of fully tight.

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

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

With no annotations and no output schema, the description must explain the tricky return fields, and it covers the highest-risk ones (null semantics, leverage always null, funding_paid sign). It does not describe the overall shape of 'positions' or equity composition, and offers no routing against sibling snapshots, leaving a small 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?

The tool takes no parameters, so per the rules the baseline is 4 and there is nothing for the description to clarify. The description's detailed semantics instead cover the return fields, which is appropriate given the absence of both a schema and an output 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?

States a specific verb+resource: 'Get the authenticated account snapshot: collateral balance, equity, and positions.' An agent immediately knows this is a read of account state. However, it never distinguishes itself from the many overlapping siblings (fetch_account_summary, fetch_account_state, get_balance, fetch_positions, get_account_state), so the agent cannot tell which near-duplicate to pick.

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

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

The only usage signal is 'Requires API credentials.' There is no when-to-use vs when-not guidance, no mention of alternatives like fetch_account_state or fetch_positions, and no scenario that selects this tool over its many lookalike 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?

No annotations are provided, so the description carries the full burden, and it does disclose the key behavioral traits: it is a public catalog requiring no credentials, and it enumerates what is returned (decimals, minimums, confirmations, fees). It does not mention rate limits, caching, or pagination behavior.

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

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

Two sentences, front-loaded with the resource and its payload, followed by the auth model and the discovery use case. The parenthetical asset lists are dense but each detail earns its place by documenting an otherwise-unspecified return 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?

With no output schema, the description must document the return value, and it does: chains, per-chain depositable/withdrawable assets, decimals, minimum amounts, confirmations, and fees. Nothing an agent needs to call a zero-param catalog 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?

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics for the description to add. The description appropriately spends its words on the return content instead.

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 ('List') and resource ('bridgeable chains ... depositable/withdrawable assets'), and enumerates the per-chain fields returned. It does not differentiate from the near-identical sibling get_bridge_assets, which appears in the sibling list, so an agent has no stated basis for choosing between the two.

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

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

Gives clear selection context: 'Use it to discover valid chain values for the other bridge tools,' which tells the agent exactly when to reach for it. It stops short of naming when-not to use it or explicitly routing against the duplicate get_bridge_assets sibling.

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

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

With no annotations, the description carries the full burden. It does disclose two useful behavioral traits: results are scoped to deposits owned by the authenticated account, and API credentials are required. However, it says nothing about error behavior (e.g., not-found vs not-owned deposits), rate limits, or what a successful response contains.

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 core action, then the ownership scope and auth requirement. Every sentence carries information and there is no padding, though the structure is plain prose rather than a tight single statement.

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 single-resource read with no output schema, the description covers purpose, scope, and auth, which is most of what is needed. It stops short of describing the returned deposit shape or failure modes, leaving a gap an agent might need.

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 single 'id' parameter is fully documented in the schema. The description merely restates 'by id' without adding format, prefix, or validity semantics, so it does not go beyond structured data. 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+resource: fetch a single cross-chain (bridge) deposit. The word 'single' implicitly differentiates it from the list-style siblings (fetch_bridge_deposits, list_bridge_deposits), but no sibling is named explicitly, so an agent must still infer the boundary.

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

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

Usage is only implied: 'single ... by id' suggests this is the lookup-by-identifier counterpart to the listing tools, but there is no explicit statement of when to use this instead of fetch_bridge_deposits/list_bridge_deposits, nor any prerequisite or exclusion guidance.

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

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

With no annotations, the description carries the burden, and it does disclose the read semantics ('List'), result ordering ('newest first'), and an auth requirement ('Requires API credentials'). It does not cover pagination/truncation behavior or error conditions, which is the remaining gap for a paginated list endpoint.

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, and the primary purpose plus ordering are front-loaded before the optional filters and the sibling disambiguation. Every clause earns its place.

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

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

For a 4-parameter, zero-required list tool with no annotations and no output schema, the description covers purpose, filtering, ordering, auth, and sibling differentiation. The only shortfall is that return contents and pagination limits (`limit` max 100) are left entirely to the 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 all four parameters and both enums are already documented. The description restates the filter values (chain, asset USDC|USDX, status detected|confirming|credited|failed) but adds no syntax or semantics beyond the schema, and never mentions `limit`. 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 ('List ... cross-chain (bridge) deposits') and adds scope detail ('authenticated account's', 'newest first'). It explicitly names the sibling it is not (`fetch_deposits`) and explains the distinction (ledger vs bridge), so an agent can disambiguate without opening either 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 the selection context directly: use this for bridge deposits, not ledger deposits, which is called out by name via `fetch_deposits`. The optional filter dimensions (chain, asset, status) further describe when to narrow results. It also states the prerequisite ('Requires API credentials').

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 disclosure burden and does so well: it explains the dead man's switch semantics, states the credential requirement, distinguishes `enabled` (account opt-in) from `active` (opt-in AND exchange switch), and clarifies that `grace_secs` is null when the feature is unavailable. It omits rate-limit and caching behavior, keeping it short of 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?

Front-loaded with the core action, then structured to explain the concept and the three returned fields in order. The sentences are dense but each carries information; the COD explainer is slightly long for a status getter, but nothing is pure 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?

There is no output schema, so the description must describe the return shape, and it does so explicitly for all three fields including the null case. It also covers auth requirements and the scope caveat for REST-only clients, leaving nothing an agent needs before calling 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 there is no parameter surface for the description to clarify. Baseline 4 applies; no parameter-level ambiguity exists to penalize.

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+resource: 'Get the authenticated account's cancel-on-disconnect (COD) status,' and then defines what COD actually is. An agent can grasp the purpose immediately. It falls short of a 5 only because the sibling list contains a near-identical `get_cancel_on_disconnect`, and the description never distinguishes itself from that tool.

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

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

Usage context is implied ('Requires API credentials,' plus the note that REST-only traders are not covered), which scopes who this is relevant for. However, there is no explicit when-to-use/when-not statement and neither `set_cancel_on_disconnect` nor `get_cancel_on_disconnect` is named as a counterpart, so the agent must infer 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?

No annotations are provided, so the description carries the full burden. It does add genuine behavioral context by noting API credentials are required (useful given public siblings like fetch_markets), but it says nothing about pagination behavior, default ordering, rate limits, or result shape.

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

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

Two short sentences, front-loaded with the operation and followed by the auth caveat; no filler. It is appropriately terse for a one-parameter list tool, though the brevity leaves disambiguation gaps that could have been closed in the same space.

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

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

For a simple read tool this would nearly suffice, but the presence of a near-duplicate sibling ('list_deposits') and no output schema means the description should clarify how this differs and what the records contain. Neither is addressed, leaving the agent unable to confidently choose or interpret results.

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 'limit' parameter is fully documented in the schema (max 100), so the baseline of 3 applies. The description adds no format, default, or semantics beyond what the schema already states.

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 (List) and resource (deposit history) scoped to the authenticated account, plus the credential requirement. However, it does nothing to distinguish itself from the near-identical sibling 'list_deposits' (and the withdrawals counterparts), so an agent cannot tell the two apart from the text alone.

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 no when-to-use, when-not-to-use, or alternative routing. With a sibling 'list_deposits' that appears functionally equivalent in the same toolset, the absence of any disambiguation guidance is a real selection hazard.

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 it well: it discloses the ~1h window bound, the 5s sampling cadence, ordering, the credential requirement, and the exact pagination termination condition. These are non-obvious behavioral traits an agent could not infer from the name or 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?

Front-loads the most decision-relevant fact (the narrow ~1h window) and the alternative before the pagination detail. Every sentence carries information, though the pagination explanation runs slightly long relative to what the schema cursor description already states.

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?

No output schema exists, yet the description fully documents the return shape (`{ items, next_cursor }`) and the meaning of each field, plus the loop needed to consume it. For a two-parameter read tool, nothing an agent needs 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it clarifies that `limit` sizes ONE page rather than a total, and frames `cursor` as the value passed back from the previous response. The mechanics of the pagination loop are the notable addition beyond the schema text.

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?

Names a specific resource (the authenticated account's equity time-series) with its defining constraints: 5s cadence, ~1h window, oldest-first ordering. It explicitly distinguishes itself from the sibling `fetch_portfolio_history`, so an agent can disambiguate without opening either 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?

States when to use the alternative ('For a longer window, or for PnL and volume series alongside equity, use fetch_portfolio_history') and gives the operational procedure for exhausting history (call repeatedly with the previous next_cursor until null). Conditions and exclusions are 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the auth requirement and that results are returned newest first, but says nothing about pagination/cursor behavior, rate limits, or what a record contains. For a read tool with zero annotation coverage, that is adequate but not rich.

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 no filler; scope and ordering come first and the credential note closes it out. Every clause carries information an agent needs.

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

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

With no output schema, the description does enough for a simple filtered read: it names the resource, the scope, the ordering, and the auth prerequisite. Missing only pagination/return-shape detail, a minor gap for a two-parameter list tool.

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

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

Schema description coverage is 100%, so both parameters are already documented (limit cap of 1000, market_id example format). The description only restates the optional market filter and adds the 'newest first' ordering hint, adding little beyond the structured data. 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 with scope: 'the authenticated account's funding-payment history', plus ordering and an optional market filter. It is clear what the tool returns, but it does nothing to distinguish itself from the near-identical siblings get_funding_history and get_funding_payments, 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?

It gives the selection context ('authenticated account's', 'optionally filtered to a single market') and a prerequisite ('Requires API credentials'), which implies when it applies. However, it never names or excludes its obvious alternatives (get_funding_history, get_funding_payments, fetch_funding_samples), leaving the agent to guess which funding tool to call.

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 add one genuinely useful behavioral fact: no credentials are required. It is silent on rate limits, pagination/ordering of the history, and whether the series is bounded or continuous, so the disclosure is partial.

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, no filler, with the core purpose front-loaded and the auth caveat immediately after. Nothing here can be cut without losing information.

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

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

For a simple public read tool with 100% schema coverage and no output schema, the description covers purpose, subject scope, and auth requirements, which is close to sufficient. The one omission that matters is disambiguation from the many similarly named funding-history siblings.

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% (both limit and market_id are documented in-schema, including the max-1000/default-300 behavior), so the baseline is 3. The description adds only the 'one market at a time' scoping constraint, which is meaningful but already implied by the required market_id.

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+resource ('Get the funding-rate history') and scopes it to 'one perpetual market', so the operation is unambiguous. It fails to differentiate from near-identically named siblings such as fetch_funding_history, get_funding_history, fetch_funding_samples and get_funding_samples, which is a real gap given the crowded namespace.

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 states the access condition ('Public — no credentials needed'), which tells the agent this can be called without auth. However, it never says when to prefer this over fetch_funding_history, get_funding_history, or fetch_funding_samples, leaving the agent to guess among several plausible alternatives.

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

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

No annotations are provided, so the description carries the full disclosure burden. It states public/no credentials, 60s cadence, and max 480 points / 8h, which tells the agent this is a safe public read, but it does not explicitly state read-only/no side effects 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?

Two tightly written sentences with no waste. The key granularity and scope are front-loaded before the alternative-tool comparison.

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 public read, it supplies cadence, time window, credential requirement, and alternative tool. The main missing piece is any description of returned sample structure, since no output schema exists, and it does not differentiate from get_funding_samples.

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 baseline is 3. The description adds meaning beyond the schema by tying the limit to 'up to 480 points = 8h' and scoping the market_id to one perpetual market.

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?

Combines a specific verb ('Get') with a precise resource ('dense per-tick funding premium-index samples') and scope ('one perpetual market'). It clearly distinguishes itself from fetch_funding_rate_history by granularity.

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?

Names fetch_funding_rate_history as the settled-hourly alternative and gives the selection condition (finer-grained per-tick samples), plus public/no-credentials context. However, it does not address the similarly named get_funding_samples sibling or state explicit when-not conditions.

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 usefully disclose the auth profile ('Public — no credentials needed') and the data source (engine's market registry), which implies a read-only, non-mutating call. It says nothing about behavior for invalid/delisted markets, caching, or rate limits, so the safety picture is only partially filled in.

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 clauses, front-loaded with the verb and resource and followed by the scope and auth note. No filler or redundancy; every phrase 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?

With no output schema, the description responsibly enumerates the return contents (margin requirements and maximum leverage), which is the key thing an agent needs. It is nearly complete for a simple single-parameter lookup, missing only failure/edge-case behavior for unknown market ids.

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% for the single market_id parameter, including a concrete format example ("BTC-USDX-PERP"). The description adds no syntax, casing, or validity rules beyond that, so the schema does all the work; 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 ('Get') plus a scoped resource ('one market's risk parameters') with the actual payload named: margin requirements and maximum leverage. It also names the source of truth (the engine's market registry), which differentiates it from neighbors such as list_market_specs, get_mark_price, and get_market_status.

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

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

The description establishes context ('one market', 'public — no credentials needed') so an agent can infer this is a per-market lookup on the read path. However it never says when to prefer this over list_market_specs or get_market_status, nor does it state what to do if the market id is unknown. Usage is implied rather than guided.

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

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

With no annotations, the description carries the full burden and does disclose the key behavioral traits: this is a read-only public call needing no credentials, and it returns static definitions rather than live summary stats. It stops short of covering pagination, response size, or error behavior, which are minor for a zero-parameter listing.

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, each earning its place: what it returns, the auth posture, and the routing hint. The most decision-relevant content (static specs vs live stats) is 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?

With no output schema and no parameters, the description should convey what comes back, and it does by naming the returned fields (tick size, lot size, leverage, contract details). Nothing essential is missing, though the field list is illustrative rather than exhaustive.

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

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

The tool takes no parameters, so there is nothing for the description to clarify beyond confirming the call is unconditional. Baseline of 4 applies for a 0-parameter tool.

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

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

States a specific verb and resource ('List all markets') and immediately enumerates what the listing contains (tick size, lot size, leverage, contract details). It explicitly separates itself from fetch_markets_summary, so an agent can pick the right tool without opening a schema.

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

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

Gives both the positive condition (static specs, no live stats) and the explicit alternative ('Use fetch_markets_summary for live mark price / volume / funding'). It also states the auth posture (public, no credentials), which is actionable routing information.

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

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

With no annotations, the description carries the full behavioral burden; it does usefully disclose that the endpoint is public and requires no credentials, and it names the returned fields. It does not say whether the call is rate-limited, paginated, or how large the response may be, and read-onlyness is only implied by 'List'.

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

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

A single, front-loaded sentence plus an auth note, with no filler. The most useful information (what it lists and what fields it returns) comes first.

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

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

For a trivial zero-param, no-auth listing tool with no output schema, the description adequately covers the return payload and access model. The remaining gap is sibling disambiguation, which no output schema or annotation would have supplied anyway.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4 and there is nothing for the description to compensate for. No parameter information is missing or required.

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 (List) and resource (tradable markets) and enumerates the payload (mark price, 24h change, volume, open interest, funding), so the agent knows what data comes back. However, it does not distinguish this from near-identical siblings such as fetch_markets, list_markets, fetch_tickers, or fetch_mark_price, which is the main disambiguation need here.

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

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

There is no when-to-use, when-not-to-use, or named alternative guidance at all, despite a crowded sibling set of market-data tools. 'Public — no credentials needed' hints at the auth context but does not tell the agent why to pick this tool over fetch_tickers or fetch_markets.

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 usefully discloses the auth profile (public, no credentials) and qualitatively describes what is returned, but says nothing about rate limits, caching, or response format. It adds genuine value over the bare name but does not fully cover behavior for an unannotated 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?

Two short sentences, purpose front-loaded and the access constraint second. Every clause carries information — nothing is filler or redundant.

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

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

For a simple one-parameter read tool with full schema coverage and no output schema, the description is close to complete: it conveys what is fetched, the possible states, and the no-auth property. The one omission is disambiguation from the 'get_market_status' sibling, which an agent selecting between the two would want.

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%: the single 'market_id' parameter is already documented with an example ("BTC-USDX-PERP") in the schema. The description adds no parameter-level detail, 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?

States a specific verb (get) and resource (a market's trading status) and enumerates the returned states (open, halted, auction), so the agent knows exactly what it retrieves. However, it does not differentiate from the near-identical sibling 'get_market_status', which also exists in the tool list, leaving ambiguity about which to pick.

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 when-to-use or when-not-to-use guidance and no routing to alternatives. Given a sibling 'get_market_status' with essentially the same purpose, the absence of any disambiguation is a real gap. The only contextual cue is 'Public — no credentials needed', which is a property, not usage guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the key trait that this is a public, unauthenticated read, which is genuinely valuable; but it says nothing about error behavior for an invalid market_id, snapshot freshness, or whether the result reflects live or last-known state.

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 scope, followed by the access constraint. 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?

For a single-parameter read with a fully documented schema and no output schema, the description covers action, scope, and auth — nearly enough. The remaining gap is the absence of any disambiguation from get_mark_price, which matters in this densely populated sibling set.

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

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

Schema coverage is 100% and the schema already documents market_id with an example ("BTC-USDX-PERP"), so the baseline is 3. The description's "one market" phrasing adds no syntax or format detail beyond what the schema provides.

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 ("Get the current mark price") and constrains scope to "one market," which is clear. However, it does not distinguish itself from the near-identical sibling get_mark_price (or from fetch_tickers/get_ticker), so an agent cannot tell from the text alone which of these to call.

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?

"Public — no credentials needed" gives useful access context, but there is no when-to-use guidance and no routing versus the sibling get_mark_price or the broader ticker tools. Usage is only implied from the name.

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

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

With no annotations, the description carries the whole burden and mostly succeeds: it discloses the auth requirement, the sort order (newest first), the response shape, and the full pagination contract including that cursors are opaque and must not be constructed. It does not mention rate limits or explicitly confirm the operation is read-only, leaving minor gaps.

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

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

Front-loads what the tool returns and how to page through it; every sentence either states scope, the return contract, or a usage rule. Slight overlap with the schema's `cursor` prose, but the description adds the loop-level view the per-field text cannot.

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?

No output schema exists, so the description takes on return-value documentation and does so completely — naming `items` and `next_cursor` and their roles. Auth, ordering, and pagination termination are all covered; nothing an agent needs to invoke 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 already 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema — notably that `limit` bounds ONE page rather than a total, and that the pagination loop terminates on a null `next_cursor`. That is exactly the kind of clarification a schema cannot easily 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?

States a specific verb and resource — 'List the authenticated account's fills (executed trades)' — and the parenthetical resolves the ambiguous term 'fills'. The qualifier 'authenticated account's' cleanly separates it from the market-wide `fetch_trades`/`get_trades` 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?

Gives explicit operational guidance for the pagination loop: keep calling with `cursor: <previous next_cursor>` until null, and warns that `limit` is per page, not a total. It states the credential requirement. It stops short of naming a specific alternative for public/market-wide trade history, so it lands at clear-context rather than full routing guidance.

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

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

With no annotations, the description carries the full burden and does disclose the key trait — it is a public, credential-free read — plus the default timeframe. It omits other relevant behavior: ordering of returned candles, how limit interacts with defaults, and whether older candles are truncated or rejected.

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

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

Two short sentences, zero filler, with the core action and the scoping constraint front-loaded ahead of the auth note and default timeframe.

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

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

With no output schema and no annotations, the description must carry more weight, yet it says nothing about the shape of a candle record or pagination behavior. It covers market scope, auth, and timeframe adequately but is thin for a data-fetch tool with an opaque return value.

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 market_id, limit (max 1000) and the timeframe enum plus its default. The description only restates the timeframe options and default without adding format, syntax, or edge-case meaning beyond 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 and resource ("Get OHLCV candles") and narrows scope to "one market", so the agent knows it is a single-market candle fetch. However, it never distinguishes itself from the near-identical sibling get_candles, leaving the agent to guess which one to pick.

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?

"Public — no credentials needed" tells the agent this is usable without auth, which is real usage context, but there is no when-to-use/when-not guidance and no mention of the alternative tools (get_candles, get_trades, fetch_trades) that overlap in 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 provided, the description carries the full burden, and it does disclose one real constraint: the call requires API credentials. It does not mention pagination, ordering, rate limits, or the shape of the returned order records, which is the remaining gap for a read 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?

Two short sentences, zero filler, with the purpose leading and the auth prerequisite following. Nothing could be trimmed without losing information.

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

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

For a zero-parameter read tool this covers the essentials, but with no output schema, no annotations, and an indistinguishable sibling (get_open_orders), the description should say more about what is returned and how it differs from that sibling.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No conflicting or undocumented inputs exist.

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 ('Get ... resting (open) orders') and clarifies the scope as open rather than historical or all orders. However, it does not distinguish itself from the near-identical sibling get_open_orders, leaving an agent unable to choose between the two without opening a schema.

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

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

The sentence implies authenticated-account usage but gives no when-to-use guidance, no exclusions, and no routing to the many alternatives (get_open_orders, fetch_orders, fetch_order, get_order_history). With a duplicate sibling present, this omission is costly.

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 it does meaningful work: it declares API credentials are required and discloses a real behavioral quirk — the spec marks `market_id` required for routing while the gateway currently resolves without it. It omits error behavior and rate limiting, but the auth and spec-vs-implementation disclosure is above baseline for an unannotated read 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?

Three compact clauses, front-loaded with what the tool returns, then the parameter nuance and the auth note. No filler; the em-dash aside is informative 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?

With no output schema, the description usefully enumerates the returned fields, and with no annotations it covers auth and the parameter caveat. The main gap is sibling disambiguation against `get_order`, which matters given how many order-readers exist.

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, but the description adds meaning beyond the schema: it explains why `market_id` matters (routing) and clarifies the conflict between the spec's requirement and actual gateway behavior, which the schema alone 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?

Specific verb+resource ('Get a single order by its id') plus the return surface (status, fills, remaining size). It does not distinguish itself from the near-identical sibling `get_order` or from `fetch_orders`/`get_open_orders`, leaving an agent to guess which order-reader to call.

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

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

Gives explicit guidance for when to supply `market_id` and flags the credential requirement, but offers no when-to-use guidance relative to `get_order`, `fetch_orders`, or `get_open_orders`. Usage is implied rather than routed.

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

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

With no annotations, the description carries the full burden, and it does disclose the key behavioral fact that this is a public, credential-free endpoint plus the qualitative content of the response (bids/asks with price + size). It does not say whether the book is a snapshot or streamed, whether depth is limited, or how often it updates.

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 resource and scope and closed with the access requirement. No filler or redundancy.

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, public, single-parameter read tool with no output schema, the description supplies the essential missing pieces: access requirement and the shape of the returned data. It falls short only on depth/update characteristics an agent might want 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 description coverage is 100% and there is a single required parameter, so the schema already documents market_id fully. The description's 'for one market' adds only a restatement of cardinality, so 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?

States a specific verb+resource (get the current order book) and constrains scope to one market, with a note on the returned fields. However, it never distinguishes itself from the near-identical sibling get_orderbook (or the ticker/trades tools), which an agent would plausibly 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 when-to-use or when-not-to-use guidance and no mention of alternatives such as get_orderbook, even though a sibling with an almost identical name exists. 'Public — no credentials needed' gives a contextual cue but not routing guidance.

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

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

With no annotations present, the description carries the full behavioral burden and does it well: it discloses the read-only nature implicitly, the auth requirement, the ordering (newest first), the pagination termination rule, and the exact return envelope. It stops short of rate limits, error behavior, and what happens to non-terminal orders (error vs empty).

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 purpose, then the return shape, then the iteration procedure. Every sentence earns its place; nothing is redundant filler and the pagination instructions are placed after the reader knows what the fields mean.

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?

No output schema exists, so the description correctly supplies the return contract ({ items, next_cursor }) and the termination condition, plus auth requirements. It is close to complete, with only error cases and the distinction from sibling history tools left uncovered.

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