DAMO Market State

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

Annotations already establish this as a safe, idempotent read, and the description adds real behavioral context that goes beyond them: verified candles are recorded and never change, live candles are provisional, and the record carries DAMO's write timestamp. It does not discuss quota or error behavior in depth (though the schema notes did_you_mean on bad symbols), which keeps it just under a 5.

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 triggering condition, then a scope disclaimer, then return-shape details, in three tight sentences with no filler. Each sentence carries distinct information: when to use, what it does not return, and how to interpret the payload.

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 and 100% parameter coverage, the description covers the remaining ambiguity: verified vs live semantics, timestamp meaning, and vector ordering. The main remaining gap is that it does not route the agent to the sibling tools for multi-symbol or definition lookups.

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 a baseline of 3 applies, but the description adds meaning beyond the schema: it explains that as_of is DAMO's write time and that live-layer candles expose candle_close_expected while verified uses states[tf].candle_close. It also clarifies the fixed timeframe ordering of the returned vector, which the schema cannot express.

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: returns the current DAMO market state of one symbol across 10 timeframes, with an explicit scope disclaimer ('state data only: no prices, forecasts or trade signals'). The 'one symbol' phrasing implicitly separates it from the plural sibling get_market_states, but that sibling is never named, so 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?

'Use when the user asks about the current market state (trend or momentum) of a crypto asset on any timeframe from 1 minute to 1 month' gives a clear trigger condition and acceptable timeframe range. No exclusions or named alternatives (e.g. when to prefer get_market_states or get_state_definitions) are provided.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The only real addition is the claim of behavioral equivalence to get_market_state, plus the 50-symbol cap (which repeats maxItems from the schema). Nothing is said about quota consumption per symbol, partial failures across a batch, or whether the whole call fails if one symbol is bad — meaningful gaps for a batch tool whose schema notes a per-timeframe quota.

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

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

Two sentences, front-loaded with the triggering situation and then the equivalence and batch limit. Every clause earns its place and there is no filler.

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

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

Output schema exists and annotations are rich, so return values and safety need no explanation. However, the description defines the tool entirely by reference to get_market_state, forcing the agent to read another definition to understand the response shape, and it omits batch-specific behavior (per-symbol quota cost, mixed valid/invalid symbol handling) that matters at 50 items.

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 80%, so the schema already explains layer, proof, format, symbols (with accepted ticker variants and did_you_mean errors) and timeframes quota accounting. The description adds no parameter-level meaning beyond the 50-symbol limit already encoded as maxItems, so baseline 3 applies.

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

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

States a clear capability: batch retrieval of DAMO market state for several crypto assets, up to 50 per call. It explicitly ties itself to the sibling get_market_state as the multi-symbol form, so an agent can distinguish it from the single-symbol tool. No verb is spelled out, but 'Same as get_market_state ... in one call' makes the resource and operation 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?

'Use when the user asks about several crypto assets at once' gives a clear selection condition, and 'Same as get_market_state for up to 50 symbols' implicitly routes single-symbol requests to the sibling. It stops short of any explicit exclusion or mention of list_symbols/get_state_definitions, so the routing picture is not fully closed.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds that the content is fixed reference material (the 4 permanent states, the layer taxonomy), which tells the agent results are static and not user-specific. It says nothing about size or format of the returned reference, which is the remaining behavioral gap.

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

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

Two sentences, with the usage trigger front-loaded ahead of the content inventory. The second sentence is a fragmentary list rather than a clause, but every element in it (states, codes, order, layers, output scope) maps to something the agent would otherwise have to guess.

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

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

For a zero-parameter reference tool with an output schema present, the description covers the trigger and the scope of returned knowledge, which is enough to select and call it. The only thing an agent might still want — an explicit pointer to the sibling that returns actual state values — is absent.

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 of 4 applies and there is no parameter surface requiring explanation. The description correctly does not invent any input dimensions.

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

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

The description names a specific resource (DAMO's states, codes, timeframe order, verified/live layers) and frames it as a glossary/reference lookup rather than data retrieval. It implicitly separates itself from get_market_state/get_market_states by scoping the answer to 'what DAMO outputs (state data only)', though it never names those siblings as the alternative for actual values.

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

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

The opening clause 'Use when the user asks what DAMO's states, codes or layers mean' is an explicit, actionable trigger condition. It stops short of a when-not statement or naming get_market_state as the path for live state values, so routing for the adjacent case 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?

The annotations already declare read-only, idempotent, non-destructive behavior, so the description does not need to restate safety. It adds useful behavioral context by noting that results include available layers and 'any timeframe not yet available,' which discloses coverage limitations beyond the annotations.

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

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

The description is two tight sentences, with the usage guidance front-loaded before the output content. Every phrase contributes to helping an agent decide when to call it and what it returns.

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

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

For a zero-parameter, read-only listing tool with an output schema and clear annotations, the description is nearly complete: it says when to use it and summarizes the returned coverage details. It could be fuller only by mentioning sibling-tool alternatives, which is already a usage-guideline 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 has zero parameters, so there are no parameter semantics to explain. Per the rubric, a zero-parameter schema establishes a baseline of 4.

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 purpose: check DAMO coverage and identify the symbol name to use, and it specifies that results include covered symbols, available layers, and unavailable timeframes. It does not explicitly differentiate itself from the sibling state-related tools, so it falls short of a 5.

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

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

The opening phrase 'Use to check whether DAMO covers an asset and which symbol name to use' gives clear usage context. It does not state when not to use this tool or name alternatives such as get_state_definitions, so it lacks the explicit routing needed for a 5.

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