Bitget Agent MCP

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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds value by separating read actions (oiLimit, paymentCoins, switchStatus, deductInfo) from write/set actions. However, it does not disclose side effects, reversibility, or any confirmation requirements for writes. The description does not contradict annotations, but it also doesn't go beyond the basic read/write split.

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

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

The description is a single, dense sentence that efficiently lists all action categories and includes a valuable parenthetical limitation. The '[VERB]' placeholder is a minor structural flaw, but the rest is well-packed with 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?

With 14 parameters and 9 distinct actions, the description provides a compact overview of all action groups and highlights a key limitation. The schema covers individual parameter semantics, so the description's role is to tie actions together, which it does. It could have mentioned the 'view' summary/full parameter or confirmation flow, but those are already 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?

Schema coverage is stated as 100%, so the baseline is 3. The description adds one meaningful cross-reference: the isolated margin note linking to setLeverage posSide. It also summarizes action-to-parameter relationships (e.g., 'setLeverage (needs: category, leverage)'), which the schema independently provides. No major added semantic beyond the schema.

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

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

The description clearly enumerates the tool's scope: setting account mode, holding mode, leverage, switching account/deduct, and reading oiLimit/paymentCoins/switchStatus/deductInfo. It distinguishes itself from sibling account_overview by covering configuration actions. However, it lacks a single strong verb due to the literal '[VERB]' placeholder, and the resource is phrased as 'Account settings by intent' rather than a direct verb+resource.

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 explicit usage context by grouping actions by intent and explicitly notes a non-supported operation: 'No standalone cross/isolated margin-mode switch in v3 — see setLeverage posSide for isolated.' This points to an alternative, satisfying the when-not/alternative guidance. It does not explicitly say when to prefer this tool over account_overview, but the action list gives 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses that the tool 'fans out' to multiple subresources and that 'Each section reports ok/error independently.' This is valuable behavioral context about partial failures. It does not mention pagination, rate limits, or response structure, but the safety profile is already covered by annotations, so the added disclosure merits a 4.

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

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

The description is a single, front-loaded sentence with no fluff, but the literal '[VERB]' placeholder is a structural artifact that undermines clarity. The rest of the sentence is efficient, but the placeholder prevents a higher 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?

There is no output schema, so the description carries responsibility for explaining return behavior. It mentions the sections and independent error reporting, but does not describe the structure of each section or the full response shape. For a tool with multiple optional parameters and no output schema, this is adequate but not comprehensive.

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 has 100% parameter description coverage, so the schema already explains the coin filter, view mode, fields, symbol, and category parameters. The tool description adds only marginal context by referencing 'with category/symbol' for positions and fee rate, which is already in the schema. This aligns with the baseline of 3 for high 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 it is a 'One-call account snapshot' that aggregates multiple account aspects (assets, settings, funding assets, positions, fee rate), which distinguishes it from sibling tools that focus on individual resources. The verb is implied by 'snapshot' and the scope is specific, though the leading '[VERB]' placeholder is a minor artifact. It does not explicitly name alternatives, so it stops short of a 5.

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

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

The description conveys clear usage context: use this for a consolidated account overview in a single call. It also specifies conditional behavior ('with category/symbol') for including positions and fee rate. However, it does not explicitly state when to use an alternative tool or provide exclusion criteria, so it misses the top score.

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 non-read-only, non-idempotent, non-destructive behavior. The description adds no additional behavioral context, such as whether setupAccount modifies account state, whether records pagination is handled, or any side effects or prerequisites. It does not contradict annotations, but it also fails to enrich the agent's understanding beyond the structured fields.

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

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

The description is extremely brief, but the inclusion of the literal '[VERB]' placeholder indicates an incomplete template. The pipe-separated list is not a coherent, well-structured description and fails to front-load a clear purpose.

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 tool with 15 parameters, three action modes, and no output schema, the description is inadequate. It does not explain the overall workflow, what setupAccount entails, or how deposit relates to funds_records or transfer_funds. The agent would have to rely entirely on the schema to understand usage, leaving significant 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 100%, so the schema already documents all parameters including the action enum with per-action requirements. The tool description merely lists intents without adding meaning beyond what the schema provides, so it meets the baseline for high 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 literally begins with '[VERB]' placeholder and the remaining text is a list of intents rather than a clear verb+resource statement. It provides some clarity by enumerating address, records, and setupAccount, but fails to articulate the tool's unified purpose or distinguish it effectively from sibling tools.

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

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

The description provides no guidance on when to use this tool versus alternatives, and no exclusion or preference context. The action parameter schema partially fills in per-action requirements, but the tool description itself does not help an agent decide when to call deposit over related tools like transfer_funds, funds_records, or withdraw.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds specific behavioral detail by stating exactly what each discovery call returns, including the no-argument case. 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 description is a single sentence with semicolon-separated variants, effectively front-loading the meta nature and covering all four modes with zero waste. Every clause earns its place.

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

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

