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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description is not required to restate the risk. The description adds useful behavioral context by disclosing the 50 requests/second rate limit and the creator-only authorization, while also describing the functional effect of enabling non-LP quotes. The irreversible nature is covered by the confirm parameter 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 compact and front-loaded with the core action. The agent hint partially restates the opening sentence, so there is slight redundancy, but every section earns its place and there is 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?

The description covers the tool's purpose, effect, rate limit, authorization constraint, and rfqId usage. The destructive nature is already captured by annotations and the confirm parameter schema. No output schema exists, but nothing critical for selecting and invoking the tool correctly is missing.

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

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

The input schema provides detailed semantics for confirm but leaves rfqId undocumented. The description compensates by instructing to 'Pass the rfqId of the target RFQ', which gives the missing parameter its intended meaning. With 50% schema coverage, this is adequate compensation.

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: 'Enable acceptance of non-LP quotes for a specific RFQ.' It further clarifies the effect by explaining that normal counterparties can now quote and execute, distinguishing it clearly from siblings like createQuote, executeQuote, and cancelQuote.

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 agent hint explicitly identifies when to use the endpoint: to allow non-LP counterparties to quote on an RFQ. It also provides the key authorization constraint that only the RFQ creator can call it. It does not enumerate alternatives or when-not conditions, but the guidance is clear enough for selection.

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, covering the mutation risk. The description adds useful scope constraints like variable-rate-only and Unified-account-only, but does not disclose consequences such as creation of debt, accruing interest, or how the borrowed amount affects the account. No contradiction with annotations.

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

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

The description is short and well-structured with bullet rules that are easy to scan. The 'Service:' line adds minor operational metadata that is not directly useful for tool invocation, but the overall size is appropriate and the key constraints are front-loaded.

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

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

For a simple three-parameter mutation tool, the description covers account eligibility, rate type, and operation mode. However, it lacks any guidance on parameter values for coin and amount, and does not explain what happens after a successful borrow. The confirm parameter is well-documented in the schema, but the overall definition has notable 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 description coverage is only 33%: coin and amount have no descriptions in the schema, and the tool description does not explain their meaning or format. The description fails to compensate for the low schema coverage, leaving the agent without guidance on what values coin and amount should take.

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

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

The description clearly identifies the operation: 'Manual borrow for Unified account.' It further distinguishes itself with rules stating variable-rate-only, manual-only, and Unified-account-only, which separates it from many sibling borrow tools like accountFixedBorrow or postCryptoLoanFixedBorrow.

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 rules explicitly state when this tool is appropriate: manual borrowing, Unified account, variable rate only. This provides clear exclusions, though it does not explicitly name alternative tools for fixed-rate or non-Unified borrowing, which would have made it fully complete.

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 and openWorldHint, and the description does not contradict them. It adds useful behavioral context around master API key sub UID access and cross-account transferable balance queries, which goes beyond the structured annotation 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?

The description is compact and front-loaded: one clear opening sentence followed by a tight bullet list of conditional requirements. Every line adds decision-relevant information without 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?

The description covers the key parameter dependencies and access-pattern nuance for a multi-mode balance query. It does not describe the return value, but for a balance query this is largely inferable, and no output schema is provided to supplement it. The main gap is the lack of explicit sibling differentiation.

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 0% schema description coverage, the description compensates well by explaining the roles and conditional requirements of accountType, coin, memberId, toMemberId, toAccountType, and withLtvTransferSafeAmount. It does not explain withBonus or withTransferSafeAmount, but the most important parameter semantics are clarified.

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

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

The description states a specific action ('Query the balance of a specific coin in a specific account type') with a clear resource and scope. It does not explicitly compare against sibling tools like getWalletBalance or queryBalance, but the parameter-focused wording makes the tool's purpose reasonably distinct.

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 clear conditional usage guidance: it specifies required parameters, when memberId is needed for sub UID queries, and when toMemberId/toAccountType are needed for cross-account queries. It does not mention alternatives or exclusions, but the within-tool scenarios are well 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?

The description goes well beyond the destructiveHint annotation by explicitly warning that this 'creates a real loan with interest obligations' and instructing the agent to never execute automatically without user confirmation. It also discloses dependency on available supply and clarifies maturity handling 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 well-structured with a clear opening line, bulleted rules, service context, and a prominent agent hint. Every section serves a purpose, and the critical safety warning is front-loaded in the hint, making it easy for an agent to notice.

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

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

The description covers the essential rules, prerequisites, and risk warnings, which is sufficient for executing a loan order. Since there is no output schema, a brief note on expected return values would have been helpful, but the current description is largely complete for safe 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?

With only 14% schema description coverage, the description compensates by explaining the enum values for term, strategyType, and repayType, and by naming the critical confirmation parameters in the agent hint. It does not add detail for orderCurrency, but the overall contribution is meaningful given the schema's sparse documentation.

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: 'Create a fixed-rate borrow order for Unified account.' This clearly identifies the action and distinguishes it from flexible borrowing options, though it does not explicitly reference sibling tools or contrast 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?

The description provides relevant usage context such as 'Unified account only' and the requirement to confirm with the user before executing. However, it does not explicitly state when to choose this tool over alternatives like accountBorrow or postCryptoLoanFixedBorrow, leaving alternative selection 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?

Beyond the destructiveHint and readOnlyHint annotations, the description discloses concrete behavior: it uses only spot available balance, has a daily blackout window (04:00-05:30), calculates interest at 05:00, repays floating before fixed liabilities, and forbids BYUSDT. This is substantial behavioral context.

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

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

The description is front-loaded with the core purpose and uses a compact bulleted list for rules. Each bullet carries a distinct constraint or behavior, and the service tag adds useful provenance without bloat.

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 4-parameter tool with no output schema, the description covers the essential interaction rules, timing restrictions, and asset constraints. The only meaningful gap is the absence of explicit semantics for repaymentType, but the enum values plus the fixed/floating rule provide enough for an agent to proceed.

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 only 25% schema description coverage, the description compensates with explicit rules for coin and amount: the default-balance behavior when amount is omitted, the constraint that amount depends on coin, and BYUSDT being invalid. It does not elaborate on the repaymentType parameter's meaning, but the enum values and the floating/fixed precedence rule give some guidance.

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

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

The description states a specific action ('Manual repay without asset conversion') and resource (debt currency spot balance), and explicitly differentiates this tool from conversion-based repayment paths. The name itself and the phrase 'lossless repay' make the intent 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?

The description provides clear operational context: when coin/amount may be used, when repayment is prohibited, and which coin is not allowed. It does not explicitly name alternative sibling tools such as accountRepay or quickRepayment, so it stops short of a full when-to-use-this-vs-that statement.

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 destructiveHint annotation, the description discloses substantial behavioral details: balance usage order, asset conversion triggers, repayment priority, excluded coins, maintenance windows, interest calculation timing, and conversion fee limits. This is strong, decision-relevant behavioral transparency.

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 well-structured with a one-line purpose followed by logically grouped bullet rules. Every bullet carries distinct, non-redundant information, and the most important invocation rules are front-loaded.

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

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

The description covers many critical operational constraints, but it omits repaymentType semantics and does not describe the expected response or results. With no output schema and a destructive, high-risk action, these omissions leave some ambiguity for an agent deciding how to invoke and interpret the call.

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

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

The description clarifies coin/amount combination rules and repayment-all behavior, which the schema leaves opaque. However, it does not explain the meaning or interaction of repaymentType values (ALL, FIXED, FLEXIBLE), and schema description coverage is low at 25%. This is partial but not complete compensation for the schema gaps.

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

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

