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

No annotations provided, so description carries full burden. While 'Get' implies read-only, the description discloses no information about rate limits, caching behavior, or the structure/format of the returned currency 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?

Single sentence, six words. Front-loaded with no waste, appropriately sized for a zero-parameter utility function.

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 zero parameters and high (trivial) schema coverage, the description is minimally adequate. However, lacking an output schema, it should ideally describe what is returned (e.g., list of currency codes vs. detailed objects); this gap leaves it incomplete.

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

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

Zero parameters present. Per guidelines, baseline score is 4 when no parameters require semantic clarification beyond 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?

Clear verb 'Get' with resource 'currencies' and scope 'all on Derive'. The plural 'all' effectively distinguishes it from sibling tool 'get_currency' (singular), though it doesn't explicitly name that alternative.

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 no guidance on when to use this versus 'get_currency' for specific lookups, nor mentions if result sets are large or require pagination handling.

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?

With no annotations provided, the description carries full disclosure burden but only states the basic read operation. Fails to mention pagination behavior, rate limits, authentication requirements, or what 'available' implies regarding instrument status.

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 of 9 words with action-fronted structure. No redundancy or waste, though brevity comes at the cost of behavioral details.

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

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

Inadequate for a paginated listing tool with 5 parameters and no output schema. Description omits any mention of the paginated return structure, required filtering logic, or how the `expired` parameter affects results.

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?

Maps schema enum values (erc20, option, perp) to domain terminology (ERC20 tokens, options, perps), adding semantic context. However, it omits explanation of the `expired` flag's purpose and pagination strategy despite 100% 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?

States clear verb (Get) and resource (instruments) with specific scope clarification (options, perps, or ERC20 tokens). Distinguishes from singular `get_instrument` by specifying 'all', but lacks explicit cross-reference to guide selection between the two.

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

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

No explicit guidance on when to use this versus siblings like `get_instrument` or `get_all_currencies`. No mention of when to apply the optional currency filter or pagination parameters.

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

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

No annotations are provided, and the description carries the full burden. It omits what constitutes 'details', error behavior for invalid symbols, caching, or rate limiting characteristics.

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?

Extremely concise at six words with no redundancy. However, it is minimally informative rather than efficiently packed with useful 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?

Adequate for a single-parameter read operation, though the lack of output schema means the description should ideally clarify what 'details' are returned. Sibling differentiation is implied but could be explicit.

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

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

Schema coverage is 100% with the 'currency' parameter fully documented including examples (ETH, BTC). The description adds no parameter semantics beyond the schema, which is acceptable given the high coverage 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 uses specific verb 'Get' and resource 'currency', and distinguishes from sibling 'get_all_currencies' by specifying 'specific currency'. However, 'details' is vague regarding what information is returned.

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 provided on when to use this single-currency lookup versus 'get_all_currencies' for bulk operations, or what to do if the currency symbol is unknown.

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?

Zero annotations provided, so description carries full disclosure burden. Fails to mention read-only nature, pagination behavior, rate limiting, or that data is limited to 30 days (constraint buried in schema but not described). Doesn't explain what funding rates represent (periodic payments between long/short positions).

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 7-word sentence with zero redundancy. Front-loaded with action verb. However, extreme brevity leaves it under-specified; conciseness becomes under-conciseness given the tool's complexity and lack of supporting 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?

Financial data tool with 4 parameters including time ranges, yet no output schema provided. Description fails to indicate return format (array of rate objects?), data granularity, or that funding rates are typically 8-hour or 1-hour intervals. Missing crucial context for a derivative/finance API 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 has 100% description coverage (all 4 params documented). Description adds 'perpetual instrument' context for instrument_name but provides no additional semantics for timestamp formats, period granularity selection guidance, or default value behaviors beyond what's in the schema. Baseline 3 appropriate given schema completeness.

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?

Clear verb 'Get' with specific resource 'historical funding rates' and scope 'perpetual instrument'. Distinguishes from generic 'history' tools and correctly identifies the domain (perpetual swaps vs spot/options). However, doesn't explicitly differentiate from sibling get_interest_rate_history despite both being rate histories.

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 siblings like get_spot_feed_history or get_interest_rate_history. No mention of prerequisites (e.g., needing a valid instrument_name from get_instruments) or typical use cases (calculating funding costs over time).

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?

