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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety and idempotency are covered. The description adds the scoping constraint (trading accounts only) and the weight-1 rate-limit cost, which is useful, but it omits return shape, pagination, and whether the account must be authenticated. A 3 reflects modest added value over annotations.

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

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

Two short sentences, front-loaded with the verb and resource, then the scope caveat and rate-limit weight. No filler. The title/description duplication ('Get account balances' repeated) is minor waste, keeping it below a 5.

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

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

For a zero-parameter read tool with no output schema, the main missing piece is what the response contains (asset list, available/frozen fields) and any auth prerequisite. Annotations cover safety, but the description leaves the agent without a sense of the return payload or account context.

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

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

With zero parameters, the baseline is 4. There is no parameter surface to document, and the description correctly does not invent any, so nothing is misleading. The scope qualifier is the only parameter-like information needed.

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 account balances') and narrows scope to 'trading account balances (excludes bot and earn accounts)'. That scoping distinguishes it from pionex_wallet_get_balance_full and pionex_earn_*_balances siblings, though it does not explicitly name them. Clear but not maximally differentiated.

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

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

The exclusion of bot and earn accounts implies when this tool is appropriate versus the earn/wallet siblings, but no explicit when-to-use or alternative routing is provided. Usage is implied by the scope note rather than stated.

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

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

Adds value beyond annotations by disclosing that it runs addMarginCheck validation, executes asynchronously, affects available balance and liquidation price, and omits a status field. The 'call with care' warning and async disclosure are genuinely useful. Annotations already cover destructive=true, so this layered context raises it above baseline.

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 validation behavior, async nature, and side effects, ending with weight. All four lines earn their place with no 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?

Covers the async execution, missing status field, validation flow, and balance/liquidation impact, which is thorough for a mutation without an output schema. Could go further on permissions or reversal, but it's substantially complete.

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

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

Schema coverage is 100% and parameters are self-describing. The description adds no syntax, format, or constraint details about coin, amount, or buOrderId beyond what the schema already documents.

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

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

States a specific verb (add/transfer margin) and resource (futures grid order). Distinguishes itself from reduce_margin by naming 'add margin', but doesn't explicitly contrast with the sibling pionex_bot_reduce_margin_futures_grid or the _check variant.

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?

Mentions it runs the same validation as addMarginCheck and executes asynchronously, implying a check-then-execute workflow. However, it never states when to use this vs the check variant or when not to call it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description still adds real value by confirming nothing is executed, disclosing the return content (before/after liquidation prices), noting that openPrice is not accepted and the live market price is used, and stating Weight: 1 (a rate-limit signal not present in structured fields). It does not, however, address the unusual idempotentHint=false on an ostensibly read-only validation.

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 dry-run purpose, then the validation behavior and output, then the openPrice caveat and weight. Every sentence earns its place, though restating the title verbatim as the opening line is mildly 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 output schema, the description compensates by naming what is returned (estimated liquidation prices before and after the change). Combined with the dry-run guarantee, the openPrice note, and the weight figure, an agent has everything needed to call and interpret this tool correctly.

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

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

Schema description coverage is 100% for both parameters, so baseline is 3. The description adds only a negative constraint ('Does not accept openPrice') and does not clarify the semantics of 'amount' as add-vs-reduce (the schema itself says 'add / reduce'), leaving the schema to carry the parameter burden.

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 (validate an add-margin amount on a futures grid bot), states the dry-run semantics ('without executing'), and even names the concrete output ('estimated liquidation prices before and after'). This clearly separates it from the sibling pionex_bot_add_margin_futures_grid (which actually executes) and from the reduce-margin check variant.

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

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

The dry-run framing makes the when-to-use condition clear: validate before committing margin. However, it never explicitly names the execution sibling (pionex_bot_add_margin_futures_grid) as the follow-up action, so the agent must infer the pairing from the naming convention rather than being routed explicitly.

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

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

Annotations already declare readOnly=false, destructive=true, idempotent=false, and openWorld=true, so the safety profile is covered. The description contributes only the rate-limit note 'Weight: 1' and the mode list; it says nothing about the PnL precondition, the PROFIT_LESS_THAN_ZERO rejection, or that investment base may be recalculated after modification — all of which live in the schema, not the description.

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 modes; no filler. Minor waste: the first line simply repeats the tool title verbatim, and 'Weight: 1' is metadata rather than description 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?

This is an 18-parameter, destructive, non-idempotent mutation with no output schema and a dedicated check/preview sibling. The description omits the check-before-execute workflow, the interaction between the many conditional flags, and any indication of failure modes — significant gaps for a tool of this 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?

Schema description coverage is 100% and the schema itself carries detailed conditional semantics (keepInvestment/isReinvest/quoteInvestment precedence). The description adds nothing beyond restating the mode names already in the type enum, 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 ('Adjust futures grid') and enumerates the three modes (add investment, modify range, set trigger investment), which lets an agent distinguish it from sibling mutations like add_margin_futures_grid, reduce_margin_futures_grid, and cancel_futures_grid_order. It does not, however, distinguish itself from its own dry-run sibling pionex_bot_adjust_futures_grid_params_check, nor from the spot equivalent pionex_bot_adjust_spot_grid_params.

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 enumerated modes imply which 'type' values are relevant, but there is no explicit when-to-use guidance, no statement about prerequisites (e.g. validating via adjust_futures_grid_params_check first), and no exclusion of adjacent tools such as add_margin_futures_grid or reduce_futures_grid. Usage must be inferred from the schema's enum rather than the description.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is safe and non-mutating. The description reinforces this with 'without executing' and adds 'Weight: 1' (a rate-limit/cost hint), which is useful. But it does not describe the estimated-data return shape or validation failure behavior, so with annotations carrying the safety profile, a 3 is appropriate.

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 content is front-loaded and efficient: a title line, a one-sentence purpose, a one-sentence usage note, and a weight line. The title is repeated as the first line, which is slightly redundant, but otherwise there is no wasted text.

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

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

This is a read-only check tool with a fully documented 18-parameter schema and no output schema. The description conveys the dry-run nature and the sequencing relative to adjustParams, which is the key context. Given the schema's richness, it is nearly complete; only the preview return content is left implicit.

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 carries extensive per-parameter detail (e.g., isReinvest, keepInvestment, adjustParamsSence precedence rules). The description adds no parameter-level meaning beyond what the schema provides, so the 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?

The description states a specific verb and resource: validate futures grid adjust parameters as a dry-run, returning estimated data without executing. It clearly distinguishes itself as a preview/check tool versus the sibling adjustParams (and pionex_bot_adjust_futures_grid_params). However, it does not name that sibling explicitly, so it falls 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?

It gives explicit when-to-use guidance: 'Use this before calling adjustParams to preview the impact.' This routes the agent to the correct sequence. It does not state when not to use it or name alternatives explicitly, so a 4 rather than a 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is carried structurally. The description adds the 'running order' constraint and a 'Weight: 1' rate-limit note, but says nothing about reversibility, validation failures, or side effects beyond what annotations provide.

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?