The description uses a specific verb ('repay') and resource ('liabilities of Unified account'), and the word 'Manually' distinguishes it from automatic or quick repayment flows. It clearly identifies the tool's core function even among siblings like quickRepayment and accountNoConvertRepay.

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 detailed parameter-combination rules but does not state when to use this tool versus alternatives such as quickRepayment or accountNoConvertRepay. It gives context for repayment behavior but no explicit when-to-use or when-not-to-use guidance relative to sibling tools.

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

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

Beyond the destructiveHint and readOnlyHint annotations, the description warns that this tool 'commits real assets', is 'hard-to-reverse', involves impermanent-loss risk, and must not be executed automatically. It also documents the rate limit and idempotency behavior, which are not visible in annotations.

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

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

The description is well-structured with bullet points for conditional requirements, rate limit, and a prominent agent safety hint. Every sentence adds operational value, and the most critical safety warning is clearly highlighted.

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 high-risk execution tool with no output schema, the description covers the safety gate, conditional parameters, idempotency, and rate limiting. It is incomplete only in not describing what productId represents or what leverage means, which an agent would need to invoke the tool 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?

With schema description coverage at only 13%, the description compensates well by explaining the conditional logic for quoteAmount/baseAmount, quoteAccountType/baseAccountType, and orderLinkId semantics. However, productId and leverage remain undescribed, and productId is a required parameter, leaving a meaningful gap.

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

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

The description opens with 'Inject funds into a Liquidity Mining pool', which names a specific action, resource, and direction of funds flow. This clearly distinguishes it from siblings like removeLiquidity, reinvestLiquidity, and claimLiquidityInterest.

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

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

The description gives clear usage context: injecting funds into a liquidity mining pool, with conditional requirements for quote/base amounts and account types. It does not explicitly name alternative tools or exclusion conditions, but the agent hint adds critical guidance that manual confirmation is required before execution.

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

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

Annotations already mark destructiveHint: true and readOnlyHint: false. The description adds valuable safety context by warning that this adds real collateral to an existing position and requires explicit user confirmation. The rate limit note is also useful. It does not detail other side effects, but it goes beyond the structured annotations.

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

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

The description is concise and front-loaded: a clear one-sentence function, a rate-limit note, and a critical safety hint. Every sentence adds operational value and there is 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?

This is a high-stakes, destructive mutation with 6 required parameters, no output schema, and very low schema description coverage. The description covers purpose, rate limit, and user confirmation well, but does not explain several required parameters or what the API returns, leaving an agent under-equipped for fully 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 only 17%, and the description only references 'position ID and margin amount' (positionId and amount). It leaves productId, orderLinkId, and quoteAccountType unexplained, and does not specify amount format or how orderLinkId should be generated. The confirm flag's semantics are covered by the schema, not the description.

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

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

The description states a specific verb and resource: 'Add additional collateral (margin) to a leveraged Liquidity Mining position to avoid liquidation.' This clearly identifies the operation and its purpose, and distinguishes it from related siblings like addLiquidity or removeLiquidity.

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 purpose clause 'to avoid liquidation' gives clear usage context, and the agent hint explicitly says not to execute automatically and to require user confirmation of position ID and margin amount. However, it does not explicitly contrast this tool with similar margin-related alternatives like addReduceMargin or setAutoAddMargin.

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 this as a non-readonly, destructive action. The description adds useful behavior beyond those flags: negative values reduce margin, values are limited to 4 decimal places, hedge mode requires positionIdx, and the response includes updated position details with liqPrice. No contradiction with the annotations was found.

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 reasonably short and front-loaded, but it repeats the positive/negative margin rule and the return-value statement between the main body and the agent hint. Tightening these redundancies would make it cleaner while preserving the useful details.

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, no-output-schema mutation, the description covers the core call requirements: isolated margin mode, margin sign and precision, hedge-mode positionIdx, and the updated position response. Minor gaps remain around positionIdx value meanings and category selection, but the schema's enums and confirm description fill some of that need.

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

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

Schema description coverage is low (20%), so the description must compensate. It clarifies the margin parameter's signed meaning and precision, and it explains when positionIdx is needed. However, category and symbol semantics are left to the schema/enums, and positionIdx's values (0/1/2) are not explained, leaving some interpretation to the agent.

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

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

The description uses a specific verb phrase, 'Add or reduce margin for a position in isolated margin mode,' naming both the action and resource. It also states the outcome ('Returns updated position details') and the sign convention, which makes it easy to distinguish from related tools like addMargin or setAutoAddMargin.

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 agent hint explicitly states when to use it: 'Use this to manually adjust margin on isolated margin positions.' It also provides the hedge-mode condition for positionIdx. However, it does not explicitly name alternatives or state when not to use it, such as preferring setAutoAddMargin for automatic margin management.

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 destructive=true, and the description adds real behavioral context: the target must be open, response is only an acknowledgement, and confirmation must come from the WebSocket order stream. It also clarifies that option IV uses a decimal value (0.1 = 10%). These are beyond the annotation flags.

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 bullet list is scannable and front-loaded with the core action. Minor redundancy exists between the first sentence and the 'Agent hint' sentence, but no significant fluff.

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 17-parameter mutation tool with no output schema, the description provides the essential call constraints, eligibility condition, response behavior, and category note. It does not enumerate every parameter's semantics, but the important operational knowledge is 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 only 6%, so the description must carry param meaning. It does explain orderId/orderLinkId exclusivity, orderIv formatting, and category for TradFi, but it leaves several params (tpslMode, triggerBy, slTriggerBy/tpTriggerBy, limit price fields) to be inferred from names/enums.

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

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

The opening sentence states a specific action and resource: 'Modify an existing open order,' and enumerates the mutable fields (price, quantity, trigger price, TP/SL). It does not explicitly distinguish this tool from its batch or WebSocket siblings (wsAmendOrder, batchAmendOrders), so it misses the top-rung 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?

It gives concrete eligibility constraints: one of orderId/orderLinkId must identify the order, and only unfilled/partially filled orders can be amended. It also includes an agent hint for when to use it and category guidance for TradFi, but it does not explicitly state when to prefer wsAmendOrder or batchAmendOrders.

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 destructive, but the description adds valuable behavior beyond that: the asynchronous response requiring WebSocket monitoring, the empty-string vs '0' price semantics, and the state restriction to unfilled/partially filled orders. These are precisely the operational details an agent needs to avoid misusing a modifying 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 description is well-organized with bold headers and bullets, front-loading the action and then key usage scenarios and important constraints. The final 'Agent hint' paragraph largely repeats the preceding bullets, which is redundant, but the structure keeps the essential information scannable.

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

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

The description covers all critical operational aspects for a mutation tool: target identification, required amendments, which order states are eligible, the special price semantics, auth requirement, and async notification behavior. With no output schema to describe returns, the WebSocket-final-status note closes the main remaining gap.

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

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

Schema coverage is only 17%, so the description carries the burden for the undocumented parameters. It explains the roles of qty, price, orderId, and orderLinkId, including the identification requirement and the special price sentinel values. The only remaining parameter without an explanation is the self-explanatory symbol, and confirm is fully documented in 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?

Description opens with a specific verb and resource: 'Amend (modify) the price and/or quantity of an existing spread trading order.' This clearly identifies the operation and distinguishes it from create/cancel spread order siblings, and the 'spread' qualifier separates it from the generic amendOrder 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 gives concrete usage scenarios (adjust price without cancel/re-create, modify qty) and explicit constraints (only unfilled/partially filled orders, orderId or orderLinkId required, at least qty/price). It does not explicitly contrast with batch/WebSocket sibling tools, but the context is clear enough for an agent to decide when this tool applies.

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 adds behavioral context beyond the annotations: quote time limit, need to request a new quote after expiration, trading pair limits, and the Master UID requirement. However, it does not explain what side effect the destructiveHint=true annotation implies or whether an existing quote is invalidated.

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 well-organized with headings, bullet lists, and use cases. Every section adds value and the most critical information (return fields, rules, auth) is front-loaded, though the use case section is slightly redundant with the rest.

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

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

