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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and network-call profile is covered. The description adds the useful detail that it validates *configured* credentials rather than performing a market action, but says nothing about failure modes or whether it consumes rate limits.

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

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

A single tight sentence with the purpose front-loaded and no filler. Nothing could be removed without losing meaning.

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?

An output schema exists, so return values need no explanation, and with no parameters there is little else to specify. However, the definition never resolves the full-access vs read-only sibling pair, leaving the agent to guess which status check to call.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

Specific verb (Check) plus a clear resource (configured full-access API credentials) and a stated outcome (working). It is distinguishable from most siblings, though it never explicitly contrasts itself with the very similar check_readonly_status.

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

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

No when-to-use guidance, no prerequisites, and no mention of the alternative tool check_readonly_status, which is the obvious sibling to route between. The agent must infer that this is a credential pre-flight check.

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 openWorldHint=true, so the safety profile is covered structurally. The description adds essentially nothing beyond the name: it does not say whether invalid credentials cause an error or a boolean result, nor what 'working' means (auth success vs. permission scope).

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

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

A single front-loaded sentence with no filler. It is appropriately sized for a zero-argument probe, though the 'read-only/full' phrasing introduces ambiguity rather than trimming it.

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

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

An output schema exists, so return values need not be described. However, given the near-identical sibling check_full_access_status, the description is not complete enough to let an agent choose correctly; the read-only vs. full distinction is left unresolved.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameter-free 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 verb 'Check' and resource 'read-only/full API credentials' are stated, but the phrase conflates two distinct concepts ('read-only' and 'full'), which is exactly the distinction the sibling check_full_access_status exists to make. An agent cannot confidently tell this tool apart from that sibling from the description alone.

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

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

There is no when-to-use guidance, no prerequisites (e.g., credentials must already be configured), and no mention of the obvious alternative check_full_access_status. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no note on whether the list is cached/filtered by region, whether it changes over time, or any scope limits, so it does not earn credit for added 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?

A single short sentence with the purpose front-loaded and zero filler. Nothing can be trimmed without losing meaning.

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

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

With no parameters and an output schema present, the definition does not need to explain return values, so the core contract is covered. It is still thin on how this list relates to quote_buy_now and the sell-side counterpart, which is the main contextual gap.

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

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

The tool takes zero parameters, so the description has no parameter semantics to explain; the baseline for a no-param tool applies.

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

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

States a clear verb+resource (list coins) scoped to the Buy Now flow, which implicitly separates it from the 'sell now' siblings. It does not, however, explicitly name get_sell_now_coin_list or quote_buy_now, so the differentiation is left to inference.

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

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

No when-to-use guidance, no prerequisites, and no pointer to adjacent tools such as quote_buy_now (which an agent likely needs next). The agent must infer the workflow entirely from the sibling names.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered without help. The description adds nothing beyond 'latest'—no data source, staleness, refresh cadence, or rate-limit context—leaving the behavioral picture thin for a live-market lookup.

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

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

Purpose is front-loaded in the first sentence, followed by a compact Args block. No filler; each line serves the parameter documentation.

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?

An output schema exists, so return values need not be described, and the two parameters are documented. The main gap is routing: with four closely related price siblings, the definition never says how this differs or when to prefer it.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does provide example values ('BTC', 'USDT') and marks markettype optional. That is a modest but real addition over the bare schema, though format constraints or fallback behavior for an omitted markettype are not explained.

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

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

States a specific verb and resource ('Get the latest buy price for a coin'), which is enough to distinguish it from get_sell_price. However, it does not differentiate itself from the very similar siblings get_latest_coin_price or get_latest_prices, leaving the agent to guess which price endpoint to pick.

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

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

There is no when-to-use guidance, no mention of alternatives, and no exclusions. With siblings like get_latest_coin_price and get_latest_prices, the agent gets no signal on which tool is appropriate for a given request.

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 openWorldHint=true, so the safety profile is covered. The description adds the useful detail that multiple networks and addresses may be returned, but says nothing about authentication requirements or how the network list is selected per coin. Reasonable but not rich.

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

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

One front-loaded sentence stating purpose, followed by a short Args block. Nothing is wasted; the Args repetition of the parameter is slightly redundant but clarifies the ticker format.

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 an output schema present, return values need not be described, and the read-only/open-world annotations cover behavior. For a single-parameter lookup tool, the description supplies the purpose and the parameter format, leaving only minor gaps such as auth context.

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

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

