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

Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description reinforces this with the warning that confirm=true must only be set after user agreement and that this is the final action. It also exposes the non-obvious preview behavior of the first call. This meaningfully augments the annotation-only picture with safety-relevant behavioral detail.

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

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

The description is short and front-loaded: it states the purpose first, then the critical confirmation workflow. Every sentence carries either identity, workflow, or safety information. There is no filler or restatement of available schema data.

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 workflow for a destructive execution tool: do not confirm until the user agrees, and expect a preview on the first call. It names the source quote tools and the required proforma_id provenance. It does not describe the return payload, but with no output schema and a strong parameter schema plus annotations, the remaining gap is minor.

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

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

Schema coverage is 100%, so the schema already documents all four parameters in detail. The description nevertheless adds value by explaining that proforma_id comes from broker_quote_* operations and by clarifying the confirm parameter's preview-then-execute behavior. It does not need to repeat jwt or idempotency_key because those 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 identifies the tool's verb and resource: it 'confirms and executes' a 'previously created proforma' from broker_quote_buy, broker_quote_sell, or broker_quote_swap. It also frames itself as 'STEP 2' and the 'Final action', which distinguishes it from the quote-creation sibling tools. This is specific and 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 gives explicit workflow instructions: first call without confirm=true returns a preview, and confirm=true should only be set after the user agrees. It also implies the correct timing by stating it follows broker_quote_* operations. This is strong, actionable guidance on when and how to invoke the tool.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive, so the safety profile is covered. The description adds meaningful behavior context: the data source (Wallet/Broker vs Pro), the output shape (ISO 8601 date/time and quote-symbol price), and the public access marker.

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

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

Three concise sentences with no filler. The core purpose, data source caveat, required inputs, and return shape are all included without unnecessary detail.

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

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

Even though there is no output schema, the description explains the return format: data points with ISO 8601 date/time and quote-symbol price. For a simple two-parameter read-only tool, this covers what an agent needs. It could go slightly deeper on exact candle fields, but the description is not incomplete enough to penalize heavily.

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

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

Schema coverage is 100%, and both pair and timeframe are fully documented with formats, examples, and enum values. The description reinforces that the price is in the quote symbol, but adds little beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: it gets Wallet price history/candles for a pair and timeframe. It also explicitly distinguishes itself from Pro Trading, which separates it from sibling tools like pro_get_candles and broker_get_asset_price.

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 for Wallet/Broker-service price history, not Pro Trading data. It also states the required inputs (pair and timeframe). It does not name an explicit alternative tool, but the exclusion is clear enough for an agent to route correctly.

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

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

Annotations already cover read-only, idempotent, and non-destructive safety. The description adds meaningful behavior beyond annotations: prices include spread and differ from Pro Trading prices, and the endpoint is marked [PUBLIC], which is useful authentication context. It doesn't detail the response shape, but for a read-only ticker call the safety profile is already well covered.

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

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

Three sentences with no filler: it front-loads the operation, gives the key differentiator, then provides minimal parameter requirements. Every sentence adds information needed for selection or invocation, and the structure is easy to scan.

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 only two parameters, full schema coverage, and strong sibling context, the description contains what an agent needs to call the tool correctly. The lack of an output schema means return fields aren't specified, but 'comprehensive market ticker data' plus the tool name is sufficient for a basic call. A minor gap is not explicitly listing the data fields returned, but this is acceptable at 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%, so both base_symbol and quote_symbol are already fully documented in the input schema. The description only restates the examples and default (BTC, EUR) without adding new semantic constraints or format details. The baseline of 3 is appropriate because the schema handles the heavy lifting.

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

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

States a specific action ('Gets comprehensive market ticker data') and resource ('a cryptocurrency') with explicit service scope: Wallet/Broker, not Pro Trading. The phrase 'prices include spread and differ from Pro Trading prices' clearly distinguishes it from sibling quote/ticker tools. This is unambiguous and directly tied to the tool's name and role.

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 identifies the Wallet/Broker context and warns that prices differ from Pro Trading, which tells an agent when this tool is appropriate. It also states the required base_symbol and optional quote_symbol with defaults. However, it does not name the exact sibling alternative (e.g., pro_get_ticker) for Pro Trading data, leaving the alternative somewhat 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?

Annotations already declare readOnly, non-destructive, idempotent, and open-world hints, so the safety profile is established. The description adds useful behavioral facts beyond that: it returns a list, prices are for one base unit, EUR is the default quote, and the operation is public. 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?

Three concise sentences plus the [PUBLIC] tag front-load the purpose, add the key default, and note the optional filters. Slightly repetitive phrasing around Wallet/Broker service costs the fifth point, but there is no wasted detail.

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

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

For a read-only price lookup with three optional parameters and no output schema, the description covers the essential semantics: price in quote units, default quote, optional base filter, historical date support, and list response. It is adequate for correct invocation, though it leaves minor ambiguity about what each list entry contains when multiple symbols are returned.

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

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

Schema description coverage is 100%, so each parameter already has a meaningful description. The description reinforces that date is for historical rates and base_symbol is optional, and it clarifies the price-unit semantics, but it does not substantially extend the parameter definitions themselves.

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 identifies a specific verb and resource: gets Wallet/Broker exchange rates for cryptocurrencies and returns the price of one unit in a chosen quote symbol. It is clear enough to differentiate a price lookup from other broker reads, though it does not explicitly name sibling tools like broker_get_asset_data or pro_get_ticker to eliminate ambiguity.

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

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

The description gives context about optional filters and the default EUR, but it never states when to use this tool versus alternatives such as pro_get_ticker, broker_get_asset_data, or portfolio_get_validation. No when-not-to-use guidance 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?

Annotations already mark the tool as read-write and idempotent, but the description adds critical behavioral context: the operation only creates a proforma quote and must be followed by broker_confirm_quote. The [PRIVATE] tag also flags restricted scope. No annotation contradiction is present.

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

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

Two short sentences plus the [PRIVATE] tag deliver the purpose, prerequisite, process step, and required next action without waste. Critical information is front-loaded: the verb, the resource, the proforma nature, and the mandatory confirmation step.

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?

Although there is no output schema, the description conveys that the result is a proforma quote and that confirmation is mandatory, which gives an agent enough to orchestrate the two-step flow. It does not spell out the exact return fields or quote expiry, but those are minor gaps given the clear sequence and the fully documented input schema.

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

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

Schema description coverage is 100%, so the baseline is a 3. The description adds extra meaning by explaining that origin_pocket_id holds fiat currency and destination_pocket_id receives cryptocurrency, and by directing the agent to wallet_get_pockets for finding these IDs. This helps map parameters to real-world roles beyond the schema text.

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

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

The description uses a specific verb ('Buy') with a clear resource ('cryptocurrency using fiat balance from a pocket') and then clarifies that it creates a proforma quote, not a final purchase. This distinguishes it from siblings like broker_quote_sell, broker_quote_swap, and broker_confirm_quote. No ambiguity remains about what the tool accomplishes.

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 explicitly staps the process: STEP 1, use wallet_get_pockets to find pocket IDs, and REQUIRES subsequent confirmation with broker_confirm_quote. It does not mention alternatives for sell/swap scenarios, but the buy-specific language and the named confirmation step give clear context for when this tool is the right choice.

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-destructive, idempotent, and open-world. The description adds valuable behavioral context: this is a proforma quote, not an execution, and it must be followed by broker_confirm_quote. It also marks the tool [PRIVATE], which is useful. It does not detail auth requirements or quote validity, but the core behavior is 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 compact, front-loaded with the action, and uses clear steps. Every sentence provides useful information: what it does, how to find pocket IDs, and the required next step. The [PRIVATE] tag is extra useful context. It is slightly dense but not bloated.

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 definition is complete enough for a first-step quote tool. It names the prerequisite (wallet_get_pockets), the required follow-up (broker_confirm_quote), and the key parameter semantics. With no output schema, it could describe the quote response, but that is likely covered by the confirm tool and not essential to invoke the sell quote step.

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. The description adds directional semantics: origin is cryptocurrency, destination is fiat, and amount is in the origin cryptocurrency. This aligns with the parameter descriptions and enhances understanding. It could mention that the quote result is needed for confirmation, but the workflow hint covers that.

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

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