Given the absence of an output schema, the description helpfully enumerates return fields and operational constraints. However, with zero parameter documentation, it leaves gaps around how to populate requestAmount correctly, which coin types are valid, and what the destructive side effect is.

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

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

Schema description coverage is 0%, so the description needed to compensate. It does not explain any of the six parameters, the fiat/crypto enums, or the optional requestCoinType default. Only the indirect mention of 'quote amount' and 'trading pair limits' gives minimal semantic guidance for requestAmount.

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

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

The description states a specific action ('Apply for a conversion quote') and lists the returned data (quoteTxId, exchange rate, expiration, amounts). It is clear about the resource and goal, though it does not explicitly distinguish itself from the many quote-related siblings such as getTradeQuote, QuoteApply, or createQuote.

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 concrete use cases (lock an exchange rate, show exact received amount, validate trade parameters) and important quote rules (30s expiry, re-request after expiry, amount limits). This gives clear context for when to use the tool, but it does not name alternatives or specify when not to use 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 mark this as destructive and non-read-only, and the description adds valuable behavioral detail beyond that: the response is acknowledgment-only, per-order status is in retExtInfo.list[].code, and final confirmation must come via the WebSocket order stream. This tells the agent what to expect and what to check.

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 well-structured with purposeful bullet points, a clear agent hint, and a domain-specific TradFi note. Every sentence adds actionable information, and the main purpose is front-loaded.

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

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

For a complex mutation tool with no output schema, the description covers the critical call requirements, acknowledgment semantics, and per-order status checking. It stops short of fully explaining every nested request parameter and error-handling behavior, but the essential context for invoking the API correctly is present.

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

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

Schema description coverage is only 33%, so the description must compensate. It does explain the key request semantics: each order needs orderId or orderLinkId, the per-request limits differ by category, and category=spot/linear maps to TradFi use cases. However, many optional nested fields like triggerPrice, tpslMode, and takeProfit are left without any description, so semantic coverage is still incomplete.

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

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

The description opens with a specific verb and resource: 'Modify multiple existing open orders in a single API call.' It also explicitly names the single-order alternative 'amendOrder', so the tool is clearly distinguished from its most similar sibling.

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

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

Usage guidance is explicit: 'Use this endpoint to modify multiple orders at once. For a single order, use amendOrder instead.' It also provides concrete eligibility constraints, such as max order counts, the orderId/orderLinkId requirement, and that only unfilled or partially filled orders can be amended.

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?

Despite destructiveHint already being true, the description adds substantial behavioral context: only unfilled or partially filled orders are cancellable, responses are acknowledgments only, per-order status must be checked via retExtInfo.list[].code, and final confirmation requires the WebSocket order stream. This is exactly the kind of non-obvious behavior an agent needs.

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 uses tightly scoped bullets for constraints and response semantics. The agent hint and TradFi note earn their place by aiding tool selection. No redundant or filler content is present.

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

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

Given the lack of an output schema and the destructive nature of the operation, the description is remarkably complete: it covers limits, per-order status handling, acknowledgment-only semantics, alternative tool routing, and category mapping. The input schema already documents the confirm parameter's critical confirmation requirement, so that omission from the description is acceptable.

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 only 33% schema description coverage, the description compensates well by explaining order identification requirements (orderId or orderLinkId), per-market batch limits, and category usage. However, the statement that each order requires either orderId or orderLinkId is not reflected in the schema's required fields, which only marks symbol as required; this minor inconsistency prevents a top score.

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

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

The description opens with a specific verb and resource: 'Cancel multiple orders in a single API call.' It clearly distinguishes itself from sibling cancelAllOrders via the agent hint, which says to use this endpoint for multiple specific orders and cancelAllOrders for cancelling all orders.

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 agent hint explicitly states when to use this tool and when not to: use for multiple specific orders, use cancelAllOrders for all orders. It also provides concrete category guidance for TradFi use cases and per-market order limits, leaving little ambiguity about selection.

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 adds substantial behavioral context beyond the annotations: max order limits per category, independent validation and partial success, how to read per-order status via retExtInfo.list[].code, and that the response is acknowledgment-only requiring WebSocket confirmation. This clearly enriches the destructiveHint/readOnlyHint annotations.

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

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

The description is well-structured with front-loaded purpose and scannable bullets. It loses a point for mild redundancy: the 'Agent hint' repeats the opening purpose and the retExtInfo.list guidance already stated in the bullet list.

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

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

For a complex, high-risk batch order tool with no output schema, the description covers limits, partial success, response semantics, and confirmation requirements. It falls short of fully complete by not explaining the request item structure beyond what the schema already provides, and the 'futures/options' limit wording leaves inverse category coverage slightly ambiguous.

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

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

With schema description coverage at only 33%, the description partially compensates by explaining category usage for TradFi and clarifying per-order response codes. However, it does not add meaningful semantics for the request array's many nested fields or the confirm parameter, leaving key parameter meaning to the sparse schema.

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

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

The description opens with a specific verb and resource: 'Place multiple orders in a single API call.' This clearly distinguishes batch behavior from single-order tools like createOrder, though it does not explicitly differentiate from wsBatchCreateOrders or name alternatives.

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

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

The description provides clear context for when to use the tool via the agent hint 'Use this endpoint to place multiple orders at once' and includes TradFi category guidance. However, it does not explicitly state when not to use it or direct the agent to alternatives such as createOrder or wsBatchCreateOrders.

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?

DestructiveHint=true in annotations already marks the risk profile; the description adds useful behavior beyond that: the response is only an acknowledgment and actual cancellations must be confirmed via the WebSocket order stream. It does not repeat irreversibility, but the annotation covers that.

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 summary line is followed by tight bullets covering per-category behavior, filter usage, response semantics, agent routing, and TradFi mapping. Every line adds information; nothing is redundant with the schema or annotations.

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, no-output-schema tool, the description covers category-specific requirements, response semantics, and the key alternative (cancelOrder). The only notable omission is a direct explanation of stopOrderType and a more explicit mapping of orderFilter enum values to the named order types.

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 low (only confirm is described), so the description must compensate. It does for most parameters by explaining the linear/inverse symbol/baseCoin/settleCoin one-of rule, category behavior, and orderFilter purpose. stopOrderType is left unexplained, though its single enum value limits ambiguity.

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

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

The first sentence is a precise verb+resource statement: 'Cancel all open orders matching the specified criteria.' The category bullets further specify what 'all' means for linear/inverse, options, and spot, and the agent hint explicitly sets it apart from the single-order sibling cancelOrder.

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 exactly when to use this endpoint ('all open orders for a category/symbol at once') and when not to ('For cancelling a single order, use cancelOrder instead'). Per-category criteria requirements and orderFilter guidance leave no ambiguity about invocation context.

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 annotations already state destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds useful context: the 50 requests-per-second rate limit and the array-of-statuses response shape. However, the statement 'No request body parameters are needed' is misleading because the schema requires the confirm parameter, which weakens behavioral accuracy.

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, front-loaded, and clearly formatted with a rate-limit line and agent hint. Still, it contains redundancy: 'Returns an array of results...' and 'The response lists each cancelled quote...' say the same thing, and the agent hint repeats the first sentence. Not every sentence earns its place.

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

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

With no output schema, the description appropriately covers the response format, and the rate limit is a helpful operational detail. However, the incorrect 'No request body parameters are needed' statement creates confusion about how to invoke the tool, and there is no explicit warning about the irreversible nature beyond what the schema and annotations already convey.

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

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