Schema coverage is 0% and the single parameter is undocumented in the schema, so the description carries the burden. It does so adequately: 'cointype: Coin ticker such as BTC' names the expected format and gives a concrete example, which is meaningfully more than the schema offers.

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

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

States a specific verb and resource: 'Get deposit networks and addresses for a coin.' It is clearly distinguishable from price/order/balance siblings, which cover different resources. It stops short of noting it is per-coin scoping vs. account-wide deposit history (get_my_deposits), so it is clear but not maximally differentiated.

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

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

There is no statement of when to use this tool, no prerequisites, and no mention of related siblings like get_my_deposits or get_my_balances. The agent must infer that this retrieves the address to send funds to rather than a deposit history.

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 openWorldHint=true, so the safety profile is covered. The description adds useful scoping context ('public', 'completed', 'recent') but never defines the recency window, result limits, or pagination.

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

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

One-sentence purpose followed by a compact Args block; nothing is wasted. The leading sentence is well 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?

An output schema exists, so return values need no explanation, and both parameters are named. What is missing is usage context and any bound on 'recent', leaving an agent unable to judge result scope.

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

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

Schema description coverage is 0%, so the description carries the burden. It documents both parameters with ticker examples ('BTC', 'USDT') and flags markettype as optional, but adds no format constraints or validation rules beyond the examples.

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 recent completed public buy/sell orders for a coin market'), which is clearly distinct from get_open_orders and get_latest_coin_price. It does not, however, explicitly name its closest sibling get_completed_orders_summary to explain the difference.

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

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

No guidance on when to use this tool versus alternatives such as get_completed_orders_summary or get_my_order_history. The word 'recent' is never bounded, so the agent cannot infer scope or exclusions.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the 'recent' and 'public' scope qualifiers, which is useful context, but says nothing about pagination, result limits, or whether 'summary' aggregates by pair — gaps an agent would care about.

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

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

Front-loaded single-sentence purpose followed by a compact Args block. Efficient overall; the Args section largely duplicates schema fields but earns its place with the examples.

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?

An output schema exists, so return values need no explanation. However, with 0% schema coverage and dense sibling overlap, the description leaves the agent without enough to distinguish this tool from get_completed_orders or to understand result limits.

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

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

Schema description coverage is 0%, so the description must carry the load and it does: it defines cointype as a coin ticker (BTC example) and clarifies markettype is optional with a ticker example (USDT). This meaningfully compensates for the undocumented schema, though it omits valid-value format constraints.

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

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

Specific verb ('List') plus resource ('recent completed public orders') and it signals a distinct output shape ('combined summary'), which distinguishes it from the raw-order sibling get_completed_orders. It stops short of explicitly naming that sibling, so the differentiation is implied rather than stated.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative despite many overlapping siblings (get_completed_orders, get_my_order_history, get_readonly_market_completed_orders). The agent must infer that 'public' means not-my-orders on its own.

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 openWorldHint=true, so the safety profile is covered. The description adds one useful behavioral detail — the default market is AUD when markettype is omitted — but says nothing about data freshness, source, or rate behavior for a live-price tool.

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

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

Front-loaded purpose sentence followed by a compact Args block; every line earns its place. The docstring-style Args formatting is slightly redundant with the schema but not wasteful.

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

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

An output schema exists, so return values need no explanation, and annotations cover safety. The gap is routing: with many sibling price tools, the description omits the differentiation an agent needs to pick this one correctly. Note the description states markettype defaults to AUD while the schema declares a null default.

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 0%, so the description must carry the burden, and it does document both parameters: cointype with ticker examples (BTC, ETH, DOGE) and markettype as optional with a default. It stops short of format constraints or accepted value lists, but the semantics are largely conveyed.

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

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

States a specific verb and resource ('Get latest prices for a coin') with an optional market qualifier, so the core action is clear. However, it never distinguishes itself from the close sibling 'get_latest_prices' (plural) or the buy/sell price tools, leaving ambiguity about which is appropriate.

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

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

No guidance on when to use this tool versus get_latest_prices, get_buy_price, or get_sell_price. The reader must infer usage from the name alone; no conditions or exclusions are given.

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 openWorldHint=true, so the safety profile is covered. The description adds only the returned field set (buy/ask/last), which duplicates the output schema, and says nothing about rate limits, market count, or freshness/staleness of the prices. With annotations carrying the safety burden, a 3 is appropriate.

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

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