No annotations provided, so description carries full burden. 'Get' implies read-only but doesn't confirm safety, caching behavior, rate limits, or what happens if instrument_name is invalid. Lacks disclosure on returned data structure since no output schema exists.

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

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

Single sentence, 9 words, front-loaded with verb. Efficient and direct. However, given lack of annotations and output schema, the brevity leaves informational gaps rather than demonstrating optimal information density.

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

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

Adequate for a single-parameter lookup tool, but fails to compensate for missing output schema. Doesn't describe what 'details' include (metadata, specs, pricing), nor does it hint at behavior for non-existent instruments. Acceptable minimum but not robust.

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

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

Schema coverage is 100% with clear examples (ETH-PERP, BTC-20260328-50000-C) in the parameter description. Main description adds 'by name' which aligns with parameter intent but doesn't add syntax or format details beyond schema. Baseline 3 appropriate given schema completeness.

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 clear verb (Get) + resource (instrument details) + scope (specific by name). Distinguishes from bulk operations like get_all_instruments via 'specific...by name' phrasing, though it doesn't clarify distinction from get_ticker which also retrieves instrument data.

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

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

No guidance on when to use this versus siblings like get_all_instruments or get_ticker. No mention of prerequisites (e.g., whether instrument must exist) or error scenarios.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to indicate this is a read-only operation, omits pagination behavior details (despite having page/page_size parameters), and does not mention rate limits or data granularity.

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

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

The description is extremely concise at only 4 words. While efficient and front-loaded with the verb, it is arguably under-specified given the lack of annotations and output schema. No wasted words, but misses opportunity to add 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?

Despite having 4 parameters (2 required) with full schema documentation, the description lacks necessary context for a data retrieval tool: no mention of result format, time range limits, or pagination requirements. Without an output schema or annotations, the description should compensate but does not.

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

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

Schema description coverage is 100%, with clear descriptions for all 4 parameters including timestamp units and pagination constraints. The description adds no parameter semantics beyond the schema, which is acceptable given the complete schema coverage, warranting the baseline score.

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

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

The description uses a specific verb ('Get') and resource ('historical borrowing interest rates'), making the purpose clear. It implicitly distinguishes from sibling 'get_funding_rate_history' by specifying 'borrowing' vs 'funding', though it could explicitly clarify this distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'get_funding_rate_history', nor does it mention prerequisites such as valid time ranges or maximum date spans.

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?

With no annotations provided, the description carries the full burden. It mentions 'oracle' indicating data source, but omits critical behavioral details: what 'signed' entails (cryptographic signatures?), data freshness guarantees, verification requirements, or return format.

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 of four words with no redundancy. Front-loaded and efficient, though undersized for the domain complexity rather than unnecessarily verbose.

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

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

For a financial oracle tool with signed data (implying cryptographic complexity), the description is insufficient. No output schema is present, yet the description doesn't hint at return structure, signature format, or validation needs.

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%, documenting both the currency and expiry filters. The description adds no parameter-specific guidance, meeting the baseline for well-documented schemas.

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 it retrieves oracle price feeds with a specific verb and resource, but fails to explain what 'signed' means (present in the tool name) or differentiate from sibling price tools like get_spot_feed_history or get_ticker.

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 no guidance on when to use this tool versus alternatives. Siblings include multiple price-related endpoints (get_ticker, get_spot_feed_history), but no selection criteria or prerequisites are offered.

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?

With no annotations provided, the description carries the full disclosure burden but reveals only that the data is 'historical'. It omits safety confirmation (read-only nature), pagination behavior implications (despite page parameters existing), data volume expectations, or authentication 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?

While the four-word description is extremely concise and front-loaded, it is underspecified rather than appropriately minimal. The brevity sacrifices necessary contextual detail for a data retrieval tool with temporal filtering and pagination.

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?

Complexity includes date ranges and pagination (4 parameters), yet the description provides no output format details, no explanation of pagination strategy, no data retention limits, and no domain context given the absence of both annotations and output schema.

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

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

With 100% schema description coverage, the input schema already documents all four parameters (timestamps, pagination). The description adds no semantic context beyond the schema, but baseline 3 is appropriate given the schema completeness.

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 the basic action (Get) and resource (historical liquidation events), but lacks specificity about what constitutes these events (e.g., forced position closures) and fails to differentiate from sibling history tools like get_funding_rate_history or get_option_settlement_history.

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 no guidance on when to use this versus alternative data sources, no mention of data retention limits, rate limiting, or prerequisites for accessing liquidation 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?