The schema itself provides strong, 100% coverage for the confirm parameter, explaining it as a mandatory high-risk confirmation. The description adds no useful parameter meaning and in fact contradicts the schema by stating 'No request body parameters are needed,' which could mislead an agent into omitting the required confirm field. This is a significant, harmful inaccuracy.

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

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

The description opens with a specific verb and resource: 'Cancel all active quotes for the authenticated account.' It clearly distinguishes this bulk operation from sibling tools like cancelQuote, cancelRfq, and cancelAllRfqs by focusing on active quotes and the account-level scope.

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 the goal is to cancel all active quotes at once. However, it does not explicitly contrast this with cancelQuote for individual quotes or cancelAllRfqs for RFQs, so an agent must infer the alternative-selection logic from the tool name and context rather than from explicit 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?

Beyond the annotations (destructiveHint=true), the description discloses important side effects: cancelling as an inquirer invalidates corresponding quotes, while cancelling as a quoter leaves the inquiry unaffected but invalidates the quote. It also adds a rate limit and describes the array-shaped 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?

The description is well-structured and mostly front-loaded, with the core action first followed by behavioral consequences and rate limit. The 'Agent hint' section is slightly redundant with the opening sentence and duplicates the return-value statement, but overall the length is appropriate.

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 tool with no output schema, the description covers the return shape, side effects, and rate limit. It does not explicitly restate the confirm requirement or irreversibility, but those are already captured by the annotations and the parameter schema, so the description is sufficiently complete.

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

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

The schema fully documents the confirm parameter with a detailed safety rationale, so the baseline is 3. The description adds no meaningful parameter semantics and the phrase 'No request body is needed' could be read as downplaying the required confirm parameter, though it may refer to the underlying HTTP transport rather than MCP arguments.

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

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

The description opens with a specific verb and resource: 'Cancel all active RFQs for the authenticated account.' It clearly distinguishes this from sibling tools like cancelRfq (single RFQ) and cancelAllQuotes (quotes, not RFQs), and clarifies the scope with 'all active RFQs.'

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 conveys that this is the bulk-cancellation endpoint ('cancels all active RFQs at once'), which implies use when all RFQs should be cancelled. However, it does not explicitly mention alternatives such as cancelRfq for a single RFQ or explain 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?

The annotations already mark this as destructive and non-read-only, and the description adds important behavioral context: the endpoint is asynchronous and final status must be confirmed via WebSocket. It also clarifies the surprising precedence behavior where cancelAll is ignored when symbol is present.

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

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

The content is well-structured and front-loaded, but the 'Agent hint' section largely duplicates the 'Important' section. This redundancy means not every sentence earns its place, though the overall organization remains clear.

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 bulk-cancel endpoint with three parameters and no output schema, the description covers the key facts: what gets cancelled, how filtering works, the precedence rule, authentication requirement, and asynchronous confirmation via WebSocket. An agent has enough to invoke it correctly.

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

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

The description adds crucial meaning beyond the bare schema for symbol and cancelAll, including their interaction and precedence. The confirm parameter is already thoroughly documented in the input schema, so the description does not need to repeat it.

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

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

The description states a specific action ('Cancel all open spread trading orders') with optional symbol filtering, which clearly identifies the tool's resource and scope. It is readily distinguishable from siblings like cancelSpreadOrder and cancelAllOrders because it explicitly targets spread orders.

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 scenarios explicitly define when to cancel all symbols versus a specific symbol, and the precedence rule ('When symbol is provided, cancelAll is disregarded') gives clear operational context. It does not name alternative sibling tools or state when not to use them, but the behavior is unambiguous enough for selection.

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, and the description adds meaningful context beyond that: 'System prioritises orderId when both are provided but conflict' and 'Response is acknowledgment only; confirm via WebSocket order stream.' These are behavioral traits not inferable from the schema, and there is no contradiction with annotations.

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

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

The core action is front-loaded and followed by compact bullets covering precedence, orderFilter, and response behavior. The 'Agent hint' sentence repeats the opening line almost verbatim, adding mild redundancy, so it is not maximally tight.

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

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

There is no output schema, but the description states the response is acknowledgment only and directs the agent to the WebSocket stream for confirmation. It captures the essential invocation decisions: which id to provide, what category to use for TradFi, and when orderFilter applies. It could mention not-found or error behavior, but the coverage is adequate for a single-order cancel.

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 only 17%, but the description compensates by explaining the one-of requirement for orderId/orderLinkId, the precedence behavior, the orderFilter targeting for spot orders, and the TradFi category mapping. Symbol and confirm are left to the schema, but confirm already has a detailed description there.

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

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

The description opens with 'Cancel a single open order by orderId or orderLinkId,' giving a specific verb, resource, and the two identifier options. The word 'single' clearly distinguishes it from siblings like batchCancelOrders and cancelAllOrders, and the precedence rule for orderId adds precision.

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 agent hint explicitly states 'Use this endpoint to cancel a single open order,' and the TradFi note tells the agent which category to use for which instrument type. However, it does not explicitly name alternatives such as batchCancelOrders or wsCancelOrder for multi-order or low-latency cancellation, leaving those exclusions 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 indicate destructive behavior, and the description adds meaningful behavioral detail beyond that: priority order when multiple identifiers are supplied, the RFQ-wide cancellation effect, and a 50-requests-per-second rate limit. This goes beyond what the annotations alone 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?

The description is reasonably short and front-loaded, but the 'Agent hint' largely repeats the earlier parameter and priority information. This redundancy means some sentences do not earn their place, though the rate limit and RFQ behavior are useful additions.

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

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

The description covers parameter selection, priority, rate limit, and the RFQ-wide cancellation behavior, which are the most important operational details. However, there is no output schema and the description does not explain what a successful cancellation returns or how to handle already-executed quotes. It is adequate but has notable gaps for a destructive action.

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 25%, and the three identifier parameters have no schema descriptions. The tool description compensates by explaining the identifier options, the priority order, and the special meaning of rfqId. It does not define quoteLinkId or mention the confirm requirement, but it adds substantial semantics over the bare schema.

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

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

The description clearly states the action: 'Cancel an active quote,' with a specific verb and resource. It also explains which parameters can identify the quote. However, it does not explicitly distinguish this tool from sibling tools like cancelRfq or cancelAllQuotes, so it stops short of full 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?

The description gives clear usage context: pass one of quoteId, rfqId, or quoteLinkId, with an explicit priority order. It also notes the rate limit and the important behavior that using rfqId cancels all quotes for that RFQ. It does not mention when to prefer a sibling tool such as cancelRfq, so exclusions are missing.

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 (destructiveHint=true, readOnlyHint=false), the description discloses important behavioral consequences: cancelling invalidates all associated quotes, either rfqId or rfqLinkId can be used with rfqId taking precedence, and the rate limit is 50 requests per second. These are non-obvious side effects and constraints the agent needs to know.

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 main description is front-loaded and reasonably brief, but the 'Agent hint' section largely repeats the first two sentences about passing either id and rfqId precedence. This redundancy adds no new information and could be trimmed.

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

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

For a destructive mutation tool with no output schema, the description covers the essential behavior, parameter selection, side effects, and rate limit. It omits return-value details, but the schema's confirm description and the annotations cover the high-risk nature sufficiently.

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 only 33%, with rfqId and rfqLinkId undocumented. The description compensates by explaining that exactly one is required and that rfqId wins if both are supplied. It does not describe the confirm parameter, but that parameter already has a thorough schema description.

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

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