Very short and front-loaded: the adjustable fields come before the trailing Weight metadata. Nothing is wasted, though 'Weight: 1' is peripheral to the agent's decision.

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 would ideally note what a successful adjustment returns or how partial parameter usage is treated (e.g. updating only top without bottom). It covers the core action and relies on annotations for safety, leaving moderate gaps for a mutation 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 each of the five parameters (row, top, bottom, buOrderId, quoteInvest) is already documented in the schema. The description only restates the same fields and adds no format, unit, or constraint detail, 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-plus-resource (adjust spot grid parameters) and enumerates what can be modified: grid range (top/bottom/row) or investment. The 'spot' qualifier distinguishes it from the many futures-grid siblings. It does not, however, name the closely related check tool (pionex_bot_check_spot_grid_params) that an agent might otherwise reach for.

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 phrase 'for a running spot grid order' implies a precondition (the grid must already exist and be active), which is useful implicit guidance. But there is no explicit when-to-use/when-not framing and no routing to the check or cancel siblings, so usage is only weakly 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?

Annotations declare destructiveHint=true, readOnlyHint=false, and NOT idempotent. The description adds 'Weight: 1' (rate-limit cost) and 'Close and cancel' but doesn't explain side effects, authorization needs, or what gets destroyed. With annotations covering the safety profile, this is adequate but thin.

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?

Very concise with a front-loaded action. The title is duplicated in the body, which is slightly redundant but not harmful. 'Weight: 1' is a useful operational detail.

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 output schema and no annotations beyond the safety flags, the description is too sparse. It doesn't explain state requirements, what 'close' entails, or what happens on success/failure. The rich schema helps, but the behavioral gap is significant.

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 rich parameter descriptions (especially the detailed immediate flag semantics) are already documented in the schema. The description adds no parameter detail, so baseline is 3, but the schema's unusually clear parameter docs and the 0 required parameters raise this to 4.

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

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

States a specific verb (cancel) and resource (futures grid order), clearly distinguishing it from siblings like cancel_spot_grid_order and cancel_smart_copy_order. The repetition of the title in the body adds no value, but the core action is unambiguous.

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

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

No guidance on when to use this versus alternatives like reduce_futures_grid or pause_futures_grid, or when a close is appropriate. No prerequisites or state requirements are mentioned.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the safety profile is covered. The description contributes the 'close' nuance (assets/positions are wound down, not merely terminated), but says nothing about irreversible liquidation of holdings or what happens to remaining funds beyond the schema's convert_into_earn_coin flag.

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?

Very short and front-loaded: the action verb and resource lead, with the clarifying sentence second. The 'Weight: 1' API metadata is minor noise that does not help an agent, but the rest 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?

With full schema coverage and annotations present, the essential mechanics are covered, and no output schema means return values need not be explained. However, for a destructive bot-closing operation the description omits what happens to open positions and funds on close, which an agent should know before invoking.

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 close_note, bu_order_id, and convert_into_earn_coin are already explained in the schema. The description adds no syntax, format, or behavioral detail about these parameters, so baseline 3 applies.

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

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

States a specific verb (cancel) and resource (smart copy bot order), and the second line clarifies the action also closes the bot order. It is distinguishable from its many sibling cancel tools (spot grid, futures grid, plain order cancellation) by naming the smart-copy resource explicitly.

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

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

No guidance on when to use this versus pionex_bot_reduce_futures_grid, pionex_bot_profit_spot_grid, or the other bot-termination siblings, and no stated prerequisites (e.g., bot must be running, ownership). The agent must infer usage entirely.

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

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

Annotations already declare destructive=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds that the operation both closes and cancels (implying position liquidation, not just order removal) and gives 'Weight: 1' for rate-limit budgeting, which is genuine value beyond the structured fields.

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 lines with no filler, though the first line is a verbatim restatement of the title, which is mild redundancy. The actual behavioral content is front-loaded and easy to parse.

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

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

For a destructive mutation tool with no output schema, the description omits what happens after cancellation (funds returned, base sold per closeSellModel, timing) and any prerequisite conditions. Schema and annotations cover the mechanics and safety hints, so this is adequate but not thorough.

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% – buOrderId, slippage, and the closeSellModel enum are fully documented in the schema. The description adds no syntax or format detail on top, 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+resource: 'Close and cancel a spot grid bot order.' The 'spot grid' scope implicitly distinguishes it from pionex_bot_cancel_futures_grid_order, but the description never names that sibling explicitly, so differentiation rests on the reader parsing similar names.

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

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

