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

No annotations are provided, so the description carries the full burden. It discloses that only the latest value is returned and explains the two modes. It implies a safe read operation without destructive effects.

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

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

The description is extremely concise, using bullet points for clarity. Every sentence adds value (purpose, mode explanation, alternative usage). No wasted words.

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

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

Given the tool's simplicity and the absence of an output schema, the description covers the essential aspects: what it returns, modes, the limitation of latest value only, and a pointer for charting. It could mention the typical response structure but is 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 description coverage is 0%, so the description must compensate. It adds meaning for the `mode` parameter by explaining default vs extended. Other parameters (`pair`, `type`, `limit`) are not described, though defaults and enums are in the schema.

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

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

The description clearly states it provides a numerical snapshot of Bollinger Bands values, with specific modes for basic or extended analysis. It distinguishes itself from sibling tools by being BB-specific and lightweight.

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 advises using `prepare_chart_data` for time-series chart drawing, indicating when not to use this tool. However, it does not contrast with other indicator snapshots like `analyze_sma_snapshot`.

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, the description should disclose behavioral traits. It mentions detection and providing context/statistics, but fails to mention that the tool is read-only, fixed to daily timeframe (as per schema), or any side effects. No information about data source, processing time, or potential cost.

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 and relatively concise, but the first sentence contains a bracket-enclosed list that could be streamlined. It front-loads the key purpose but includes redundant Japanese/English translations. Slightly less concise than ideal, but still 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 10 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the return format (context and past statistics), constraints (timeframe is fixed to 1day), or how to interpret results. For a tool with this complexity, the description fails to provide minimal 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 description coverage is only 30%, so the description must compensate. However, it only lists a few pattern names (doji, engulfing, hammer, harami) without explaining parameters like 'date', 'as_of', 'pair', 'timeframe', 'window_days', etc. No parameter semantics are clarified beyond the schema.

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

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

The description clearly states it detects candlestick patterns (doji, engulfing, hammer, harami) and provides context and past statistics. The verb 'detect' and resource 'candle patterns' are specific, and it distinguishes from sibling tools like 'detect_patterns' or other analyze_* tools that focus on different indicators.

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 alternatives. The description lists patterns but does not state prerequisites, limitations, or when to choose this over similar tools like 'detect_patterns' or 'analyze_indicators'. The usage context is only implicitly derived from the tool name.

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

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

No annotations are provided, so the description must disclose behavioral traits. It details the composite score methodology and that it covers all JPY pairs. However, it does not describe output format, update frequency, rate limits, or any side effects. For an analysis tool, knowing the return structure is critical.

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, front-loading keywords and using a clear structure. It avoids unnecessary text. The mix of Japanese and English may slightly reduce clarity but does not waste space.

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 absence of an output schema, the description should explain what the tool returns (ranked list, scores, etc.). It only says 'ranking/screening' without detailing output format. For a screening tool with two non-required params, this is a notable gap.

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

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

Schema description coverage is 100%, with both parameters (topN, type) documented. The description reinforces that topN selects from volume-sorted pairs and type determines RSI/SMA timeframe, but adds no new meaning beyond the schema. According to the calibration, baseline 3 is appropriate.

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

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

The description explicitly states the tool analyzes currency strength, ranking, and screening using a composite score for all JPY pairs. It includes relevant keywords and indicates its use for discovering noteworthy instruments. While it distinguishes from sibling tools that focus on individual indicators, it does not explicitly contrast them.

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

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

The description implies usage for screening and discovering strong/weak currencies via composite scoring. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when to use analyze_indicators or analyze_sma_snapshot), and no when-not-to-use information 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?

No annotations are provided, so the description carries the full burden. It discloses that only the latest value is returned, which is a key behavioral constraint. But it does not mention idempotency, data source, authentication, or potential side effects.

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

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

The description is concise with two sentences and a warning. It front-loads the purpose and provides critical usage guidance without unnecessary 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?

Given the tool has 4 parameters, no output schema, and many siblings, the description provides a fair overview of purpose and a key usage warning. However, lack of parameter semantics and output format details leaves gaps for the agent to properly invoke the tool.

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

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

Schema description coverage is 0%, so the description should compensate. It only discusses the 'periods' parameter via default values. No explanation is given for 'pair', 'type', or 'limit'. This is insufficient for the agent to use parameters correctly without external knowledge.

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 returns EMA latest values, alignment, crosses, and slope with default periods. It distinguishes from chart drawing via prepare_chart_data, but does not explicitly differentiate from other snapshot tools like analyze_sma_snapshot.

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 ⚠️ warning explicitly states when not to use (for chart drawing, use prepare_chart_data). However, it lacks guidance on when to use this tool versus other snapshot analysis tools among siblings.

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

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