The description clearly states the action and resource: 'Cancel an active RFQ.' This distinguishes it from quote-level tools like cancelQuote and from bulk operations like cancelAllRfqs, though it does not explicitly name those sibling alternatives.

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

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

It gives clear context about cancelling an active RFQ and invalidating associated quotes, but it does not explicitly tell the agent when to prefer this over cancelQuote, cancelAllQuotes, or cancelAllRfqs. The usage guidance is implied rather than explicit.

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

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

Goes beyond the destructiveHint annotation by disclosing that the response is only an acknowledgement, the cancellation is asynchronous, and final status must be confirmed via WebSocket. It also adds the authentication requirement. This is exactly the kind of behavioral context an agent needs to avoid falsely treating the reply as success.

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 purpose and organized with clear sections, but key facts ('Either orderId or orderLinkId must be provided', 'Response is asynchronous') are repeated in the Important block and the Agent hint. This minor redundancy prevents a top score.

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 cancelling tool with no output schema, it gives the essential operational facts: identifier choice, required identifier condition, async acknowledgement, WebSocket confirmation, and authentication. The confirm parameter's high-risk semantics are covered by the input schema, so nothing critical 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?

With only 33% schema description coverage, the description compensates by explaining that orderId and orderLinkId are alternative identifiers and that one of them must be provided—a conditional requirement not encoded in the schema. It does not repeat the confirm parameter's semantics, but that parameter already has a thorough description in 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 action ('Cancel') and resource ('single spread trading order') and clearly identifies the two supported identifiers (orderId, orderLinkId). The word 'single' differentiates it from sibling cancelAllSpreadOrders, and 'spread trading order' distinguishes it from generic cancelOrder.

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

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

Provides explicit usage scenarios ('open limit order that has not yet been fully filled') and the choice of identifier. It does not explicitly name alternative tools for related cases (e.g., cancelAllSpreadOrders, cancelOrder), so it lacks a full when-not-to-use statement, but the context is clear.

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

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

Annotations mark this as a non-read-only, destructive action; the description adds valuable context by stating the yield's destination (user's default account), forbidding accountType, explaining why positionId is absent, and giving the rate limit. This goes beyond the structured fields. It doesn't state idempotency or reversibility, but the annotations already signal side effects.

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

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

One action sentence plus three focused bullets, with the most important call-scope detail first. The rate-limit note is additional useful context and does not bloat the description.

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

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

Despite no output schema, the description covers the action, the only parameter, sentinel behavior, destination account, why other fields are unnecessary, and the rate limit. For a single-parameter claim tool this is complete enough for an agent to invoke it correctly.

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

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

The input schema only exposes a bare `productId` string with 0% coverage, and the description compensates by documenting the special `-1` sentinel for claiming all products and by explaining that `accountType` and `positionId` are intentionally not required. For a one-parameter tool this fully resolves the semantics that the schema leaves open.

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

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

States the exact action ('Claim all available interest'), the resource ('specified product'), and the one-click scope. The productId=-1 bullet further defines the difference between claiming one product and all products, which clearly differentiates it from sibling liquidity-mining tools such as reinvestLiquidity and getLiquidityMiningYieldRecords.

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

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

Use case is implied by the verb and domain: an agent should call this when the user's goal is to claim accrued interest from a liquidity-mining product. It does not explicitly say when not to use it or point to alternatives such as reinvestLiquidity for compounding, so the routing guidance is only implicit. The constraints about default account and absent positionId help shape the call but not the choice of 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?

The description adds substantial behavioral context beyond the annotations: it explains the destructive effects (canceling orders, closing positions), the running-state prerequisite, the rate limit, and a recommended post-close verification step. This aligns with destructiveHint=true and adds detail about what actually gets destroyed.

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 well-organized and front-loaded, with the core action and effects in the first sentence. However, the bot_id sourcing information is repeated in both the body and the agent hint, adding 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?

For a destructive action with no output schema, the description covers prerequisites, side effects, rate limiting, and follow-up guidance. The main gap is the lack of stop_type value semantics, which may leave an agent unsure which reason code to send.

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 33%, so the description must compensate. It usefully explains that bot_id comes from createComboBot or getComboDetail and that stop_type indicates the closing reason, but it does not document the meaning of each stop_type enum value or whether it is optional. The confirm parameter's safety semantics are already well-covered in the schema.

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

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

The description clearly states a specific verb ('Closes (stops)') and resource ('running futures combo trading bot'), and explains the concrete effects: cancel pending orders and close all positions. This distinguishes it from sibling bot-closing tools like closeGridBot or closeDCABot through the 'combo' qualifier.

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

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

The agent hint explicitly says 'Use this to stop a running combo bot' and explains where to find bot_id and what to do afterward. It does not explicitly name alternatives or exclusion conditions, but the combo-specific framing and sibling tool names make the intended use clear.

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

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

Annotations already mark it destructive and non-read-only, and the description adds valuable behavioral detail: remaining assets are settled according to the chosen mode, the operation can fail with 503 when the bot is mid-cycle, and there is a rate limit of 3 qps per UID. No contradiction with annotations.

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

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

The purpose is front-loaded, the mode mapping is formatted as an easily scannable list, and the state caveat, rate limit, and agent hint each add non-redundant value. No wasted sentences.

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, the description covers what the tool does, the settlement options, when it may fail, and the relevant rate limit. The confirm safety behavior is supplied by the schema, so nothing essential to invoking the tool correctly is missing.

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

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

Schema description coverage is only 33%, but the description fills the main gap by explaining exactly what the three close_mode enum options mean. The confirm parameter is already thoroughly covered in the schema, and bot_id is a self-evident identifier with a permissive schema, so the partial compensation is sufficient.

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

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

The description opens with a specific verb and resource ('Closes a running DCA bot') and then clarifies the effect through close_mode settlement semantics. The resource (DCA bot) distinguishes it from sibling close tools like closeGridBot and closeComboBot without relying only on 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?

It gives clear operational context: the bot must be closeable, and a 503 may occur mid-investment-cycle, plus an agent hint for choosing close_mode=3 when the user wants conversion to quote. It does not explicitly compare against sibling close tools, but the target tool is unambiguous from the DCA-specific context.

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 explicitly discloses destructive behavior: 'cancel all pending grid orders and close positions.' It also adds practical context such as the 10 requests/sec rate limit, the running-state precondition, and the suggestion to call getFGridDetail afterward. These details complement the destructiveHint=true annotation without contradicting it.

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 compact and front-loaded with the core action. The rate limit and agent hint add useful guidance, though the bot_id sourcing is stated twice, once in the main description and again in the agent hint, creating 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?

For a two-parameter, destructive action with no output schema, the description covers what the tool does, what it destroys, how to obtain the required bot_id, the running-state condition, rate limiting, and a recommended follow-up call. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 50%, and the description compensates by explaining that bot_id comes from the createFGridBot response or getFGridDetail. The confirm parameter's high-risk semantics are already well documented in the schema, so the description's limited mention is acceptable.

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

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

The description opens with a specific verb and resource: 'Closes (stops) a running futures grid trading bot.' It clearly states what the tool does and differentiates it from closeGridBot and other close* siblings by specifying 'futures grid' and referencing createFGridBot/getFGridDetail.

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

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

The description gives clear context: 'Use this to stop a running grid bot' and notes 'Only bots in a running state can be closed.' It tells the agent where to find bot_id but does not explicitly name alternatives or state when not to use this tool instead of closeGridBot.

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 (readOnlyHint=false, destructiveHint=true), the description discloses concrete side effects: it cancels all pending orders and closes the position. It also states the rate limit (10 requests per second per UID) and the precondition that only running bots can be closed. This gives the agent a solid picture of the mutation's impact. No contradiction with annotations 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?

