aipricepatterns

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description only needs to add value beyond that. It adds useful interpretive context—shape tokens alone cannot explain a context/volume score, and similarity is not a probability—while also sketching what the explanation contains. It stops short of detailing response format or client-side behavior, but the added caveats are meaningful.

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

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

The description is three short sentences with no filler, and the main deliverable is front-loaded in the first phrase. It is compact but jargon-heavy—p10/p50/p90, anatomy-token observations, and context/volume score may be opaque to a new agent—which slightly reduces clarity without bloating the text.

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

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

With no output schema, the description partially covers return content by naming distance, anatomy-token observations, and outcome vs neighbours, while annotations cover the safety profile. However, it does not describe response structure, edge cases, or how the many optional parameters affect behavior beyond what the schema states, so an agent would need to infer some behavior from the schema and sibling tools.

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

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

Schema coverage is 100%, with enums, defaults, ranges, and format constraints documented for all 11 optional parameters, so the description does not need to repeat them. Phrases like 'ranked,' 'reported method,' and 'neighbour p10/p50/p90' add some conceptual context to rank and limit parameters, but no parameter-specific semantics beyond what the schema already provides. 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 names a specific deliverable—an explanation of why a candle 'twin' ranked under the reported retrieval method—and enumerates the evidence types considered: distance, anatomy-token observations, and outcome vs neighbour p10/p50/p90. It avoids tautology and makes the tool's scope clear, though it does not explicitly distinguish it from siblings like inspect_candle_analogue or get_candle_evidence_board.

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 when the tool is relevant: explaining a match ranking, not predicting direction. It also provides a negative guard with 'Similarity is not P(direction).' However, it never names an alternative tool or offers explicit when-to-use/use-this-instead guidance, leaving sibling selection largely to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds meaningful context beyond that by stating 'Free; does not use the daily quota,' which is a behavioral cost guarantee not present in the annotations. It also previews what the returned guide covers.

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

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

Two sentences with zero filler. The critical 'Start here' call to action is front-loaded, followed by a compact list of guide contents and a useful quota note. Every sentence earns its place.

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

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

For a zero-required-parameter, read-only guide tool with a fully covered schema, the description is complete. It tells the agent what the guide contains, that it is free, and that it should be the starting point. No output schema exists, but the return value is a guide whose contents are itemized, so no critical information is missing.

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%, and the single 'topic' parameter is fully documented in the schema with an enum and per-value explanation. The description does not add any parameter-level detail, but the schema already carries the full semantic load, so 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 states a specific verb ('Returns') and resource ('the candle market-memory guide') and enumerates concrete contents (evidence, chart presets, call order, band reading, track records, access). It also positions itself as the entry point with 'Start here,' which clearly distinguishes it from the sibling tools that each focus on a specific candle function.

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?

'Start here' gives a clear contextual cue that this should be the first tool an agent invokes before the more specific siblings. It does not explicitly name alternatives or state when not to use it, but the entry-point framing and mention of 'recommended call order' provide sufficient usage direction.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond those annotations by clarifying that results are a two-sided map of forward behavior on the live close and by excluding certain output categories; there is no contradiction.

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

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

The description is two short sentences with no filler. The core resource and its output contents are front-loaded, and the negative boundary is stated compactly at the end.

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 read-only, idempotent tool with a fully documented schema, the description covers the essential purpose and output features without an output schema. Minor gaps remain — 'two-sided' is not explained and 'retrieved twins' assumes domain context — but an agent can still select and invoke the tool 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 100%, so the schema already documents all nine parameters, their enums, defaults, and limits. The description does not add parameter-level meaning, such as how f, q, limit, anchorTs, or token options affect the map, so the schema continues to carry the full semantic load.

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

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

The description names a specific resource — a two-sided map of what matched candles ('twins') did next on the live close — and enumerates its contents (P10/P50/P90 reach, clustered turn prices, band-edge order). It also draws a clear boundary with 'Not stops, targets, or LONG/SHORT,' which helps distinguish it from related tools, though it does not explicitly name a sibling alternative.

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

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

The description implies usage by describing the map's content and includes a negative scope statement ('Not stops, targets, or LONG/SHORT'), so an agent can avoid this tool for those needs. However, it never explicitly says when to choose this tool over siblings like inspect_candle_analogue or get_candle_track_record.

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

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds meaningful context beyond that: it is free, recomputed daily, based on a 4-of-5 phase verdict, and explicitly not a direction signal. This is substantial behavioral disclosure for a parameterless informational 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 not overly long, and the core subject is near the front. However, it opens with a one-word sentence and then a fragment ('Which ... carry range information:') rather than a clear declarative statement, making the structure harder to parse. The dense technical detail is relevant but could be better organized.

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 parameterless, read-only tool with no output schema, the description covers what the tool reports: a walk-forward record of bands, averaging over five anchor phases, a consensus verdict, and daily recomputation. It does not specify the exact output shape, but the description is sufficient for an agent to understand the tool's purpose and call it without arguments.

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?

There are zero parameters, so the description does not need to explain any. Schema description coverage is trivially 100%, and the 0-parameter baseline of 4 applies.

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

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