The description states a clear verb and resource: sell cryptocurrency to receive fiat balance in a pocket, creating a proforma quote. It distinguishes this from siblings by specifying the sell direction and the two-step flow. It could be more explicit about being a quote-only operation, but 'proforma quote' conveys that.

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 workflow guidance: use wallet_get_pockets to find pocket IDs, and REQUIRES subsequent confirmation with broker_confirm_quote. This tells an agent when to use the tool and what must happen next. It does not explicitly contrast with broker_quote_buy/swap, but the sell direction is clear from the name and description.

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

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

Annotations do not cover quote vs. execution behavior, so the description adds valuable context by calling this a 'proforma quote' and requiring later confirmation. This prevents the agent from believing the swap is executed atomically. 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?

Three dense sentences, with the core action first, prerequisites second, and required follow-up last. The 'STEP 1' marker clearly sets expectations, and every sentence contributes value without repetition.

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

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

The description covers the action, how to find input IDs, and the mandatory next step. The main gap is that it does not specify what the returned proforma quote contains or how to reference it in broker_confirm_quote, but the two-step workflow is still reasonably clear.

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

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

Schema description coverage is 100%, so the params are already well documented. The description adds only procedural context ('Use wallet_get_pockets to find pocket IDs'), which slightly supplements the origin/destination parameters but is not needed to understand 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 states a specific action ('Swap/exchange one cryptocurrency for another between pockets') and clarifies it 'Creates a proforma quote.' It clearly differentiates this from sibling buy/sell/confirm tools by describing the swap-between-pockets workflow.

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?

Directs the agent to 'Use wallet_get_pockets to find pocket IDs' and explicitly says it 'REQUIRES subseuent confirmation with broker_confirm_quote,' which frames the correct usage flow. It does not explicitly say when not to use it versus buy/sell, but the description's scope is clear enough.

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 annotations: reveals the preview-then-confirm two-call pattern, enumerates operation statuses, and notes that rewards start accruing. For a mutating tool this is substantial behavioral context beyond readOnly/destructive 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?

Four dense sentences with no fluff: action, consequence, return shape, prerequisite lookups, status enum, and confirmation protocol are all front-loaded and necessary.

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

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

Complete for a mutating tool: describes prerequisites, preview/confirm, status values, and helper tools. Without an output schema, it could spell out more of the operation-details structure, but the status enum and type: deposit cover the main return expectations.

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 six parameters. The description adds useful context for pocket_id and confirm, but does not need to repeat parameter definitions.

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

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

States a precise action: transfer funds from Simple Wallet pocket to Earn/Staking. It distinguishes itself from earn_withdraw by direction and specifies the return type (operation details with type: deposit).

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?

Tells the agent to use wallet_get_pockets to resolve pocket_id and earn_get_positions to find available strategies. It also explains the preview/confirm protocol. It does not explicitly contrast with earn_withdraw, but the deposit/withdraw direction is clear from the description.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by detailing the returned data (symbols, APY rates, availability status, lock periods, reward currencies) and marking the endpoint as [PUBLIC]. No contradictions 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?

Three sentences with no filler. The main purpose is front-loaded, followed by return details, use cases, and a public marker. Every sentence adds distinct value.

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

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

Given no parameters, no output schema, and simple list semantics, the description is complete. It states what the tool returns, why to use it, and that it is public. Nothing an agent needs to invoke or interpret this tool correctly is missing.

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

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

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to explain parameters; it instead clarifies what asset information is returned, which is sufficient for an agent to know the tool's scope.

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 ('Get list'), resource ('assets (cryptocurrencies) supported in Earn/Staking'), and scope ('with full details'). It is clearly distinct from general asset tools, though it does not explicitly name a sibling for contrast.

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 use cases: 'discover stakeable assets, verify availability before deposit/withdrawal, and compare returns.' This gives clear context, but it does not mention when not to use it or point to an alternative tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral detail: the response includes movement types, amounts, dates, rates, source/issuer info, supports filtering and pagination, and that all parameters are optional. It does not mention rate limits or exact pagination envelope, but this is sufficient for a read-only list operation.

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

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

The description is compact: one sentence for the core action and scope, one for return fields, one for filter options, and one for response shape and optionality. Every sentence adds value, no filler, and the key information 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?

Given the 11 optional parameters and no output schema, the description adequately conveys the resource scope, return fields, filter dimensions, pagination behavior, and response metadata concept. It does not spell out exact pagination response fields or explicitly route to siblings, but those are minor gaps because the schema covers parameter details and the description covers the operational essence.

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 input schema already documents every parameter. The description adds a useful grouping of filters and the note that all parameters are optional, but it does not substantially expand on individual parameter semantics beyond what the schema provides. Thus the high-coverage baseline of 3 applies.

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

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

The description states a specific verb and resource: 'Get movement history across all Earn positions.' It also enumerates the returned fields and the available filters, which clearly distinguishes it from sibling tools like earn_get_position_movements (position-specific) and earn_get_movements_summary (summary-level). The scope 'across all Earn positions' 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 intended use is clear: retrieve detailed movement history across all Earn positions, with optional filters for symbol, position, type, date range, and pagination. However, it does not explicitly name alternative tools for single-position or summary queries, nor state exclusions. The context is obvious enough for routing, but not 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?

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds meaningful behavioral context: it returns total count, total amounts, and aggregated data, and scopes the query across all Earn positions. It also flags PRIVATE status. Nothing contradicts 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?

Two tight sentences front-load the core action and resource, embed the valid values and return content, and drop a PRIVATE marker. No redundant words or restatement of the tool name.

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

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

With no output schema, the description reasonably discloses what is returned (total count, total amounts, aggregated data) and the scope (all Earn positions). It could name sibling tools for disambiguation or describe response structure more precisely, but for a two-parameter summary endpoint with strong annotations this 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?

Schema description coverage is 100%, so the baseline is 3. The description repeats the valid type values already present in the schema and adds no new meaning for jwt or type beyond what the schema provides.

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

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

Description names the exact operation (get summary statistics), the resource (Earn movements), and the aggregation scope (across all Earn positions), which separates it from sibling movement-listing or position-level tools. It also enumerates the valid type values, leaving no ambiguity about what it operates on.

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 retrieving aggregated movement data by type, but it never explicitly states when to prefer it over earn_get_movements, earn_get_summary, or earn_get_position_movements_summary, nor does it give exclusion criteria. The guidance is implicit in 'summary statistics' versus alternatives, not explicit enough for a 4.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds value by disclosing the return payload: movement types (deposit, withdrawal, reward, fee), amounts, dates, status, and paginated metadata. No contradictions 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?

Four tightly written sentences front-load the core action and return shape. Every sentence adds necessary context: operation, fields returned, pagination, prerequisite, and response format. No filler or repetition.

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

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