The description is front-loaded with the core action and effect, followed by short useful sections on bot_id sourcing, running-state precondition, rate limit, and an agent hint. There is minor redundancy because the agent hint repeats the bot_id source already stated above, but the overall structure remains compact and scannable.

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 covers the purpose, side effects, precondition, rate limit, bot_id sourcing, and the recommended follow-up call (getFMartDetail for final PnL and close reason). It does not describe the response of closeFMartBot itself, but the post-close guidance mitigates this, and the confirm parameter is documented thoroughly in 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?

With schema description coverage at only 33%, the description adds meaning for bot_id by identifying its sources (createFMartBot response or getFMartDetail) and stating it is required. It also clarifies that stop_type indicates the reason for closing. The confirm parameter is already fully documented in the schema. The main remaining gap is that stop_type enum values are not explained beyond their self-descriptive names.

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

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

The description opens with 'Closes (stops) a running futures Martingale trading bot,' which names a specific verb, resource, and bot type. It further specifies the effect ('cancel all pending orders and close the position'), clearly distinguishing this from sibling close tools for other bot types and from read-only tools like getFMartDetail.

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 clear usage context: 'Only bots in a running state can be closed' and an explicit agent hint to use it for stopping a running Martingale bot. It also points to createFMartBot/getFMartDetail for bot_id and recommends getFMartDetail after closing. However, it does not explicitly name sibling close tools as alternatives or state when not to use it beyond the running-state precondition.

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 indicate destructiveHint=true, and the description adds valuable behavioral context beyond that: settlement behavior per close_mode, required bot state, and a rate limit of 3 qps per UID. There is no contradiction with annotations; the description enriches the agent's understanding of what happens when the tool is 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 well-structured: purpose statement, bullet list for close modes, state constraint, rate limit, and agent hint. Every sentence carries useful information without redundancy or fluff. The key decision-driving content is front-loaded.

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

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

For a destructive, state-dependent action with no output schema, the description covers purpose, parameter semantics for the most complex parameter, state preconditions, and rate limiting. The confirm parameter's high-risk requirement is already thoroughly documented in the schema. A minor gap is the lack of explicit guidance on how to obtain or validate grid_id, but this is secondary.

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 only 33% (only confirm is documented). The description fully compensates for close_mode by explaining each of the four enum values and adding usage hints for modes 3 and 4. grid_id remains underexplained, but its meaning is fairly inferable from the name and type plus the tool's purpose.

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

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

The first sentence states a specific verb and resource: 'Closes a running spot grid bot.' This clearly distinguishes it from sibling tools like closeDCABot or closeFGridBot via the 'spot grid' qualifier. The subsequent state requirement (NEW or RUNNING) further sharpens the scope.

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 explicit when-not guidance by stating that bots in CANCELLING or COMPLETED state cannot be closed. It also provides agent hints for choosing close_mode based on user intent (stablecoin cashout vs keeping both tokens). It stops short of naming alternative tools for other bot types, but the 'spot grid bot' qualifier provides clear context.

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, so the description's main contribution is operational context: API Key authentication, the specific ACL permission (RESOURCE_GROUP_EXCHANGE_HISTORY + PERMISSION_READ), and a global rate limit (100/path/s). These are exactly the kind of behavioral traits that help an agent invoke the tool correctly and match the read-only annotation without contradiction.

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

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

One purpose sentence front-loaded, followed by three tightly scoped operational bullets (auth, ACL, rate limit). Every line earns its place, and there is zero filler or repetition of the input schema.

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

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

With 5 parameters at 0% schema coverage, no output schema, and two unexplained enum parameters, the description leaves meaningful gaps: the semantics of fromCoinType/toCoinType, valid accountType values, and the response shape are all absent. The operational details are strong, but an agent would still struggle to construct a fully correct request or interpret the result.

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

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

Schema description coverage is 0%, so the description carries the burden of parameter explanation. It names the coin pair (fromCoin, toCoin) and accountType semantics, but leaves the two enum parameters (fromCoinType, toCoinType) completely unexplained — an agent cannot determine the meaning of '0' versus '1', and no valid values are given for accountType. Partial compensation for a low-coverage schema.

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

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

The description states a specific verb ('Query'), a precise resource ('single conversion min/max limit'), and scope ('specified coin pair under specified account type'). This clearly differentiates it from sibling tools like ConvertExecute, ConvertHistoryQuery, and QuoteApply, which an agent could otherwise confuse it with.

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

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

The description makes the usage context clear: an agent needing conversion limit/range information for a coin pair under an account type would select this tool. However, it does not explicitly name alternatives or state when not to use it, leaving the exclusion logic to inference from the sibling names.

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 annotations already declare readOnlyHint and openWorldHint, and the description adds concrete behavioral constraints not present in structure: exact ACL permission, per-user and global rate limits, and a compliance-review requirement. These details go well beyond the annotations and help the agent anticipate access failures or throttling.

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

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

The purpose sentence is front-loaded and the four bullet points are compact, each providing non-redundant operational information. There is no filler or repetition of schema content.

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

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

For a read-only list-query tool, the description covers purpose, auth, ACL, rate limits, and compliance, with annotations covering safety. It does not describe the return shape or the exact meaning of the side enum values, but the tool name and schema largely fill those 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?

With 0% schema description coverage, the description compensates by mapping 'account type' to the required accountType parameter and 'conversion direction' to the side parameter. The coin parameter is left to inference from its name, and the enum values are not expanded, but the core semantic guidance is present.

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

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

The description opens with a specific verb and resource: 'Query convertible coin list', and adds two scoping dimensions—account type and conversion direction—that map directly to schema fields. This clearly distinguishes it from generic list tools like queryCoinList and from conversion execution/history 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 gives strong operational context: API key authentication, ACL permission, rate limits, and compliance review, which help an agent know whether it is permitted to call the tool. However, it never explicitly says when to prefer this tool over siblings like ConvertExecute, ConvertHistoryQuery, or CoinConvertLimitQuery; the usage context is only implied by 'convertible coin list'.

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 destructiveHint and readOnlyHint annotations, the description discloses the mechanism: it confirms the new MMR and lifts the reduce-only restriction. It does not spell out irreversibility or other side effects, but the confirm parameter schema covers user-consent requirements, and the annotations already flag destructiveness.

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

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

The purpose is front-loaded and the agent hint is actionable, but the hint repeats 'confirms the new MMR and removes the reduce-only restriction' already stated in the opening. This redundancy could be trimmed without losing information.

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

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

For a single-purpose state-confirmation action, the description provides the trigger condition, the affected state, and the diagnostic step. It lacks return/error details, but there is no output schema, and the confirm parameter plus annotations already cover the user-consent and destructive aspects.

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 33% and the tool description does not explain how symbol or category should be populated; it only implies they identify the affected position. The confirm boolean is well documented in the schema, but the description does not compensate for the undocumented 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 ('Confirm'), a precise object ('pending maintenance margin rate update for a position'), and the actionable consequence ('removes the reduce-only restriction'). This clearly separates it from generic confirm tools like confirmQuote and read-only position 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?

Explicitly tells the agent when to invoke: when a position has isReduceOnly=true due to a Bybit risk-limit adjustment, and tells it to check getPositionInfo to detect that condition. No alternative confirmation tool competes for this scenario, so the absence of an exclusion list is not a gap.

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 (readOnlyHint=false, destructiveHint=true), the description discloses asynchronous execution, the need to poll or use webhooks, and the processing/success/failed statuses. This materially helps an agent predict outcomes and post-call 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 compact, front-loaded with the core purpose, and organized into scannable sections (Important, Trade Status, Use Cases). Every bullet adds necessary operational detail without 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 an asynchronous, destructive trade action, the description covers validity, status verification, and notifications, and the schema's confirm parameter handles explicit-user-consent semantics. It is slightly incomplete because it refers generically to 'the trade query endpoint' and never clarifies the meaning or source of `quoteTxId`/`subUserId`.

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 only 20%, so the description needed to compensate. It explains `webhookUrl` and `merchantRequestId` via the webhook and custom-tracking-ID use cases, but the required `quoteTxId` and `subUserId` are never explained—what they are or where to obtain them.

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

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