Despite lacking an output schema, the description adequately explains the return behavior for each mode (domains, tools, schema, search results). Given that this is a lightweight meta-discovery tool, it fully covers what an agent needs to know 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?

Schema description coverage is 100%, so a baseline of 3 applies. The description elevates this by grouping parameters into distinct usage modes and clarifying the empty-call behavior, which the schema alone doesn't explicitly state. It adds a little semantic value beyond the schema, though not extensive.

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 this as a [META] tool to 'Discover the tool surface', with a specific verb and resource. It distinguishes itself from operational siblings by enumerating four explicit discovery modes: listing domains, listing domain tools, retrieving full tool schemas, and keyword searching.

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 explicit when-to-use guidance for each invocation variant (no args, domain, tool, search). Although it doesn't name alternatives, none of the sibling tools offer this introspection capability, so the usage context is unambiguous and 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=true, idempotentHint=true, and destructiveHint=false, so the description's 'read-only' note is redundant. It adds some context by listing the data categories, but it does not disclose pagination behavior, response format, or other operational details. This is a marginal addition beyond the annotations.

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

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

The description is extremely brief, but it is not effectively concise because it contains a '[VERB]' placeholder and uses a cryptic pipe-separated list. The structure is under-specified and gives the impression of a template that was not completed.

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 18 parameters and no output schema, this one-line description is insufficient for an agent to understand how to invoke the tool correctly. It does not explain pagination, return values, or how to combine parameters for different actions. The schema descriptions help, but the tool-level description leaves significant 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?

The input schema provides 100% description coverage for all 18 parameters, so the description does not need to repeat parameter details. It does mirror the 'action' enum (financial, convert, subTransfers, transferableCoins) in its list, but this adds no new semantic value since the schema already explains each action. The description fails to provide any additional parameter-level 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 clearly identifies the resource as funds history and enumerates the record types (financial ledger, convert, sub-transfers, transferable coins), which provides useful scope. However, it begins with a literal '[VERB]' placeholder instead of a concrete verb, making the action implied rather than explicit. It does not explicitly differentiate from sibling tools, but the category list gives some implicit distinction.

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

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

There is no guidance on when to use this tool versus alternatives like account_overview or transfer_funds. The description merely states what the tool covers without any context on selection criteria or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's main addition is 'no credentials required', which is a useful behavioral detail. This does not contradict any annotation, but it lacks depth about rate limits, pagination, or potential response size.

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

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

The description is a single sentence but contains the placeholder '[VERB]', which is an incomplete structural artifact. This undermines usability and indicates a lack of finalization, despite the otherwise concise length.

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

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

With 13 parameters, 16 action options, and no output schema, the description is far too sparse. It lists data types (tickers, orderbook, candles, etc.) but does not explain how to choose actions, what the response structure looks like, or how view/limit affect output. The description fails to adequately cover the tool's complexity.

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

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

Schema coverage is 100%, and the input schema already provides detailed descriptions for all parameters. The description itself adds no parameter-specific semantics, so it meets the baseline without going beyond.

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 placeholder verb '[VERB]' instead of a specific action, making it unclear whether the tool fetches, lists, or queries data. The resource 'Public market data' is clear, but the lack of a proper verb reduces purpose clarity to a noun phrase rather than a command.

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

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

No explicit guidance is given on when to use this tool versus siblings like 'order', 'position', or 'account_overview'. The only usage hint is 'no credentials required', which implies public data access but does not state exclusions or alternatives.

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

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

Beyond annotations, the description discloses important behaviors: writes honor dryRun/confirm/readOnly, and cancelAll requires confirm. This adds context about safety gates and destructive actions. The mention of reads clarifies which actions are non-mutating.

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, two sentences, and front-loaded with the core purpose. The list of actions is necessary. Minor penalty for the '[VERB]' placeholder artifact and the mention of 'readOnly' which is not in the schema.

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

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

Despite 33 parameters and no output schema, the description provides only a high-level overview. It lacks information about return values or per-action output expectations. The schema covers parameter details, but the description doesn't explain what the agent should expect from open/detail/history/fills.

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

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

Schema coverage is 100%, so baseline is 3. The description adds semantics for the `orders` parameter (batch) and the confirm requirement for cancelAll, which goes beyond the schema descriptions.

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 manages orders, listing specific actions such as place/cancel/modify, batch support, cancelAll, countdownCancel, and read operations. This is a specific verb+resource that distinguishes it from sibling tools like strategy_order, market, and position.

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

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

The description implies usage for order management but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or alternative tools. The list of operations gives context, but no sibling differentiation is provided.

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

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