The description identifies the resource: symbol/timeframe configurations carrying range information for the /candles default preset. It does not use an explicit verb like 'returns' or 'lists', but the tool name and content make the purpose reasonably clear. The closing 'Not a direction signal' helps distinguish it from direction-oriented 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?

The phrase 'Which symbol/timeframe configurations carry range information' implies when to use it, and 'Not a direction signal' gives a useful when-not. However, no sibling alternative is named, and there is no explicit statement of when to prefer this over the other candle-related tools.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is known to be safe and idempotent. The description adds valuable behavioral caveats: 'Similarity is not a directional probability' and 'Analogues are dated look-alikes, not a tested rule' — these directly warn against misinterpretation. It also mentions 'signal-integrity gate' and 'freshness', providing behavioral context beyond the annotations. No contradiction.

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

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

The description is dense but well-structured. It front-loads the main purpose and then lists the returned components. The inclusion of a URL with utm parameters is somewhat extraneous, but it serves as a pointer to an alternative for backtesting. Overall, every sentence contributes meaning, though it could be slightly more concise without losing key caveats.

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, no output schema, and no nested objects, the description is fairly complete. It lists all major output components (analogues, bands, ledger, freshness, integrity gate) and includes critical interpretive disclaimers. It doesn't specify the exact response format or data types, but since there is no output schema, this is an acceptable level of detail. It could mention pagination or limits, but the limit parameter is already in the schema. Overall, adequate for an agent to call and interpret 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?

The input schema covers all 9 parameters with detailed descriptions (100% coverage), so the baseline is 3. The description does not add parameter-specific semantics beyond the schema; it focuses on the output content. It doesn't explain parameter relationships or syntax beyond what the schema provides, so it doesn't elevate the score.

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

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

The description clearly states the tool's purpose: 'Return the full-OHLC candle context used by /candles' and enumerates the specific components (calibrated price/context/volume market memory, rankingMethod, fallback reason, historical analogues, magnitude bands, versioned analogue ledger, freshness, signal-integrity gate). This is a specific verb+resource with a detailed list that distinguishes it from sibling tools like get_candle_analogue_map or get_candle_evidence_board, even though those are not named.

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 context for when to use the tool (for full candle context), but it does not explicitly state when to prefer this over sibling tools or when not to use it. It does point to an external tool (RLXBT MCP) for backtesting, which is a form of alternative guidance, but it lacks explicit comparisons to the listed sibling tools. Thus, it gives some context but no clear exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds meaningful process/output context: it walks forward over independent anchors, compares range bands against an unconditional baseline, and returns coverage, confidence intervals, Winkler scores, regime diagnostics, and non-directional signal integrity. This goes beyond the annotations without contradicting them.

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 dense sentences carry the full purpose and output scope with no filler. The core action is front-loaded, and the metric enumeration earns its place by explaining what the agent will receive, especially since there is no output schema.

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

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

For a complex statistical tool with 10 parameters and no output schema, the description lists the key return concepts (coverage, confidence intervals, Winkler scores, regime diagnostics, signal integrity), which is sufficient for selection. However, it leaves terms like 'independent resolved anchors' and the exact walk-forward procedure somewhat underspecified, which may matter for invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description references symbol, interval, q, and f as the configuration, and mentions anchors implicitly, but it does not add any parameter meaning beyond what the schema already provides. It neither compensates nor detracts.

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

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

The description names a specific verb ('Walk forward') and resource ('exact chart candle configuration (symbol, interval, q, f) over independent resolved anchors'), and it distinguishes this tool from siblings by focusing on statistical track-record evaluation with coverage, Winkler scores, and non-directional signal integrity. This is clearly a backtest/validation tool, not just another candle data or analogue lookup.

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 the tool is for evaluating the performance of a specific candle configuration over resolved anchors, but it never explicitly states when to use this tool versus alternatives like get_candle_analogue_map or inspect_candle_analogue. There are no exclusions or routing hints, so the agent must infer usage from context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the manifest is versioned and includes JSON argument schemas, which is useful context, but it does not disclose other behaviors such as response size or error conditions. No contradiction with annotations.

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

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

The description is two sentences with no filler. The first sentence fronts the core purpose, and the second efficiently explains the profile behavior. Every sentence contributes to understanding the tool.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description is reasonably complete: it names the returned content and the two profiles. It could go slightly further by noting the JSON shape of the response, but the phrase 'JSON argument schemas' implies the manifest is JSON, so this is a minor gap rather than a blocker.

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

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

Schema coverage is 100% with a clear enum description, including the ~200 KB note for 'full'. The description paraphrases the default and full profiles but does not add meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Return', the resource 'versioned MCP compatibility manifest', and its contents (canonical tools, aliases, JSON argument schemas). It also differentiates the two profiles, which distinguishes this meta-tool from the sibling data-lookup 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?