The description opens with a specific verb and resource: 'Confirm the quote and execute the conversion trade.' It clearly conveys the tool's role, but it does not explicitly differentiate it from the sibling `executeQuote` or mention which step in the quote lifecycle this covers.

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 'Important' section gives clear usage constraints: confirm within quote validity, treat execution as asynchronous, and verify final status via a trade query endpoint. Use cases add context (after user confirmation, custom tracking ID, webhook), but there are no explicit exclusions or named alternatives such as `executeQuote`.

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, the description discloses async execution, the need to poll a separate status API, quote expiry constraints, API key authentication, ACL permissions, rate limits, and KYC requirements. This is substantial behavioral and operational context that annotations alone do not 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 description is compact and front-loaded: the core action and async behavior appear first, followed by a concise bulleted list of constraints. Every sentence adds operational value, and there is no redundant 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 two-parameter mutation tool, the description covers the essential workflow: confirming before expiry, executing, and polling for final status. It also includes auth, rate limit, and KYC notes. It could additionally clarify the initial response shape or behavior on expired quotes, but the overall guidance is nearly complete.

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

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

The confirm parameter is already richly described in the schema, including the high-risk confirmation rule. The description adds only light value by referring to 'quote ID' for quoteTxId and warning about expiry, but it does not explain where quoteTxId comes from or its format. With 50% schema coverage, this partial compensation is adequate but not strong.

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

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

The description states a specific action ('Confirm and execute a conversion') and the key input ('quote ID'), making the core purpose clear. However, it does not differentiate itself from sibling tools like confirmQuote or executeQuote, so an agent comparing these names gets no explicit 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?

The description provides clear operational context: the exchange is async, final status must be checked via the query result API, and the quote must be confirmed before expiry. It does not explicitly state when to use this tool instead of quote-related siblings or when not to use it, but the context is strong enough for basic routing.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete operational behavior: it is an OpenAPI interface requiring API Key authentication, requires a specific ACL permission, and has a global rate limit of 50/path/s. This is exactly the kind of auth and rate-limit context that helps an agent invoke the tool safely.

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 compact and front-loaded: one clear purpose sentence followed by three concise, high-signal bullet lines covering access, permission, and rate limit. Every sentence adds operational value 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?

The description gives strong access and scope context, but it is incomplete for an agent that needs to call the tool correctly: index and limit semantics are absent, no output format is described, and there is no guidance on pagination or defaults. With no output schema, these gaps matter.

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

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

The schema provides no descriptions for index, limit, or accountType, and the description only clarifies accountType via 'comma-separated accountType' and 'multiple wallet types'. Index and limit are left completely undocumented, so the description only partially compensates for the 0% schema coverage.

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 tool queries 'all confirmed conversion records', specifying a concrete verb, resource, and scope. It does not explicitly differentiate itself from the many conversion-related siblings like QueryResult or QueryOrderByPage, so it falls just short of a 5.

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

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

The description implies the tool is for reading confirmed conversion history and notes prerequisites like API Key authentication and ACL permissions. However, it gives no explicit guidance on when to choose this tool over sibling conversion tools or when not to use 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 indicate destructiveHint=true and readOnlyHint=false, but the description goes well beyond that by detailing the cancel-and-replace behavior, reliance on order book data, API rate-limit implications, maxChasePrice protection, and explicit stop conditions. It also warns about runaway risk in extreme volatility, providing actionable behavioral 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?

The description is well-structured with markdown headings and bullet points, and every section adds actionable information. The core behavior is front-loaded, followed by execution steps, price formulas, and risk notes. Despite its length, it remains tightly organized and free of 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?

Given the complexity of a strategy creation tool with no output schema and a very sparse input schema, the description covers the core execution model, price calculations, risk controls, and alternatives. It falls slightly short by not explaining a few parameters, not clarifying if a chase distance or percentage is required, and not indicating the response shape or strategy ID. Overall it is still rich enough to support correct selection and 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?

With schema description coverage at only 8%, the description carries most of the semantic weight. It provides explicit formulas for chaseDistance and chasePercentE4, explains maxChasePrice as a protection bound, and offers parameter selection recommendations. However, it leaves several parameters (triggerPrice, reduceOnly, positionIdx, leverageType) undocumented and does not clarify whether chaseDistance and chasePercentE4 are mutually exclusive or if at least one is required.

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

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

The description clearly states the tool creates a Chase Order strategy that monitors market price and adjusts order price, and the agent hint explicitly ties it to 'fast order execution with price tracking'. It also distinguishes itself from TWAP and Iceberg strategies, so an agent can tell it apart from sibling strategy tools without opening their schemas.

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

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

The description includes a dedicated 'When to use' section listing concrete conditions (fast execution, volatile market, staying near top of order book), and a 'Do not use' clause pointing to TWAP or Iceberg instead. It also gives guidance on when to prefer chaseDistance versus chasePercentE4 based on liquidity.

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 adds meaningful behavioral context beyond the annotations: the bot automatically rebalances positions, rate limiting is 10 requests/second per UID, and the endpoint is subject to compliance wall, GEO IP, and KYC checks. This complements the destructiveHint annotation without contradicting it.

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 organized into readable paragraphs and front-loads the main purpose, but it is somewhat redundant: the getComboLimit pre-call instruction and the bot_id follow-up note are each stated twice. It would be tighter if the agent hint did not repeat the earlier guidance.

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

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

The description covers the key workflow, required parameter categories, output bot_id, rate limits, and compliance checks. However, it omits confirm from its 'Required parameters' summary even though confirm is required in the schema, and it leaves important enum semantics unexplained, so an agent still needs external knowledge to invoke with full confidence.

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 only 6% schema description coverage, the description needed to compensate, and it partially does by explaining that leverage, initial margin, rebalancing mode, and symbol_settings with target_position_percent and side are core. However, it does not explain the many enum values or optional parameters, leaving substantial ambiguity for a 16-parameter schema.

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

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

The first sentence states a clear verb and resource: 'Creates a futures combo trading bot that manages a portfolio of multiple futures symbols.' It also signals the distinct behavior of rebalancing positions, which sets it apart from other bot-creation siblings even without naming them explicitly.

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

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

The description gives explicit workflow guidance: call getComboLimit first to validate parameter ranges, and use the returned bot_id for getComboDetail or closeComboBot. It does not explicitly contrast this tool with createDCABot, createGridBot, or other create-* siblings, so it stops short of a 5.

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

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

Annotations already mark the tool as destructive and not read-only. The description adds useful behavioral context: the request is forwarded to a downstream MT5 bind flow with validation checks, business failures surface as MCP tool errors, and unsupported optional parameters may cause downstream rejection. It could more explicitly state the hard-to-reverse nature of the binding, but the confirm parameter schema already covers that.

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 long, but it is organized with headings, bullets, and an explicit agent hint. Nearly every sentence carries actionable information for correct invocation, post-success messaging, or failure handling. Some verbosity around the leaderboard recommendation flow could be trimmed, but it supports correct tool selection in the orchestrated flow.

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, externally visible bind operation with no output schema, the description is unusually complete. It covers prerequisites, parameter format, common failure modes, post-success reply content, and even testnet vs production link construction. An agent has everything needed to invoke the tool correctly and handle the user-facing outcome.

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 33% of parameters are described in the schema, but the description compensates strongly. It explains that investmentE8 is an integer e8 amount representing whole-number USDT values with a concrete example, and that providerMark must be an exact identifier rather than inferred from a display name. The confirm parameter's requirement is already fully described in the schema.

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

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