The description explicitly states that close and closeAll are destructive and require confirm, which directly contradicts the annotation destructiveHint=false. This is a serious inconsistency, earning a score of 1. The additional mentions of normalized reads and pagination are helpful but do not override the 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?

The description is a single, dense sentence that quickly lists the main action categories and key caveats. It is appropriately sized and front-loaded, but the '[VERB]' placeholder feels incomplete and slightly detracts from an otherwise concise structure.

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

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

Given the tool's 13 parameters, lack of output schema, and only moderate annotation coverage, the description gives a solid overview but omits several operational details (e.g., fetchAll, view, fields). It covers the core actions and destructive requirements, but more context about pagination behavior and parameter interdependencies would improve completeness.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds marginal context beyond the schema, such as 'reads are normalized' and 'history paginates', but the action descriptions in the schema already explain the parameter semantics in detail. The description does not significantly reduce ambiguity about the 13 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 clearly states the tool acts on positions by intent, enumerating specific actions (info, history, adlRank, close, closeAll) and clarifying that close targets one symbol while closeAll targets a whole category. This distinguishes it from siblings like order or account_overview, though the placeholder '[VERB]' is slightly unpolished.

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 context on when to use it (e.g., for position management) and warns that close/closeAll are destructive and require confirmation. However, it doesn't explicitly mention alternatives or exclusions, such as 'for placing orders, use order' — making the guidance implied rather than fully 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?

The description states it can invoke any operation, including high-risk destructive ones like withdrawal, but the annotations declare readOnlyHint=true and destructiveHint=false. This directly contradicts the annotations, making the tool's safety profile misleading. The description does add nuance about the safety gate, but that cannot reconcile the fundamental 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?

The description is a single, dense sentence that front-loads the core purpose ('[RAW] Escape hatch') and packs in essential safety behaviors without unnecessary fluff. Every phrase earns its place, maintaining high information density.

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 open-ended escape hatch, the description covers the essential usage (operationId, args, dryRun, confirm) and notes that valid IDs are in a generated catalog. It lacks details about return format or error handling, but given the tool is generic, it is reasonably complete. The contradiction with annotations is a notable gap that could confuse agents.

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

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

Schema description coverage is 100%, so all parameters (args, dryRun, confirm, operationId) are already documented. The description adds minimal extra parameter-level value (e.g., dryRun works even in readOnly), but the baseline of 3 applies since the schema carries the heavy lifting.

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

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

The description clearly states the tool invokes any v3 operation by operationId, positioning it as an escape hatch that bypasses the curated surface. It uses a specific verb ('invoke') and resource ('any v3 operation'), distinguishing it from curated sibling tools that target specific endpoints.

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 ('Bypasses the curated surface') and mentions the safety gate (dryRun, confirm for high-risk ops), giving context for appropriate usage. However, it does not explicitly say 'use when no sibling covers your operation' or provide exclusions.

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

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

Annotations already set readOnlyHint=false, indicating a write operation, so the description doesn't need to restate that. It does add behavioral context by enumerating two possible actions (submit and list), which shapes expectations. However, it does not disclose details like confirmation requirements or dry-run behavior beyond what the schema provides.

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

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

The description is a single sentence, very concise and front-loaded with the core purpose. However, the literal '[VERB]' prefix is an artifact that should have been replaced, and the structure could be slightly cleaner without it.

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

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

The tool has 9 parameters and no output schema, yet the description is minimal. It does not explain return values, how the two modes differ in response, or how parameters like confirm, dryRun, and lists interact. Given the complexity, the description is insufficient for an agent to fully understand the tool's behavior.

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

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

All 9 parameters have descriptions in the schema (coverage 100%), so the baseline is 3. The description itself adds little parameter-level meaning, but it does reinforce the split between 'submit' and 'repayable' actions, which aligns with the action parameter enum.

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 ('repay') and resource ('account liabilities'), and clearly distinguishes between two modes: submitting a repayment or listing repayable coins/amounts. This differentiates it from sibling tools like deposit or withdraw, which handle funding or withdrawals.

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 the tool—when you need to repay liabilities—but does not explicitly mention alternatives or exclusions. The two modes ('submit' vs 'repayable') give hints on sub-usage, but there is no direct comparison 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?

Annotations already declare readOnlyHint=false, and the description usefully adds that writes honor dryRun/confirm/readOnly, clarifying preview and confirmation behavior for a mutation-capable tool. It does not disclose response shapes, error semantics, or auth requirements, but the added safety-flag context goes beyond the annotations.

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

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

The description is extremely concise and front-loaded with the core intents, with zero filler. The '[VERB]' placeholder is an unnecessary artifact, but for a tool with 26 parameters, this brevity keeps the most important information accessible.

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 tool's complexity (26 parameters, no output schema), the description is thin: it names intents and safety behavior but does not explain return-value conventions, how to map actions to required parameters, or pagination behavior. The schema's rich per-parameter descriptions partially compensate, making it minimally viable but not complete.

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

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