With no annotations, the description explains the tool performs automatic swing detection, calculates levels, and outputs historical reaction data. It does not mention side effects or permissions, but the behavior is well-described for a read-only analysis 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?

The description is concise with two sentences and a list of related terms. It front-loads the key purpose. However, it could be better structured for 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?

The description covers main functionality but does not explain the return format or detailed output fields (e.g., what 'reaction history' includes). Given the complexity and lack of output schema, more detail would be beneficial.

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

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

Schema description coverage is 0%. The description does not explain the parameters (pair, type, lookbackDays, historyLookbackDays) except for the mode inferred from 'retracement/extension'. The agent must rely solely on the schema, which lacks 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 it performs Fibonacci analysis (retracement/extension) with automatic swing detection and historical reaction data. It explicitly mentions the alternative analyze_mtf_fibonacci for multi-timeframe, distinguishing it from siblings.

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

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

The description provides a clear alternative for multi-timeframe analysis (analyze_mtf_fibonacci), implying this tool is for single-frame analysis. However, it does not explicitly state when not to use it 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?

With no annotations provided, the description carries the full burden. It explains that the tool returns a numerical snapshot of Ichimoku metrics and is limited to the latest data point. While it does not mention auth or rate limits, the tool is read-only and non-destructive, and the description is accurate and truthful.

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 plus an alert about latest value only. Every word adds value, and the structure is front-loaded with the tool's purpose.

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

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

Given no output schema, the description should provide more detail about the return format (e.g., field names, data types). While it lists the concepts covered (price-cloud relation, cross, slope), an agent cannot reliably parse the output without additional structure info. The complexity is moderate, but completeness is only adequate.

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

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

The schema has 0% description coverage, meaning the parameter names/types provide minimal context. The description fails to explain the meaning or effect of any parameter (e.g., pair, type, limit, lookback), leaving agents to guess. This is a critical gap for a tool with 4 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 it returns a numerical snapshot of Ichimoku Cloud indicators (price-cloud relation, tenkan-kijun cross, cloud slope) and specifies it is 'latest value only.' This sets it apart from sibling tools like analyze_sma_snapshot or prepare_chart_data, which serve different purposes.

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 notes that it provides only the latest value, and directs users to prepare_chart_data with ICHIMOKU for time-series charting. This gives clear guidance on when to use this tool vs 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?

No annotations provided, so description carries the burden. It discloses that the tool is analytical (returns text with values/trends/signals) and implies read-only behavior. Could explicitly state it does not modify data, but overall adequate.

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?

Concise, front-loaded with purpose, includes key usage hint and cross-references to siblings. 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?

Given no output schema, description adequately describes return format (text with latest values, trend, signals). It covers usage context (limit recommendation) and distinguishes from many siblings. Slightly vague on exact output structure, but sufficient for an analysis 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 0% description coverage. Description adds meaning by advising an appropriate limit value ('e.g., 日足200本') but does not explain pair or type in detail. Some compensation, but not full parameter documentation.

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 provides comprehensive analysis of technical indicators (RSI, MACD, SMA) and returns latest values, trend judgments, and signals as text. It distinguishes itself from sibling tools like analyze_ema_snapshot by being a general multi-indicator 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?

Explicitly suggests specifying a sufficient limit (e.g., 200 daily bars) and directs users to separate tools for drawing (prepare_chart_data/render_chart_svg) and backtesting (run_backtest), providing clear when-to-use 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?

No annotations are provided, so the description carries the burden. It discloses that the tool returns a snapshot and is not for time series. However, it does not mention authentication, rate limits, or error handling. For a simple analysis tool, the transparency is good but not exhaustive.

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 key information. It includes a summary, limitations, and references to alternatives. Some redundancy could be trimmed, but overall it is 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?

No output schema is provided, and the description does not specify the return format or fields. Given that there are 5 parameters and no parameter descriptions, the description is incomplete for an agent to fully understand 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 has 5 parameters with 0% description coverage. The description does not explain any parameter's meaning, format, or role. It only mentions the composite score and its factors but does not map them to input parameters. This is a significant 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 it evaluates a composite market signal from 5 factors with a score range of -100 to +100. It distinguishes itself from sibling tools by positioning as a starting point for analysis and explicitly names alternatives for detailed analysis and charting.

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?