A single front-loaded sentence with no filler. The scope qualifier ('all CoinSpot markets') is placed where it matters most for disambiguation, and nothing is repeated from the schema or annotations.

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

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

For a no-parameter read tool with an output schema present, the description covers the essential purpose; return values need not be explained. It could still note breadth (e.g. how many markets / pagination) or freshness, which are the only realistically useful additions.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify, and it correctly introduces none.

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 (latest buy/ask/last prices) with an explicit scope: all CoinSpot markets. The 'all markets' scope implicitly separates it from the singular sibling get_latest_coin_price, but the description never names that alternative, so differentiation is inferential rather than 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?

Usage is only implied by the scope phrase 'for all CoinSpot markets' – an agent can infer this is the bulk version versus get_latest_coin_price, get_buy_price, or get_sell_price. There is no explicit when-to-use or when-not-to-use statement and no alternative is named.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the 'completed' scope, which usefully excludes pending payments, but says nothing further about filtering, timing, or account requirements.

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

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

A single front-loaded sentence with the verb and scope first and zero filler. Appropriately sized for a no-argument list 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?

An output schema exists, so return values need no explanation, and the empty input schema needs none either. What is missing is the one thing only the description can supply: how this differs from get_my_referral_payments, making the definition merely adequate.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify. Baseline 4 applies; the 'completed' qualifier is the only implicit filter and it is stated.

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

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

Names a specific verb (List) and resource (affiliate payments) plus a scope qualifier (completed), so the operation is unambiguous. However, it does nothing to distinguish itself from the near-identical sibling get_my_referral_payments, leaving 'affiliate' vs 'referral' payments undefined.

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

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

There is no statement of when to call this tool, when not to, or which sibling to prefer. The presence of get_my_referral_payments makes that omission especially costly, since an agent has no basis for choosing between them.

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

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

readOnlyHint=true already declares the safe-read profile, so the bar is lower. The description adds useful context by clarifying that 'available' returns the unlocked balance, hinting at a locked/unlocked distinction. It does not mention auth requirements, and output is covered by an existing output schema.

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

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

Front-loaded purpose sentence followed by tight per-parameter notes. No filler; every sentence carries information, though the 'Args:' block format is slightly verbose for two simple 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?

A simple read tool with annotations covering safety and an output schema covering return values; the description fills the remaining gap by documenting both parameters. It is nearly complete, missing only explicit routing against the sibling get_my_balances.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so for both parameters: cointype is explained with ticker examples (BTC, AUD) and available is explained as returning the unlocked balance. This meaningfully compensates for the empty schema.

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

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

States a specific verb+resource ('Get balance details') and scopes it to 'a single coin', which implicitly separates it from the plural sibling get_my_balances. However, it never names that sibling, so the agent must infer the distinction from the singular/plural naming.

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

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

The phrase 'for a single coin' implies when this is appropriate versus a multi-coin variant, but there is no explicit when-to-use, when-not, or named alternative. Usage is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and open-world behavior are covered structurally. The description adds only that values are converted to AUD with a rate, which is mild extra context; it says nothing about authentication requirements or what an empty account returns. Adequate but thin against the annotation baseline.

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

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

A single ten-word sentence that front-loads the verb and resource and wastes nothing. There is no filler, preamble, 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?

With zero parameters, an output schema covering return values, and annotations covering the safety profile, the description has little left to carry. The one real gap is sibling disambiguation against get_my_balance, which the description omits.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the fact that no filtering arguments exist. Baseline 4 applies for a parameterless call.

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

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

States a specific verb+resource ('List all coin balances') plus the scope of returned data ('AUD value and rate'). However, it never differentiates itself from the near-identical sibling get_my_balance, leaving the agent to guess whether the singular tool is a subset, alias, or per-coin variant.

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

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

No when-to-use guidance and no mention of alternatives, despite the sibling list containing get_my_balance and many other balance-adjacent tools (get_my_deposits, get_my_open_market_orders). Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds the UTC semantics of the date inputs, which is useful operational context, but says nothing about pagination, result size, ordering, or auth requirements beyond what annotations give. Adequate given the lower bar set by 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?

It is brief and front-loaded with the core purpose in the first line, followed by the Args block. The Args formatting is slightly boilerplate-ish but every line carries real information. No filler sentences.

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

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