No when-to-use, when-not-to-use, or alternative guidance is offered. The only signal is the tool name itself; nothing tells the agent when to cancel a spot grid bot versus adjusting, reducing, or pausing it (all of which have 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'without creating an order'. Beyond that, it discloses rich behavioral detail: automatic market-price fetching, the FailedWithData contract (data field present even when result=false), and a full validation-error table mapping causes to messages and whether partial data is returned. This is far beyond what the annotations provide.

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 tables are information-dense and well organized, but the definition is long and includes some redundancy with the schema (e.g., repeating that base must end with .PERP). Still, every section earns its place for a validator with complex mode semantics; front-loaded purpose statement is good.

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 validator tool with no output schema, the description fully covers what the agent needs: input semantics under both margin modes, automatic price fetching, the FailedWithData response shape, and a complete error taxonomy with associated data flags. Nothing material 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 only 67%, but the description compensates extensively: the extra_margin mode table redefines quote_investment, extra_margin_amount, estimate_investment, and min/max_investment semantics per mode, and the validation table maps each parameter (base, trend, grid_type, bottom, top, row, leverage, condition_direction, quote_investment) to its constraint and error message. This adds substantial 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 (validate/estimate) and resource (futures grid bot creation parameters) and explicitly contrasts with the sibling pionex_bot_create_futures_grid_order by saying 'without creating an order'. An agent can immediately tell this is the dry-run/pre-flight validator.

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?

Clear context: validate parameters and estimate investment values without creating an order. It implies this precedes creation but doesn't explicitly name pionex_bot_create_futures_grid_order as the follow-up or state when not to use it. Strong usage signal without explicit 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the required 'Bot reading' permission scope, the weight value, and the concrete outputs (max investment, max leverage, notional/available 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 action, then permission requirement, then return values, in a few tight sentences. No filler, and the most decision-relevant facts (purpose, permission, what comes back) appear 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?

With no output schema, the description usefully enumerates what is returned, and it discloses the permission prerequisite. It is complete enough to invoke correctly; only the relationship to the create tool is left implicit.

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

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

Schema description coverage is 100%, so every parameter (base, quote, leverage, signal_type, signal_param, quote_investment) is already documented in the schema. The description references the 'base/quote/signal combination' only in passing and adds no format, range, or validation detail beyond the schema — baseline 3.

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 (validate/check) and resource (smart copy bot creation parameters, max investment limit), and the word 'smart copy' cleanly separates it from the futures/spot grid param-check siblings. It stops short of naming the create_smart_copy_order sibling it gates, so it is clear but not fully differentiated.

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

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

Usage is only implied: an agent infers this is a pre-flight validation step before pionex_bot_create_smart_copy_order. There is no explicit 'use before creating' statement, no when-not, and no pointer to the sibling that consumes the validated parameters.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description is consistent with these. Beyond that it discloses the weight (1), the FailedWithData behavior (a `data` field with min/max investment and slippage even on result=false), automatic market price fetching, and a detailed table of validation error messages and causes.

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

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

Front-loads the core purpose and key rules before the error table. The validation-error table is long but each row carries distinct, actionable information; minor redundancy between prose and table.

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 carries the return-shape burden and does so for the failure path (data field, min/max investment, slippage). It is largely complete for a validation/estimation tool, though the success-path estimate fields are only summarized.

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 67%, and the description richly compensates: it specifies that quote_total_investment must be positive, that `top`/`bottom` have numeric/k-digit constraints, the row range [2,1000], grid_type enum values, and precision limits. It adds meaning beyond the schema, though the description could more directly tie these constraints to the named parameters.

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

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

States a specific verb+resource+scope: 'Validate spot grid bot creation parameters and estimate investment values without creating an order.' This distinguishes it from the sibling pionex_bot_create_spot_grid_order by making clear it is a non-mutating dry run.

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

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

Clearly implies when to use it (pre-flight validation before creating a spot grid bot) and notes it does not create an order. However, it does not explicitly name the alternative sibling (e.g., create_spot_grid_order or check_futures_grid_params) or state when NOT to use 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered by structured data. The description adds only 'Weight: 1' (a rate-limit detail) and omits notable behavioral traits such as the irreversibility of creating a bot, the funding/margin requirement, and the copy-trading pool side effect documented in copyBotOrderId.

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?

Very short and front-loaded, with no wasted prose. The only inefficiency is the opening line duplicating the tool title before the actual definition 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?

This is a destructive creation tool with a deep nested buOrderData object (30+ fields), no output schema, and a copy-pool side effect, yet the description says nothing about prerequisites, expected outcomes, or the check-params workflow. For a tool of this complexity the description is materially incomplete.

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 83%, which is high, so the schema already carries parameter meaning and the baseline is 3. The description supplies no parameter context whatsoever, neither explaining the buOrderData payload nor the copyFrom/copyBotOrderId semantics, so it does not go 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?

Names a specific verb (create) and resource (futures grid bot order), and the 'futures' qualifier does separate it from the sibling pionex_bot_create_spot_grid_order by implication. However, the first line merely restates the tool title, so the definition adds no genuine differentiation beyond the name itself.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as pionex_bot_check_futures_grid_params, which is the obvious validate-before-create sibling in this grid tool family. The agent gets no routing help for choosing this over the spot grid or check variants.

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

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

Annotations already declare the safety profile (destructiveHint=true, openWorldHint=true, idempotentHint=false), so the description is not the sole carrier here. It adds the API rate-limit cost ('Weight: 1'), which is genuine behavioral information not present in annotations, but it says nothing about funds being committed or the consequences of the destructive create.

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?

Very short, which is good, but the first sentence is a verbatim copy of the title and the second restates the same purpose, so two of three lines are redundant. Only 'Weight: 1' carries new information, meaning little of the text 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?

This is a complex, nested, destructive creation tool with no output schema and 7 parameters, yet the description explains none of the portfolio/investment semantics, no validation step, and no post-create behavior. For a live trading-bot creation endpoint, the description is materially under-specified.

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 86%, so the schema already documents base/quote/bu_order_data and the nested portfolio fields in detail. The description adds no parameter meaning whatsoever, 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 ('Create') and resource ('smart copy bot order'), and the 'smart copy' qualifier implicitly separates it from the grid-order creation siblings. It stops short of naming or routing against those siblings, so it is clear but not fully differentiating.

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

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

No when-to-use or when-not-to-use guidance. In particular it never mentions the sibling pionex_bot_check_smart_copy_params, which an agent would plausibly need to validate parameters before creating a live bot, nor does it state prerequisites such as funded balance or a source signal.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered by structured data. The description adds only 'Weight: 1' (rate-limit cost) and otherwise says nothing about the fact that this commits real capital into a live trading bot or what happens on partial failure.

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

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

It is short and front-loaded, and 'Weight: 1' is an efficient rate-limit note. But the first two lines are redundant restatements of the tool name and title, so part of the brevity is duplication rather than economy.

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, capital-committing bot-creation call with a 4-parameter nested schema, no output schema, and many sibling lifecycle tools, the description is far too thin. It omits prerequisites, the check-params workflow, and any caution about funds being deployed, leaving the agent under-informed.

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 75% and the nested buOrderData object is heavily documented (grid levels, stop/profit types, delays, sell modes), so the schema carries the detail. The description adds nothing beyond that baseline, which is the expected 3 when coverage is high.

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 clear verb+resource: 'Create a new spot grid bot order,' which unambiguously conveys the operation. However, it does not differentiate this tool from the near-identical sibling pionex_bot_create_futures_grid_order or the related spot-grid lifecycle tools (check/adjust/cancel), so an agent gets the action but no disambiguation.

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 reference to alternatives. It never mentions that pionex_bot_check_spot_grid_params should typically be run first, nor does it distinguish itself from creating a futures grid order. Only implied usage is available.

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

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

Annotations already declare the safe/unsafe profile (destructiveHint=true, idempotentHint=false), and the description usefully adds the authorization requirement and a hard quota (100 signals). It does not disclose what happens on quota exhaustion or what the created object looks like, but the added auth/quota context is real value beyond the annotations.

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

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

Short and front-loaded, with the permission requirement bolded at the end. The opening line restates the title almost verbatim ('Create user custom signal' / 'Create a new user-defined signal'), which is a small redundancy but the rest 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 two-parameter creation tool with no output schema and rich annotations, the description covers the essentials: what is created, the auth requirement, and the per-user quota. Only the failure behavior at the quota boundary and confirmation of request/response shape are left unaddressed.

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

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

Schema description coverage is 100% and both parameters (title, description) carry their own max-length descriptions, so the schema does the heavy lifting. The prose adds no format or content guidance for the signal name or description beyond what the schema already states, making the baseline 3 appropriate.

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

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

States a specific verb (create) and resource (user-defined signal), which cleanly separates it from the sibling edit/delete/list/get user-signal tools. It is clear and unambiguous, though it does not explicitly name the alternative tools the way a top-tier definition would.

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 prerequisites (requires `Bot trading` permission, max 100 signals per user) rather than usage routing. It never says when to choose this over pionex_bot_edit_user_signal or pionex_bot_list_user_signals, so an agent must infer the create-vs-modify boundary from the name alone.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds substantial behavioral context beyond annotations: it names the required permission scope and specifies the failure condition and error code (SIGNAL_HAS_UNCLOSED_ORDERS with data.cnt), which an agent needs to handle errors correctly.

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

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

The description is effectively sized and front-loads the core action, permission requirement, and failure condition. It slightly duplicates the title by repeating 'Delete user custom signal' as the first line, but overall it is tight and 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 one-parameter destructive mutation with no output schema, the description covers the essentials: required permission, failure condition, and error response format. Combined with annotations that already signal destructive/idempotent behavior, an agent has enough context to invoke and handle the tool correctly.

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

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

Schema description coverage is 100%; the sole parameter 'signalType' is already documented in the schema as 'Signal type identifier'. The description adds no additional meaning about the parameter's format, accepted values, or source, 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 ('Delete') and resource ('user custom signal' / 'user-defined signal'), clearly distinguishing it from sibling tools like list_user_signals, create_user_signal, get_user_signal, and edit_user_signal. An agent can identify its function 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 a clear prerequisite ('Requires Bot trading permission') and an exclusion condition ('Deletion is rejected if the signal has any non-cancelled orders'), which is useful when-not guidance. However, it does not explicitly name alternatives such as edit_user_signal or signal_listener, so it falls short of full when/when-not/alternatives coverage.

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

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

Annotations cover mutation semantics (readOnlyHint=false, destructiveHint=true, idempotentHint=false), so the safety profile is already declared. The description adds useful non-annotation context: the required 'Bot trading' permission and the constraint that at least one field must be provided, both of which affect how the tool can be invoked.

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

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

The description is front-loaded with the purpose, followed by the constraint and permission requirements in short, discrete lines. Every sentence contributes useful information with no filler.

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

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

For a 3-parameter mutation tool with no output schema, the description covers purpose, permission requirement, and the at-least-one constraint, which are the key operational facts. It stops short of describing what the updated signal looks like or whether edits are reversible, but the essential calling requirements 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 coverage is 100%, with title and description documented including max lengths, so the schema carries the parameter burden. The description restates the 'at least one of title/description' rule, which adds the mutual-dependency constraint not expressed in the schema, but doesn't add format or syntax details beyond that.

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

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

States a specific verb (Edit) and resource (user custom signal), and the body clarifies it updates title/description of an existing user-defined signal. This distinguishes it clearly from pionex_bot_create_user_signal, pionex_bot_get_user_signal, and pionex_bot_delete_user_signal.

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 states the requirement 'At least one of title or description must be provided' and the 'Bot trading' permission requirement, which gives some invocation context. However, it offers no explicit when-to-use guidance versus siblings like the create or delete variants, leaving the agent to infer applicability.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description goes beyond them usefully by disclosing pagination support and the rate-limit cost ('Weight: 1'), which an agent cannot get from the annotations.

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

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

Short and front-loaded: the verb+resource leads, followed by filters and pagination/weight in two compact sentences. The only waste is the title restated as the opening line, a minor 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?

With no output schema and no required parameters, the description covers what an agent needs: the filter categories and the fact that results are paginated. It would be stronger if it pointed to the response's nextPageToken, but the schema's pageToken description already supplies that link, so the definition is essentially complete.

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

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

Schema description coverage is 100%, so each of the five parameters is fully documented in the schema itself (including the default status and the supported order-type values). The description merely restates the filter categories at a high level, adding no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Get bot order list') and enumerates the filterable fields, so the agent knows it retrieves bot orders rather than a single bot order. It does not explicitly distinguish itself from close siblings like pionex_bot_get_spot_grid_order or pionex_bot_get_futures_grid_order, so sibling differentiation is left implicit.

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

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

The phrase 'Query bot order list with optional filters' implies the usage context, and 'Supports pagination' hints at iterative calls, but there is no explicit when-to-use/when-not-to-use guidance or named alternative for fetching a single bot order. Usage is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'Weight: 1' (a rate-limit cost), which is genuinely useful context not present in structured fields, but says nothing about what the returned order 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?

The description opens by repeating the title verbatim, which is waste, then gives one efficient sentence plus the weight note. Front-loaded enough, but the title duplication costs it.

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-only lookup with a fully documented 2-parameter schema and no output schema, the description is minimally adequate. It lacks any indication of what fields the returned futures grid order will contain, which an agent calling this cold 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 description coverage is 100% and the schema documents both buOrderId and lang. The description's 'by ID' merely echoes the required parameter, adding no format or source detail 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?

The sentence 'Query a futures grid bot order by ID' names a specific verb and resource, and the 'futures' qualifier distinguishes it from pionex_bot_get_spot_grid_order. It does not, however, differentiate itself from pionex_bot_get_bot_orders or other order-lookup siblings.

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

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

There is no guidance on when to use this tool versus pionex_bot_get_bot_orders, pionex_orders_get_order, or the various check/adjust futures grid tools. The agent is left to infer usage purely from the name.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds useful context such as rate-limit weight (Weight: 1) and pagination/sorting support, but does not describe return values, authentication needs, or detailed rate-limit behavior.

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

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

The description is short and front-loaded, with the core purpose stated first and supporting details after. The opening line restates the title/name, which is mildly redundant, but overall there is little 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 read-only list tool with full parameter schema coverage and clear safety annotations, the description supplies the needed purpose, filter capabilities, pagination, sorting, and weight. The lack of return-value detail is a minor gap given there is no output schema, but the definition is otherwise complete for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all ten parameters. The description repeats some filter concepts (symbol, trend, leverage, pagination, sorting) but adds no syntax, format, or constraint details 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 (query KOL curated/pinned copy-trade order list) and names key scope details like share code, symbol, trend, and leverage filters. It clearly distinguishes this from generic order-list tools, though it does not explicitly contrast with sibling tools.

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

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

The description implies when to use it—when retrieving a KOL's curated/pinned copy-trade order list by share code—but provides no when-not guidance, prerequisites, or explicit alternatives. Usage is clear enough but left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, covering the safety profile. The description adds 'Weight: 1', useful rate-limit context beyond the annotations, but says nothing about response contents 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?

Very short and front-loaded, with no filler. Minor redundancy in restating the title, but the core sentence and weight note are efficiently placed.

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-by-ID tool with full schema coverage and rich annotations, this is minimally adequate. It lacks any statement of what the returned order contains or how it relates to the smart-copy workflow, but nothing critical for 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%, so buOrderId (UUID) and lang are fully documented in the schema. The description's 'by ID' adds little beyond the schema's own description, 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: 'Query a smart copy bot order by ID.' This distinguishes it from product-type siblings like get_spot_grid_order and get_futures_grid_order by naming the smart copy bot resource. However, it doesn't explicitly contrast with listing tools such as get_bot_orders, so it is clear but lacks explicit sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives (e.g. get_bot_orders for listing, create/cancel for mutations). The only cue is the implicit 'by ID' lookup, which the agent must infer from the parameter name rather than from prose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds essentially no behavioral context of its own — it doesn't say whether the AI recommendation is deterministic, sourced from a model, or what constraints apply, beyond the word 'AI-recommended.'

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 body is one useful sentence, but it is front-loaded with a verbatim repeat of the title/tool name, and 'Weight: 1' is dangling jargon that isn't explained. Two of the four lines do little work.

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 read-only, two-parameter tool with no output schema, the description is minimally adequate but leaves the agent guessing what the returned strategy parameters are and how this tool relates to the grid-order and param-check siblings. It is complete enough to invoke, not enough to choose confidently.

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

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

Schema coverage is 100% with both base and quote documented (BTC/USDT examples), so the schema already carries the parameter semantics. The description adds nothing about pair formatting or required-ness beyond what the schema states — the baseline 3 is appropriate.

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

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

The description gives a specific verb+resource: 'Query AI-recommended grid strategy parameters for a trading pair,' which is clearer than the title alone. It does not, however, distinguish itself from near-siblings like pionex_bot_get_spot_grid_order or pionex_bot_check_spot_grid_params, so an agent must infer which one returns AI recommendations.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as check_spot_grid_params or get_spot_grid_order. The trailing 'Weight: 1' is API rate-limit metadata, not usage guidance, and is unexplained.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds only the API weight (Weight: 1), which is minor extra context; it doesn't disclose return shape, error behavior, or rate-limit implications beyond weight.

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, front-loaded sentences with no filler. The title repetition ('Get spot grid order') is slightly redundant with the title field but not harmful.

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 annotation coverage and a rich sibling set, the minimal description is adequate but thin. It lacks return-value context (no output schema) and doesn't help the agent distinguish this from pionex_bot_get_bot_orders or the futures grid getter.

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% for the single parameter (buOrderId: "Bot order ID"), so the schema already documents it fully. The description adds no format, prefix, or source guidance for obtaining the ID, 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 (query/get), resource (spot grid bot order), and the lookup key (by ID). It is distinguishable from the futures counterpart (pionex_bot_get_futures_grid_order) and from the order-creation sibling, though it doesn't explicitly 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?

Implied usage: the agent should call this to retrieve a single spot grid bot order. There is no explicit when-to-use vs. pionex_bot_get_bot_orders or the futures grid variant, nor any stated prerequisites such as needing a valid buOrderId.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds two things annotations cannot: it requires the 'Bot reading' permission and it states the API weight (1). These are genuine, actionable operational facts for an agent.

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?

Compact and front-loaded: purpose sentence, then the returned content, then weight and permission. The first line repeats the title verbatim rather than starting with the richer sentence, a small redundancy, but overall there is little 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 single-item read with no output schema, the description tells the agent what is returned (webhook URL, message template), what permission is needed, and the call weight. That covers the essentials; only the routing vs sibling tools 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?

Only one parameter with 100% schema description coverage, so the schema carries the semantics baseline. The description only implies that 'a specific user-defined signal' is selected by signalType; it adds no format, accepted values, or lookup-failure information 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') and resource ('user custom signal detail'), and the body clarifies it returns one user-defined signal including webhook URL and message template. It is distinguishable from pionex_bot_list_user_signals by being single-item, though it never names that sibling explicitly.

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

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

There is no 'use this when' guidance and no mention of the natural alternatives (pionex_bot_list_user_signals for enumeration, pionex_bot_signal_listener, or edit/delete siblings). The required signalType implies a detail lookup, but the agent must infer when this tool is preferable to its 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?

Annotations already declare destructiveHint=true and idempotentHint=false, so the bar is lower, yet the description adds almost nothing beyond the 'running order' precondition. It does not disclose that real funds are committed, whether the quote amount is pulled from available balance, minimum amounts, or any rate/permission constraints for what is effectively a fund-moving operation.

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

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

The first line duplicates the title verbatim and 'Weight: 1.' is metadata noise, so the prose is not fully earning its place. The body is short and front-loaded, but a third of it is 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 destructive financial mutation with no output schema, the description omits what happens on success or failure, whether grid state is altered, and when the operation is appropriate. The well-covered schema and existing annotations carry some of the load, but the definition is still thin for this operation.

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% for both parameters (buOrderId and quoteInvest are fully documented in the schema), so the baseline is 3. The description adds no formatting, currency, or minimum-value detail beyond what the schema already 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?

The description names a verb and resource ('add investment to a running spot grid order'), but the first line merely restates the title, and the second line extends it only marginally. It never distinguishes this from the many sibling spot-grid tools (adjust_spot_grid_params, create_spot_grid_order, get_spot_grid_order) or from the futures counterpart add_margin_futures_grid.

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

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

There is no guidance on when to use this tool versus adjust_spot_grid_params or add_margin_futures_grid, and no stated prerequisites beyond the implied 'running' grid. The agent must infer everything about context from the name alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds valuable non-annotation context: the paginated nature (via pageToken) and the required 'Bot reading' permission, which is a genuine auth prerequisite. It still omits the return shape, but with no output schema that's a minor gap.

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 plus an operational note, front-loaded with the verb+resource. The title line is duplicated as the first sentence, which is slight redundancy, but overall it's efficient and earns its 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 single-parameter read-only list tool with full schema coverage, this covers purpose, permission prerequisite, and pagination. Nothing an agent critically needs is missing, though return-value expectations are unstated (no output schema exists).

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 pageToken parameter is fully documented in the schema. The description adds 'Return a paginated list', which corroborates the pagination semantics but contributes nothing the schema doesn't already say. Baseline 3 per rubric when 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 (List) and resource (user custom signals), and the body clarifies 'user-defined signals'. It does not explicitly differentiate from siblings like pionex_bot_get_user_signal (singular) or pionex_bot_signal_listener, though the plural 'list' and 'paginated list' give a reasonable hint.

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 permission prerequisite ('Requires Bot reading permission') but no explicit when-to-use or when-not-to-use guidance relative to the singular get_user_signal sibling. Usage is implied by the list semantics rather than stated.

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

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

Beyond the annotations (destructive, non-idempotent), the description adds meaningful traits: asynchronous execution, that the grid stops auto-refilling while the position is retained, and that no `status` field is returned. It stops short of explaining what 'destructive' entails for the user, but the added async/retention context is substantive.

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 text is front-loaded and short, leading with the action and then adding async behavior and retention details. The opening line repeats the title and 'Weight: 1' is API metadata, minor redundancy, but overall it earns its length.

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 an async destructive mutation with no output schema, the description covers the key gaps: async processing, no status returned, and position retention. It could say more about reversibility or the effect of the stop-loss/profit flags, but it is largely complete.

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

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

Schema coverage is 100%, so the schema already documents all six parameters including the mode enum, trigger prices, and stop-loss/profit toggles. The description only restates that immediate mode uses the live market price, adding marginal value over 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?

The description states a specific verb and resource ('Pause a running futures grid order') and the title mirrors it, so an agent immediately knows the operation. It does not explicitly contrast itself with close siblings like resume, cancel, or reduce, but the action is unambiguous.

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

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

It hints at the workflow by noting it 'Runs the same validation as `pauseCheck`', implying the check tool precedes it, and that 'immediate' mode acts at live market price. However, it never states when to use pause vs resume, cancel, or reduce, nor any prerequisite/exclusion 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, confirming a safe read operation. The description adds valuable context: it's a dry-run, returns current and post-trigger estimated liquidation prices, and doesn't accept openPrice. It doesn't detail rate limits or response format, but with annotations covering safety, this is good.

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

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

The description is concise, front-loaded with the core purpose, and includes only necessary details. Every sentence earns its place, and the weight note is brief.

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

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

Given no output schema, the description explains what the tool returns (current plus post-trigger estimated liquidation prices) and the dry-run nature. It also clarifies the openPrice exclusion. It could mention whether it requires specific permissions or the response structure, but it's largely complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, so the schema already documents all parameters in detail, including enums and optionality. The description adds some clarification about triggerPausePriceUp/Down being independent, but that's already in the schema. Baseline 3 is appropriate when 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?

The description clearly states the specific action (validate whether a futures grid order can be paused) and explicitly notes it's a dry-run that does not execute. It distinguishes itself from the sibling tool pionex_bot_pause_futures_grid by clarifying this is a check/dry-run operation.

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 clarifies that the tool does not execute and returns estimated liquidation prices. It also notes that openPrice is not accepted and the backend uses the live market price. However, it doesn't explicitly say when to use this vs. the non-check version, though the dry-run nature is 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds essentially no behavioral context beyond the annotations: it does not say whether the grid keeps running after extraction, whether repeated calls extract again, or where the funds go. 'Weight: 1' is the only extra operational detail.

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?

Very short and front-loaded, with the key action first. The opening line repeats the title verbatim, which is minor waste, and 'Weight: 1' is a useful trailing detail.

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 tool with no output schema, the description is minimally adequate but leaves notable gaps: the effect on the still-running grid, the destination of the extracted profit, and whether the amount must not exceed accumulated profit are all unstated.

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

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

Schema description coverage is 100% and both parameters (amount, buOrderId) are documented in the schema, so the baseline of 3 applies. The description adds no meaning beyond the schema, e.g., whether 'amount' is capped by accumulated profit or has a minimum.

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 ('extract') and resource ('accumulated grid profit') scoped to a running spot grid order, which distinguishes it from sibling read tools like pionex_bot_get_spot_grid_order. It is clear but does not explicitly contrast itself against the many sibling bot tools.

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

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

The phrase 'from a running spot grid order' implies a precondition, but there is no explicit when-to-use guidance, no mention of alternatives (e.g., cancel vs. adjust vs. profit extraction), and no stated prerequisites such as available profit balance.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The only added behavioral context is 'Weight: 1', a rate-limit detail, which is a small but genuine contribution. Nothing is said about reversibility or side effects on the grid strategy.

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?

Very short and front-loaded. The first line merely restates the title, which is mild redundancy, but there is no filler beyond that.

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 trading mutation with six parameters and no output schema, the description covers the action but omits prerequisites, the relationship to its check variant, and what a successful reduction does to the running grid. Adequate but with clear gaps.

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

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

Schema coverage is 100%, so all six parameters (including the condition/conditionDirection trigger pair and the reduceNum precision multiplier) are documented in the schema itself. The description adds no param meaning beyond that, 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: 'Reduce position size of a futures grid order.' This is distinguishable from reduce_margin_futures_grid on the surface, but the description never mentions the near-identical _check sibling or any other grid tool, so differentiation is left to the name.

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

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

No when-to-use guidance, no prerequisites, and no mention of pionex_bot_reduce_futures_grid_check, which the naming convention strongly implies is a required validation step. The agent must infer timing and ordering entirely.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context by stating no execution occurs and estimated data is returned, which is useful. However, it does not disclose return format details or any validation failure behavior, and the schema already documents parameters.

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

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

The description is three short, front-loaded sentences with no filler. The inclusion of 'Weight: 1' is a minor but arguably unnecessary detail that slightly detracts from pure conciseness.

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

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

Given 6 parameters with full schema coverage, no output schema, and annotations that cover safety, the description supplies the essential dry-run concept and usage hint. It is complete enough for correct invocation, though it could mention that no state changes occur beyond the annotation hints.

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 fully documents all six parameters including enums and required fields. The description adds no parameter-level meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description clearly states a specific verb (Validate/Check) and resource (futures grid reduce), and adds that it is a dry-run returning estimated data without executing. It does not explicitly name the sibling pionex_bot_reduce_futures_grid as the execution counterpart, leaving some differentiation to inference, but the dry-run scope is clear.

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

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

The description provides a clear when-to-use ('Use this before calling reduce to preview the impact'), directly pointing to the execution tool. It does not spell out when-not-to-use or other alternatives, keeping it short of a 5.

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

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

Annotations already cover the safety profile (destructiveHint=true, readOnlyHint=false), yet the description adds substantive context: asynchronous execution, absence of a returned status field, the maxAmount validation, and raised liquidation risk. This is meaningful disclosure beyond the structured fields.

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 action and resource, then layers constraints and warnings in short sentences. The "Weight: 1" line is extraneous but minor; nothing else is wasted.

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

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

With no output schema, the description helpfully notes the missing status field, and annotations carry the safety profile, so an agent has enough to invoke it correctly. Only explicit usage/alternative routing is absent.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description only echoes the amount semantics via the maxAmount reference and adds no syntax or format detail, 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 ("Transfer margin out of a futures grid order") that clearly separates it from the sibling add_margin tool. It does not explicitly name siblings, but the operation is unambiguous.

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

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

It implies the companion validation tool ("Runs the same validation as reduceMarginCheck") and warns "call with care," but gives no explicit when-to-use vs. when-not guidance or prerequisites. Usage must be inferred from the cautionary tone.

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

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

Annotations already mark this as a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower, and the description still adds real behavioral value: it returns estimated liquidation prices before/after, reports failure via checkResult=false with reason EXCEEDS_MAX_AMOUNT, and discloses Weight: 1 for rate-limit budgeting. It does not contradict any annotation.

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?

Tight and front-loaded: the dry-run nature and validation behavior come first, then the error contract, then the weight. The opening line restates the title almost verbatim, which is minor redundancy, but nothing else is wasted.

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

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

With no output schema, the description carries the return-value burden and does so adequately by naming liquidation prices before/after and the checkResult/reason failure shape. What is missing is the explicit relationship to the executing counterpart tool, which matters given the large 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 both parameters are documented in the schema, so the baseline is 3. The description references the maxAmount hard limit and the amount semantics but adds no format or constraint detail beyond what the schema already carries.

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 (check/validate) and resource (futures grid reduce-margin), and the '(dry-run)' plus 'without executing' framing cleanly separates it from the mutating sibling pionex_bot_reduce_margin_futures_grid. It stops short of naming that sibling explicitly, so an agent must infer the pairing rather than being told.

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

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

Usage is implied rather than stated: the tool validates a reduce-margin amount before committing, which naturally precedes pionex_bot_reduce_margin_futures_grid. There is no explicit 'use this before X' or when-not-to-use guidance, and no statement about required auth or prerequisites.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is known. The description adds useful context that after resuming the grid restarts auto-refilling and the liquidation price moves with the market. However, it does not mention required permissions or confirm irreversibility beyond what annotations imply. With annotations covering safety, a 3 is appropriate.

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

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

The description repeats the title 'Resume futures grid order' and then provides a paragraph. The repetition is mild waste, but the operational details (auto-refilling, liquidation price movement) are front-loaded well after the redundant opening.

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 tool with annotations, the description covers the essential behavior: it runs validation then executes, and explains a behavioral side effect (auto-refilling, liquidation price adjustment). The main gap is lack of explicit prerequisite (order must be paused).

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

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

Schema coverage is 100% and the single parameter buOrderId is documented in the schema as 'Bot order ID'. The description does not add format or source details for buOrderId. Baseline 3 is correct when schema fully documents parameters.

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

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

The description states a specific verb (Resume) and resource (paused futures grid order), and distinguishes itself from siblings like pionex_bot_resume_futures_grid_check by noting it 'executes' after validation. This clearly separates it from the check variant and from pause/cancel siblings.

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

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

The description implies usage by referencing the resumeCheck validation flow, which hints that this should be used after the check passes. However, it does not explicitly state when to use this vs. the check tool, nor does it note that the order must be paused first.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context: it returns estimated liquidation prices after resuming without executing, and requires the order to be paused. It could still state what happens on a failing validation response, but the added context is useful.

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

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

The description is short and front-loaded, with the dry-run behavior stated first and the precondition last. A little of the wording repeats the title, but it is 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?

Given one required parameter, full schema coverage, no output schema, and read-only annotations, the description provides enough to invoke correctly. It explains the dry-run result and paused-state precondition; only failure behavior is left unspecified.

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 buOrderId parameter is documented in the schema. The description does not add syntax or format detail beyond that, 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 states a precise verb+resource+scope: it validates whether a paused futures grid order can be resumed and returns estimated liquidation prices after resuming, without executing. It clearly distinguishes itself from the sibling write tool pionex_bot_resume_futures_grid, since this is the dry-run counterpart.

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

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

It gives a clear usage condition: the order must be in 'paused' state, and the description makes the dry-run nature explicit compared to the real resume tool. It does not explicitly name the alternative sibling, but the check/execute split is strongly 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description adds real value beyond that with the required 'Enable trading' permission and the 'Weight: 1' rate-limit hint, but it never explains what the signal affects, its reversibility, or the response.

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?

Brief and front-loaded, but the title 'Push custom trading signal' is redundantly restated as the first body line, wasting the opening sentence. The remaining lines (weight, permission) are compact but the duplication hurts structure.

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

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

For a 7-parameter, destructive, nested-object tool with no output schema, the description is thin. It conveys purpose and an auth requirement but leaves the signal payload semantics and the effect on smart copy orders unexplained, which is inadequate given the 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?

Schema description coverage is 86%, so the schema already documents all seven parameters, including the nested `data` object. The description adds no parameter-level meaning (e.g., signalType/signalParam formats), 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?

Specific verb+resource: 'Push a custom trading signal to drive smart copy orders.' Clearly states what the tool does and ties it to the smart-copy subsystem. It does not, however, distinguish itself from siblings like pionex_bot_create_user_signal or pionex_bot_list_user_signals, which also concern signals.

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

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

No explicit when-to-use or when-not-to-use guidance. It notes that it 'drives smart copy orders' and requires the 'Enable trading' permission, which implies setup context, but it never explains how this listener differs from the signal-management siblings or when an agent should choose it.

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

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

Annotations already declare the write/destructive/non-idempotent profile, but the description adds genuinely new behavior: the write is asynchronous and a success response only means the request was accepted. It also surfaces the exact rejection messages (e.g. `order is disable change tp`, `forbidden for future_grid_bonus order`) and the clear-via-empty-string convention, which annotations cannot convey.

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?

Well front-loaded — the one-line summary plus the create-vs-update routing appears before any tables. The tables and restriction list are scannable, but the eight example bodies are more repetition than most agents need, so it is slightly longer than strictly necessary.

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

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

For a mutation tool with no output schema, the description still closes the loop: it explains the asynchronous persistence model and the exact read-back fields (`lossStop`/`profitStop`) to confirm success. Combined with the error catalogue and clearing semantics, nothing an agent needs to invoke this 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 meaning the schema alone does not: the snake_case-vs-camelCase divergence from sibling endpoints, the rejection of legacy `type` spellings, how `value`/`limit_price` interact per `stop_type`, and worked request bodies. Only `stop_delay` is covered solely by an example rather than prose, which keeps it from a 5.

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 set (set/update/clear) and a precise resource (take-profit & stop-loss of an already-running futures grid order). It immediately distinguishes itself from the sibling `create` flow and from the other futuresGrid endpoints. An agent can identify the tool 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 this is only for an already-running order and points to `create` (with `lossStopType`/`profitStopType`) for a not-yet-started order. It also names the confirmation path (poll `GET /futuresGrid/order`) and enumerates the states that reject the call, so when-to-use and when-not-to-use are both covered.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new operational context beyond that: the required `View` permission and a rate-limit weight of 1, neither of which appears in the annotations.

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

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

Short and front-loaded: the purpose statement leads, then permission/weight, then a concrete example request. The opening line redundantly restates the title, and the raw GET URL example is slightly more low-level than needed, but overall it is 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?

With no output schema, the description carries the burden of describing the returned data, yet it only says 'list of Term Arbitrage products' without any field, term, or rate detail. Permission and weight are covered, but an agent still cannot anticipate the response shape.

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 empty, so the baseline is 4. The description correctly indicates via the example that no filters or pagination inputs are accepted, matching 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 (List) and resource (Term Arbitrage products currently available), which is clearly distinct from sibling write operations like pionex_earn_arbitrage_stake and pionex_earn_arbitrage_un_stake. It does not explicitly name or contrast a sibling, so the differentiation is inferable rather than stated.

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

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

Requires `View` permission is stated, which is useful prerequisite context, but there is no explicit when-to-use guidance or mention of how this relates to fetch_user_balances or the stake/un-stake tools. Usage is only implied (enumerate products before acting on them).

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's added value is the auth requirement ('Requires View permission') and the cost signal ('Weight: 1'), both of which an agent cannot get from the schema. It still says nothing about pagination, response shape, or whether balances are settled vs. pending, which is a modest gap for a balance 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?

The opening line is a verbatim restatement of the title and the first sentence is then repeated in expanded form, so roughly a third of the text is redundant. The permission and weight facts are useful but sit after the duplication instead of leading; the example request is the most informative part and is placed last.

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 no-parameter, read-only balance fetch with a rich annotation set, the description supplies what matters: what is returned (positions and balances), the permission needed, and the weight. Without an output schema it could go further on response structure, but nothing essential for a correct call 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 per the rubric the baseline is 4; there is no parameter semantics to explain. The only input shown, the timestamp query string, appears solely in the example and carries no documentation of format requirements beyond the sample.

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 user Arbitrage balances') and sharpens it with 'the authenticated user's Term Arbitrage positions and balances,' so the domain (Term Arbitrage earn product) is unambiguous. It does not explicitly differentiate itself from the nearby earn sibling pionex_earn_dual_balances, which is the main remaining ambiguity.

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

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

Usage is only implied: the 'authenticated user' framing tells the agent this is a personal-portfolio read rather than a product lookup, which separates it from pionex_earn_arbitrage_fetch_products. There is no explicit when-to-use statement and no named alternative such as pionex_earn_dual_balances or pionex_account_get_balance.

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

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

Annotations already flag readOnlyHint=false, destructiveHint=true, idempotentHint=false, so the mutation risk is covered structurally. The description adds the key auth requirement (`Earn` permission) plus an example response showing a txid, which is useful context beyond the annotations.

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

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

Front-loads the verb and permission/weight metadata, then validation, then examples. Slightly padded by a response example that isn't strictly needed, but every section is scannable and 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 3-param mutation tool with no output schema, it covers permission, validation, and a sample request/response. The main missing piece is what happens on failure or whether the stake can be withdrawn (though the unstake sibling implies reversibility).

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 restates the enum constraint, the decimal-amount requirement, and the source-of-truth for productId, and adds a concrete example body showing amount as a string. It mostly mirrors the schema, keeping it just above baseline.

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

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

States a specific verb+resource ('Stake into an Arbitrage product') and explicitly scopes it as subscribing to a Term Arbitrage product. The validation note tying productId to `GET /api/v1/earn/arbitrage/fetchProducts` also distinguishes it from siblings like pionex_earn_arbitrage_un_stake and fetch_products.

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 preconditions: requires `Earn` permission, productId must come from the fetchProducts list, and coin is limited to USDT/USDC. It doesn't state explicit when-not conditions or naming the unstake sibling as the inverse alternative, but the context is strong.

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

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

Annotations already declare the write/destructive/non-idempotent profile, and the description adds value beyond them: the required Earn permission, the weight, validation constraints, and a sample success response. It still does not say whether redemption is instant or queued, or how the redeemed amount/interest is returned, which is the main behavioral gap.

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 permission/weight, then validation and examples in clearly separated sections. The example response is slightly verbose but defensible given there is no output schema; overall well-structured with little 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?

With no output schema present, the description usefully supplies a sample response shape and status field, plus permission and validation requirements. It is nearly complete for a 3-required-param mutation tool, with only the redemption lifecycle left implicit.

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 each parameter already carries its own description and enum, so the description's validation bullets largely restate the schema. The example request body adds format cues (e.g., amount as '100', productId shape 'ARB-USDT-30D') but nothing substantial 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 ('Redeem') and resource ('Term Arbitrage product'), and clearly contrasts with the sibling stake operation. An agent can distinguish this from pionex_earn_arbitrage_stake or the dual_revoke_invest tools 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?

Clear context including the prerequisite chain ('productId must exist in the product list returned by fetchProducts') and permission requirement ('Requires Earn permission'). It does not, however, name explicit alternatives or when-not conditions (e.g., distinguishing from dual revoke), so it stops short of 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds real behavioral context beyond that: the 'Weight: 1' rate-limit cost, the definition of a delivery price, and a concrete example response shape. It does not explain time-range defaults or pagination, so it stops 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?

Purpose and the delivery-price definition are front-loaded well, but the body carries two near-identical example requests plus a full example response, which is more verbose than needed for four parameters. The repetition costs space without adding proportional 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?

With no output schema, the description usefully includes an example response showing the prices/date/deliveryTime fields, which an agent needs to interpret results. It omits any statement about how startTime/endTime affect the result set or default behavior, leaving a modest gap.

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

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

Schema coverage is 100%, so the schema already documents base, quote, startTime, and endTime. The description restates that base is required and quote optional/recommended with the USDXO-vs-USDT rule, which largely duplicates the schema text rather than adding new semantics. 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 ('Get historical delivery prices') and then defines what a delivery price actually is (the index price at expiry, used to determine settlement direction). This makes it distinguishable from sibling tools like pionex_earn_dual_prices and pionex_earn_dual_index, though it never names those alternatives outright.

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

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

It gives practical guidance on parameter values (quote optional but recommended; USDXO for BTC/ETH, USDT for others), which is useful. However, it never states when to choose this tool over sibling price-related tools such as pionex_earn_dual_prices, so usage is implied rather than contrasted.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the 'View' permission requirement and weight, which is extra context. However, it doesn't describe pagination, rate limits, or the merge parameter behavior beyond the schema.

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

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

The description is front-loaded with the core purpose, then includes example request/response. The examples take space but provide concrete value for an agent. No wasted sentences, though the JSON example is somewhat verbose.

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

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

Given no output schema, the example response compensates by illustrating the return structure. The permission requirement and weight are included. Missing details like error cases or pagination are minor for a simple balance retrieval 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 coverage is 100%, so the parameter 'merge' is fully documented in the schema. The description doesn't add any parameter details, which is acceptable given high coverage. Baseline 3 is appropriate.

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

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

The description clearly states it returns the authenticated user's Dual Investment account balances, which is a specific verb and resource. It doesn't explicitly differentiate from sibling tools like pionex_account_get_balance or pionex_wallet_get_balance_full, but the 'Dual Investment account' qualifier implicitly scopes it.

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

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

It mentions requiring 'View' permission, which is useful, but doesn't say when to use this tool versus alternatives like pionex_earn_arbitrage_fetch_user_balances or other balance tools. No explicit when-not-to-use 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?

Annotations already declare destructiveHint=true, non-idempotent, openWorld. The description adds genuine context beyond them: the required Earn permission scope, the settled-state precondition, the weight (1), and a worked response showing the boolean result and echoed clientDualId. It stops short of 5 because it doesn't say what happens on retry of a non-idempotent collect.

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, permission, weight, and precondition are front-loaded before the examples. The request/response JSON is not waste since there is no output schema, but the examples make the entry longer than a single tight paragraph would be.

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

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

For a 3-required-param mutation with no output schema, the description covers permission, precondition, weight, and return shape via example. The one gap is that the example body drops the required productId, leaving the agent to reconcile it against 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 coverage is 100%, so the schema itself defines all three parameters; baseline is 3. The example body is marginally helpful but actually omits the required `productId`, which makes the illustration incomplete rather than clarifying.

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: 'Collects settled Dual Investment earnings into the user's spot account.' That is unambiguous against siblings like pionex_earn_dual_get_invests or pionex_earn_dual_revoke_invest, though those siblings are never named, so the agent must infer the distinction.

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

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

'Only orders in a settled state can be collected' and 'Requires `Earn` permission' give real preconditions for when the call will succeed. It does not name competing tools (e.g. get_invests vs. collect) or state when not to use it, so it stops short of the top tier.

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?

The description presents this as a read-only query that returns details, but the annotations declare readOnlyHint=false and destructiveHint=true. That is a direct contradiction: an agent cannot safely reconcile 'query/returns' with 'destructive' and 'not read-only'.

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

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

The description is short and front-loads the core purpose, permission requirement, and weight. The opening line repeats the title and the example adds length, but overall it remains readable and mostly 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?

There is no output schema, so the description should carry more of the burden for explaining return values, but it only says 'Returns details' without describing the response shape or pagination. Combined with the annotation contradiction, the definition is not complete enough for confident 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%, so both parameters are already documented in the input schema. The description's example shows a sample request body, but it does not add constraints, requiredness, or format meaning 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?

The description states a specific verb and resource: it returns details for a batch of Dual Investment orders by client order ID list. This is clear and distinct from generic order queries, though it does not explicitly differentiate itself from sibling tools such as pionex_earn_dual_invest_records.

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 says it requires View permission and gives a weight, but it does not explain when to use this tool versus alternatives like pionex_earn_dual_invest_records or single-order lookups. No exclusion conditions or selection guidance are provided.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the safety profile needs no restating. The description adds genuine context beyond them: the index price's settlement role, the weight (1), and a full example response body, which is useful since no output schema exists.

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

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

Purpose is front-loaded, followed by constraints and then worked examples. The content is slightly long but the example requests and response earn their place; there is little 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 two-parameter read tool with no output schema, the description supplies the response shape via a concrete example, the scoping constraints, and the semantic meaning of the returned value. 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?

Schema description coverage is 100%, so both parameters and the quote enum/rule ('USDXO for BTC/ETH, USDT otherwise') are already documented. The description's example requests reinforce the pairing convention but add no syntax meaning beyond what the schema states, so the baseline 3 applies.

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

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

The description states a specific verb+resource ('Get underlying index price') and clarifies it returns the real-time index price for a Dual Investment underlying asset. It explains the role of the value (settlement reference for strike-hit determination), but does not differentiate itself from nearby siblings like pionex_earn_dual_prices or pionex_earn_delivery_prices.

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 specifies that both base and quote are required and that it works for USDT and USDXO quoted pairs, with example requests for each. However, it never states when to choose this tool over siblings such as pionex_earn_dual_prices or pionex_earn_delivery_prices, so the usage context 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?

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true. On top of that the description adds the permission requirement, the stale-profit rejection behavior, the weight, and the clientDualId idempotency recommendation — real operational context beyond the structured hints.

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

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

Front-loaded with the action and constraints, with examples placed after the rules. Minor redundancy from repeating the title line, but the workflow callout and JSON examples each earn their 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 destructive, open-world order-creation tool with no output schema, the description covers permissions, prerequisites, mutual exclusivity, and even ships an example response showing state CONFIRMED, which compensates for the missing 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 all six parameters are already documented in the schema, including mutual exclusivity and the profit-matching rule. The description's example request body adds concrete syntax value but mostly restates schema content, 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 ('Creates a new Dual Investment order') and names the exact product family. It does not explicitly differentiate itself from sibling earn tools like earn_dual_collect or earn_arbitrage_stake, but the product-specific naming makes it reasonably unambiguous within the earn_dual cluster.

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 prerequisite workflow ('Call GET /api/v1/earn/dual/prices first to obtain the current profit value, then pass it unchanged'), states the required 'Earn' permission, and clarifies the mutual exclusivity of baseAmount vs currencyAmount. It does not state when NOT to use this versus other order-creation tools, so it falls short of a 5.

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