Description explicitly states it provides only a snapshot of the latest value, not time series. It directs users to prepare_chart_data for charting and lists specific sibling tools for detailed analysis, providing clear when-to-use and when-not-to-use 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?

Given no annotations, the description carries the full burden. It mentions parallel computing and automatic confluence detection, but does not explicitly state that the tool is read-only or describe any side effects.

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

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

The description is short and front-loaded with key information, using both English and Japanese. Every sentence adds value, though it could be slightly more 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?

The tool has no output schema and two parameters, yet the description does not explain the return format or what the confluence zones look like. This leaves significant gaps for an 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?

Schema description coverage is 0%, and the description adds no explanation for the 'pair' or 'lookbackDays' parameters. The agent must rely solely on schema defaults and types, which is insufficient.

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 performs multi-timeframe Fibonacci analysis with confluence detection, and explicitly distinguishes from sibling tool analyze_fibonacci by noting that individual calls are unnecessary.

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

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

It explicitly recommends using this instead of calling analyze_fibonacci individually, providing clear context. However, it does not mention when not to use it or any 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?

No annotations provided, so the description carries the burden. It discloses it does batch analysis and outputs alignment/confluence, but lacks details on prerequisites, data sources, or limitations.

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 short (one sentence) but lacks structure. It is concise but does not use space effectively to convey 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?

With 3 parameters, no output schema, and no annotations, the description is insufficient. It does not cover inputs or outputs, making it hard for an agent to invoke correctly.

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

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

Schema description coverage is 0%, and the description does not explain the three parameters (pair, periods, timeframes) beyond their names. It adds no value to the schema.

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

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

The description states it performs multi-timeframe SMA batch analysis and determines alignment direction and confluence, which is specific and distinguishes it from sibling tools like analyze_sma_snapshot (single timeframe).

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 vs alternatives (e.g., other analysis tools). The description does not provide context for 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?

With no annotations, the description carries the full burden. It discloses that only latest values are provided, not historical data. However, it lacks details on side effects, permissions, performance, or output structure, making it adequate but not thorough.

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 only two sentences plus a warning. It front-loads key terms (SMA, golden cross, dead cross) and is mostly efficient. However, the Japanese text might reduce clarity for non-Japanese readers, and a structured format could improve scannability.

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

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

Given the tool has 4 parameters with no schema descriptions, no annotations, and no output schema, the description is incomplete. It fails to explain the output format, the role of limit and periods, and the exact meaning of alignment state. A more detailed description is needed for reliable use.

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

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

Schema coverage is 0%, and the description provides no explanation of the four parameters (pair, type, limit, periods). It only vaguely relates to 'latest values' but does not define what each parameter does or how they affect the snapshot.

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 this tool as an SMA snapshot tool providing latest values, cross detection, and alignment state. It distinguishes from prepare_chart_data but does not explicitly differentiate from other snapshot siblings like analyze_ema_snapshot or analyze_mtf_sma.

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 states when not to use this tool (for chart drawing, use prepare_chart_data). However, it does not provide guidance on when to use this over other snapshot tools, leaving some ambiguity.

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 must carry burden. It states it returns 'latest status' and 'determines zone, cross, divergence', which implies a read-only analysis. However, it does not explicitly confirm no side effects or clarify any behavioral traits beyond the analysis type, leaving some ambiguity.

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 short (3 sentences) and front-loaded with the indicator name. Includes a warning and a clear alternative tool reference. Could be slightly more concise by removing redundant symbols, but overall 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?

Even for a simple snapshot tool without output schema, the description fails to specify the return format or what exactly each determination (zone, cross, divergence) looks like. With 6 parameters and no explanation, the agent lacks sufficient context for correct invocation.

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

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

Schema description coverage is 0%, yet the description does not explain any of the 6 parameters (pair, type, limit, kPeriod, smoothD, smoothK). It only mentions stochastic terms like %K and %D but not how parameters affect calculation. This provides minimal added value over the schema.

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

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

The description states 'Stochastic / Overbought / Oversold' and specifies it analyzes 'zone, cross, divergence'. It clearly distinguishes from sibling tools like 'analyze_bb_snapshot' by naming the specific indicator. The verb 'analyze' and resource 'stochastic snapshot' are explicit.

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

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