An output schema exists, so return values need not be explained. However, for a history-listing tool with two optional filters, the absence of any note about result limits, pagination, or default date range leaves a gap an agent would need to resolve before calling 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 0%, so the description must carry the parameter burden, and it does: both startdate and enddate are explained as optional UTC dates in YYYY-MM-DD or UNIX epoch format, matching the string-typed schema. This meaningfully compensates for the empty schema descriptions, though it does not explain date-boundary inclusivity.

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: 'List your AUD deposit history.' An agent can distinguish this from siblings like get_my_withdrawals or get_my_send_receive_history because the resource (AUD deposits) is named. It does not explicitly contrast itself with any sibling, which keeps it short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative. The optional date range is documented as a parameter but the description never says when to supply it or what happens if it is omitted. Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds operational context (default 200 records, hard cap of 500) but says nothing about pagination, ordering, or how far back history goes.

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

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

One lead sentence followed by a tidy Args block; nothing is redundant. The prose form of the arg list is slightly verbose compared to schema-level docs but remains 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?

An output schema exists, so return values need no explanation, and all parameters are described. The remaining gap is the lack of auth/permission context and any pointer to sibling tools that return similar data.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it documents all five parameters including accepted date formats ('YYYY-MM-DD or UNIX epoch') and the limit default/max. It does not state valid values for cointype or markettype, leaving two filters loosely specified.

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

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

The first line gives a specific verb and resource ('List your completed market order history'), which clearly separates it from siblings like get_my_order_history or get_my_open_market_orders. It stops short of explicitly naming when to prefer it over the general history tool, so it is clear but not fully differentiated.

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

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

There is no guidance on when to use this tool versus get_my_order_history, get_completed_orders, or get_readonly_market_completed_orders, all of which sit in the sibling list. The agent must infer the distinction from names alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful scoping detail that results span limit and stop orders, but says nothing about authorization requirements, pagination, or whether the list can be empty.

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

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

Front-loaded with the purpose in one line and a compact Args block; every sentence earns its place. The 'Args:' scaffolding is marginally noisy but harmless.

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?

An output schema exists, so return values need not be described. For a simple read-only listing tool this is close to sufficient, but the definition omits any hint about result scope (open only), ordering, or auth prerequisites that would round it out.

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 0%, so the description must carry the parameter burden. It does name the single parameter and explain it as an optional coin ticker filter, which is adequate meaning for a one-parameter tool, though it gives no format examples or wildcard behavior.

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

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

States a specific verb and resource ('List your open limit/stop orders') and implicitly scopes to limit/stop order types, which distinguishes it from the market-order sibling get_my_open_market_orders. It does not explicitly name any sibling, but the resource 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?

There is no when-to-use guidance. With siblings like get_open_orders, get_my_open_market_orders, get_readonly_market_open_orders, and get_my_order_history, the agent gets no signal about which to prefer or when this one applies.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that these are the user's own orders, but does not disclose pagination, sorting, or what constitutes an 'open market order' vs limit order. It meets the lower bar set by annotations without adding much.

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

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

The description is short and front-loads the purpose, but it includes a Python-style Args block that duplicates schema structure rather than adding value. The content earns its place, but the formatting is tooling-specific and slightly awkward for an LLM consumer.

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?

An output schema exists, so the description needn't explain return values. For a 2-param, read-only list tool, the essentials are present, but the lack of usage guidance relative to multiple sibling tools leaves an agent less able to choose 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 0%, so the description must compensate. It documents both parameters and specifies that markettype accepts values like AUD or USDT, which is useful. However, it doesn't clarify formats, valid ranges, or what happens if both filters are applied.

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 your open market orders.' The scope is clear (current user, open, market type specifically). However, it doesn't distinguish itself from close siblings like get_open_orders or get_my_open_limit_orders, leaving the agent to infer the distinction from the name alone.

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

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

No when-to-use or when-not-to-use guidance. The presence of several sibling tools (get_open_orders, get_my_open_limit_orders, get_readonly_market_open_orders) makes differentiation critical, but the description offers no routing help.

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 openWorldHint=true, so the safety profile is covered. The description adds useful defaults (limit default 200, max 500) but says nothing about sort order, pagination behavior, or what 'completed' excludes. With annotations carrying the safety burden, a 3 is appropriate.

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

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

