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

Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds that Odin has access to all data and can reason about conditions, correlations, etc., and states premium access required. This provides useful behavioral context beyond 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 concise with three sentences covering purpose, capabilities, and requirements. It is front-loaded and avoids unnecessary detail, though the second sentence could be merged for even tighter structure.

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

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

Given there is an output schema (not shown) and annotations, the description covers the tool's AI reasoning nature and domain constraints. It doesn't need to detail return values. The sibling tools are all data retrieval, so this Q&A tool is well-situated.

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 50%: question param has a description, response_format does not. The tool description reinforces the question domain but adds no detail on response_format. Thus it only slightly supplements the schema.

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

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

The description clearly states 'Ask Odin a specific question about Bitcoin markets' with a specific verb ('ask') and resource ('Odin' with domain expertise). It distinguishes from sibling tools that are all data retrieval functions, as this is for natural language reasoning.

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

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

It indicates when to use: asking specific questions about Bitcoin/crypto markets. It mentions 'Requires premium access' as a prerequisite. Although it doesn't explicitly contrast with siblings, the context implies it's for reasoning beyond 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, establishing the tool as safe and read-only. The description adds context about the output (percent change, ratio) but does not disclose further behavioral traits like data freshness, limitations, or side effects. It provides moderate value beyond annotations.

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

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

The description is three sentences long, front-loaded with the main purpose, and each sentence provides relevant information without verbosity. There is no fluff or repetition.

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

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

Given the presence of output schema (which defines return structure), annotations covering safety, and two simple parameters, the description is adequate. It explains the output content (historical comparison, percent change, ratio) and the use case. It is not exhaustive but sufficient for the tool's simplicity.

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

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

The schema description coverage is 50%, meaning only the 'days' parameter has a description in the schema (which also appears in the tool description). The tool description does not add meaning for the 'response_format' parameter, nor does it provide additional insight beyond what the schema already offers. The parameter semantics are weak.

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

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

The description clearly states the tool gets a historical price comparison and ratio between BTC and Gold, mentioning normalized comparison, percent change from period start, and the BTC/Gold spot ratio. This distinctly sets it apart from sibling tools that focus on Bitcoin-only metrics (e.g., get_btc_metrics) or other comparisons (e.g., get_btc_vix_correlation).

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

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

The description provides context on when to use the tool: 'tracking Bitcoin's performance as a store of value relative to the traditional safe haven asset.' It implies utility but does not explicitly state when not to use it or list alternatives. Among siblings, it is the only BTC/Gold ratio tool, so differentiation is inherent.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by specifying that data is real-time and that a premium tier provides additional on-chain metrics, which goes beyond the annotations.

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

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

Three concise sentences. The first states the purpose, the second lists returned data, and the third mentions premium tier. No fluff, front-loaded, and efficient.

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

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

Given the tool's complexity (multiple data points), annotations (safe read), and the presence of an output schema, the description is fairly complete. It covers the scope of data and the premium tier. It does not mention errors or pagination, but these are minor gaps.

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

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

The only parameter 'response_format' is not described in the description. With schema description coverage at 0%, the description should compensate by explaining the parameter, but it does not. The parameter is trivial with a default, but the omission reduces clarity.

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

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

The description clearly states the verb 'Get' and the resource 'Bitcoin metrics', listing specific data points like price, volume, derivatives, and exchange flow. It distinguishes itself from sibling tools which focus on more specific metrics.

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 does not explicitly state when to use this tool vs alternatives. The listing of broad data points implicitly suggests it for general BTC metrics, but no clear guidance on when-not-to-use or which sibling to prefer.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds valuable behavioral details: it includes custom analysis, 30-day rolling correlation, VIX spike zone detection, and specific backtested statistics (91% hit rate, avg +8.8% recovery). These complement the annotations without contradiction.

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

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

The description is front-loaded with a clear purpose sentence, then provides additional context. While it includes detailed backtest statistics, these are relevant to the tool's value. Slightly verbose but efficient overall.

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

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