Provides explicit guidance: 'Only latest value' and directs users to 'prepare_chart_data (indicators: ["STOCH"])' for time series. This tells when not to use the tool. Missing comparison with other analyze_* siblings but the indicator-specific naming implies use for stochastic 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?

No annotations are provided, so the description carries the full burden. It mentions analysis of contact frequency, strength, and breakdown history, which gives some behavioral insight. However, it does not disclose any side effects, dependencies, or limitations (e.g., data source, computational cost).

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 a single sentence that is concise but lacks structure. It does not use bullet points or separate sections to convey key information about parameters or usage, making it less efficient for an agent to parse.

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

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

Given no output schema, no annotations, and 0% schema coverage, the description is too sparse. It covers only the high-level purpose, leaving out parameter meanings, output details, and any context for proper usage. The tool is not sufficiently documented for an agent to use independently.

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

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

Schema coverage is 0%, and the description does not explain any of the four parameters (pair, topN, tolerance, lookbackDays). The agent has no semantic information about what these parameters do, which is critical for correct invocation.

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 detects support/resistance/key levels and analyzes contact frequency, strength, and breakdown history. This specific verb-resource pair distinguishes it from sibling tools like analyze_fibonacci or analyze_volume_profile.

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. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without context for selection among many technical analysis 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?

No annotations are provided, so the description bears full responsibility. It describes what the tool calculates but does not disclose whether it is read-only, any side effects, authentication requirements, or rate limits. The description implicitly suggests it's a query tool, but this is not explicit.

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 a single short paragraph that front-loads key terms like Volume Profile and VWAP, making it quickly scannable. Every sentence contributes meaningful information 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?

The description covers the purpose and mentions the computational outputs (bands, distributions), but since there is no output schema, it doesn't specify the return format or structure. This leaves some ambiguity for the agent regarding what data to expect.

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

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

The input schema has 67% description coverage, with descriptions for bins, hours, limit, and valueAreaPct. The description adds context for the hours parameter (default 4h, max 24h) and mentions the analysis type, but does not explain tz or pair, which lack schema descriptions. This adds marginal value but does not fully compensate for the missing 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 it performs volume profile analysis including VWAP, POC, value area, and calculates bands and distributions. It uses specific financial terms that distinguish it from other technical analysis tools, though it does not explicitly differentiate from sibling tools.

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

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

No guidance is provided on when to use this tool versus alternatives. It only mentions the hours parameter for specifying time range, but does not indicate when not to use it or suggest other tools for related analyses.

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, so the description must carry full burden. It mentions behavioral aspects like forming detection and past statistics for single pair mode but does not disclose side effects, read-only nature, rate limits, or return format. The description lacks thorough transparency for a tool with zero 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, about 10 lines, with a clear structure using bullet points for screen parameters. It front-loads the purpose and avoids unnecessary text. However, it could be slightly more organized by separating mode descriptions explicitly.

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 (11 parameters, nested object, no output schema), the description inadequately covers non-screen parameters like lookback, performanceWindows, and minHistogramForForming. While it mentions forming detection and stats, it does not explicitly link them to includeForming and includeStats, leaving an agent potentially underinformed.

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 55%, and the description adds meaningful context for screen parameters (crossType, minHistogramDelta, etc.) by listing them and their purposes. However, other parameters like lookback, historyDays, and performanceWindows are not elaborated, leaving some gaps that the schema partially fills with defaults.

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 MACD crosses (golden cross, dead cross) and distinguishes between screening mode (multiple pairs) and single pair deep analysis. It uses specific verbs like 'detect' and 'screening' and resource 'MACD cross', making it distinct from sibling tools that analyze other indicators.

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 two usage modes: screening (pair omitted) and single pair (pair specified), with clear parameter directives for each. It provides context on when to use each mode but does not explicitly contrast with sibling tools for alternative indicators, leaving room for improvement.

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 that structural data (data.patterns range) remains in UTC ISO strings for backward compatibility and that display datetime is formatted per timezone. It does not disclose any side effects, rate limits, or destructive behavior, leaving gaps in transparency.

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, front-loading the purpose and key usage instructions. It avoids extraneous details, though some phrasing (e.g., '形成中+完成済みを統合検出') is repeated. Overall, it efficiently conveys essential 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 tool has 14 parameters, no output schema, and no annotations, the description should offer more comprehensive guidance. It introduces overlays for visualization and mentions data.patterns but does not fully explain the output structure or parameter interactions. It is adequate for basic use but lacks depth.

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 36%, so the description must compensate. It adds recommended parameter settings for patterns (e.g., double_top default swingDepth=7, tolerancePct=0.04) and explains aliases like 'flag' mapping to double flags. This provides meaningful guidance beyond the schema.

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

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