The core purpose is front-loaded in one sentence and the argument list is tightly formatted with no filler. Minor redundancy in restating that optional params are optional, but nothing wasteful.

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

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

An output schema exists so return values need no explanation, and the params are reasonably covered. However, ordering of results, pagination semantics, and the boundary between this tool and its many order-history siblings remain unaddressed.

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

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

Schema description coverage is 0%, so the description has to carry the parameter burden and largely does: it gives date formats (YYYY-MM-DD or UNIX epoch, UTC), identifies cointype/markettype as ticker filters, and states the limit default and cap. This is materially more than the bare schema types provide.

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

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

States a specific verb (List) and resource (completed order history scoped to 'my'). The possessive 'my' implicitly separates it from the market-wide get_completed_orders, but that sibling relationship is never made explicit. Clear but without direct sibling differentiation.

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

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

No when-to-use guidance and no alternatives named, despite a crowded sibling set including get_completed_orders, get_my_market_order_history, and get_my_open_market_orders. The reader must infer from the name alone when this tool applies.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read against live data. The description adds only the 'completed' status filter as extra context and says nothing about pagination, ordering, or rate limits, which is a modest but not empty contribution given the annotation coverage.

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

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

A single front-loaded sentence with no filler or redundant restatement of the name. Every word earns its place, and the scope qualifier ('completed') comes before any potential alternative routing.

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?

An output schema exists, so the description need not explain return values, and with zero parameters there is little else required. The main omission is routing guidance relative to the affiliate-payments sibling, which keeps this from being fully complete.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. No parameter meaning is lost by the terse description.

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

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

The description states a specific verb ('List') and resource ('referral payments') with a status qualifier ('completed'). It is clear what the tool returns, but it does not distinguish itself from the closely related sibling get_my_affiliate_payments or explain the difference between referral and affiliate payments.

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

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

There is no guidance on when to use this tool versus alternatives such as get_my_affiliate_payments, nor any prerequisite or exclusion information. The only usage signal is the implicit 'completed' filter baked into the purpose statement.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds nothing beyond that: no time-range defaults, no pagination or result-limit behavior, and no statement of what counts as a 'send' versus a 'receive'. It essentially restates the tool name.

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

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

A single front-loaded sentence with no filler. For a zero-parameter list tool this is appropriately sized, and nothing is buried.

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?

An output schema exists, so return shape need not be described, and the operation is simple. What remains unaddressed is scope: whether the history is paginated, time-bounded, or returns everything, which an agent would want to know before calling.

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

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

The tool takes zero parameters, and schema description coverage is 100%, so there are no parameter semantics to clarify. The baseline for a no-param tool 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 ('List') and resource ('your coin send and receive transaction history'), so the agent knows this is a read over the caller's own transfer history. However, with heavily overlapping siblings such as get_my_deposits and get_my_withdrawals, it never clarifies how 'send and receive' differs from deposits/withdrawals, leaving boundary 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?

There is no when-to-use guidance, no exclusions, and no named alternative. An agent choosing between this and get_my_deposits or get_my_withdrawals gets no routing help 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=true and openWorldHint=true, so the safety profile is covered. The description adds useful scoping context ('your' AUD withdrawals, UTC date filtering) but says nothing about pagination, result limits, or authentication requirements beyond what annotations imply.

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

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

Front-loaded purpose sentence followed by tightly scoped parameter notes; no filler. The raw 'Args:' block is functional if slightly unpolished.

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?

An output schema exists, so return values need no explanation, and both input parameters are documented. The main remaining gap is the absence of any routing guidance among the many sibling history tools.

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

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

Schema description coverage is 0%, so the description carries the burden and does so reasonably: both parameters are marked optional and their accepted formats are spelled out (YYYY-MM-DD or UNIX epoch, UTC). This is genuine added value the schema lacks.

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 your AUD withdrawal history'), which cleanly separates it from siblings like get_my_deposits and get_my_send_receive_history. It does not name those siblings directly, but the resource scope is unambiguous.

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

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

No indication of when to use this tool versus alternatives, whether authentication is required, or any preconditions. The agent must infer usage purely from the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that these are public (not account-scoped) orders, which is meaningful context, but says nothing about pagination, depth, or rate limits.

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

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

Front-loaded one-line purpose followed by a compact Args block; no filler sentences. Efficient, though the Args list duplicates schema-level naming rather than adding semantics.

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?