Schema coverage for parameters is 100%, and each parameter already has detailed descriptions and enums, including action-specific remarks in the 'action' parameter. The tool description itself adds no parameter-level information beyond listing high-level intents, so the baseline 3 is appropriate.

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

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

The description identifies the resource as strategy (trigger/plan) orders and enumerates the five distinct intents (place, cancel, modify, open, history), which clearly distinguishes it from sibling tools like 'order'. The literal '[VERB]' placeholder is a formatting flaw, but the action list makes the purpose specific and actionable.

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 implicitly scopes the tool to strategy trigger/plan orders versus normal orders, and the 'writes honor dryRun/confirm/readOnly' note gives some operational context. However, it never explicitly states when to prefer this tool over a sibling like 'order' or 'market', nor does it list exclusions or prerequisites.

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

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

The annotations declare destructiveHint=false, yet the description exposes actions like deleteApiKey and freeze, which are high-risk/destructive operations. This is a direct contradiction. The description also fails to mention side effects, confirmation requirements, or rate limits, so behavioral traits are not transparently disclosed.

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

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

The description is only one line and compact, but it is a pipe-separated fragment beginning with the placeholder '[VERB]'. It is under-specified and lacks a well-formed, front-loaded summary; this is more an incomplete scaffold than a concise, polished 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?

For a 23-parameter, multi-action tool with no output schema, the description is too thin: it omits return shapes, pagination behavior, confirmation semantics, and broader operational context. Although the schema provides detailed parameter descriptions, the top-level description does not adequately orient an agent for a tool of this complexity.

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

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

Schema description coverage is 100% with 23 parameters, and the action parameter provides especially rich semantics, mapping each action to its required fields. The top-level description adds nothing beyond the schema, but the baseline of 3 applies because the schema carries the parameter-documentation burden effectively.

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 lists sub-account intents (create, list, freeze, assets, apiKeys, depositAddress, depositRecords) and makes the domain clear, but it lacks an explicit verb and starts with the placeholder '[VERB]'. It communicates that the tool handles sub-account operations but does not clearly differentiate from sibling account-related tools.

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

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

No guidance is given on when to use this tool versus alternatives such as account_overview, transfer_funds, or deposit. The action list implies sub-account management, but there are no explicit exclusions, prerequisites, or recommendations for when a sibling tool would be more appropriate.

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 reveals that preflight performs no funds movement and that transfers honor dryRun/readOnly, which is valuable safety-relevant behavior. It does not mention authentication needs or response details, but adds meaningful context not present in the annotations.

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

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

The description is a single sentence and not verbose, but it includes the placeholder '[VERB]' which wastes words and reads as an unfinished template. The sentence structure is tight but the artifact prevents a higher 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?

Given the tool has 13 parameters and no output schema, the description is too sparse. It does not explain the overall transfer workflow, required fields for each action, return values, error conditions, or account type prerequisites. The preflight note is helpful but insufficient for a tool of this complexity.

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

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

The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description doesn't add parameter-level meaning; its mention of preflight and dryRun relates to behaviors already covered by the schema. No extra semantics are provided.

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 moves funds and enumerates the three action intents (internal, mainToSub, subToMain), which distinguishes it from sibling tools like withdraw or deposit. However, the literal '[VERB]' placeholder is an artifact that slightly detracts from professionalism, so it’s a strong but not perfect purpose statement.

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

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

The description implies usage by listing the three action types and mentions preflight for checking without transferring. It does not explicitly contrast with alternatives like withdraw/deposit for external moves, nor does it state when not to use this tool. Guidance is present but implicit.

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 annotations (readOnlyHint=false, idempotentHint=false), the description adds that submit is 'irreversible' and 'needs confirm', and that records is the history view. This gives important behavioral warnings not present in the annotations. 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 a single compact sentence that conveys the core operation split. The '[VERB]' placeholder is a minor flaw, but otherwise every word earns its place.

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

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

For a tool with 27 parameters and two intents, the description provides a high-level map of behavior and key requirements. The schema handles detailed parameter semantics, so the description's brevity is acceptable, though it could mention confirm more.

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 groups required parameters by intent ('submit needs...', 'records needs...'), which is not obvious from the flat schema. Since schema coverage is 100%, this grouping adds practical semantic value.

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 identifies the tool as 'Withdrawals' and distinguishes two intents: 'submit' for sending funds out and 'records' for history. This clearly separates it from sibling tools like deposit and transfer_funds, and the resource is explicit.

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 tells the agent when to use each intent: 'submit' requires coin, transferType, address, size; 'records' requires startTime, endTime. It also warns that submit is irreversible and needs confirmation, which is key usage context. It does not explicitly name alternative tools, but the intent split provides sufficient guidance.

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