The description clearly states the tool detects chart patterns such as double top, head and shoulders, triangle, wedge, and flag, and indicates it detects both forming and completed patterns. This distinguishes it from sibling analysis tools that focus on indicators, support/resistance, or candle patterns.

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 specific guidance on how to use the output: pass overlays to render_chart_svg for visualization, and explicitly prohibits direct SVG output in chat. It also mentions timezone formatting. However, it does not explicitly compare with sibling tools or state when this tool should be preferred 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?

No annotations provided, so the description must fully disclose behavior. It mentions 'speculation-based' and 'simple detection', but lacks details on output format, error handling, or behavior under different conditions.

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

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

The description is short but mixes languages and lacks structure. It conveys the core idea but could be more organized and 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?

Without output schema and with no parameter descriptions, the description fails to provide complete context. The agent cannot determine return values or how parameters affect 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?

Schema coverage is 0% and the description does not explain any parameters (pair, minSize, lookback). The agent has no additional meaning beyond the raw schema.

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

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

The description clearly states the tool detects whale/large orders using order book and candlesticks, and it is speculation-based. It distinguishes itself from sibling tools that are primarily technical indicators or data retrieval.

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 alternatives. The description implies it is for detecting large orders but does not specify context or exclusions.

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

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

No annotations provided, but description fully discloses date/timezone interpretation, limit caps per type, and fallback behavior for tz. 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?

Concise paragraph with bullet-like formatting. Front-loads core purpose and important note. Every sentence adds value with no 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?

Covers date/timezone complexity, limit behavior, and mentions backtest alternative. Lacks explicit return format (OHLCV implied) but sufficient given no 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?

Schema coverage is 50%, but description adds meaning beyond schema: date formats for different types, limit maximums per type, and tz fallback. Compensates well for missing schema details on pair and view.

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 candles/OHLCV data and specifies supported timeframes (1min to 1month). It distinguishes from siblings by directing backtest usage to run_backtest.

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 explicit guidance: 'バックテストには run_backtest を使用' tells when not to use this tool. Also explains date interpretation and limit behavior.

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?

Despite no annotations, the description discloses important behavioral details: internal sorting by timestampMs ascending, deduplication logic using timestampMs:price:amount:side when merging data sources, and the fact that hours parameter can fetch across multiple days. This adds substantial value beyond the schema.

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

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

The description is concise with two clear sections: purpose/usage and processing contract. It front-loads the main function and uses efficient language, though the Japanese '加工契約' section is somewhat technical but necessary.

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

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

Given no output schema, the description should clarify return structure. It mentions view parameter options (summary, compact, buckets, full) but does not explain what each returns. The tool has 8 optional parameters with defaults, but no description of default behavior beyond hours/limit priority.

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 63%, and the description adds meaning for key parameters: explains that hours is prioritized over limit, specifies that limit refers to execution count not bucket count, and clarifies that hours automatically spans multiple days. This helps agents understand parameter interplay.

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: analyzing fund flow metrics (flow/CVD/aggressor ratio/buy-sell pressure) from execution data. It specifies detection of CVD, aggressor ratio, and spikes, and distinguishes it from sibling analysis tools by focusing on flow-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 recommends using 'hours' over 'limit' for time range specification, but does not provide explicit guidance on when to use this tool versus alternatives. There is no 'when-not-to-use' or mention of prerequisites, limiting clarity on appropriate usage.

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 only describes modes and parameters, omitting important traits such as whether the operation is read-only, if it makes network calls, or how it handles errors. The description does not add behavioral context beyond what the schema implies.

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, consisting of only two sentences. The first sentence serves as a clear title, and the second provides a compact enumeration of modes. However, the mix of Japanese and English may reduce clarity for some agents.

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 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the return format, provide examples, or cover all parameters. The mode descriptions are helpful but insufficient for a tool of this complexity.

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

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

Schema coverage is 0%, but the description adds substantial meaning for the 'mode' parameter by explaining each enum value. However, it fails to describe other parameters (pair, topN, ranges, bandsPct, priceZones), which remain undocumented. The partial compensation lifts the score from a baseline of 1 to 3.

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

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