With no output schema, the description adequately conveys the return value structure and pagination metadata. The prerequisite workflow (earn_get_positions → this tool) is stated. It could mention ordering or default pagination values, but the essentials for correct invocation are present.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by specifying that position_id comes from earn_get_positions and by clarifying that limit and offset serve pagination, reinforcing the schema without redundancy.

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

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

The description names a specific verb ('Get') and resource ('movement history of a specific Earn position'), clearly distinguishing it from general movement tools like earn_get_movements and from related summary tools. The inclusion of movement types and fields makes the scope 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 explicitly instructs to call earn_get_positions first to obtain the position ID, providing a clear usage sequence. It does not explicitly name alternatives or when not to use the tool, but the 'specific position' scope implies differentiation from broader movement endpoints.

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, covering the safety profile. The description adds return-content context but does not explain the [PRIVATE] marker, auth requirements, rate limits, or error behavior.

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

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

The description is three short sentences with zero filler: core action, return contents, prerequisite. It is front-loaded with the main purpose and keeps supporting details compact.

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

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

For a read-only two-parameter tool with rich annotations, the description provides the prerequisite and high-level return contents. Without an output schema, a bit more detail about the response shape would help, but the gaps are minor.

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 already documents both parameters fully at 100% coverage, including position_id's UUID format and jwt's optional session-token purpose. The description only reinforces that position_id comes from earn_get_positions, adding little beyond the schema.

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

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

The description states a specific verb and resource: 'Get rewards configuration for a specific Earn position.' It also lists what is returned (reward calculation rules, APY details, position-specific staking parameters), and the word 'specific' plus 'position-specific' helps distinguish it from the sibling earn_get_rewards_config.

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 an explicit prerequisite: 'Use earn_get_positions first to get the position ID.' It does not explicitly name alternatives like earn_get_position_rewards_summary or say when not to use them, but the usage 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile needs no restatement. The description adds value by specifying what the response contains (reward symbol, amount, converted fiat) and flags the data as private with the [PRIVATE] marker, though the marker's implications for authentication are left unexplained. 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?

Roughly 50 words, front-loaded with the core purpose and return value. The user_currency sentence partially duplicates the schema, and the trailing [PRIVATE] tag is cryptic, but overall the description earns its length.

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

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

For a read-only 3-param tool with no output schema, the description covers purpose, return fields, and the prerequisite workflow. The main gap is that [PRIVATE] suggests access restrictions but the description never says whether authentication is required despite the jwt parameter existing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds mild value by clarifying that user_currency drives fiat conversion and that position_id originates from earn_get_positions, but it largely mirrors what the schema already documents.

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

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

States a specific verb (Get), resource (rewards summary for a specific Earn position), and the returned payload (reward symbol, amount, converted fiat amount). This scope cleanly distinguishes it from siblings such as earn_get_positions (lists positions) and earn_get_position_rewards_config (position config, not reward values).

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 sequences the workflow: 'Use earn_get_positions first to get the position ID.' This tells the agent the prerequisite call. It does not name alternatives or state when not to use this tool, but the context is clear enough for correct invocation.

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 read-only, idempotent, and non-destructive. The description adds that it lists only active positions, enumerates the returned fields, and emphasizes that positions are locked/yielding funds unlike Pockets. This goes beyond what annotations alone convey, with no 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?

Four sentences, front-loaded with the main purpose, then filter, output fields, and routing guidance. All sentences earn their place, though the [PRIVATE] tag is slightly cryptic and could be clearer.

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

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

For a simple read-only list operation with two optional parameters, the description covers the purpose, output fields, and sibling routing. Combined with full schema coverage and safety annotations, nothing critical is missing for 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?

The schema already fully describes both parameters (jwt and position_id) with 100% coverage. The description merely restates the optional position_id filter without adding format or usage details, so it adds no significant meaning beyond the schema.

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

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

States a specific verb and resource ('List active Earn positions/strategies') and clarifies the optional position_id filter. The description also distinguishes this tool from earn_get_assets and wallet_get_pockets, making its purpose unambiguous relative to siblings.

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

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

Explicitly directs APY-related needs to earn_get_assets and contrasts Earn positions with liquid Pockets. It doesn't compare to every sibling such as earn_get_summary, but the provided routing and distinction give an agent sufficient context for selecting this tool.

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

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

Annotations already indicate readOnly, non-destructive, idempotent behavior. The description adds value by disclosing the returned fields, the global scope, and the [PRIVATE] marker, which signals sensitive data considerations 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?

Two concise sentences deliver the purpose, the response scope, and a privacy signal without fluff. The key 'global' and 'all positions' framing 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 simple optional-parameter read-only tool, the description sufficiently covers purpose, scope, and returned fields despite lacking an output schema. It could be slightly more explicit about how this differs from the position-specific sibling, but that is not a major gap.

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

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

Schema description coverage is 100% for the only parameter, jwt, and the schema already explains it as an optional session token. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool gets global rewards configuration for Earn/Staking, which identifies the resource and scope. It distinguishes itself from the sibling earn_get_position_rewards_config by emphasizing 'global' and 'all positions'.

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

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

It explicitly says to use this to understand reward configuration for all positions, providing a clear intended context. It does not explicitly mention the position-specific sibling as an alternative, but the global versus position scope is strongly implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds useful return-content context such as breakdown by symbol and overall performance, but doesn't describe pagination, auth nuances, or other behavioral traits. 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 three short sentences with no fluff. The main purpose is front-loaded, and the usage guidance is actionable and efficient.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description adequately states the resource, scope, and return content. It could mention an explicit response structure or auth caveats, but given the simplicity and annotation coverage, it 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?

Schema description coverage is 100% for the only parameter, jwt, so the schema already documents it fully. The description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description uses a specific verb ('View') and resource ('summary of accumulated rewards in Staking/Earn') and clearly specifies what it returns: total rewards, breakdown by symbol, and overall performance. It also indicates scope across all Earn positions, which helps distinguish from position-level tools, though it does not explicitly name 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?

Provides clear usage context with 'Use this to see your total staking rewards,' which tells an agent when to choose this tool. It does not explicitly mention exclusions or alternatives, but the 'across all Earn positions' phrasing implies separation from position-specific 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 annotations (destructiveHint=true, idempotentHint=false), the description discloses key behavioral details: funds stop earning rewards after withdrawal, the first call without confirm=true returns a preview, and the operation status ENUM is defined. It also flags the [PRIVATE] nature of the confirmation requirement, giving the agent an accurate model of the tool's 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?

The description is appropriately sized and front-loaded with the core purpose. Every sentence adds value: destination, reward consequence, return details, balance-check prerequisite, status enum, and preview/confirm behavior. It is slightly dense but well-organized, earning a strong 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 destructive financial mutation with no output schema, the description covers the essential context: what the operation does, the consequences, how to check balance, the operation statuses, and the preview/confirm safety flow. It does not fully specify the return payload structure beyond 'operation details with type: withdrawal,' but that is adequate for an agent to invoke and 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 100%, so the schema already explains all six parameters. The description reinforces the confirm=true behavior and mentions the destination pocket, but it does not add meaningful parameter-level detail beyond what the schema provides. This meets the baseline, but no extra semantic value is added.

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 ('Withdraw'), a precise resource ('Earn (Staking)') and a destination ('Simple Wallet pocket'), making the tool's purpose unmistakable. It also distinguishes itself from related siblings like earn_deposit and pro_withdraw by the Earn-to-Simple-Wallet direction, so an agent can select it confidently.

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: use earn_get_positions to check balance ahead of withdrawing, and the two-step preview-then-confirm calling pattern. It does not explicitly state when not to use the tool or name alternatives, but the clear Earn context and the confirmation flow provide enough practical direction for correct use.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive; the description adds value by detailing the exact return contents and flagging it as [PUBLIC], giving additional context beyond 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?