An output schema exists, so return values need not be described. The description covers the nature of the data (correlation, VIX spike zones, backtest findings) and historical period. It lacks mention of data limits or pagination but is generally complete for the tool's 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 50% (only 'days' has a description in schema, 'response_format' lacks one). The tool description does not explain either parameter, leaving the agent to infer from defaults. This is insufficient for clear parameter usage.

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

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

The description clearly states the tool retrieves historical correlation data between BTC and VIX, specifying rolling Pearson correlation and VIX spike zone detection. It distinguishes from sibling tools by its unique analytical focus on this specific relationship.

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

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

The description provides context such as backtested findings and the post-ETF era, but does not explicitly state when to use this tool over alternatives like signallord_get_btc_metrics or signallord_get_macro_indicators. Usage context is implied but not directed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context: score range (0-100), meaning of high values (panic selling under leverage unwind), and that components are returned. It does not contradict annotations.

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

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

The description is three sentences, front-loaded with the key composite definition, followed by range and interpretation, then additional details about components and source. Every sentence adds value with no 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 an output schema present, return values are covered. The description explains the composite, components, source payload, and interpretation of scores. It is complete for a read-only data retrieval tool, though it omits details like update frequency or pagination.

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

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

The input schema has only one optional parameter (response_format) with no description coverage. The tool description does not mention this parameter, failing to add semantics for it. The parameter is trivial, but given 0% schema coverage, the description should compensate.

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

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

The description clearly defines the tool as returning a 'Capitulation Index' composite score from 0-100, composed of specific metrics (volume anomaly, liquidation surge, etc.). It distinguishes itself from sibling tools like 'signallord_get_composite_score' by specifying the unique composite and that components are 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?

The description implies usage for detecting capitulation conditions but does not explicitly state when to use this tool versus alternatives like 'signallord_get_composite_score' or other indicators. No exclusions or prerequisites are provided, leaving the agent to infer the appropriate context.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds value by explaining the composite's derivation from 6 gauges and the interpretation of scores, which annotations do not cover. No contradictions.

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

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

Two concise, front-loaded paragraphs. Every sentence adds meaningful information: tool purpose, score interpretation, and composition. No redundancy or fluff.

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

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

For a tool with no required parameters and a clear output (output schema exists), the description covers all necessary context: what the score represents, how to interpret it, and what it comprises. Complete and sufficient.

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

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

Schema coverage is 0%, but the only parameter (response_format) is optional with a default of 'json'. The description does not explain this parameter, but its purpose is obvious. Baseline score of 3 is appropriate given minimal parameter complexity.

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

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

The description clearly states it gets a composite Bitcoin market score on a 0-100 scale, with interpretation thresholds (above 70 bullish, below 30 bearish). This verb+resource combination is specific and distinguishes from sibling tools like gauge_breakdown.

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

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

The description implies usage for a quick overall market sentiment check but does not explicitly mention when to prefer this over alternatives or provide exclusion criteria. No sibling tools are named for comparison.

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

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

Annotations already indicate safe read-only, non-destructive, idempotent. Description adds context on signal composition and output fields (current.signals, delta_30d), but does not disclose full behavior 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?

Two sentences plus bullet-like output description. No fluff, front-loaded with purpose. Efficient and well-structured.

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 output schema likely covers return values, description sufficiently explains the score nature and sub-signals. Minor gap on parameter usage.

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 only 50% (days described, response_format not). Description does not mention parameters at all, failing to compensate for the gap.

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?

Clearly states it calculates a cycle bottom probability by aggregating multiple bottoming signals. Name and description together distinguish it from siblings like get_cycle_top_probability, but lacks explicit 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 explicit guidance on when to use versus alternatives. Does not mention prerequisites or exclusions. Relies on name and vague context.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, setting a baseline. The description adds behavioral detail by explaining the aggregation of multiple signals and output fields (current.signals, delta_30d), which is informative and non-contradictory.

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

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

The description is concise with three sentences, front-loading the key purpose and then detailing output fields. Every sentence adds value without redundancy.

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

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