An output schema exists, so return values need not be explained. What is missing is routing context among the many order-listing siblings; otherwise the definition is minimally complete for a two-parameter read 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 0%, so the description must compensate, and it does: cointype is described with an example ('BTC') and markettype is flagged optional with an example ('USDT'). This is more than the bare schema provides, though it lacks accepted formats or default behavior.

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

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

States a specific verb and resource ('List public open buy/sell orders for a coin market'), and the word 'public' implicitly distinguishes it from the 'get_my_*' order tools. However, it never names an alternative explicitly, so sibling differentiation is left to inference.

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

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

There is no when-to-use guidance beyond the word 'public'. It does not say whether this returns the order book vs. your own orders, nor point to get_my_open_market_orders / get_my_open_limit_orders as the personal-order alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the 'authenticated read-only API' phrasing is consistent with them. The description usefully adds the pagination default (200) and cap (500), but does not disclose auth prerequisites or any rate-limit behavior. With annotations covering the safety profile, a 3 is appropriate.

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

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

Front-loaded one-line summary followed by a compact, well-labeled Args block. Every line earns its place by documenting an otherwise undescribed parameter. The docstring formatting is slightly verbose but not wasteful.

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

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

With an output schema present, return values need not be explained, and the annotations cover the safety profile. The description fills the 0% schema-coverage gap for parameters and states scope. Only the missing when-to-use routing keeps it from being fully complete.

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

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

Schema coverage is 0%, so the description must carry all parameter meaning, and it does: it names each of the 5 params with format and examples (cointype 'such as BTC', markettype 'such as AUD or USDT', startdate/enddate as YYYY-MM-DD or UNIX epoch, limit default 200/max 500). This cleanly compensates for the absent schema descriptions.

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

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

States a clear verb (List) and specific resource (completed market orders) with the access mechanism (authenticated read-only API). This distinguishes it implicitly from get_readonly_market_open_orders (open vs completed), but it never explicitly names or contrasts the sibling tools it overlaps with, so differentiation requires inference.

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

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

The description provides no when-to-use guidance or alternatives. It never clarifies when an agent should pick this over get_readonly_market_open_orders, get_my_market_order_history, or get_completed_orders, all of which are adjacent siblings. Only the 'read-only API' framing hints at context.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the call goes through 'the authenticated read-only API,' which usefully signals auth/output scope, but it does not disclose rate limits, pagination, or what the read-only tier excludes.

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

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

The purpose sentence is front-loaded and short, and the docstring-style Args block efficiently documents both parameters without padding. Slightly awkward formatting, but nothing is wasted.

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

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

An output schema exists, so return values need no explanation, and the read-only auth context is mentioned. However, given a crowded sibling set and a 0% schema coverage, the description should say more about how this differs from the other open-order tools.

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

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

Schema description coverage is 0%, so the description carries the burden and does a fair job: it names both parameters and gives concrete examples (BTC for cointype, AUD/USDT for markettype) and marks markettype optional. Only the precise ticker/format rules are left unspecified.

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

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

States a specific verb (List) plus resource (open market orders) and scopes it to the authenticated read-only API. It is clear what the tool returns, but it does not distinguish itself from close siblings like get_open_orders or get_my_open_market_orders, leaving the read-only tier distinction implicit.

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

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

There is no when-to-use guidance and no mention of alternatives, despite several siblings (get_open_orders, get_my_open_market_orders, get_readonly_market_completed_orders) that an agent must choose between. The 'read-only API' phrasing implies a context but never states the condition that selects this tool.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the useful behavioral scope that the list contains only coins eligible for Sell/Swap Now, but it does not disclose anything about freshness, rate limits, or ordering beyond 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?

Single sentence, fully front-loaded, with no wasted words. It states the resource and the scoping condition immediately.

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

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

An output schema exists, so the description need not explain return values. For a zero-parameter read-only list, the description is mostly complete, though it could mention if the list is market-wide or user-specific.

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 schema is empty and there are no parameter semantics to clarify in the description.

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

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

The description gives a specific verb (List), resource (coins), and scope (available for Sell/Swap Now). This distinguishes it from the sibling get_buy_now_coin_list and from quote tools, so an agent can identify the tool without opening the schema.

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

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