The description clearly states it's an integrated tool for order book, depth, and spread information, and enumerates the different modes (summary, pressure, statistics, raw). It effectively communicates the tool's purpose, though a more concise verb+resource phrasing would improve 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 offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or reference sibling tools. This is a significant omission for a tool with many siblings.

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

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

No annotations are provided, so the description carries the burden. It discloses the data returned (price, volume, 24h high/low) but does not explicitly state it is a read-only operation or any behavioral traits beyond data retrieval.

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 with two sentences, no unnecessary words, and front-loads the purpose. Every sentence serves a clear 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 simplicity (1 optional parameter, no output schema), the description covers the main purpose and output fields. However, it lacks mention of the default pair and return format, making it marginally adequate.

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

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

Schema coverage is 0%, and the description does not mention the 'pair' parameter, its default value, or possible values. The description adds no meaning beyond the schema, leaving the agent without guidance on 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 it gets the ticker for a single pair, including price, volume, and 24h high/low. It distinguishes from siblings like get_tickers_jpy by specifying '単一ペア' (single pair).

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

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

The description implies use for a single pair but does not explicitly state when to use this tool versus alternatives like get_tickers_jpy or other analytical tools. No exclusions or context 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?

No annotations provided, so description carries full burden. It only states it acquires data, omitting behavioral traits like read-only nature, idempotency, or side effects. Does not mention if any data is modified.

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

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

One sentence, front-loaded with bracketed summary. No wasted words. Could be more informative but is appropriately concise.

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

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

For a tool with 4 parameters, no output schema, and no annotations, the description is too minimal. It does not describe the ticker data fields (price, volume, etc.) or explain the difference between 'items' and 'ranked' views. Falls short of providing complete context.

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

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

Schema coverage is 0%, so description must add meaning. It mentions ranking by change rate/volume, which maps to sortBy and view parameters. However, it does not explain view ('items' vs 'ranked'), limit, or order. At least provides context for ranking capability.

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 it retrieves tickers for all JPY pairs and supports ranking by change rate/volume. It contrasts with the singular 'get_ticker' sibling, though not explicitly mentioned. The verb '取得' (acquire) and resource '全JPYペアのティッカー一覧' (all JPY pair tickers list) are specific.

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 alternatives like 'get_ticker' or other analysis tools. The description implies it's for a market overview, but lacks when-to-use/when-not-to-use statements.

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, so the description carries the full burden. It implies a read-only operation ('get') and hints at filtering and date specification, but does not disclose pagination, rate limits, or data freshness beyond the default 60 items.

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 a clear front-loaded title and a single sentence covering core functionality. It avoids fluff but could be slightly more 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?

With 8 parameters, no output schema, and no annotations, the description is too brief. It does not explain default behavior (e.g., how 'latest' interacts with the 'limit' default of 100) or the difference between 'summary' and 'items' views.

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 13% (only the 'date' parameter has a description). The description adds that filtering by amount/price is possible and mentions date specification, but does not detail the view or limit parameters, leaving significant gaps.

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 '約定履歴' (transaction history), distinguishing it from sibling tools like get_candles or get_orderbook by specifying it's for transactions/trades.

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

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

The description mentions fetching the latest 60 items or by date, and filtering by amount/price, providing basic context. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It mentions implementation details (Wilder ATR, annualization) but does not state whether the operation is read-only, what side effects exist, authentication requirements, or limits. The description is insufficient for an agent to understand the tool's safety profile.

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

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

The description is a single paragraph of moderate length. It front-loads the main purpose but mixes general functionality with a specific implementation note. While not overly verbose, it lacks structure (e.g., sections) that would improve readability for an agent.

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 9 parameters with no schema descriptions and no output schema, the description is incomplete. It provides an overview of what the tool computes but does not explain how to configure parameters or interpret results. An agent would struggle to invoke this tool correctly without additional context.

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

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

Schema description coverage is 0% for 9 parameters, yet the description does not explain critical parameters like 'windows', 'annualize', 'useLogReturns', 'cacheTtlMs', or 'view'. The only parameter mentioned is 'aggregates.atr', which is not an input. This fails to compensate for the schema 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 explicitly states the tool calculates volatility indicators (volatility, ATR, realized vol) and lists specific methods (RV, ATR, Parkinson, etc.). It distinguishes from sibling tools by focusing solely on volatility metrics, and name 'get_volatility_metrics' is precise. No sibling tool duplicates this functionality.

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 'analyze_indicators' or 'analyze_market_signal'. It does not mention prerequisites, fallbacks, or exclusions. The only usage hint is internal ('track volatility changes with RV/Parkinson'), not for 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?