With an output schema present, the description does not need exhaustive return value details, but it highlights key output fields (signals, delta_30d). The tool has only two optional parameters, so the description sufficiently orients the agent for invocation.

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

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

Schema coverage is 50% with only 'days' and 'response_format' described. The description does not add parameter-specific meaning beyond the schema, but it does explain the output fields which indirectly helps parameter understanding. Baseline score of 3 is appropriate given the coverage.

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

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

The description clearly states the tool computes a composite cycle top probability score (0-100) by aggregating multiple topping signals like Pi Cycle proximity and funding euphoria. It distinguishes itself from siblings like get_cycle_bottom_probability by specifying the direction (top) and the output fields that list triggering signals.

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

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

The description implies use when assessing cycle top likelihood but does not explicitly guide when to use this tool over alternatives like get_composite_score or get_cycle_bottom_probability. No exclusion criteria or context for appropriate use is provided.

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

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

Annotations declare read-only, idempotent, non-destructive. Description adds that stale means degraded data, downstream values may be estimated/held over, and details access restrictions for operator scope (403 if not allowed). No contradictions.

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

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

Two short sentences plus one explanatory sentence. Front-loaded with action and context. No fluff.

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 is present, so return format is covered. Description covers purpose, when to use, what stale means, and access restrictions. Complete for a simple health-check tool with two optional parameters.

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 provides description for 'scope' but not 'response_format' (50% coverage). The description adds context on what 'scope' values return and operator restrictions, going beyond schema default values.

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?

Clearly states it checks which signals are stale due to upstream data issues. Specifies context: 'Use this before acting on regime, gauges, indicators, or playbooks.' Distinct from sibling tools that fetch specific 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?

Explicitly frames when to use ('before acting on...') and explains what stale means. Does not list when not to use or alternatives, but the purpose is clear and contrasted with sibling tools.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds data source (CoinGlass), start date (January 2024), and pre-computed cumulative sums. However, it does not disclose update frequency, rate limits, or behavior when data is unavailable, which are relevant for a historical data 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?

Three sentences with optimal front-loading: first sentence states primary purpose, subsequent sentences add specifics on aggregation, cumulative windows, and source. No redundant 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?

Tool is relatively simple with one optional param and an output schema. Description provides data source, temporal granularity, and cumulative window definitions. Missing parameter description but compensated somewhat by the output schema and annotations. 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?

Input schema has one optional parameter (response_format) with a default. Schema description coverage is 0% because the description does not mention this parameter or its possible values. Since description fails to add meaning beyond the schema, even though there is only one simple parameter, this is a gap.

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

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

Description clearly states 'Get Bitcoin ETF flow history' and elaborates on data sources, temporal resolutions (daily, weekly, monthly, quarterly, yearly), and cumulative windows (7d, 30d, 90d, 365d). This is a specific verb+resource that distinguishes it from sibling tools which cover different BTC metrics.

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 tool vs. alternatives. The description implies usage context by detailing the data provided, but lacks exclusions or references to sibling tools. The agent must infer from the tool name and description 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?

Description adds behavioral context beyond annotations: explains meaning of negative/positive net flow, time summaries, and signal classification. Does not contradict any annotation.

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?

Description is concise and front-loaded with purpose, but could be slightly more structured. Sentences are efficient.

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

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

Explains key signals and time frames. Output schema exists, so return values are documented. Completes the context for a specialized metric 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?

Only non-required parameter (response_format) is documented in schema but description adds no value or meaning for parameters.

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

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

Description clearly states the tool gets Bitcoin exchange flow history and explains accumulation vs distribution signals. It distinguishes from siblings by focusing on exchange flows.

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?

Implied usage for tracking BTC accumulation/distribution signals, but no explicit guidance on when to use vs alternatives or when not to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds useful behavioral context (free vs premium tiers, 0-10 scale) but does not cover additional traits like rate limits or data freshness. With good annotations, the added value is moderate.

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

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

Three efficient sentences: purpose, tier details, scoring scale. No wasted words, front-loaded with action.

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?