Declares the simulation/non-destructive nature ('Simulate', 'hypothetical'), which is critical behavioral context given no annotations. However, lacks disclosure about what the tool returns (margin totals, risk arrays, liquidation levels), calculation methodology, or any rate/authentication constraints.

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 is front-loaded and wastes no words. However, for a complex financial simulation tool with four parameters (including nested array objects), the extreme brevity makes it underspecified despite being technically 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?

Inadequate for the domain complexity. No output schema exists, yet description gives no indication of return structure (e.g., margin total, maintenance requirements, currency breakdown). With 100% schema coverage handling inputs but zero behavioral annotations, the description fails to compensate for missing output documentation.

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%, establishing baseline 3. Description mentions 'hypothetical portfolio' which loosely maps to the simulated_positions and simulated_collaterals arrays, but adds no specific guidance on parameter formats, valid asset names, or the distinction between Portfolio Margin (PM) and Standard Margin (SM) beyond what the schema enum 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?

States specific action 'Simulate' and resource 'margin requirements' clearly. Mentions 'hypothetical portfolio' which distinguishes from real-margin tools and aligns with 'simulated_' parameters. However, lacks explicit differentiation from sibling data-retrieval tools (e.g., get_instrument) and doesn't specify what margin types (PM/SM) represent beyond the schema.

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

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

Provides no guidance on when to use this simulation tool versus retrieving actual margin data. No mention of prerequisites (e.g., understanding of portfolio margin vs standard margin) or when the simulation is appropriate versus using real position 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?

With no annotations provided, the description carries the full burden of behavioral disclosure but offers almost none. It does not confirm the read-only/safe nature of the operation, describe pagination behavior, time range limitations, or what data fields are returned in the settlement records.

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 four-word description contains no fluff or redundancy, but is arguably underspecified given the lack of annotations and output schema. It is front-loaded (purpose first) but too minimal to fully earn its place as the sole documentation source.

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 zero annotations, no output schema, and three parameters controlling pagination and filtering, the description fails to provide necessary behavioral context. It should explain the settlement domain, pagination limits, and safety profile, but offers only the tool name restated as a sentence.

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

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

Schema description coverage is 100%, with clear descriptions for page, page_size, and subaccount_id. The description adds no additional parameter context, meeting the baseline expectation when the schema does the documentation work. No compensation needed for missing schema docs.

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 the basic verb ('Get') and resource ('historical option settlement data'), but provides minimal specificity about what 'settlement' encompasses (expiries? exercises?) and does not differentiate from sibling history tools like get_funding_rate_history or get_liquidation_history despite the crowded tool namespace.

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 provided on when to use this versus other history endpoints, when pagination is required, or prerequisites like subaccount requirements. The description is purely declarative with no contextual usage hints.

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?

Zero annotations are provided, so the description carries full disclosure burden. It fails to specify the return format (array of objects vs other structure), rate limits, maximum queryable date ranges, or whether the data is real-time vs delayed. The 'Get' verb implies read-only, but specific behavioral constraints are absent.

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 is efficient and front-loaded with the core action. However, it is potentially underspecified for the complexity (4 required parameters, no output schema), verging on minimalism rather than rich conciseness.

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

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

For a 4-parameter data retrieval tool with no output schema and no annotations, the description meets minimum viability but has clear gaps. It omits return value structure, pagination behavior, and the relationship to the candles variant, which are necessary for robust agent operation.

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

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

Schema description coverage is 100%, documenting all four parameters including units (seconds) and currency examples. The description adds no semantic depth beyond the schema, but the high coverage means the baseline score 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 states a clear action ('Get') and resource ('historical spot price data') with scope ('for a currency'). However, it fails to differentiate from the sibling tool `get_spot_feed_history_candles`, leaving ambiguity about whether this returns raw ticks, aggregated data, or how it differs from the OHLC 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 guidance provided on when to use this versus `get_spot_feed_history_candles` or other history tools like `get_funding_rate_history`. No mention of timestamp range limits, pagination requirements, or prerequisites.

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

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

No annotations provided, so description carries full burden. While 'Get' implies read-only, there is no disclosure about pagination behavior, maximum date range limits, rate limiting, or whether data is real-time vs historical. Critical gaps for a financial data API.

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?