No annotations present, so description carries full burden. It discloses response format, rounding behavior for JPY pairs, automatic exclusion of null series, timezone effects, and context consumption by indicators. Lacks rate limits or auth requirements but is thorough for a data retrieval 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?

Well-structured with bullet points and emojis, front-loading purpose. Slightly lengthy but each sentence adds value; 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?

Given 5 parameters, no output schema, and complexity (indicators, timezone, response format), description covers response format, special behaviors, and sibling tools. Missing output structure for subPanels/series details, but sufficient for agent use.

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

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

Schema description coverage is low (20%), but description compensates by explaining tz parameter behavior, default limit recommendation, indicators list with usage note, and default output. Could detail pair format and type options more, but adds significant value 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 clearly states it is the first choice for chart drawing, returning OHLCV candlesticks and optionally indicators. It distinguishes from siblings like render_chart_svg and analyze_indicators by specifying their roles.

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?

Explicit guidelines provided: limit default 30 recommended, only increase if user specifies period; indicators only when explicitly requested; alternatives noted (SVG/PNG → render_chart_svg, indicator analysis → analyze_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?

With no annotations, the description fully discloses behavior: read operation via /depth API, return format with detailed fields, ordering of bids/asks, band calculation, rounding for JPY pairs.

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?

Well-structured with purpose first, then usage guidance, then response format. Efficient but could be slightly more 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?

No output schema, but description provides comprehensive response format and behavioral details. All parameters have defaults; no required params. Context is complete for agent 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 coverage is 67% (levels and bandPct described). The description does not add significant parameter details beyond schema, but the baseline is 3.

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

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

The description clearly states this is the primary tool for drawing depth charts, calling the /depth API and returning cumulative volume arrays. It distinguishes itself from sibling render_depth_svg.

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 recommends using this tool when client-side visualization is possible and directs to render_depth_svg for file output, providing clear when-to-use 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?

Discloses that without arguments it re-acquires all pairs, and specifying a pair only highlights that pair's rate while still refreshing all. No annotations provided, so description carries full burden; it is transparent about the forced cache update.

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 with front-loaded category. Every word adds value; 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?

Given no output schema and a single optional parameter, the description fully covers purpose, behavior, and parameter semantics. No gaps.

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

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

Schema coverage is 100% and description adds critical nuance: the 'pair' parameter only affects display, not which pairs are refreshed. This goes beyond the schema's description.

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

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

Description clearly states it refreshes the TTL cache for fee rates, specifying the endpoint (/spot/pairs) and the domain (fees/maintenance). It distinguishes from sibling analysis tools by indicating it's a maintenance action.

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 states when to use (to immediately reflect latest fee rates at campaign boundaries) and describes default behavior (1h TTL). Does not mention when not to use or alternatives, but the context is clear.

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

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

No annotations provided, so description carries full burden. It discloses key constraints: no automatic calls, output is widget code, educational purpose. Does not mention side effects or authorization, but for a rendering tool this is sufficient.

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 fairly concise, front-loaded with purpose and usage rules. Some redundancy with brackets and Japanese/English duplication, but overall efficient.

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

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

For a visualization tool with nested schema and no output schema, the description covers when to use, what it does, and how to handle output. Missing return value details but adequately complete for correct invocation.

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

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

Schema description coverage is 75%, so baseline is 3. The description does not add significant parameter info beyond schema; it gives usage context but no new semantics for individual 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 it renders an educational candle pattern diagram, visualizing results from analyze_candle_patterns for beginners. It distinguishes from siblings like render_chart_svg by specifying it's for pattern education and only when user explicitly requests.

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 says use only when user says 'show me a diagram' etc., and prohibits spontaneous invocation. Also provides precise instructions for output handling: pass data.svg to Visualizer widget, no direct SVG output.

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, so the description must carry the full burden. It discloses that this is a server-side generation tool and prohibits spontaneous calls. However, it does not describe the return format (e.g., raw SVG string, file path, or PNG binary), nor potential side effects, error handling, or limits. Some behavioral context is given but incomplete.

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 brief and front-loaded with the most critical information: purpose, alternative tool, and usage constraints. Every sentence adds value. It could be slightly more structured, but overall it is concise and effective.

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 (22 parameters, nested objects, no output schema), the description is somewhat incomplete. It lacks details on the return output (SVG/PNG specifics), error conditions, and parameter formatting beyond indicators and overlays. However, it does adequately address usage context and primary purpose. A more complete description would cover what the agent receives after calling the tool.

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

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

Schema description coverage is only 41% (low), so the description should compensate. The description adds meaning for the 'indicators' and 'overlays' parameters by specifying usage conditions, but it ignores the other 20+ parameters. For instance, it does not explain the meaning of 'bbMode', 'ichimoku', or 'subPanels' in natural language. This insufficiently aids an agent to fill parameters 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?

Description clearly states the tool generates candlestick/line charts as SVG/PNG on the server side. It specifically distinguishes itself from prepare_chart_data, noting that client-side rendering should be preferred. The verb 'generate' and resource 'SVG/PNG' are explicit, and the scope (candlestick/line chart) is well-defined.

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?

Excellent usage guidance: explicitly instructs to use only when user requests SVG/PNG save, prohibits spontaneous calls, and prioritizes prepare_chart_data for client-side rendering. Additionally, it specifies that indicators should only be added when the user explicitly requests them, with defaults off. This provides clear when/when-not to use and even names the sibling tool.

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

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

No annotations provided, so description carries full burden. It discloses SVG generation, file saving capability (autoSave/preferFile), and fallback role. Does not detail side effects or constraints 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?

Description is front-loaded with purpose but contains bilingual text and some redundancy. Could be more concise, but key information is present.

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

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

With 5 parameters, no annotations, and no output schema, the description lacks details on return value (e.g., whether SVG string or file path) and behavior of nested depth parameter, leaving gaps for agent invocation.

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

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

Schema description coverage is 0%. Description adds meaning for autoSave and preferFile by linking to file saving, but pair, type, and depth lack elaboration beyond defaults.

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 generates SVG for depth chart/order book visualization, and distinguishes it from the sibling prepare_depth_data by noting this tool is a fallback for file saving/embedding.

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 recommends using prepare_depth_data when client-side rendering is possible, and reserves this tool for file save/embedding fallback 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?

No annotations are provided, so the description must cover behavioral aspects. It describes the output (SVG chart, equity/drawdown curves) and chartDetail options. It does not explicitly state that the tool is read-only (no side effects) or discuss authentication or rate limits, which would be helpful.

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 verbose and contains repetition (strategies listed twice in first paragraph). While the key information is front-loaded, it could be more concise. Every sentence adds value but could be trimmed.

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 (12 parameters, nested strategy object, no output schema), the description is fairly complete. It explains strategies, periods, chartDetail levels, and output format. Missing: an example of the JSON equity curve structure and error handling, but overall adequate.

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

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

Schema description coverage is 100%. The description adds meaningful context beyond the schema, such as how fee_bp resolves dynamically, that chartDetail=default samples 200 points, and how start_date/end_date override period. This helps the agent understand parameter behavior.

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

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

The description clearly states it is a general-purpose backtest tool that fetches data, calculates strategy performance, and draws charts. It lists supported strategies (sma_cross, rsi, etc.), timeframes, and periods, distinguishing it from sibling analysis tools that do not perform backtesting.

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 guidance on when to use chartDetail=default vs full, and notes that start_date+end_date overrides period. It also mentions that custom implementation is not needed. However, it does not explicitly compare to alternatives; siblings are sufficiently distinct.

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?

Describes detection logic, auto-thresholds based on liquidity tier, and adjustable parameters. Without annotations, it could be clearer about read-only nature, but the validation intent is well communicated.

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 paragraph with logical flow: purpose, use case, detection features, auto-tier logic, manual adjustment. It is concise given the number of parameters, though slightly verbose with redundant phrases like '暗号資産のファットテール分布'.

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?

Covers core validation functionality and threshold logic but lacks detail on return format (e.g., whether it returns a score alone or a report with anomaly details). No output schema exists, so description should ideally describe what the agent receives.

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?

Adds meaning beyond schema by explaining auto-threshold behavior for price_sigma and volume_multiplier based on pair tier, and ties pair to liquidity tier. Schema coverage is 71%, and description compensates with contextual value.

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 validates OHLCV candlestick data quality before analysis/backtesting, detects specific anomalies, and computes a quality score. It uniquely distinguishes from sibling analysis tools by focusing on data reliability.

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 says to use before analysis or backtesting to check data reliability, providing clear context. However, it does not explicitly contrast with sibling tools or state 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.