Description covers core functionality, tier differentiation, and scoring semantics. Output schema exists, so return values are documented elsewhere. Missing minor details like 'underlying metrics', but overall complete for a simple 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?

Only one parameter (response_format) with default value. Schema description coverage is 0%, but the parameter is trivial. The description does not explain the parameter, but it's not critical. Baseline 4 for 0 params is adjusted down slightly due to no mention.

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

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

Description states 'Get individual scores for Signal Lord gauges with underlying metrics', clearly indicating the verb and resource. It distinguishes from siblings like composite score or history, but could be more explicit about which specific gauges are included.

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 sibling tools like signallord_get_composite_score or signallord_get_gauge_history. The description only mentions tier differences but does not help an agent choose among 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 indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds value by specifying that returns are daily snapshots containing both composite and individual gauge scores, which informs the agent about the response 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?

Two sentences: the first clearly states the purpose, the second describes the return content and use case. No unnecessary words 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?

The output schema exists, so return values are covered externally. However, the description lacks details like the meaning of 'gauge scores', any rate limits, or how the 'days' parameter affects the response. It is adequate but not comprehensive.

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

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

The description does not elaborate on any parameters. The two parameters (days and response_format) are defined in the input schema with moderate coverage (50%). The description adds no additional meaning beyond the schema, missing an opportunity to clarify usage or 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?

The description clearly states the tool retrieves historical gauge scores for trend analysis, including daily snapshots of composite and individual scores. However, it does not explicitly differentiate from siblings like 'get_composite_score' or 'get_gauge_breakdown' that might provide single-point 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?