The description explains when to use the 'golden' vs 'full' profile, but it does not explicitly compare this tool to alternatives or state when to prefer it over siblings. The usage context is implied by the tool's unique manifest-listing purpose, so it is adequate but not explicit.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description adds valuable behavior beyond annotations: the NO_TRADE gate when candle direction is unvalidated or server-side order flow is unavailable, plus the 'conservative' disposition. This meaningfully enriches the annotation-only picture.

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

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

Two sentences with zero waste. The core purpose is front-loaded in sentence one, and the critical gating behavior occupies sentence two. Every clause earns its place.

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

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

With no output schema, the description covers the most important return behavior (NO_TRADE gate) but doesn't describe what a positive decision payload looks like. However, all 9 parameters are fully documented in the schema and annotations carry the safety profile, so the tool is reasonably complete 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 100%, so the baseline is 3. The description references 'freshness and execution-component gates' conceptually but adds no per-parameter detail beyond what the schema already documents thoroughly (enums, defaults, limits). It doesn't need to compensate, so a 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?

States a specific verb+resource ('Return a conservative chart-parity trader decision') with a clear qualifier ('conservative') that hints at its differentiation from sibling data-retrieval tools like get_candle_market_snapshot. It doesn't explicitly name a sibling to differentiate from, so it falls short of a 5, but the purpose is unambiguous.

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

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

The description implies when to use it (when you want a trader decision rather than raw candle data), but never explicitly states when to prefer it over alternatives like explain_candle_match or get_candle_track_record. No exclusions or alternative names are given, leaving routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the description does not need to re-establish safety. It adds useful behavioral context by clarifying that the tool is not a directional call and by enumerating exactly what the inspection returns, which helps the agent anticipate the response shape.

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 dense sentence with a front-loaded action and a colon-delimited list of delivered components. Every clause adds information and there is no filler, though the long list requires careful parsing.

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 read-only inspection tool with no output schema, the description lists the key returned components and frames the operation clearly. Parameters and safety are already fully covered by the schema and annotations; the main remaining gap is explicit sibling routing, which is more of a usage-guideline concern.

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%, so every one of the 11 parameters already has explicit enums, defaults, constraints, and descriptions. The main description does not add parameter-level semantics beyond tying the tool to a 'reported rankingMethod,' so the 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 states a specific action ('Open one neighbour from the reported rankingMethod as an episode') with a clear resource and output scope: OHLC, twin OHLC, rebased forward, distance, display similarity, and dated permalinks. The closing 'Not a directional call' distinguishes it from directional/decision siblings, and the 'reported rankingMethod' hook differentiates it from map-level or evidence-board 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?

The description clearly implies when to use it: after a ranking method has reported a neighbour list, to inspect one specific neighbour. It also gives an explicit when-not ('Not a directional call'). It does not name alternative sibling tools such as explain_candle_match or get_candle_evidence_board, so it stops just short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context such as auth requirements, rate limits, or response format. It is consistent with annotations and adds only the 'Sketch-to-Search' concept, which is more purpose than behavior.

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

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

Two sentences with no wasted words. The action is front-loaded ('Search for historical patterns...') followed by a concise usage note. Every sentence earns its place.

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

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

The tool has no output schema, and the description does not mention what it returns (e.g., matches, similarity scores, pagination). The limit parameter is also not referenced. While the purpose is clear, for a search tool the return format is an important missing piece, so completeness is moderate.

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%, so all parameters are already documented. The description adds no additional meaning about parameters, so the baseline of 3 applies without any extra credit.

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 'search' and the resource 'historical patterns', and specifies the unique aspect of a 'sketched' price trajectory. This distinguishes it from siblings like explain_candle_match or get_candle_analogue_map, 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 provides a clear usage context: 'Useful when you want to find matches for a hypothetical or hand-drawn pattern.' It does not explicitly mention alternatives or when not to use it, but the context is sufficient for an agent to infer when this tool applies.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the behavioral caveat that output is research bullets, not a trade signal, and implies a summary-style response. It does not contradict annotations.

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

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

One dense sentence, front-loaded with the core purpose ('Salience card') and followed by a compact list of the card's contents. Every phrase earns its place, though the jargon list is heavy.

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

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

With no output schema, the description should explain the return shape and interpretation, but it only says 'Research bullets, not a trade' and lists metric names without defining them (e.g., 'D tightness', 'closest-twin vs median'). It also does not explain how parameters like f, q, or includeAnalogueCandles shape the card. For a 9-parameter tool with no output schema, this is a meaningful 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%, so the schema already documents all nine parameters, including enums, defaults, and token/billing caveats. The description adds no parameter-specific meaning, but it does not need to; baseline 3 applies.

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

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

The description identifies the tool as a 'Salience card for the current window' and enumerates the analyses it surfaces (neighbour band vs all-history width, ledger coverage vs 80%, closest-twin vs median, etc.), so an agent can tell it is an anomaly/research report rather than a trade execution tool. It lacks an explicit verb like 'returns' or 'computes,' and the jargon is dense, but the resource and scope are clear enough.

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 gives a clear context cue: 'Research bullets, not a trade' tells the agent this is for research rather than actionable trading. However, it never states when to prefer this tool over siblings such as get_candle_evidence_board or explain_candle_match, nor does it list exclusions.

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