Usage is implied: call this to discover which coins can be sold or swapped before using quote_sell_now or quote_swap_now. However, it does not explicitly state when to prefer this over siblings, nor does it include prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety/external-call profile is covered. The description adds only the word 'latest', with no disclosure of price freshness, streaming vs snapshot, or auth requirements, so it contributes little beyond the structured fields.

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

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

Purpose is front-loaded in the first sentence and parameter notes follow in compact Args style. No wasted sentences, though the docstring formatting is a bit verbose for the amount of information conveyed.

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?

An output schema exists, so return values need no explanation, and the read-only nature is covered by annotations. For a simple two-parameter tool it is adequately specified, but the omitted markettype default and price-freshness semantics leave meaningful gaps.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does provide both parameters with useful examples (BTC as cointype, USDT as markettype). It stops short of explaining the default/behavior when the optional markettype is omitted.

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

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

States a specific verb+resource ('Get the latest sell price for a coin'), and 'sell' naturally distinguishes it from the sibling get_buy_price. However it does not differentiate itself from get_latest_coin_price or get_latest_prices, leaving the agent to guess which price tool applies.

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

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

No when-to-use, when-not, or alternative guidance is given, despite a cluster of overlapping price siblings (get_buy_price, get_latest_coin_price, get_latest_prices, quote_sell_now). The agent gets no help choosing among them.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that the description adds nothing behavioral: a quote tool typically has a validity window / expiry and may require authenticated access, neither of which 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?

Front-loaded one-line purpose followed by a tight Args block; nothing is padded. The wording is slightly terse but no sentence is wasted.

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

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

An output schema exists, so return values need not be described. However, for a quote-generation tool the description omits the practically critical facts: whether the quote expires and how long it is valid, and whether authentication is required. With no annotations covering those, the definition is incomplete for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry the parameters, and it does: it explains cointype (ticker such as BTC), amount, and — importantly — that amounttype is 'coin' or 'aud', an enum the schema does not encode. Minor gap: no note that amounttype defaults to 'coin' or that it only matters for interpreting amount.

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

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

States a specific verb and resource ('Get a Buy Now quote'), which separates it from quote_sell_now and quote_swap_now by name. It does not, however, distinguish itself from the sibling get_buy_price, leaving the agent to guess which one to call for pricing.

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

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

No when-to-use guidance, no prerequisites, and no mention of the alternatives (get_buy_price, quote_sell_now, quote_swap_now) despite a crowded sibling set. Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the schema restated as Args — no note on quote validity windows, rate limits, or that the returned quote is indicative rather than an executed trade.

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

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

Front-loaded with the one-line purpose, followed by a terse Args block. Nothing is padded, though presenting the parameters as 'Args' prose partly duplicates the schema rather than adding new 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?

An output schema exists, so return values need not be described, and the parameter meanings are covered. What remains missing is the operational context — when to call this versus the live price or order tools — which matters for a quote tool sitting among many pricing siblings.

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

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

Schema description coverage is 0% with no enums, so the description carries the full burden and does compensate: it explains cointype as a ticker like BTC, amount as the quantity, and amounttype as 'coin' or 'aud'. This is the only source of meaning for those three fields, and it usefully exposes the two-value semantics that the schema omits.

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

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

States a specific verb+resource: produces a 'Sell Now' quote, which parallels and is distinguishable from the sibling quote_buy_now and quote_swap_now by the resource qualifier. It never explicitly names an alternative, so differentiation relies on the agent inferring the buy/sell/swap split from names.

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

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

There is no when-to-use statement, no mention of prerequisites or account access, and no comparison against get_sell_price or quote_buy_now. The agent must infer that this is the pre-trade pricing step from the word 'quote' alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no extra behavioral context such as rate limits, authentication needs, or error behavior, but it does not contradict the annotations either.

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 four lines, front-loads the purpose, and then lists arguments efficiently. Every part earns its place with no wasted text.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. The parameters are well described. The only notable gap is the lack of sibling differentiation, but for calling the tool correctly the description 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 0%, so the description must carry the full burden. It successfully defines all three parameters, clarifying the swap direction (sell/from, buy/to) and the meaning of amount. It lacks format details such as ticker format or amount precision.

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 a Swap Now quote') and the word 'Swap' distinguishes it from buy/sell quote siblings. However, it does not explicitly name or contrast with the sibling tools, so full sibling differentiation is absent.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. Despite the presence of sibling quote tools, the description offers no routing information.

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