Extremely brief at 7 words. No filler content, but arguably under-specified rather than optimally concise given the lack of annotations and output schema. Front-loads the essentials without wasted sentences.

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

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

Mentions 'OHLC' which hints at return structure (compensating somewhat for missing output schema). The complete input schema helps, but for a 4-parameter financial tool with no annotations, the description lacks critical context about data behavior and constraints.

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 has 100% coverage with detailed descriptions (including specific period values like 60, 300, etc.). The description adds no parameter-specific context, but baseline 3 is appropriate since schema does the heavy lifting.

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

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

States specific action ('Get') and resource ('OHLC candlestick data'), and identifies the domain ('spot prices'). However, it fails to distinguish from sibling tool 'get_spot_feed_history' which likely returns non-aggregated data.

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 no guidance on when to use this tool versus the sibling 'get_spot_feed_history' or other historical data tools. No mention of appropriate time ranges or use cases for candlestick vs raw data.

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?

No annotations provided, so description carries full burden. Only behavioral disclosure is 'aggregate' implying summed data. Missing: time range behavior (if end_time omitted), whether data is real-time or cached, rate limits, and return structure.

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, front-loaded with no filler. Slightly weakened by 'etc.' vagueness, but otherwise tight and purposeful.

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?

Adequate for a simple 3-parameter read operation with complete schema documentation, but lacks critical context for an agent selecting between this and similar statistic-fetching siblings (get_ticker, get_tickers). No output schema exists, but that's acceptable for a standard data retrieval tool.

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

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

Schema coverage is 100%, so descriptions are complete in structured fields. The tool description adds semantic context that statistics include 'volume, open interest' (financial metrics) rather than restating parameter names, meeting the baseline expectation when schema is complete.

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 specific verb ('Get') and resource ('aggregate platform statistics') with concrete examples ('volume, open interest'). Could better distinguish from sibling 'get_ticker' which also retrieves statistics, but the 'aggregate' qualifier helps differentiate.

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

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

No guidance on when to use this versus get_ticker or get_tickers, no mention of what happens when optional parameters (currency, end_time) are omitted, and no time-range guidance despite having an end_time parameter.

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?

With no annotations provided, the description carries the full burden. It discloses that data is 'current' (implying real-time/snapshot) and specifies return fields (bid/ask), but omits caching behavior, rate limits, market hours constraints, or error handling for invalid instruments.

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, eight words, front-loaded action verb. Efficient but overly terse given the lack of annotations and output schema; sacrifices necessary behavioral context for brevity.

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?

Adequate for a simple lookup tool but incomplete given the financial domain complexity and absence of output schema. Missing critical distinctions from similar sibling tools and operational details (data freshness, market status requirements).

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 has 100% coverage with a clear example (ETH-PERP), establishing baseline 3. The description adds only 'for an instrument' which is redundant with the parameter name, providing no additional semantic context about instrument identifiers or formats.

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 specific data points retrieved (price, volume, bid/ask) using a clear action verb. However, it fails to differentiate from sibling 'get_tickers' (plural) which likely supports batch retrieval, or 'get_instrument' which may return static metadata.

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 no guidance on when to use this single-instrument lookup versus the 'get_tickers' batch endpoint, or versus 'get_instrument'. No prerequisites or error conditions mentioned.

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

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

No annotations provided, so description carries full behavioral burden. Discloses nothing about read-only safety, rate limits, real-time vs cached data, or what specific data fields a 'ticker' contains beyond the basic retrieval action.

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 9-word sentence is appropriately front-loaded and waste-free. However, extreme brevity is insufficient given zero annotations and conditional parameter logic that requires explanation.

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 100% schema coverage, parameter documentation is complete. However, lacks necessary context about option-specific filtering behavior and sibling differentiation that would prevent selection errors.

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 schema documents all parameters (instrument_type, currency, expiry_date) adequately. Description mentions 'type' (mapping to instrument_type) but adds no semantic detail about currency/expiry_date being option-specific filters. Baseline 3 appropriate given schema carries load.

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 specific action ('Get tickers') and resource scope ('all instruments of a given type'), but fails to distinguish from sibling tool 'get_ticker' (singular) or clarify when bulk retrieval is preferred over single-instrument queries.

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 no guidance on when to use this tool versus 'get_ticker', 'get_all_instruments', or other siblings. Does not mention the conditional requirement that 'currency' is only required for options, despite this being critical usage context.

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