Two concise, front-loaded sentences with no filler; the first clause states the tool's purpose and the second gives the practical use case. 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 single-parameter introspection tool, the description plus schema and annotations are sufficient for an agent to call it correctly. The absence of an output schema is mitigated by the description naming the return fields (description, inputSchema, exampleArgs, exampleResponse).

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 tool_name parameter is already fully described with an example ('broker_'quote_buy'), so the description doesn't need to add per-parameter detail. It does add context that tool_name refers to another tool in the catalog, but that's marginal.

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 ('returns') and identifies a clear resource ('description, inputSchema, exampleArgs and exampleResponse of any other tool in the catalog'), making it easy to understand and distinguish from sibling domain-specific 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 states the trigger condition: 'Useful when an LLM needs to learn how to call a tool it hasn't seen before.' It does not explicitly list exclusions or name alternatives, but no sibling tool serves an introspection role, so the guidance is sufficient.

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 read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: the endpoint is public, it supports an optional symbol filter, and it returns a specific set of asset fields. 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 two sentences with no filler. It front-loads the action and resource, then gives filter behavior, return payload, and use cases. 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?

For a read-only config tool with only optional parameters, the description covers purpose, return fields, public access, and use cases. Since there is no output schema, listing the returned fields is helpful. It does not mention pagination or response formatting, but that is not strongly required here.

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 all three parameters have clear descriptions, so the baseline is 3. The description reinforces the optional symbol filter but adds no extra meaning for show_exchange or include_testnet beyond what the schema already provides.

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

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

The description names a specific verb and resource: 'Gets asset configuration for Bit2Me.' It also lists the returned fields (symbol, name, type, network, trading status, loan availability, pro_trading_pairs) and states the intended use cases. It does not explicitly differentiate this from sibling config/getter tools, but the resource and output detail make the purpose clear.

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

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

The description provides clear usage guidance: 'Use to discover symbols or verify if an asset is tradeable/loanable.' This tells an agent when to invoke the tool. It does not mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful context beyond that: the tool reports local process health and does not make external calls to Bit2Me, which is valuable behavioral information for an agent deciding whether this tool could be affected by external systems.

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 two short sentences with no filler. The primary purpose and return categories are front-loaded, and the clarifying 'does not call Bit2Me' is placed at the end where it supplements, not obscures, the main message.

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

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

For a zero-parameter, read-only health tool, the description is complete: it lists the key outputs and explicitly notes the tool's local-only scope. No output schema exists, but the summary of fields is enough for an agent to understand what to expect.

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

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

The tool has zero parameters, so the baseline is 4. The description offers a compact overview of the returned health categories, which is sufficient for a parameterless health-check 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 clearly identifies the resource ('local process health of this MCP server') and the specific contents (status, version, uptime, circuit-breaker/cache/rate-limiter stats). It also explicitly differentiates itself from exchange-data tools by stating it does not call Bit2Me.

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 that this tool is for server-local operational information, not external market or account data. It provides a when-to-use signal ('local process health') and an exclusion ('Does not call Bit2Me'), though it does not name specific sibling alternatives.

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

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

Annotations already declare destructiveHint=true, so the write/mutation nature is known. The description goes further by disclosing the two-step confirmation flow, the preview-before-execute behavior, and the rationale for amount_type (preventing mathematical mistakes). This is exactly the kind of behavioral context that annotations cannot express.

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

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

The description is dense but every sentence earns its place: purpose, calculation modes, rationale, return mention, and the two-step confirm protocol. It is front-loaded with the core action and finishes with the privacy/confirmation caveat. No filler or repetition.

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

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

For a 9-parameter mutation tool with no output schema, this description covers the critical operational context: what the tool does, how amount_type changes behavior, the preview/confirm flow, and authentication notes via schema. The idempotency_key, user_symbol, and jwt details are already fully documented in the schema, so the description doesn't need to repeat them. An agent has enough to invoke this correctly and safely.

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

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

Schema coverage is 100%, so the schema already documents every parameter. The description adds value by explaining amount_type in relation to avoiding LTV calculation errors, and by noting the required-conditional relationship (loan_amount vs guarantee_amount). It does not restate every schema description, but the schema already carries that load; the description compensates where it matters most.

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

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

The description names a specific verb ('Create') and resource ('loan'), and specifies that cryptocurrency is pledged as collateral to receive loan currency. It also explains the two calculation modes (fixed_collateral vs fixed_loan), making the tool's purpose and scope far clearer than the bare name alone, and distinguishes it from sibling loan tools like loan_get_orders or loan_increase_guarantee.

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 explicitly instructs when to call once without confirm=true for a preview and when to call again with confirm=true after user agreement. It also says to use amount_type to avoid manual LTV guessing, which doubles as usage guidance. This is concrete, actionable, and prevents a common error mode.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds useful behavioral detail beyond annotations, such as the two-array return structure and the meaning of each currency type. [PUBLIC] also signals no authentication requirement.

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

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

Three sentences are each purposeful: the first defines the operation, the second details the return structure, and the third gives usage context. Information is front-loaded 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?

Given there is no output schema, the description thoroughly explains what the agent will receive and how to interpret it. It also tells the agent when in the workflow to call it, making the description complete for a zero-parameter read-only config tool.

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

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

The tool has zero parameters and 100% schema coverage, so parameter semantics are not a burden on the description. The description compensates well by explaining the output, which is the only semantically relevant content.

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

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

States a specific verb ('Get') and resource ('currency configuration for loans'), then details exactly what is returned: guarantee_currencies and loan_currencies with their associated fields. This clearly distinguishes it from sibling tools like loan_create or loan_get_simulation.

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 to use this tool before creating a loan to understand available options and limits. It does not mention when not to use it or name alternatives, but the context of use 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 already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context beyond that: the shape of the returned movement history, the nested loan/guarantee objects, LTV tracking, and a PRIVATE label that implies access restrictions. It does not go into sorting, pagination behavior, or error cases, but the annotations already cover the safety profile.

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

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

The description is short and front-loaded: it leads with the purpose, specifies the return contents, then gives the filter and use case. 'with full details' is slightly redundant because the next sentence already specifies the details, but there are no unnecessry clauses overall.

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 movement-history tool with no output schema, the description adequately covers what the agent needs to call it: return content, movement types, nested object details, an optional filter, and its use case. It could be more explicit about output shape and ordering, but schema covers limit/offset and the description covers the tool's purpose well enough.

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

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

Schema description coverage is 100%, and each parameter (jwt, limit, offset, order_id) is already documented with sensible descriptions. The description only repeats 'Optional order_id filter' and adds no new parameter semantics beyond what the schema provides, so it stays at the baseline.

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

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

The description opens with a clear verb and resource: 'Get loan movement history with full details.' It then enumerates the loan-specific contents (movement types, nested loan/guarantee objects, fiat values, LTV tracking), which clearly distinguishes this from sibling tools like loan_get_orders, earn_get_movements, or wallet_get_movements.

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

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

The description provides a clear usage context with 'Use to track loan lifecycle events' and notes the optional order_id filter. However, it does not explicitly name alternatives or state when not to use this tool versus siblings like loan_get_orders or earn_get_movements.

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

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

Annotations already establish read-only, non-destructive, idempotent behavior. The description adds meaningful context by disclosing what data is returned (LTV, APR, interest, fiat values), the private access flag, and the optional single-order filter. It does not mention pagination details, but the safety profile is already covered by 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?

Three compact sentences with no filler. The core action and resource are stated first, followed by concrete use cases and the optional filter, so the description is easy to scan and 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?

For a read-only list tool with rich annotations and fully documented optional parameters, the description covers what the tool returns and why it should be used. Minor gaps like pagination result shape are inferable from the schema and don't significantly hinder an agent from selecting and invoking the tool.

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

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

Schema description coverage is 100%, and each parameter already has clear documentation. The description only restates the order_id filter and does not add new semantic detail beyond the schema, so the baseline score is appropriate.

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

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

The description clearly identifies the resource ('loan orders') and the action ('Get all'), and adds useful distinguishing content (LTV, APR, interest, fiat values). This differentiates it well from sibling tools like loan_get_movements, loan_get_simulation, and loan_get_config.

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 helpful context for when to use the tool: monitoring loan health, tracking payments, and calculating costs. However, it does not explicitly contrast this with sibling tools or state when to prefer e.g. loan_get_movements or loan_get_simulation, so guidance remains 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?

Beyond the readOnly/idempotent annotations, the description explains that the unprovided amount is calculated, that LTV uses a ratio where 1.0=100% and lower is safer, and that APR is returned. It also groups symbols by role (crypto, loan, fiat), which is not 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?

Four short sentences, front-loaded with the action and outputs, each sentence earning its place: purpose, input rule, return semantics, and usage context. 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 five-parameter tool with no output schema, the description covers the key inputs, derived-value behavior, output semantics, and the recommended invocation point. It leaves minor gaps around exact numeric string formatting and behavior when both or neither amount is provided, and the 'Requires' wording is stronger than the schema's zero required params.

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

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

Schema coverage is 100%, so the schema already documents each parameter, but the description adds the OR relationship between guarantee_amount and loan_amount and clarifies that one is derived from the other. This is meaningful beyond the per-field descriptions, though it doesn't add format or unit details for the amount strings.

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 ('Simulate loan LTV and APR'), immediately distinguishing the tool as a pre-flight computation rather than a loan mutation. It names the key output concepts and closes with 'Use before loan_create', separating it from the loan lifecycle siblings.

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

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

It gives an explicit usage cue ('Use before loan_create') and the core input constraint (provide either guarantee_amount or loan_amount). It does not spell out when not to use the tool or compare alternatives, but the downstream reference to loan_create is clear enough 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 adds significant behavioral detail beyond the annotations: it reveals the preview behavior without confirm=true, requires confirm=true only after user agreement, and states that updated loan details are returned. This is especially valuable because destructiveHint=true alone would not tell the agent about the two-phase confirmation requirement.

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 verb, resource, and purpose appear first, followed by the critical confirmation workflow. Every sentence contributes actionable information, with 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?

Despite having no output schema, the description covers the return value, the required precursor call, and the user-consent confirmation flow. Combined with the fully documented input schema and annotations, an agent has everything needed to decide when to call this tool and how to sequence the call safely.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context on top: it explains the source of order_id ('Use loan_get_orders first') and clarifies the role of confirm (preview vs. execution). It does not need to repeat parameter definitions 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 states a specific verb and resource: 'Increase the guarantee (collateral) amount for an existing loan.' This clearly differentiates it from sibling tools like loan_create and loan_payback, and it also specifies the expected outcome: 'Returns updated loan details.'

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 a clear prerequisite and sequencing instruction: 'Use loan_get_orders first to get the order ID' and explains the two-step confirmation flow. It does not explicitly contrast with alternative loan tools, but the usage context is unambiguous enough for an agent to invoke it correctly.

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-idempotent, but the description adds important context: the loan amount is reduced, the guarantee may be released, and the function returns updated loan details. It also explains the preview-then-confirm behavior, which is critical for safe execution. This goes beyond the structured annotations and fully discloses the mutation's 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?

The description is compact and well-structured: it opens with the core action and effects, then immediately provides the prerequisite call, then the private confirmation flow. Every sentence adds useful information, and there is no redundant or filler 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 destructive mutation with no output schema, the description covers the essentials: what the operation does, its side effects, how to get the required order_id, and the confirm protocol. The idempotency_key and jwt are documented in the schema, so nothing critical is missing. An agent has enough information to invoke this tool correctly and safely.

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

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

Schema coverage is 100%, so parameter descriptions already exist. The description adds value by explaining that order_id comes from loan_get_orders and by describing the confirm workflow (first call without confirm=true is a preview, then confirm after user agreement). This supplements the schema without repeating 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 clearly states the action ('Pay back (return) part or all of a loan') and the resource (a loan), and specifies what happens: the loan amount is reduced and the guarantee may be released. It also distinguishes itself from siblings like loan_create and loan_increase_guarantee by describing repayment behavior, and points to loan_get_orders for setup. This is a specific, unambiguous purpose.

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 guidance: use loan_get_orders to retrieve order_id or check current loan details before paying back. It also outlines the confirm/preview workflow. It does not explicitly name alternative tools like loan_create or loan_increase_guarantee, but the context is clear enough for the agent to know when repayment is the appropriate operation.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat those. It adds useful behavioral context: conversion to a configurable fiat symbol with EUR default, return shape (total value, breakdown by asset, individual valuations), dust filtering, and a privacy marker. It does not mention the caching behavior, but the force_refresh 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 two sentences with no filler. It front-loads the core purpose, then gives return format, default currency, and filtering behavior. Every clause contributes actionable 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 read-only aggregation tool with rich annotations and full parameter schema coverage, the description is complete: it states what is aggregated, how values are converted, what is returned, and a key filtering behavior. The lack of an output schema is compensated by the explicit return-shape summary.

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 parameters are already documented in the input schema. The description adds only the default EUR behavior and the fiat conversion semantics, which is useful but does not substantially extend what the schema already provides for jwt, quote_symbol, or force_refresh.

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: 'Calculates the total portfolio value by aggregating all assets across Wallet, Pro Trading, Earn/Staking, and Loans.' This clearly differentiates it from narrower sibling tools like wallet_get_pockets or pro_get_balance, which cover only one asset area.

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 tool's context clear by specifying that it aggregates across all four major asset categories, so an agent can infer it is the tool for total portfolio valuation rather than a sub-account balance. It does not explicitly name alternatives or exclusion cases, but the scope statement provides sufficient routing 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 mark this as destructive and non-read-only. The description adds meaningful behavioral context beyond that: the two-step preview/confirm flow, the count return value, and the warning that all pending orders are affected. 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 main action is front-loaded, and each sentence contributes a distinct piece of information: scope, filtering, return value, caution, and the confirmation flow. Minor redundancy between 'open orders' and 'all pending orders' keeps it from being perfectly concise.

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 operation with no output schema, the description covers the most critical operational details: preview-first confirmation, required user agreement, optional pair filtering, return count, and caution. It does not specify the exact contents of the preview response or explicitly route to pro_cancel_order for single-order cancellation, but the annotations and schema fill most remaining gaps.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the preview behavior of confirm=true, which is not fully captured in the schema, and by reinforcing that the pair filter narrows cancellation to a specific market. It adds little beyond the schema for jwt and idempotency_key, but those were already well documented.

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 open orders in Pro Trading.' It further clarifies the optional pair filter and states the return value (count of cancelled orders), making it clearly distinguishable from the singular pro_cancel_order sibling.

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

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

The description clearly implies the usage context: bulk cancellation of open orders, optionally filtered by pair, with a strong caution warning. However, it does not explicitly say when not to use it or name the alternative for cancelling a single order (pro_cancel_order), so the guidance remains 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?

Beyond what annotations already state (destructiveHint=true, idempotentHint=true, readOnlyHint=false), the description reveals the two-step preview-then-confirm behavior, the open/pending eligibility rule, and the meaning of the order status ENUM. These are non-obvious behavioral traits that annotations alone would not 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 core action is front-loaded and each sentence delivers a distinct piece of information: eligibility, return value, prerequisite tool, status semantics, and the confirm flow. The status ENUM block is slightly verbose but earns its place by defining the vocabulary used in the eligibility rule.

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 no output schema, so 'Returns cancellation status' is the only return-value information an agent receives, leaving the shape of that status unspecified. Otherwise the definition is complete: the destructive nature, the two-step safety flow, prerequisites, and order-eligibility rules are all documented.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds the status ENUM explanation, which tells the agent which order_id values are actually cancellable. It also reinforces the confirm=true workflow from the schema, providing practical execution context beyond the parameter 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 opening sentence 'Cancel a specific PRO order by ID' states a specific verb and resource, and the word 'specific' distinguishes it from the sibling pro_cancel_all_orders. The additional constraint 'Only open/pending orders can be cancelled' further sharpens what the operation does.

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 names the prerequisite sibling: 'Use pro_get_open_orders first to see which orders can be cancelled.' The [PRIVATE] instruction gives a precise condition for when the second call with confirm=true is appropriate, so an agent knows both the correct sequencing and the user-consent gate.

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 annotations: it discloses the preview/confirm two-step mutation flow, clarifies that market orders execute immediately, and documents the order status enum (open/filled/cancelled). The destructiveHint and readOnlyHint annotations are consistent; no contradiction. This is rich, agent-relevant behavioral disclosure.

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 then provides necessary type-specific requirements, status enum, and confirm behavior. It is somewhat longer than strictly necessary and partially repeats schema content, but every sentence contributes useful operational context for a complex mutation tool.

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 order-creation tool with no output schema, the description covers return value, order types and their parameter requirements, execution behavior, status meanings, and the critical confirm/preview workflow. This is sufficient for an agent to invoke the tool correctly without missing major behavioral steps.

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 every parameter. The description adds some cross-parameter semantics by noting price is required for limit/stop-limit and stop_price is required for stop-limit, but this largely mirrors the schema descriptions. It does not compensate with substantially new parameter meaning, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb ('Create') and resource ('Limit/Market/Stop order in PRO Trading'), specifies return value ('Returns order ID'), and distinguishes this creation tool from the sibling status/query tools like pro_get_open_orders and pro_cancel_order. The order type list adds further 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 description provides clear usage context: it explains when each order type is appropriate, mentions the two-phase confirm flow, and explicitly routes status checking to pro_get_open_orders. It does not explicitly state when not to use this tool or name cancellation alternatives, but the guidance is strong enough for an agent to select it correctly.

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

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

Beyond the annotations (destructive, write operation), the description adds significant behavioral detail: the transfer is immediate, the status enum is defined (pending/completed/failed), and the two-call preview/confirm flow is disclosed. This materially reduces surprise for a mutating tool and does not contradict 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?

Each of the four sentences carries distinct, necessary information: purpose, prerequisite, verification, status enum, and confirmation protocol. The main action is front-loaded and there is no filler or redundant restatement of schema fields.

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 deposit tool with no output schema, the description is remarkably complete: it covers the prerequisite check, immediate execution, verification step, the two-call confirmation pattern, and the status enum for interpreting results. An agent has what it needs to select and invoke the tool correctly in the right workflow.

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

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

Schema coverage is 100% and each parameter already has a helpful description, setting the baseline at 3. The description goes further by explaining that the first call without confirm=true returns a preview and that confirm must only be set after user agreement, which adds operational meaning beyond the schema's confirm parameter 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 opens with a specific verb+resource pair: 'Deposit funds from Simple Wallet to Pro Trading account.' This precisely identifies the action and the from→to path, distinguishing it from sibling tools like earn_deposit and pro_withdraw without needing to read 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?

It provides clear workflow context by telling the agent to first check wallet_get_pockets for available funds and to verify with pro_get_balance afterward. However, it does not explicitly state when not to use this tool or name alternatives such as earn_deposit, so it stops short of a full when/when-not explanation.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds value beyond those by flagging [PRIVATE] and by clarifying that returned balances are separated into available and blocked amounts per symbol. 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 compact and front-loaded with the core action. Every sentence adds distinct value: scope, separation from Simple Wallet, transfer mechanism, return semantics, and privacy. There is no filler or redundancy.

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

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

For a simple read-only balance tool with one optional parameter and no output schema, this description is complete. It states what is returned, the account context, the relationship to deposits/withdrawals, and privacy. An agent has enough information to invoke it correctly and 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?

The only parameter, jwt, is fully documented in the input schema with its optional nature and authentication guidance. The description adds no parameter-specific meaning, but with 100% schema coverage, the baseline of 3 is appropriate.

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

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

States a specific verb and resource: 'Gets balances from PRO Trading account.' It also differentiates this tool from Simple Wallet, making its scope unambiguous. The return content ('available and blocked balances per symbol') further clarifies the tool's purpose.

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 clearly scopes usage to the PRO Trading account and explicitly distinguishes it from Simple Wallet. It also explains the necessary transfer path via pro_deposit/pro_withdraw, which helps an agent understand account architecture. It does not explicitly name a sibling tool for Simple Wallet balance reads, so guidance stops short of full alternative routing.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that: default time window of 24 hours, limit max of 1000, public access, and return shape as a list of candles with metadata. 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 front-loaded with the core action and resource, then each sentence adds useful constraints or defaults. It is slightly wordy with phrases like 'timestamp and date' and 'list of candles with metadata' that partially overlap, so it does not reach a 5.

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

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

For a read-only market data tool with no output schema, the description covers the essential invocation details: required inputs, optional params, defaults, max limit, and high-level return type. It lacks explicit ordering or inclusiveness details for time bounds, but is otherwise sufficient.

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?

Input schema coverage is 100%, so parameters are already fully documented. The description reinforces pair/timeframe requirements and adds the Unix epoch milliseconds details and 24-hour default, but does not add meaningfully beyond the schema. 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 states a specific verb ('Gets') and resource ('OHLCV candles for Pro Advanced Trading'), and clearly distinguishes it from sibling market-data tools like pro_get_ticker or pro_get_order_book by focusing on historical candle data. It also enumerates the data fields returned, making the purpose 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 explicitly identifies the intended use case ('Essential for technical analysis and charting') and notes the endpoint is public. It does not name alternatives or state when not to use this tool, but the context is clear enough for an agent to select it appropriately.

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 idempotentHint, and the description adds [PUBLIC] to indicate no auth requirement. It also discloses the returned data scope (precision, amounts, prices, fees, trading status), which is useful 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?

Three tightly packed sentences with no filler. Core function is stated first, followed by direct usage guidance and the [PUBLIC] note.

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

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

For a simple read-only config getter with one optional parameter, the description and annotations cover what it returns, when to call it, and safety. It could be slightly stronger by naming sibling alternatives like pro_get_ticker, but 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?

Schema description coverage is 100%, so the schema documents the single optional 'pair' parameter with an example. The description adds no additional parameter semantics, matching the baseline for full 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?

Description uses specific verb 'Gets' and identifies resource 'full market configuration', enumerating precision, amounts, prices, fees, and trading status. This clearly distinguishes it from price-only ticker or order-book siblings.

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

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

Explicitly instructs to use before placing orders for validation and fee understanding. It does not name alternatives or state when not to use it, but the context is clear enough for an agent to select it.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral context by defining 'open' orders as pending or partially filled and explaining the status ENUM. It also notes the [PRIVATE] nature of the tool, which is useful signal beyond annotations. It does not contradict 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 compact and front-loaded with the primary purpose, followed by optional-parameter behavior and a useful status enum. Every sentence adds relevant information, and there is no redundancy or 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 read-only query tool with three optional parameters and no output schema, the description is sufficiently complete: it states what is returned, how to narrow by pair, and how to request a single order. It leaves minor ambiguity around combining pair and order_id, but the overall context is adequate for an agent to call the tool correctly.

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

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

Schema description coverage is 100%, so the parameter attributes are already fully documented. The description reinforces the semantics of pair and order_id, but adds limited new meaning beyond what the input schema already states. Baseline 3 is appropriate here.

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 and resource: 'View open trading orders in PRO', and adds concrete detail about what counts as open (pending, partially filled). It also distinguishes this tool from siblings like pro_get_trades and pro_get_order_book by focusing on user's active orders rather than trade history or the market order book.

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 on when to use the tool: to view open orders, optionally filtered by pair or order_id. It explains the behavioral branches for the optional parameters, though it does not explicitly mention alternatives or when not to use the tool, which keeps it just 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 declare read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it is marked [UBLIC], returns a single object, and describes the market-depth data returned.

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 is fairly compact. There is slight redundancy between 'current buy and sell orders' and the later restatement as 'bids and asks,' but it remains efficient and readable.

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

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

For a one-parameter public read-only tool, the description covers purpose, required input, output shape, and public access. There is no output schema, so the explicit mention of a single object containing bids/asks helps complete the picture. It could improve by naming alternatives, but this is minor for such a simple tool.

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

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

Schema coverage is 100% and already documents the pair format with examples. The description's mention of requiring a trading pair and showing BTC-SD repeats schema information without adding substantive new semantics, so baseline 3 is appropriate.

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

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

States a specific verb ('Gets') and resource ('rder book (market depth)') and explicitly lists what is returned: bids and asks with prices and amounts. No sibling tool name overlaps this resource, so the purpose is unambiguous.

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

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

Provides clear usage context: 'seful for analyzing market liquidity and determining optimal order prices.' It does not explicitly name sibling alternatives or when-not-to-use, so it misses the top-tier threshold.

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

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

Annotations already cover the basic safety profile (read-only, non-destructive, idempotent), and the description adds beyond that by disclosing the return content: price, amount, fees, and date for each fill. The [PRIVATE] flag also hints at restricted access. It does not cover pagination, but the bar is lower given the strong annotation set.

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

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

Three short sentences plus a privacy marker, with the core function stated first. Each sentence contributes either purpose, expected output, or usage context. There is no redundant phrasing or 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 simple retrieval tool with one required parameter, the description covers what it does, what data it returns, and when it is useful. There is no output schema, so the description's return-field disclosure is valuable. It could mention pagination or behavior for orders with no trades, but those are not essential for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents both parameters adequately. The description reinforces that order_id selects the specific order whose fills are returned, but it does not add significant new parameter-level meaning. A baseline of 3 is appropriate when the schema carries the descriptive weight.

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 a specific action ('Gets all individual trades') and a specific resource ('associated with a specific order'). It distinguishes this tool from broad trade-listing calls like pro_get_trades by emphasizing order-level execution data. The mention of 'executions' and 'fills' further disambiguates its purpose.

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

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

It provides a clear use case: analyzing how a large order was executed across multiple trades. It also implies this is the order-specific variant among trade-related tools, though it does not explicitly name sibling alternatives or state when not to use it. The context is clear enough for an agent to select it appropriately.

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, destructiveHint=false, and idempotenceHint=true, lowering the disclosure burden. The description adds useful behavioral detail: it returns a list of recent transactions with price, amount, side, and date, plus limit/sort behavior. 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 compact and front-loads the main purpose before listing options and return content. There is some redundancy with schema details, such as the limit default and sort order, but no significant filler.

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

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

There is no output schema, so the description compensates by naming the returned fields (price, amount, side, date) and noting that the response is a list. The 'metadata' reference is vague, and sibling differentiation is not explicit, but the invocation-critical information 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?

All three parameters (pair, sort, limit) are already described in the input schema, including format, values, default, and max. The description largely repeats these details without adding new meaning, so it earns the schema-covered baseline of 3.

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

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

The description clearly states what the tool does: 'Gets the latest public trades (executed orders) for a market.' The word 'public' and the [PUBLIC] tag help distinguish it from account-specific trade tools, though it does not explicitly name alternatives like pro_get_trades.

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

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

The description provides a concrete use case ('Useful for seeing recent market activity') and a prerequisite ('Requires trading pair'). However, it does not explicitly state when not to use this tool or name sibling alternatives, so it falls short of full routing guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: the 24-hour lookback window, the public nature of the endpoint, and a summary of the response fields. 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 reasonably compact and front-loaded, but it contains redundancy: the returned fields are listed twice ('OHLCV, current best bid and ask, percentage...' vs 'open, close, bid, ask, high, low...'), and the pair filtering is stated twice. It is not concise enough for a 5, but not bloated enough for a 2.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description covers the essential behavior: what data is returned, the time window, and how to filter by pair. The phrase 'from the date indicated' is slightly ambiguous, but it does not prevent correct use.

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?

Input schema coverage is 100%, with the 'pair' parameter fully described. The description mostly restates this ('by requested market symbol', 'Optional pair filter'), adding little beyond the schema. 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 names a specific verb and resource: 'Get ticker information', and enumerates the data returned (OHLCV, best bid/ask, 24h percentage change), which clearly distinguishes it from sibling tools like order book, candles, and public trades. It also states the scope: all markets or a specific pair.

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

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

The description gives clear context for when to call the tool: for all markets or filtered by an optional pair, with data covering the last 24 hours. It does not explicitly mention alternative tools or exclusions, but the 'ticker information' framing makes the intended use clear relative to market-data siblings.

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

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

The annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds meaningful context by noting the response is a paginated list with metadata, enumerating the returned trade fields, and tagging the data as [PRIVATE]. These details go beyond the structural hints and help an agent understand what to expect.

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 customer-facing summary of behavior, followed by a compact filter list, a use case, and a response note. Every sentence adds useful information; there is no filler or redundancy.

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

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

Given the tool has nine optional parameters but a fully descriptive schema, and no output schema, the description appropriately covers what the tool returns and that it is paginated. The [PRIVATE] tag plus the read-only annotations provide enough safety and authorization context for an AI 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?

Schema description coverage is 100%, so the input schema carries the semantic weight for all nine parameters. The description merely summarizes filters such as pair, side, date range, limit, offset, and sort order, without adding new meaning beyond the schema. This meets the baseline but does not exceed 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 verb and resource: 'Gets the user's trade history in Pro Trading.' It clarifies that it returns executed trades with concrete fields, distinguishing it from pro_get_open_orders and pro_get_public_trades. The account-scoped 'user's trade history' also parses it apart from order-level or public trade 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 clear context in 'Use this to review past trading activity,' which tells an agent when to select this tool. It does not explicitly name alternative tools or exclusions, but the purpose statement and response details are enough to guide selection among the sibling trade-related 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 indicate a destructive, non-read-only operation. The description adds substantial behavioral detail: immediate execution, two-phase confirm/preview flow, transfer status ENUM, and required verification steps. This goes well beyond the structured annotation data.

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

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

The description is dense but every sentence earns its place: direction of funds, prerequisite check, immediacy, verification step, status semantics, and the required confirmation sequence. It is front-loaded with the core action and contains 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 preconditions, execution flow, confirmation behavior, verification, and status outcomes. Even without an output schema, the status ENUM provides necessary response context. The remaining parameter details are already fully documented 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?

Since schema coverage is 100%, a baseline of 3 applies. The description adds meaning to confirm by explaining that omitting true returns a preview and that true should only be set after user consent, and it clarifies the source/destination context for amount, symbol, and to_pocket_id.

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

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

The description clearly states the primary action and direction: withdrawing funds from Pro Trading back to Simple Wallet. This distinguishes it from related transfer tools like pro_deposit or earn_withdraw even without explicitly naming 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 gives concrete operational context: check pro_get_balance for availability, use wallet_get_pockets to verify, and call without confirm=true first. It does not explicitly exclude sibling tools or state when not to use this tool, but the workflow guidance is strong and 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 declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is fully covered. The description adds useful behavior: it lists returned card fields, supports a card_id filter, and supports limit/offset pagination. However, it does not address authentication expectations, rate limits, or why [PRIVATE] is flagged, which would add further 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?

Three concise sentences each carry distinct information: what the tool lists, what fields are returned, and how to filter/paginate. The [PRIVATE] marker adds a compact sensitivity cue without extra fluff. No wasted words.

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

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

For a read-only list tool with no required parameters and no output schema, the description is largely complete: it states the resource, return fields, optional filtering, and pagination. It could improve by explicitly saying that omitting card_id returns all cards (though the schema says this) and by elaborating on the [PRIVATE] implication, but nothing essential is missing for an agent to call it successfully.

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 input schema already fully documents jwt, limit, offset, and card_id. The description restates the card_id filter and pagination behavior but adds no new semantic detail beyond what the schema provides, matching the baseline for high 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?

Description opens with a specific verb and resource: 'List credit/debit cards registered in Bit2Me,' making the tool's purpose immediately clear. It enumerates returned fields (card ID, brand, last 4 digits, expiration, alias) and distinguishes the card-list operation from sibling wallet tools by focusing on cards rather than pockets, networks, or movements.

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 for when to use the tool—when listing or retrieving registered Bit2Me cards—and explains optional filtering and pagination. It does not explicitly name sibling alternatives or state when not to use this tool, but the domain-specific wording makes usage obvious enough.

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. The description adds value by disclosing the return fields, the status enum values, and the [PRIVATE] flag, which helps the agent understand the response shape and sensitivity 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 compact, front-loaded with the core purpose, and each sentence covers a distinct aspect: scope, filters, return fields, status enum, and privacy. No filler or redundant 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?

For a read-only list/history tool with fully described parameters and strong annotations, the description provides sufficient context: return fields, status values, pagination, and privacy. Some operational details like ordering or behavior for unknown movement_id are omitted, but these are minor given the tool's simplicity.

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. The description restates filter and pagination behavior but does not add meaningful parameter semantics beyond what the schema provides.

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

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

The description identifies the resource as wallet operations history and specifies the return payload fields (type, amount, symbol, status, date). It is clear enough to understand the tool's function, but it does not explicitly distinguish itself from sibling movement-history tools like earn_get_movements or loan_get_movements.

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 guidance on when to use movement_id, symbol, and limit/offset, and the schema confirms all parameters are optional. However, it does not state exclusions or explicitly compare against alternative tools, so the guidance is context-rich but not fully differentiated.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is established. The description adds useful behavioral context by specifying exactly what fields are returned and framing the tool around deposit network support, which goes beyond the schema.

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

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

Three sentences, with the core action front-loaded, followed by a use-before pointer and a compact list of return fields. There is no redundant wording or 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 read-only, two-parameter tool with no output schema, the description provides sufficient context: what the tool does, when to use it, what the returned data contains, and how the symbol parameter relates to the result. Nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so both symbol and jwt are already documented. The description adds mild context by giving currency examples (bitcoin, ethereum, binanceSmartChain) and implying symbol maps to a currency, but it does not substantially enhance parameter meaning beyond the schema.

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

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

The description uses a specific verb and resource: 'Lists available networks for a specific currency.' It clearly identifies what the tool returns (network ID, name, native currency, fee currency, tag/memo requirement) and differentiates it from wallet_get_pocket_addresses by noting it should be used first.

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

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

It provides explicit usage context: use before wallet_get_pocket_addresses to see which networks support deposits. It does not explicitly state when not to use the tool or compare it to other network-related tools, but the sequencing guidance and deposit-focused purpose are clear enough for an agent.

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

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

Annotations already provide readOnly, idempotent, and non-destructive hints, so the safety profile is covered. The description adds valuable behavioral context by stating the exact return fields (address, network, creation date) and the network-dependent nature of addresses. The [PRIVATE] marker also signals sensitive data, which is 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?

Five short sentences each deliver distinct value: purpose, prerequisite, nuance, return fields, and intended use. There is no filler or repetition, and the most important action is front-loaded. The [PRIVATE] tag is appended 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 a simple read-only tool with full schema coverage, the description covers all essential context: what it lists, what it returns, and how to obtain valid network values. The lack of an output schema is mitigated by explicitly listing return fields. The only minor omission, naming wallet_get_pockets for pocket_id, is already compensated by the 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?

All three parameters are already described in the input schema, meeting the high-coverage baseline. The description adds practical guidance that network values should be discovered via wallet_get_networks first and that addresses are network-specific. This helps an agent select a valid value beyond the raw 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 tool lists deposit addresses for a wallet (Pocket) on a specific network, using a specific verb and resource. It distinguishes itself from sibling tools like wallet_get_pockets and wallet_get_neteworks by focusing on deposit addresses. The return field list reinforces the purpose.

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 explicitly instructs calling wallet_get_neteworks first to see available networks, establishing a clear prerequisite. It also states the intended use case of receiving deposits and notes that networks may have different addresses, helping an agent understand when to use this tool. It does not explicitly mention wallet_get_pockets as a source for pocket_id, though the schema captures that.

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 readOnlyHint, idempotentHint, and openWorldHint annotations: it notes that Pro/Earn balances are excluded and warns that users may have multiple pockets for the same symbol, so the agent must check all pockets. The [PRIVATE] marker also signals sensitive data. 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 purpose and contains valuable admonitions about multiple pockets. It repeats some details already in the schema, such as the pocket_id filtering behavior, which slightly reduces efficiency, but the overall length is justified by the important usage caveats.

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

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

For a simple read-only wallet listing tool, the description covers the return contents, the default behavior, the optional filtering behavior, the exclusion of Pro/Earn balances, and a critical multi-pocket caveat. With annotations already covering safety characteristics, nothing essential is missing for correct invocation.

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

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

The input schema already provides 100% description coverage for jwt, symbol, and pocket_id, including format and behavior. The description mostly repeats the pocket_id filtering behavior and does not add significantly beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: getting balances, UUIDs, and available funds from Simple Wallet pockets. It also explicitly excludes Pro/Earn balances, which distinguishes it from related balance tools in the sibling list.

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

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

The description explains that the tool returns all pockets by default or a single pocket when pocket_id is provided, and it explicitly rules out Pro/Earn balances, helping the agent choose the correct balance tool. It does not name sibling wallet tools as alternatives, but the resource and scope are clear enough.

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