The description advises using this tool to identify regime shifts and score trends over time, providing clear context. However, it does not mention when not to use the tool or suggest alternative tools for other purposes.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds transparency by detailing the output structure (current, crosses, divergence) and explaining the divergence calculation (rolling z-score vs 1y 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?

The description is concise (two sentences plus a brief list of output components) and front-loaded with the key concept. No extraneous information; every sentence earns its place.

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

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

Given the technical nature of the indicator, the description is complete: it explains what the tool returns (current state, historical crosses, divergence series) and the baseline used. An output schema exists to detail return fields, so the description does not need to reiterate them.

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 only 50% (days described, response_format not described). The description does not clarify the parameters beyond what the schema provides, nor does it explain the response_format parameter. With moderate coverage, the description should compensate but doesn't.

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

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

The description clearly identifies the tool as providing Hash Ribbons data (30/60-day hashrate MA cross and divergence z-score). It distinguishes itself from sibling tools by focusing on a specific on-chain metric, and the explanation of the cross's significance adds clarity.

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

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

The description explains the bullish signal context (cross after capitulation) and what the output fields represent. While it doesn't explicitly contrast with sibling tools, the purpose is clear enough for an agent to infer when to use this tool over others.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the access constraint of a premium API key and details the included data, which provides useful behavioral context beyond 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 only two sentences, front-loading the purpose and key constraint (premium key). Every sentence adds value, with no unnecessary words or repetition.

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

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

The description explains what data the tool returns (ETF flows, Coinbase premium, CME basis, regime score) and the API key requirement. An output schema exists but its content is not provided; the description is sufficient for understanding the tool's output. Minor gaps include absence of parameter details.

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

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

The input schema has one optional parameter (response_format) with 0% description coverage. The description does not mention this parameter, leaving its meaning and allowed values unexplained. Given the low schema coverage, the description should compensate but does not.

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

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

The description clearly states the tool 'get institutional Bitcoin market data' and lists specific data points (ETF flows, Coinbase premium, CME basis, composite regime score). This differentiates it from sibling tools that focus on other metrics.

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 mentions a prerequisite ('Requires premium API key') but does not provide explicit guidance on when to use this tool versus alternatives. The context is implied but no when-not or alternative tool references.

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

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

Annotations already indicate read-only, idempotent, and open-world behavior. The description adds useful context by explaining the score interpretation (capitulation, short squeeze signals) and mentioning the raw CoinGlass summary, which enhances transparency beyond structured 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 very concise, using only four sentences. It immediately states the main purpose, then explains the score and its interpretation without any fluff. Every sentence adds 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?

The description covers the key aspects: what data is returned (liquidation momentum score and raw summary), and the scoring logic. An output schema exists so return format details are not needed. It is complete for a straightforward read tool, though it could mention any prerequisites or restrictions (none appear necessary).

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 single optional parameter (response_format) has a default and is not documented in the description. With 0% schema description coverage, the description should at least mention the parameter. However, the parameter is self-explanatory from its name and default, so the lack of documentation is a minor gap.

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

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

The description clearly states the tool retrieves Bitcoin liquidation data and a custom momentum score. It explains the score's components and interpretation, making the purpose well-defined. However, it does not explicitly distinguish this tool from sibling tools like signallord_get_capitulation_score or signallord_get_composite_score, which also provide scores.

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

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

The description implies usage for obtaining liquidation momentum data but provides no explicit guidance on when to use this tool versus alternatives. Given many sibling tools covering different metrics, some direction would be beneficial.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, indicating a safe, read-only operation. The description adds value by detailing the output structure (e.g., each section includes a composite score on a 0-10 scale) without contradicting any annotations.

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

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

The description is two sentences: the first states the purpose, the second lists the outputs. It is front-loaded, concise, and every sentence contributes essential information with no waste.

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

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

Given the tool's read-only nature, complete annotations, and presence of an output schema, the description adequately covers the key indicators and their composite scores. No critical information is missing for an AI agent to understand the output.

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

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

The input schema has one parameter (response_format) with a default, but the description does not mention this parameter or its purpose. With 0% schema description coverage, the description fails to add meaning beyond what the schema provides.

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

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

The description clearly states the tool's purpose: 'Get macroeconomic indicators relevant to Bitcoin.' It lists specific indicators (DXY, VIX, Fear & Greed, etc.), differentiating it from sibling tools like signallord_get_btc_metrics or signallord_get_composite_score which focus on different aspects.

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

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

The description implies usage when macro context is needed but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites. The user must infer from the listed indicators.

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, idempotentHint, etc. The description adds value by detailing the score range (-3 to +3) and the historical significance of alignment, which is beyond the annotations.

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

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

Two sentences: the first states the purpose, the second explains the output. No fluff, front-loaded with key 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?

The description explains the output range and significance, and an output schema exists. However, it lacks details on computation or edge cases, but given the tool simplicity, it 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 coverage is 50% (only 'days' has description). The tool description does not mention either parameter, failing to compensate for the undocumented 'response_format' parameter. The description adds no parameter semantics beyond schema.

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

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

The description explicitly states it returns a multi-timeframe trend alignment composite score from -3 to +3. The name 'get_mtf_trend' and the description distinguish it from siblings that are specific indicators (e.g., BTC metrics, capsize score). The verb 'get' and resource 'mtf_trend' are clear.

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

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

The description implies usage for identifying high-conviction moves via extreme scores, but does not explicitly state when to use this tool over sibling tools like 'signallord_get_composite_score' or 'signallord_get_regime'. No when-not-to-use guidance is provided.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds valuable behavioral context: analysis is cached for ~4 hours and refreshed automatically, and it distinguishes free vs. premium tier content. This goes beyond what annotations provide.

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 well-structured: a clear opening sentence, then contextual detail, caching info, and tier breakdown. Every sentence adds value without redundancy. It is appropriately sized for the tool's simplicity.

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

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

Given the tool's simplicity (one optional param, output schema exists), the description covers caching behavior and tier differences. It does not explain internal terms like 'gauge data', but that is acceptable for an analysis tool. The output schema fills any return-value gaps.

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

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

The input schema has 0% description coverage for the single optional parameter ('response_format'). The description does not mention this parameter at all, missing an opportunity to explain its purpose or accepted values. For a low-coverage schema, the description should compensate but fails.

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

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

The description clearly states 'Get Odin's current Bitcoin market analysis' and explains what Odin is (AI analyst synthesizing multiple data sources). It uses a specific verb-resource combination, but does not explicitly distinguish from sibling tools like signallord_ask_odin.

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

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

The description implies usage by describing what the tool returns and notes differences between free and premium tiers. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to ask Odin questions vs. get analysis).

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

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