The description opens with a precise verb and resource: 'Create a new Copy Trading TradFi follow binding' and names the only two inputs that matter. It is clearly distinguishable from sibling tools like getCopyTradingClassicLeaderboard, getCopyTradingTradFiLeaderboard, and createCopyTradeBind because it explicitly targets the MT5 TradFi bind flow.

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 thorough when-to-use guidance: call leaderboards first when the user requests a recommendation, map a TradFi selection back to providerMark, ask for the follow amount, and use this endpoint only after an exact providerMark is known. It also states when not to use it, such as not inferring providerMark from a display name and not expecting support for private-link-only admission flows.

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 indicate destructive=true and readOnly=false, but the description goes further by explaining the service automatically uses the caller's UTA account, derives symbol scope, applies downstream whitelist and Sync Master logic, and surfaces business failures as MCP tool errors. This is valuable behavioral context 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?

The description is long but front-loaded and logically organized: purpose first, then failure modes, then usage workflow, then parameter semantics, then post-call behavior. There is minor redundancy—the automatic UTA account behavior is stated twice—but the length is justified by the complexity of the tool and the required post-call reply and URL instructions.

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 there is no output schema, the description covers all operational needs: how to obtain leaderMark, how to format investmentE8, the confirm safety requirement, common failure modes, the success message format, and the testnet/production follow-detail link. The inclusion of the full copy-trading recommendation workflow also makes the context complete for an agent.

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 only 33%, but the description compensates strongly. It explains leaderMark must be exact and should come from leaderboard selection, and it fully specifies investmentE8 as an integer e8 string representing whole-number USDT, with the concrete example '10000000000 for 100 USDT'. The confirm parameter is already well documented in the schema.

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

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

The description opens with a clear, specific statement: 'Create a new Copy Trading Classic follow binding by specifying a target leaderMark and the intended investmentE8 only.' This names the exact resource, the action, and the key inputs, distinguishing it from related sibling tools like getCopyTradingClassicLeaderboard and createCopyMt5Bind.

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 explicit usage context: use only after an exact leaderMark is known, do not infer it from a nickname alone, and first consult both leaderboard endpoints before recommending. It does not explicitly name the alternative bind endpoint (e.g., createCopyMt5Bind) for MT5 scenarios, but the 'Classic' framing and workflow are clear enough for selection.

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 convey that this is a write operation with destructive potential, but the description adds substantial behavioral context beyond that: authentication/KYC requirements, return of bot_id, the banned-user status_code=421 behavior, and the 3 qps rate limit. It clearly explains what the tool does and what the agent can expect on success or 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?

The description is well-structured and dense: a one-sentence purpose, a concise prerequisites list, then return/error/rate-limit details, and finally a useful agent hint. Every section earns its place and the most important information is front-loaded. No redundant filler or vague prose.

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

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

Given the complexity of nested parameters and the absence of an output schema, the description provides the essential operational details: what the bot does, prerequisites, constraints, return value, a key error case, and rate limiting. An agent has enough context to invoke the tool correctly and understand the outcome, especially when combined with the confirm parameter's schema description.

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 only 25%, so the description must compensate for the undocumented nested parameters. It names the core fields (frequency, quote coin, pairs, max investment amount) and the agent hint adds practical meaning: common frequency values, that pairs contain base coin and per-round amount. It does not fully explain every optional field like channel or toolsDiscoveryParameter, so it is helpful but not exhaustive.

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 action and resource: 'Creates a DCA bot that automatically invests at regular intervals.' This distinguishes it from the many sibling bot creators by naming the DCA strategy and its core behavior. The key inputs are listed up front, making the tool's function immediately understandable.

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 strong contextual guidance: authentication/KYC prerequisites, pair validity rules, minimum frequency, maximum pairs, and a rate limit. However, it does not explicitly name alternatives or state when not to use this tool versus other bot-creation tools like createGridBot or createComboBot, so it stops short of full exclusion guidance.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds useful behavioral context beyond these: the bot auto-places orders, there is a rate limit, compliance/KYC walls may apply, and validation errors are surfaced via check_code. It also notes bot_id is needed for follow-up operations. No contradiction with annotations.

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

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

The description is organized with purpose first and front-loaded, but it repeats the validation instruction: 'Before calling this endpoint, use /v5/fgridbot/validate' and later 'Agent hint: Always call validateFGridInput first.' The redundancy adds length without adding information.

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

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

For a complex creation endpoint with no output schema, the description covers key operational context: required/optional parameter groups, mandatory pre-validation, rate limits, compliance/KYC, ongoing auto-trading behavior, and the need to preserve bot_id for later operations. It does not fully explain the response shape or all optional parameters, but the critical context for safe invocation is present.

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

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

Schema description coverage is only 4%, so the description must compensate. It does map high-level concepts to parameters: price range (min_price/max_price), grid count (cell_number), initial investment (total_investment), and optional TP/SL, entry trigger, and trailing stop. However, many parameters such as source, channel, create_type, block_source, and followed_grid_id remain unexplained, leaving significant gaps for a 26-parameter tool.

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

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

The description states a clear verb and resource: 'Creates a single futures grid trading bot' and explains the bot will automatically place grid orders within a price range. This distinguishes it from generic create/order tools, though it does not explicitly name sibling alternatives like createGridBot or createFMartBot.

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 explicitly instructs the agent to call /v5/fgridbot/validate (validateFGridInput) before creating, and explains how to interpret check_code if creation fails. It also provides rate limit and KYC/compliance prerequisites. However, it does not directly say when to choose this tool over similar bot-creation siblings, so it misses the 'vs alternatives' 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 carry destructiveHint=true and readOnlyHint=false, so the description does not need to restate those. It adds useful behavioral context: rate limits, compliance/KYC checks, auto-cycle restart behavior, and how the martingale order behavior scales. No contradiction with annotations detected.

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 longer than average, but the tool's 18-parameter surface and complex behavior justify the length. Core behavior is front-loaded, followed by parameter summaries, validation prerequisites, rate limits, and an agent hint. There is some redundancy between the endpoint instruction and the duplicate agent hint.

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

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

For a complex creation tool with no output schema and very low schema coverage, the description covers trading logic, validation prerequisites, compliance, and post-call bot_id usage. However, it does not specify exact value formats, fails to mention the confirm requirement beyond what the schema already says, and its enum hints are inconsistent with the schema, leaving meaningful ambiguity on required inputs.

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 only 6% schema description coverage, the description needed to compensate, and it does explain key parameter roles such as price_float_percent, add_position_percent, max add count, initial margin, and round TP. However, it gives misleading literal enum values: martingale_mode is described as '1=Long, 2=Short' while the schema requires string enums, and auto_cycle_toggle is described as '=1' while the schema uses AUTO_CYCLE_TOGGLE_ENABLE/DISABLE. It also omits the required confirm parameter and several optional 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 opens with a specific verb and resource ('Creates a futures Martingale trading bot') and explains the core trading behavior: opening an initial position, adding on price movement, and scaling each add. This clearly distinguishes it from sibling tools like getFMartLimit, closeFMartBot, createGridBot, and createComboBot.

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 instructs the agent to call getFMartLimit (or /v5/fmartingalebot/getlimit) before invoking the tool to validate parameter ranges. It also notes that the returned bot_id is needed for getFMartDetail and closeFMartBot, providing clear routing and next-step guidance.

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