Annotations already indicate readOnlyHint=true, so the tool is safe. The description adds valuable context about the internal tracking mechanism and the kind of data returned (accuracy stats, learned patterns), going beyond the annotations.

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

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

Two clear sentences front-loading the purpose. No extraneous information. Every sentence adds value.

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

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

Given an output schema exists, the description sufficiently explains the kind of data. However, it lacks detail on parameter usage and does not cover the response_format parameter, leaving some ambiguity.

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 50% (only 'days' has description). The description does not mention any parameters or add meaning beyond the schema, failing to compensate for the undocumented 'response_format' parameter.

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

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

The description clearly states 'Get Odin's prediction accuracy and learned patterns' and elaborates on accuracy by bias type and confidence level. It distinguishes the tool's focus on historical track record from sibling tools like signallord_get_odin_analysis which likely provides current analysis, though not explicitly.

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 (e.g., get_odin_analysis or ask_odin). No mention of prerequisites or scenarios where this tool is appropriate.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds value by mentioning the output field 'current.cross_state' and the historical reliability, exceeding what annotations convey. No contradictions found.

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

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

The description is extremely concise, using two sentences that front-load the core question and immediately provide context. Every sentence earns its place with no superfluous words.

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

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

Given the tool's simplicity and the presence of an output schema, the description covers the essential purpose and a key output field. It is mostly complete, though it could briefly mention the effect of the 'days' parameter on the output.

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

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

The description does not mention any parameters, leaving both 'days' and 'response_format' undocumented despite the input schema having only 50% coverage. The description fails to add meaning beyond the schema's minimal descriptions.

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

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

The description clearly states the tool identifies the Pi Cycle Top indicator by checking if the 111-day MA crossed 2x the 350-day MA. It distinguishes itself from siblings by focusing on this specific cycle-top signal, making it clear what resource is analyzed.

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

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

The description provides clear context that this is a historically reliable cycle-top warning, implying it should be used for top detection. However, it does not explicitly list alternatives or when not to use it, but the context is sufficient for most use cases.

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

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

Annotations already declare the tool safe and idempotent. The description adds behavioral context: it is a state machine that reports the current regime (above/below) and the most recent reclaim/loss event. No contradictions with annotations.

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

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

The description is concise with three sentences, each adding value: first states purpose, second provides historical context, third details output. No redundant or extraneous 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?

Given the output schema exists and annotations cover safety, the description is fairly complete: it explains the tool's function, output structure, and historical significance. However, it does not describe the effect of the 'days' parameter on the output, which would improve completeness.

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

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

Schema coverage is 50% (only 'days' has a description). The tool description does not explain any parameters, missing the opportunity to clarify the 'response_format' parameter. The schema does not provide complete meaning for both parameters.

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

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

The description clearly states the tool's purpose as a 'Realized Price state machine' that checks if spot is above or below on-chain cost basis, with historical significance. It distinguishes from sibling tools by specifying the output structure (current.state) and its market cycle implications.

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

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

The description provides context for when to use the tool (for market cycle analysis), but lacks explicit guidance on when to use it over sibling tools or exclusions. The historical context hints at usage scenarios but does not directly address tool selection.

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

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

The description adds significant value beyond annotations by detailing output tiers (free vs premium), the six regimes, and the 20+ features used. Annotations indicate readOnly and idempotent, which are consistent with the described behavior.

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

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

The description is well-structured with bullet points and front-loaded with the primary purpose. While somewhat verbose, every sentence adds valuable information, and the format aids readability.

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

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

For a complex tool with many outputs, the description covers regime types, similar historical periods, outcome probabilities, and tier differences. The output schema exists, so return format documentation is not required.

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% but the only parameter (response_format) is optional with a default and is trivial. The description does not mention it, which is acceptable given its simplicity.

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

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

The description clearly states the tool detects the current Bitcoin market regime with historical context and outcome probabilities, listing six regimes and the data sources. It distinguishes from siblings like signallord_get_regime_history by positioning itself as the flagship intelligence tool.

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

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

The description implies it's the primary regime detection tool but does not explicitly state when to use it versus alternatives or when not to use it. It mentions high-value signals but lacks direct usage guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the description adds value by clarifying data source (daily snapshots vs live 2-minute cycle). This provides context beyond annotations.

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

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

Three sentences, each adding value. The first sentence states the core purpose, the second adds use-case context, and the third clarifies the data source. No redundant or missing words.

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

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

With an output schema present, return values are implicitly covered. The description is complete enough for an agent to select and use this tool appropriately. A minor gap: no mention of authentication requirements, but annotations and tool context likely offset this.

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 50%: the 'days' parameter is well-described in the schema, but 'response_format' lacks description. The tool description does not add parameter-specific details. The baseline for 50% coverage expects more compensation, but the parameters are simple and the default values are clear.

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 begins with 'Get historical regime classifications' which is a specific verb and resource. It clearly distinguishes from sibling tools like signallord_get_regime (current regime) by emphasizing 'historical' and 'snapshots'.

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?

Useful for identifying regime transition patterns and duration statistics. The description notes it uses daily snapshot data rather than the live 2-minute engine cycle, implying when to prefer this over real-time tools. However, it does not explicitly name alternative tools to use or avoid.

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, destructiveHint, idempotentHint, and openWorldHint. The description adds that it returns 'current value + band' and 'band_distribution', providing behavioral context beyond annotations. However, it does not disclose data freshness, caching, or any potential side effects, but no contradictions.

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

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

Two concise sentences that front-load the metric definition and then describe the two output modes. No redundancy or unnecessary information; every sentence earns its place.

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

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

Given the output schema presence and two parameters (one described in schema), the description covers the metric meaning and output structure. However, it fails to explain how the input parameters affect results (e.g., days, response_format). It mentions 'current' and 'band_distribution' without clarifying they are controlled via response_format, leaving a gap for the agent.

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

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

The schema covers only 1 of 2 parameters (days) with description. The description introduces 'current' and 'band_distribution' outputs, which likely correspond to the response_format parameter, but does not explicitly link them to the parameter. This adds some semantic value beyond the schema but is incomplete for using the tool correctly.

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 defines Reserve Risk as a ratio and explains its cyclical interpretation with low/high bands, which clearly distinguishes it from sibling metrics. The verb 'get' is implicit in the name, and the description adds unique context about accumulation and distribution zones, making the purpose clear.

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

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

No explicit guidance on when to use this tool versus the many siblings. The description does not mention prerequisites, exclusions, or related tools for comparison. The agent is left to infer usage from the metric definition 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 indicate read-only, idempotent, and non-destructive behavior. The description adds that it compares to the 'most recent daily snapshot' and returns 'significant changes across all categories,' which provides useful context beyond annotations.

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

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

The description is extremely concise: two sentences that immediately convey the purpose and use case. Every sentence adds value, and the structure is front-loaded with the core 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 the output schema exists, the description does not need to detail return values. It covers the tool's scope, time window, and typical use. Minor gap: it doesn't specify what 'all categories' are, but the output schema likely addresses this.

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

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

The description does not mention the single parameter (response_format). With 0% schema description coverage, the description should compensate by explaining the parameter, but it fails to do so. The parameter is simple, but the lack of coverage reduces clarity.

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

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

The description clearly states the tool's purpose: 'Get what changed in Bitcoin markets since yesterday.' It specifies the verb (get), the resource (what changed in Bitcoin markets), and a time scope. This distinguishes it from sibling tools that focus on individual metrics.

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

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

The description explicitly says 'Useful for daily briefings,' providing clear context for when to use the tool. However, it does not mention when not to use it or suggest alternatives among the many sibling tools.

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