OneQAZ Trading Intelligence

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

Beyond annotations (readOnlyHint, idempotentHint), the description discloses meaningful behavior: it operates on paper trades, enforces a max 30-day window, and returns empty result when no trades exist. It also flags that it is informational only, adding context at the edge-case level.

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

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

The description is well-structured with labeled sections and front-loaded purpose. It is slightly long due to trigger examples and a disclaimer, but every section adds actionable value 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?

Combined with an output schema and rich annotations, the description covers purpose, triggers, prerequisites, caveats, edge cases, and parameter semantics. There is no obvious gap for an agent selecting or invoking this 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, but the description fully compensates by documenting each argument: market_id values and accepted aliases (coin/kr/us), and days default/max. This exceeds what the bare schema provides.

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

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

The description opens with 'Aggregate paper trades by day / pattern / symbol', which is a specific verb and resource. It clearly differentiates from sibling tools like get_trade_history (raw rows) by emphasizing aggregation and grouping.

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 triggers ('how's the week been?', 'which patterns are working?'), a 'When to call' section, prerequisites recommending get_trade_history for raw rows, and next steps. This is strong guidance on when and how to use the tool relative to alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict these. It adds meaningful context: the output is 'research evidence, NOT a buy or sell recommendation' and includes a caveat about symbol matching the lowercase filename. This goes beyond the structured annotations by explaining the nature and limitations of the return data.

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

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

The description is well-structured with clear headings (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer) and front-loaded with the core purpose. While the trigger examples are helpful, they are somewhat redundant given the explicit 'When to call' section, making the text slightly longer than strictly 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?

For a tool that aggregates multiple data sources, the description is remarkably complete. It explains the composition of the return (three components), provides prerequisites, notes that it ends the explanation chain, and includes a disclaimer. Even without seeing the output schema, the agent understands what to expect and how to prepare inputs.

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 carries full responsibility. It provides substantial semantics: market_id lists allowed values and aliases ('crypto, kr_stock, us_stock; aliases coin/kr/us'), and symbol gives concrete examples ('btc, eth, 005930') plus the lowercase rule. This fully compensates for the schema's 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 begins with a specific verb-resource combination: 'Multi-layer explanation for a single symbol's recent research signal.' It enumerates the three combined components (technical score_trace, Thompson + regime scores, news causality) which clearly distinguishes it from sibling getter tools. The statement 'present a structured "why" rather than a raw verdict' further differentiates it from tools that return raw data or verdicts.

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 'Use this when' and 'When to call' instructions are provided, including example triggers in both English and Korean. Prerequisites identify prior steps ('identify the symbol via get_signals or get_latest_decisions first') and 'Next steps: none' clarifies workflow completeness. However, it does not explicitly name alternative tools to avoid, so it lacks direct 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 set readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds valuable behavioral context beyond annotations: 'uncovered resource uris return description-only text (no fabricated data)' and '`text` is a JSON document for resource/signal ids.' This gives the agent critical expectations about output format and data limitations without contradicting the annotations.

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

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

The description is long but every section serves a purpose: Purpose, Namespaces, Triggers, When to call, Prerequisites, Next steps, Caveats, Output, Args, Disclaimer. It is well-organized and front-loaded with the most critical information. No filler or redundancy.

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

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

Given the tool's complexity (multiple id namespaces, output shapes, and caveats) and the minimal schema, the description is remarkably complete. It covers what the tool returns, how to invoke it for different resource types, error behavior (description-only text), and next actions. The presence of an output schema is acknowledged and the description lists the envelope fields.

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%, but the description fully compensates with a dedicated 'Args' section explaining the `id` parameter's namespace formats and examples: 'tool:{name}', 'resource:{uri}', 'signal:{market}:{symbol}'. This is far richer than the bare schema and leaves no ambiguity about the parameter's meaning.

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 function: 'standard document fetch by id from `search` results.' It specifies the resource (document), the verb (fetch), and how it relates to search, effectively distinguishing it from the sibling tools like `search` and `get_signal_detail`. The namespaces (`tool:`, `resource:`, `signal:`) further clarify scope.

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 when-to-use guidance: 'Triggers: ChatGPT connectors / Deep Research call this after `search`' and 'When to call: whenever the full content behind a search result id is needed.' It also names alternatives for next steps (e.g., `get_signal_detail` / `explain_decision` for deeper evidence), clearly differentiating from other 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, idempotentHint, and openWorldHint. The description adds meaningful behavioral details beyond this: the outcome IS NULL condition, the 'returns most recent first' caveat, and the demonstration of real-time publishing. No contradiction with annotations is present.

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

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

The description is well-structured and front-loaded with the purpose, followed by triggers, when-to-call, prerequisites, next steps, caveats, and args. While the trigger examples and explanatory sentences are somewhat verbose, each section is purposeful and earned.

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 (2 optional parameters) and the presence of an output schema, the description covers all necessary context: prerequisites, next steps, caveats, parameter semantics, and usage triggers. It is complete for an agent to decide when and how to invoke it.

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?

Despite 0% schema description coverage, the description fully compensates by explaining target_market as an optional filter with allowed values (coin_market, kr_market, us_market), and limit as a maximum with a default of 20. This adds clear meaning beyond the bare schema types.

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 'Purpose' line explicitly defines the tool's function: returns currently pending predictions (outcome IS NULL), and the 'When to call' section clarifies its role in verifying ongoing prediction activity. This clearly distinguishes it from related sibling tools like get_resolved_predictions by emphasizing the 'active/pending' scope.

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 a dedicated 'When to call' section, prerequisites, next steps, and caveats. It names get_prediction_accuracy as a next step, giving useful context. However, it does not explicitly state when not to use the tool or directly name an alternative like get_resolved_predictions, so it falls short of a 5.

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, openWorldHint, and idempotentHint, so the safety profile is known. The description adds valuable behavioral context with the caveat that 'last_backtest timestamp indicates tuning freshness' and clarifies that data is 'derived from real backtest outcomes'. 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?

The description is well-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer) and front-loads the purpose. However, it is somewhat verbose with extensive trigger examples and a boilerplate disclaimer, which could be trimmed without losing 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?

With an output schema present, return values are covered. The description provides purpose, triggers, usage sequence, prerequisites, caveats, and parameter explanations, making it highly complete for a read-only, idempotent tool. The caveat about timestamp freshness is a nice contextual addition.

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 provides only type and default for each parameter (category, target_market) with zero description coverage. The description adds 'Optional category filter' and 'Optional target market filter', which confirms they are optional filters but doesn't elaborate on allowed values or formats. This is minimal compensation 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 clearly states the tool's purpose: 'Continuous self-calibration evidence' showing auto-tuned lag_hours and sensitivity per cell derived from real backtest outcomes. It uses a specific resource (backtest tuning state) and distinguishes itself from sibling tools like get_signal_calibration and get_prediction_accuracy.

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 'When to call' context after get_prediction_accuracy, lists 'Prerequisites' and 'Next steps' (get_monthly_accuracy_trend), and includes a comprehensive list of trigger phrases. This gives clear guidance on when to use the tool and how it fits into a sequence, even though it doesn't name an alternative tool to avoid.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint as true, establishing safety profile. The description adds valuable caveat that correlation data may be empty until enough regime changes accumulate, which is beyond what annotations provide. However, no additional behavioral details about output format or edge cases are disclosed.

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 well-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Every section adds value, though 'Purpose' and 'Triggers' overlap slightly. It's slightly verbose but remains clear and scannable.

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?

Has an output schema, so return values are covered structurally. Description provides context for macro regime analysis, sibling differentiation via next steps, triggers, and caveats. The inclusion of multilingual triggers and explicit alternatives makes it complete for an AI 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 has 0% description coverage and only raw names (source_market, target_market). The description compensates by stating each is an 'Optional source market filter' / 'Optional target market filter', adding meaning about their purpose as filters. This is minimal but sufficient for such simple parameters.

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

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

Description clearly states the tool's purpose: showing cross-market lead-lag relationships and decoupling events. It specifies the resource (market correlation) and the specific insights (correlations and divergences), distinguishing it from sibling tools like get_sector_correlations_tool and get_macro_influence_map.

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 triggers with example queries, when-to-call guidance, prerequisites ('none'), next steps (get_macro_influence_map), and caveats. This is comprehensive guidance for 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?

Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description adds critical behavioral caveats: a 24-hour window and that data is paper-trading only, not real money. It also discloses the output shape and the existence of `_next_actions`, which is valuable operational context.

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 longer than average but every section earns its place, with clear labels like 'Purpose', 'Triggers', 'When to call', 'Prerequisites', 'Next steps', 'Caveats', and 'Output'. It is front-loaded with the essential purpose and uses efficient formatting; no filler or redundant repetition.

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

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

Given the modest complexity of one parameter, the description is fully complete: it covers purpose, invocation triggers, usage position relative to other tools, prerequisites, caveats, and a breakdown of the output fields. The presence of an output schema is supplemented, not replaced, by a clear enumeration of the returned full_data structure.

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?

Even though the input schema has no parameter description and 0% schema coverage, the description fully documents the `market` parameter, including its default of 'all' and the allowed values 'crypto', 'kr_stock', and 'us_stock'. This compensates completely for the schema gap and adds practical meaning.

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 opens with 'Purpose: Single-call market overview' and enumerates a specific, concrete bundle: macro regime, top strong signals, yesterday's paper-trading outcomes, active forecast count, and narrative. This clearly distinguishes it from the many sibling tools that each handle one narrower concern.

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 says 'Use this as the first call when answering "how is the market today?"' and provides a rich set of trigger phrases and when-to-call scenarios. It also advises preferring this over answering from training data, and names next-step tools for deeper dives.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses that results can be empty when feature_gate_evaluator has not run cycles yet, and explains the lifecycle semantics. This adds valuable behavioral context about state transitions and reliance on underlying system execution.

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

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

The description is well-structured with clear sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). It is slightly verbose, especially the trigger list, but every section earns its place and the purpose is front-loaded.

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 query with an output schema and strong annotations, the description is thorough: it covers purpose, usage context, parameter semantics, and a key edge case (empty result). It provides all necessary information for an agent to 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?

The schema has zero parameter descriptions, but the Args section explains all three parameters: market_id defaults to coin, target_market is a backward-compatible alias, and status_filter accepts enumerated lifecycle states. This compensates well for the schema gap, though 'defaults to coin' could be more explicit about the default 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?

The description clearly states the tool returns the current lifecycle state of external features under 3-track statistical validation, with a concrete state model. It provides specific trigger questions and distinguishes itself from siblings by focusing on lifecycle states, making the tool's purpose 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 provides explicit 'When to call' guidance (meta-level trust audit) and lists trigger phrases, but it does not directly contrast with the similarly named sibling get_feature_governance_status_tool. It gives clear context for when to use this tool, but no explicit alternatives 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint; the description adds operational context by noting the promoter cycle runs hourly and that the snapshot surfaces survival/deprecation outcomes. This goes beyond the structured hints and clarifies update cadence and expected content.

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 organized into labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats) and is front-loaded with the core purpose. It is slightly wordy with multiple trigger examples and a generic disclaimer, but each section earns its place.

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

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

Given zero parameters and the presence of an output schema, the description is fully complete: it explains what the snapshot contains, when to use it, prerequisites, the hourly caveat, and directs to the sibling tool for deeper detail. No critical information is missing for an agent to invoke it 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?

The tool has zero parameters and the schema coverage is 100%, so no parameter explanation is necessary. The baseline of 4 applies because there are no parameters to clarify and the description appropriately focuses on behavior rather than input.

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 feature governance snapshot with OBSERVATION/CONDITIONAL/ACTIVE/DEPRECATED distribution and last 7-day transitions. It also distinguishes itself from the sibling get_feature_governance_state by pointing to that tool for full per-feature lifecycle detail.

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 lists Triggers and 'When to call' with concrete examples (e.g., 'which features are actually used?', trust evaluation). It also names get_feature_governance_state as the alternative for more detailed lifecycle information, which helps with 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, lowering the burden. The description adds valuable behavioral context: 'paper-trading decisions only — no real-money order routing', the log nature, and that outcomes are included. It also notes prerequisites and caveats, going beyond the structured safety profile without contradicting it.

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 compactly structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Every section adds distinct value, though the trigger examples are somewhat repetitive. Overall, it is well-organized and front-loaded with the core 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 the 4 parameters, output schema presence, and rich annotations, the description covers all necessary aspects: purpose, usage context, prerequisites, next steps, caveats, and parameter semantics. It does not need to describe return values because an output schema exists. Minor gaps are acceptable (e.g., exact outcome format), so it is complete for practical 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%, so the description must compensate. The Args section gives meaningful semantics: market_id with accepted values and aliases, limit with default, decision_filter enumerates choices (buy, sell, hold), hours_back explains 'only decisions within last N hours'. This adds purpose to each parameter beyond the bare 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's purpose: 'Track-B (signal-driven) paper-trading decision log', with an explicit contrast to Track A (LLM judgement path) via 'see get_llm_trading_decisions'. It names specific verbs like 'review recent automated decisions and their outcomes', which distinguishes it from siblings and explains its scope.

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 explicit usage guidance: 'When to call', example triggers, prerequisites ('market://{market_id}/status recommended'), and next steps ('get_trade_history, get_signals'). It also differentiates from alternative Track B vs Track A, directing to get_llm_trading_decisions for the other path, which fulfills the when/when-not requirement.

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

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

Annotations already mark the tool as read-only, open-world, and idempotent. The description adds valuable behavioral context: the hash chain begins 2026-03-22, hashes are computed once daily (UTC), and entries are append-only at the serving-role level. It also discloses the verification_hint output, exceeding what annotations provide.

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

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

The description is well-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Output, Args) and front-loaded with the core purpose. It is slightly long but every section provides actionable 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?

Despite having an output schema, the description goes beyond by explaining the output shape, caveats, prerequisites, and usage context. Given the tool's complexity, this is fully complete and leaves no critical gaps for an agent to understand when and how to invoke it.

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 sole parameter 'days' is explained in the description as 'how many most-recent chain entries to return (max 400)', adding crucial semantics beyond the schema which only specifies type and default. This fully compensates for the 0% schema description coverage.

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

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

The description clearly states the tool's purpose: tamper-evidence for the prediction ledger via a SHA-256 hash chain with a published canonical recipe. It specifies the resource (prediction ledger) and the verb (get integrity/verify), and it is clearly distinct from sibling tools like get_resolved_predictions.

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 triggers, 'when to call' guidance, prerequisites, and suggested next steps. It even names the sibling tool to use for raw rows and frames this as the first step in credibility audits, making alternatives and context 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds valuable context beyond them: the tool is paper-trading only, and the LLM judgement is a 'capped bias on top of engine signals'. This provides behavioral nuance without contradicting 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?

Structured with clear headers (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer) and front-loaded with the purpose. Every section adds functional value, including the multilingual trigger examples, 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 purpose, usage context, exclusions, parameter semantics, and caveats, while the output schema and annotations handle return types and safety profile. It is fully complete for an agent to select and 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 has no descriptions (0% coverage), but the description fully compensates by defining market_id with allowed values (crypto, kr_stock, us_stock, commodity, forex, bond) and explaining symbol as optional and market-scoping. This is exactly the semantic detail an agent needs.

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 'Purpose: Track-A (LLM-driven) paper-trading judgement log' and differentiates Track A from Track B (signal-engine path) by referencing get_latest_decisions. It clearly identifies the verb (get/inspect) and resource (LLM-generated trading decisions).

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 'When to call' guidance ('inspect LLM-generated reasoning and trade calls'), prerequisites ('none'), and next steps ('get_latest_decisions to compare with Track B'), directly addressing when to use this tool versus the sibling alternative.

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

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

Annotations already declare readOnly, idempotent, and openWorld. The description adds critical context that the data is paper-trading only and that this is a convenience wrapper that pre-filters by max_roi. It also includes a disclaimer that the output is informational, not advice. 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 methodically structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Every section adds distinct value — the trigger examples are targeted at understanding user intent, and the caveat is essential for data context. It is front-loaded with purpose and wrapper definition.

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, filtered list tool with an output schema, the description covers all necessary context: what it returns, when to invoke it, what parameters mean, what data scope applies, and what to do next. The existence of an output schema means it does not need to enumerate return fields. This is a complete and self-sufficient tool description.

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 compensates fully. It defines market_id with allowed values (crypto, kr_stock, us_stock) and aliases (coin/kr/us), and defines limit as max results with a default of 20. This goes well beyond the bare schema and explains the wrapper's implicit max_roi parameter.

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

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

States clearly it returns 'Losing paper positions (ROI < 0)' and calls itself a wrapper around get_positions(max_roi=-0.01), which precisely describes the action and resource. The sibling get_losing_trades vs positions distinction is clear, and the parenthetical ROI condition disambiguates from other list 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?

Explicitly provides triggers ('what's underwater?', 'show me the red ones'), a 'When to call' line (drawdown / risk review), and a 'Next steps' chain (get_position_detail, get_role_analysis). It also notes there are no prerequisites, and by referencing itself as a convenience wrapper it implies that get_positions is the alternative for unfiltered view.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, lowering the burden. The description adds valuable context: data is paper-trading only, and the loss threshold is defined. It doesn't mention pagination or rate limits, but the output schema exists and the safety profile is covered by 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?

Well-structured with labeled sections and front-loaded purpose. The trigger examples and disclaimer are somewhat verbose, but each section contributes to usability, so it remains 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?

Covers purpose, triggers, when to call, prerequisites, next steps, caveats, and parameter explanations. Output schema eliminates the need for return-value details. For a simple two-parameter tool, the description is fully complete and contextually rich.

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 properties have no descriptions (0% coverage), but the description fully compensates: explains market_id accepts crypto/kr_stock/us_stock with aliases, and limit has a default of 10. This goes far beyond the bare schema and tells the agent exactly what values are valid.

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

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

Clearly states it returns losing paper trades only (P&L < 0), and identifies as a convenience wrapper around get_trade_history(max_pnl=-0.01). This distinguishes it from sibling tools like get_winning_trades and get_trade_history.

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

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

Provides explicit 'When to call: failure-pattern review' and lists example trigger phrases. The wrapper mention points to get_trade_history as a more flexible alternative, and next steps suggest analyze_trades, giving clear context on when and how to use.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds statistical caveats: Pearson-based, requires >=30 samples, p<0.05 filter, and notes that only statistically significant pairs are returned. This is useful beyond annotations, though no other behavioral traits (e.g., time range semantics) are mentioned.

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 structured with clear headings (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args) and is front-loaded with purpose. It is somewhat verbose with example queries, but every section earns its place, offering actionable guidance without excessive 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?

Despite having an output schema (so return values are covered elsewhere), the description provides complete context for a read-only analytical tool: what it does, when to use it, prerequisites, caveats, and next steps. It leaves no significant gaps for an agent to misuse 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?

The input schema provides only types and defaults (0% coverage), so the description carries the full burden. It explicitly defines each parameter: 'min_abs_corr: Minimum |corr|' and 'max_p_value: Maximum p-value', adding meaning the schema lacks. This fully compensates for the missing schema 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 states a specific verb+resource: 'Lag-aware causal graph between macro categories' and specifies the categories. It clearly differentiates from siblings like get_macro_influence_map by focusing on lead-lag pairs among macro categories, not category-to-market impact.

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 provides triggers ('what happens to VIX when bonds move?'), the specific context ('assess pre-emptive cross-category impact after a macro event'), prerequisites ('none'), and a next step (get_macro_influence_map) for an alternative use case. This distinguishes when to use this tool versus others.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering the safety and idempotency profile. The description adds meaningful behavioral context beyond these: the tool is 'static hypothesis only' and does not reflect runtime tuning adjustments. It also states 'Information only, not investment advice' as a disclaimer. Given the low bar set by annotations, this is solid added value.

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 organized with clear labels (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Each sentence serves a purpose, and the structure is front-loaded with the core purpose. While it is not terse, the length is justified by the useful contextual information, and nothing feels redundant or wasteful.

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 one optional parameter and an existing output schema, the description covers all essential dimensions: purpose, usage triggers, prerequisites, related tools, caveats, and arguments. It even provides an explicit disclaimer. The only thing not explained is the return structure, but since an output schema exists, that is not required.

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

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

The input schema is minimal (one optional string market_id) with 0% schema description coverage. The description compensates by listing possible values: 'coin_market, kr_market, us_market', and clarifies it is an 'Optional target market filter'. This gives the agent actionable information beyond the bare schema, though it could elaborate on default behavior (e.g., no filter returns all markets).

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

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

The description uses a specific verb 'Expose' and a concrete resource: 'OneQAZ's pre-defined causal hypothesis map', detailing the content (macro categories mapped to target markets with lag_hours + sensitivity). It differentiates from sibling tools by highlighting its 'highest-transparency' nature and caveat that it is 'static hypothesis only', clearly separating it from dynamic counterparts like get_backtest_tuning_state.

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 explicit 'When to call' guidance ('when an AI wants to understand WHY we make certain predictions'), concrete trigger examples (including a Korean query), and a 'Next steps' reference to get_backtest_tuning_state for runtime calibration. It also directs users away from this tool for current adjustments via the caveat, effectively naming an alternative.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable caveats about excluding the 'all' month aggregate and being empty when backtest_results is unpopulated, which goes beyond the structured metadata. 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 well-structured with labeled sections (Purpose, Triggers, When to call, Caveats) and front-loaded purpose. It is a bit lengthy due to trigger examples and disclaimer, but each section earns its place and improves usability.

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

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

Given the output schema exists, the description covers the essential context: purpose, triggers, usage chain, prerequisites, caveats, and disclaimer. The tool is simple (2 optional params) and the description fully enables correct selection and 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%, so the description must compensate for parameter semantics. It only restates 'Optional category filter' and 'Optional target market filter', adding no format, allowed values, or behavior details. The parameter names are self-evident but the description adds minimal value over the bare 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 'Monthly accuracy time series per (category, target_market, lag_bucket)' with a specific verb ('verify') and resource. It distinguishes itself from siblings like get_prediction_accuracy by emphasizing the time-series/trend aspect and explicitly listing trigger phrases for degradation detection.

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 when-to-call guidance ('after get_prediction_accuracy and get_backtest_tuning_state'), prerequisites, next steps ('trust chain complete'), and example trigger questions. This fully orients the agent on placement relative to alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds operational caveats like 'window limited to recent days' and a disclaimer, which enrich understanding without contradicting annotations. It does not reveal potential rate limits or data availability issues, but the added context is valuable.

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 organized into labeled sections (Purpose, Triggers, When to call, Next steps, Caveats, Args, Disclaimer), making it scannable. It is somewhat verbose due to multilingual trigger examples and overclaiming language, but every section earns its place and the purpose is front-loaded.

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

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

An output schema exists, so return values are handled separately. The description provides prerequisites, sequencing relative to a sibling tool, next steps, and caveats, making it sufficiently complete for a read-only tool with open-world behavior. It lacks details on data freshness or edge cases, but overall coverage is strong.

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, so the description must compensate. However, it only repeats the parameter names with minimal gloss (e.g., 'market_id: Market identifier', 'days: Lookback window in days'), adding no new meaning, examples, or constraints. The vague caveat about 'recent days' is the only extra hint, but it 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 the tool's function: classifying news into three buckets (anticipated, surprise with precursor, pure surprise). It uses specific terminology and defines each category, distinguishing it from sibling tools that focus on other news-related analytics.

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 usage context: 'When to call: after get_news_leading_indicator_performance' and lists trigger questions in multiple languages. It also includes prerequisites and next steps, giving clear guidance on when and how to use this tool relative to alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context beyond those: it states the tool returns specific fields per event type, and provides a caveat ('empty when no news events processed in the recent window'). This is meaningful behavioral disclosure, though it doesn't mention performance or rate limits, so a 4 is appropriate.

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

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

The description is well-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer) and front-loads the core purpose. It is slightly verbose with multiple trigger examples and Trust Layer context, but every section earns its place for a developer-facing 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?

The description is comprehensive given the tool's simplicity and available structure. It covers purpose, usage triggers, prerequisites, caveats, parameter meanings, next steps, and a disclaimer. The output schema exists, so return values are further specified elsewhere. There are no significant gaps for a read-only retrieval tool.

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

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

The input schema has 0% description coverage, but the description compensates fully with an 'Args' section that explains each parameter: market_id ('Market identifier (crypto, kr_stock, us_stock, etc.)'), target_market ('Alias for market_id (backward compat)'), and min_sample_count ('Minimum sample count for statistical significance (default 3)'). This adds clear meaning beyond the bare 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 opens with a specific verb and resource: 'Evidence that OneQAZ detects price moves BEFORE news publication. Returns leading_score, avg_lead_time_minutes, and accuracy_pct per event type.' It clearly states what the tool does and differentiates from siblings by mentioning 'Trust Layer A evidence' and pointing to get_news_causality_breakdown as a next step, avoiding confusion with other news-related 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?

Includes explicit trigger examples ('can you predict news?', 'how early do you catch moves?'), a dedicated 'When to call' condition ('when an AI is evaluating predictive capability'), prerequisites ('none'), and a 'Next steps' alternative (get_news_causality_breakdown). This meets the 5-level bar for when/how to use and 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?

Even though annotations already declare readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial behavioral context: paper-trading data under a synthetic fixed-book capital model, the requirement for account_type, the behavior of 'live' returning an explicit no-data error, and that the fixed window ensures reproducibility. There is no contradiction with the annotations.

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

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

The description is long but logically structured with Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, and Disclaimer. Every section adds distinct value; the length is appropriate for the tool's complexity and the critical caveats about the synthetic capital model.

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 provides a complete operational picture: fixed-window semantics, data source caveats, authentication-like requirement (account_type), reproducibility, and linkage to sibling tools. Given the output schema exists and the description covers all input semantics and edge cases, no critical context 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?

The input schema has 0% description coverage, but the Args section fully documents all five parameters: market with aliases and the 'all' 1/3 allocation, account_type as required with paper/live semantics, window_start defaulting to 2026-06-16, window_end defaulting to today KST, and include_daily_curve meaning. This entirely compensates for the schema's lack of 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 identifies the tool as providing portfolio-level performance metrics (MDD, Sharpe, Sortino, Calmar, monthly returns, equity curve) over a FIXED window, and explicitly states it is the single canonical computation path for OneQAZ blog and external clients. This distinguishes it from sibling tools like get_trade_history and analyze_trades, which cover underlying trades and breakdowns.

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 gives explicit triggers ('what's the max drawdown?', 'MDD 얼마야?'), specific when-to-call scenarios (track-record verification, blog figure cross-checks), prerequisites (none), and next steps (get_trade_history, analyze_trades). It also clarifies exclusions, such as 'live' account returning a no-data error until real records exist.

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, openWorldHint, and idempotentHint, so the safety profile is known. The description adds valuable behavioral context beyond this: it returns an 'error envelope when no position exists,' and clarifies this is a 'paper position' tool. These details are not inferable from the annotations and help the agent anticipate failure modes. There is 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 well-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). It front-loads the purpose and every section adds useful information. There is minor redundancy between 'Purpose' and 'When to call' (both mention per-symbol/full context), but the overall length is reasonable for the amount of guidance provided.

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 3 params (1 required) and an output schema, the description is thoroughly complete. It covers what the tool does, when to use it with example triggers, prerequisites, next steps, a caveat (error envelope for no position), and parameter semantics. Since an output schema exists, the description need not detail return values. This gives the agent all necessary context to select and invoke the tool effectively.

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% (no property descriptions), so the description's Args section is essential. It explains market_id with accepted values and aliases ('crypto, kr_stock, us_stock; aliases coin/kr/us accepted'), symbol with examples, and coin as a legacy alias. This adds meaning beyond the raw schema, though it could be slightly more explicit about the relationship between symbol and coin (e.g., which takes precedence). Overall, it compensates well 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 states a specific verb+resource+scope: 'Per-symbol paper position deep-dive (position + recent trades + decisions).' This clearly distinguishes it from sibling tools like get_positions (which lists positions) and analyze_trades (which analyzes trades broadly). The 'full context for one ticker' phrasing further clarifies its focused purpose.

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 explicit triggers ('how's the BTC position doing?') and a 'When to call' section ('full context for one ticker'). It also gives a prerequisite (confirm position via get_positions) and next steps (get_signal_detail, get_role_analysis). However, it does not explicitly state when NOT to use this tool or directly name alternatives as exclusions, though the prerequisite strongly implies using get_positions for listing positions. This is clear guidance but lacks an explicit when-not clause.

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, openWorldHint, and idempotentHint. The description adds important behavioral context: paper-trading only, not real money, disclaimer about investment advice, and a recommended prerequisite context. This goes beyond the annotations and clarifies the tool's operational scope.

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?

Despite being more verbose than typical descriptions, it is well-structured with clear headers (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Disclaimer, Args). Every section adds distinct value, and the most critical info (purpose) is front-loaded. No redundant 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?

Covers all necessary aspects: purpose, usage triggers, scenarios, prerequisites, next steps, caveats, and parameter details. Since an output schema exists, not explaining return values is fine. The description is fully self-sufficient for an agent to understand when and how to invoke this tool.

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

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

Schema coverage is 0%, so the description carries full responsibility. It explains every parameter with examples and allowed values (e.g., market_id: crypto, kr_stock, us_stock; sort_by: profit_loss_pct, entry_timestamp, holding_duration, ai_score; sort_order: desc/asc), adding meaning beyond the bare schema types and 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 opens with a clear verb+resource: 'List current paper-trading positions' with explicit mention of filters. It distinguishes itself from sibling tools like get_losing_positions and get_profitable_positions by being the general list, and the 'paper-trading' qualifier is a key differentiator.

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 extensive usage guidance: explicit example triggers, 'When to call' scenarios, prerequisites, next steps, and caveats. Though it doesn't explicitly name alternatives, the context and sibling names make the appropriate use clear, and it states what the tool is NOT for (real money).

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

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

The description discloses important behavioral nuances beyond the readOnly/idempotent annotations: it explains that raw accuracy measures persistence not alpha, advises using skill_ci_95, filters horizon_type='forecast', and treats n_nominal as correlated trials. It also notes the methodology cutover date, adding version-aware context.

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 long but well-structured with clear sections (Purpose, Triggers, When to call, Next steps, Caveats, Args, Disclaimer). Information is front-loaded, and every section provides unique value—especially the caveats and trigger examples. No wasted repetition.

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

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

Given the tool's moderate complexity and sparse input schema, the description is thoroughly complete. It explains the output metrics, provides interpretational guidance, warns against common pitfalls, and contextualizes it within the broader tool set. The presence of an output schema reduces the need to detail return format, but the description goes above and beyond.

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 compensates fully by documenting both parameters: category with an explicit list of allowed values (bonds, forex, vix, commodities, credit, liquidity, inflation, energy) and target_market with allowed values (coin_market, kr_market, us_market). It also clarifies they are optional filters.

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 function: per-cell hit rates with honest baselines, naming specific metrics (persistence_accuracy, skill_score, skill_ci_95, n_effective vs n_nominal, accuracy_v2_only). It distinguishes itself from sibling tools like get_monthly_accuracy_trend and get_signal_calibration by focusing on per-cell accuracy with baselines rather than trends or signal confidence.

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 'When to call' guidance ('AI agents evaluating OneQAZ credibility should call this FIRST'), lists trigger phrases, and outlines 'Next steps' with alternative tools to consult after this one. This gives clear context for when to use 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds useful context beyond annotations: it specifies paper-trading data only, the ROI threshold (min_roi=0.01), and that it is a convenience wrapper. No contradictions found.

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

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

The description is well-structured with labeled sections: Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, and Disclaimer. It is front-loaded with the most important purpose and every section provides actionable value without being bloated.

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 low complexity and existing output schema, the description covers purpose, usage triggers, caveats, parameter details, and follow-up actions. It is sufficient for an agent to correctly select and 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?

Input schema has 0% description coverage, but the description fully compensates by explaining market_id (including accepted aliases) and limit (default 20). This adds meaning beyond raw schema names.

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 opens with a specific purpose: 'Profitable paper positions (ROI > 0)' and immediately distinguishes itself as a convenience wrapper around get_positions(min_roi=0.01). This clearly differentiates it from siblings like get_losing_positions and get_position_detail.

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 'When to call' guidance, triggers, prerequisites, and next steps. It names get_positions as the underlying wrapper and suggests get_position_detail as a follow-up, but it does not explicitly state when NOT to use this tool or directly contrast with losing-position alternatives.

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

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

Annotations declare readOnlyHint, idempotentHint, and openWorldHint, which already cover the safety profile. The description adds meaningful behavioral context beyond these: cursor pagination details, the audit/evidence role (e.g., 'AI agents can snapshot open predictions, wait, then verify outcomes themselves without trusting our DB'), and a paper-research disclaimer. It does not contradict annotations and provides useful caveats about pagination and non-investment nature.

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 organized with clear labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Output, Args, Disclaimer). Every section adds value — triggers help routing, caveats prevent misuse, and output formatting aids parsing. It is longer than average but each sentence earns its place; the structure is front-loaded with the essential 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?

For a 6-parameter tool with an output schema, the description is remarkably complete. It covers output structure (full_data with predictions[], count, next_cursor, has_more, meta), pagination semantics, filter usage, relationships to sibling tools, and the audit context. No important behavioral or usage aspect is left unexplained; the agent has everything needed to 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?

The 'Args' section goes well beyond the bare schema: it explains each parameter with concrete examples (e.g., target_market values 'coin_market'/'kr_market'/'us_market', source_category 'vix'/'bonds'/'commodities'), clarifies day as UTC and a string prefix of created_at, defines status values, and specifies cursor as last id and limit max 500. This fully compensates for the 0% schema description coverage and makes parameter usage unambiguous.

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 opens with a specific and vivid purpose: 'Raw, row-level prediction ledger — every macro regime prediction's full lifecycle (created_at -> resolved_at -> outcome).' This clearly distinguishes it from sibling tools like get_prediction_accuracy (aggregates) and get_active_predictions (likely active only). The verbal resource and scope 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 'When to call' guidance: credibility evaluation, independent backtesting, archiving. It also mentions pairing with get_ledger_integrity and next steps. However, it lacks an explicit 'when not to use' / exclusion statement; the alternative tool (get_prediction_accuracy) is implied but not explicitly contrasted as 'use this for summaries.' The triggers and prerequisites are strong, but the absence of a clear negative case costs a point.

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 readOnly, openWorld, and idempotent. The description adds valuable context with the caveat that results are based on hierarchy_context and may be empty when collector lag is high, and it clarifies the tool's informational nature. 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?

The description is well-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer) and front-loaded with the purpose. It is a bit long due to multiple example triggers and a disclaimer, but every section serves a 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 the tool's analytical complexity, the description covers purpose, usage triggers, prerequisites, next steps, caveats, and parameter semantics. It also explains the dependency on hierarchy_context and the possibility of empty results, making it complete enough for an agent to invoke correctly, especially with an output schema present.

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%, but the description compensates thoroughly with an 'Args' section: market_id lists allowed values (crypto, kr_stock, us_stock), symbol provides examples, and coin is explained as a legacy alias. This adds significant meaning beyond the raw schema properties.

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 'Role-aware signal alignment per symbol (timing / trend / swing / regime) plus hierarchy alignment', giving a specific verb and resource. It clearly distinguishes from siblings like get_signal_detail by focusing on multi-timeframe alignment across 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?

Provides clear triggers ('is BTC bullish across timeframes?') and an explicit 'When to call' section for multi-timeframe analysis and cross-role agreement checks. It recommends get_signal_detail as a prerequisite but does not explicitly list alternatives or exclusions, so it stops short of a 5.

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, openWorldHint, and idempotentHint, and the description adds valuable behavioral context beyond that: data refresh cadence ('refreshed every 6 hours'), lookback window ('60-day lookback'), and a disclaimer ('Information only, not investment advice'). No contradictions with annotations.

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

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

The description is well-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer) and front-loads the core purpose. Each section adds useful information without redundancy; the length is justified by the rich guidance.

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

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

Given the output schema exists, the description doesn't need to explain return values. It covers prerequisites, usage context, refresh/lookback caveats, and parameter semantics, making it complete for an agent to invoke correctly. Even with 2 simple parameters, the description provides enough context for a reliable call.

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

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

Input schema has no descriptions (0% coverage), so the description compensates by listing valid values for market_id ('coin / kr_stock / us_stock') and explaining top_k as 'Number of top pairs to return'. This adds meaning beyond the bare schema types and defaults, though top_k could be more explicit about what 'top' means (e.g., strongest correlations).

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's function: 'Intra-market ETF / group correlation matrix and auto-cluster output' with a specific verb ('Quantifies structural co-movement') and concrete examples (ARKK <-> QQQ). It distinguishes itself from siblings like get_cross_market_correlation by explicitly being intra-market, and from get_symbol_peer_links_tool by focusing on group/sector-level correlations rather than per-symbol lead-lag.

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 'When to call' guidance ('portfolio diversification or sector concentration audits'), casual trigger examples in multiple languages, prerequisites ('none'), and a named next step (get_symbol_peer_links_tool). This clearly tells an agent when to use this tool versus 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?

Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses important behavioral caveats: daily snapshot, observation window ≈ 2 weeks retention, and n being nominal due to correlated trials. This adds meaningful context about data freshness and statistical 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?

Despite some length, the description is highly structured with headers (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer), and the essential purpose is front-loaded. Every section serves a distinct functional purpose, from trigger matching to parameter disambiguation.

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

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

With an output schema present, return values need no explanation. The description covers purpose, triggers, usage context, prerequisites, next steps, data caveats, and all parameter semantics, making it fully self-sufficient for an agent to decide when and how to invoke this 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%, but the description's Args section fully explains each parameter: market_id with enum-like examples, interval with example values, and variant with detailed semantics ('v1' vs 'v2', default, accumulating since date). This fully compensates for the schema's lack of 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 opens with a specific verb and resource: 'Reliability diagram data for Level-1 signal confidence — realized hit rate per confidence bucket ... with ECE summary.' It clearly distinguishes itself from siblings like get_structure_calibration and get_prediction_accuracy by focusing on signal confidence calibration.

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 'When to call' guidance is provided: 'before trusting get_signals confidence values as probabilities.' Trigger phrases are given, and 'Next steps' names alternative tools (get_prediction_accuracy, get_signals), offering clear usage direction and 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, idempotentHint, and openWorldHint. The description adds a caveat not in annotations: 'queries both the per-symbol signal store and the paper-trading store', disclosing data source behavior. Does not contradict annotations and provides useful additional context.

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 well-structured with clear sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Disclaimer, Args). While slightly long, each section serves a purpose and aids agent comprehension. The disclaimer is brief and relevant.

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 only 4 parameters and an output schema, the description covers all necessary context: what it does, when to invoke, prerequisites, follow-up tools, behavioral caveats, and parameter explanations. No significant gaps remain 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%, but the description defines each parameter: market_id as market type, symbol as preferred asset identifier, coin as legacy alias, and interval as timeframe with default. This adds meaning beyond the bare schema properties, though it doesn't explain 'combined' interval semantics.

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 'Per-symbol signal deep-dive — latest signal + history + feedback', using a specific verb and resource. It distinguishes from sibling tools like get_signals (list) and get_signal_calibration (aggregate) by focusing on a single symbol's detail. Example triggers further clarify the exact query intent.

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 'When to call' guidance: 'drilling into a single ticker's signal context'. Also specifies prerequisites ('confirm existence via get_signals first') and next steps (get_role_analysis, get_position_detail), giving clear directions 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavior beyond that: the caveat about market-wide scanning when symbol is omitted (including per-symbol row caps and scan caps), and the explicit disclaimer that outputs are research signals, not orders or advice. 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 well-structured with clear headings (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer), ensuring information is scannable. Every section earns its place; while detailed, it remains efficient and front-loaded with the most important 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's complexity (9 params, 1 required, output schema present), the description covers all necessary aspects: purpose, trigger examples, selection context, prerequisites, follow-up tools, parameter semantics, behavioral caveats, and a safety disclaimer. It is complete for an agent to decide when and how to invoke it.

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 fully compensates by enumerating all 9 parameters with meaningful details (e.g., 'coin: Legacy alias of symbol', interval allowed values, default limit, hours_back window). This adds semantics well beyond the bare schema and clarifies optionality and 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 opens with a specific verb ('Query') and resource ('research signals') with dynamic filters, clearly stating what the tool does. It distinguishes itself from siblings by mentioning next steps like get_signal_detail and get_role_analysis, and contrasts with get_latest_decisions.

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 triggers ('should I buy / sell X?', casual phrasing), when-to-call scenarios (drilling into a specific slice, symbol-by-symbol scanning), and prerequisites (market:// summary). It also lists appropriate siblings to pair with or follow up, offering clear guidance on when to use this tool versus 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?

Beyond annotations, it discloses the empty-distribution caveat and scopes results to 'current paper positions'. Annotations already cover read-only/idempotent behavior, and the description adds meaningful context 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?

Uses clear labeled sections and front-loads the purpose. Slightly verbose due to exhaustive trigger examples and next-steps, but each section 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?

With one well-explained parameter, an output schema, and clear caveats/prereqs/next steps, the description is complete for an agent to 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 has 0% description coverage and a bare string param. Description compensates by enumerating valid market IDs (crypto, kr_stock, us_stock) and accepted aliases (coin/kr/us), 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?

Description opens with 'Per-strategy breakdown across current paper positions (count, avg P&L, win rate per strategy)' – a specific verb and resource. It clearly distinguishes from siblings like get_positions by focusing on aggregated strategy distribution.

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 'When to call' context (diversification audit, per-strategy performance check) plus trigger phrases. It mentions prerequisites and next steps, but doesn't name alternatives like get_strategy_leaderboard, so it falls just short of a 5.

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 important behavioral caveats beyond readOnly/openWorld/idempotent annotations: GLOBAL pool may include 'synthesized win_rate values', per_symbol_leaderboard is the 'primary measured-edge surface', min_trades enforces statistical validity, and strategies are paper-tested. This significantly helps agent trust decisions.

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, Triggers, When to call, Next steps, Caveats, Args, and Disclaimer; front-loaded with purpose. Slightly verbose due to trigger examples and disclaimer, but each section serves a 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?

Complete for a read-only query tool: covers purpose, invocation context, prerequisites, caveats, next steps, and all parameters; output schema exists, so return details need not be in description.

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, but the Args section explains all six parameters and their aliases (market_id, target_market, top_n, limit, min_trades, include_per_symbol) plus defaults. This fully compensates 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?

Description clearly states tool returns 'Top RL-learned research strategies — GLOBAL pool + per-symbol partition' and includes trigger examples. However, it lacks an explicit verb and does not name sibling alternatives, so it does not fully meet the 5-level sibling differentiation.

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

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

Provides explicit triggers ('what are the best strategies?', 'top strategies?') and specifies 'When to call: final trust-validation step' with prerequisites none. It does not mention when not to use or alternative tools, so just misses 5.

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, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context: the tool returns empty results until structure-learning cycles complete, and it clarifies the Level 2 granularity (ETF/basket/sector) versus Level 1 individual symbols, which is useful for expectation setting.

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

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

The description is well-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer) and is front-loaded with the purpose. It is slightly longer than strictly necessary due to the inclusion of multiple trigger phrases and a disclaimer, but each section 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 description covers all essential context: purpose, usage triggers, prerequisites, next steps, caveats, and parameter semantics. Since an output schema exists, the lack of return-value description is acceptable. The description is complete for the tool's complexity and configuration.

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?

Despite zero schema description coverage, the description provides meaningful semantics for both parameters: market_id is an optional market filter with specific values (crypto, kr_stock, us_stock), and group_name is an optional group/sector filter with examples (layer1, defi, sector, broad_index). This compensates fully for the lack of schema descriptions.

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

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

The description clearly states the tool's function: 'Returns hit_rate_ema per (market, group, interval, regime_bucket) with sample counts' and explicitly positions it as Level 2 (ETF/basket/sector) calibration, distinguishing it from Level 1 individual symbols. It also differentiates from siblings like get_structure_validation_history by mentioning it as a next step.

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 'When to call' guidance (Layer D evidence), example trigger phrases ('how good are your sector calls?'), prerequisites (none), and next steps (get_structure_validation_history for the daily trend). This goes beyond mere context to actionable usage criteria.

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, openWorldHint, and idempotentHint. The description adds useful context: it returns an overall_hit_rate summary across the window, and clarifies the daily validation nature. 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?

Structured with clear headings (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer), front-loaded purpose, and no redundant filler. The trigger phrases add value for LLM routing, and each section 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 an output schema available, return values are covered. The description includes purpose, usage context, prerequisites, next steps, caveats, and parameter descriptions, making it complete for a simple 2-parameter getter.

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's Args section is essential. It provides meaning: market_id as 'Optional market filter' and days as 'Lookback window in days (default 90).' This compensates for the lack of schema descriptions, though a bit more detail on market_id format could elevate it.

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 'Daily validation history of Level 2 structure predictions' and defines Level 2 as 'ETF / basket / sector granularity.' It specifies hit_rate per day, distinguishing it from sibling tools like get_monthly_accuracy_trend and get_structure_calibration.

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 provides usage context: 'When to call: after get_structure_calibration' and 'Next steps: get_monthly_accuracy_trend for the macro-level comparison.' It also includes trigger phrases for casual questions, guiding when to use the tool versus alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context beyond annotations, including the 14-day lookback, 15-minute bars, and the anchoring behavior when symbol is set. This is useful but not extremely deep, missing details like pagination or output structure.

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

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

The description is well-organized into labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer) and is front-loaded with the core purpose. It is concise with no filler or repetition.

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

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

Given the output schema exists, return-value documentation is not required. The description covers enough context for correct tool selection and invocation: triggers, use case, parameters, caveats, and next steps. The tool is relatively simple, and the description addresses that complexity fully.

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 Args section adds meaning beyond the bare schema by explaining market_id options, the optional symbol's anchoring effect, and top_k as the number of links. With schema description coverage at 0%, this compensation is valuable, though it does not specify constraints like valid ranges for top_k.

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 and resource: 'Symbol-level lead-lag links' with concrete examples like 'META -> AMZN, lag=15m, rho=+0.53'. It clarifies behavior when symbol is set, distinguishing it from other get_* sibling tools by focusing on peer lead-lag relationships.

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 explicit triggers, a 'When to call' statement, prerequisites, and a next-step suggestion (get_signal_detail). It does not explicitly mention when not to use this tool or name sibling alternatives, so it stops short of a perfect 5.

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

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

Beyond the readOnly=true annotation, it adds key behavioral caveats: 'paper-trading data only (not real money)' and 'limit capped at 1000'. This gives important context about data scope and constraints without contradicting 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 well-organized with clear sections (Purpose, Triggers, When to call, Args, Caveats) and is front-loaded with the core purpose. Slightly verbose due to the extensive list of example triggers, but every section 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 7-parameter schema, presence of an output schema, and many sibling tools, this description covers purpose, usage triggers, prerequisites, next steps, parameter semantics, and caveats. It is sufficiently complete without needing to restate output structure since an output schema exists.

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 compensates fully by explaining every parameter in plain language. It adds meaning for market_id (aliases), min_pnl/max_pnl (percentage), symbol (case-insensitive), and action_filter (allowed values), going well 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 'Query paper-trading history with dynamic filters (action / P&L / time / symbol)', using a specific verb and resource. It distinguishes from siblings like get_winning_trades and get_losing_trades by framing this as the general history query with filters.

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 'When to call' scenarios (past trade review, single-symbol post-mortem, win-rate audits) and example user triggers. Does not explicitly mention when not to use or contrast with specific alternatives, which prevents a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, and the description adds important non-obvious behavior: the linkage is best-effort temporal matching, not a foreign key; paper trading only; a standard disclaimer per page; and pagination requires following next_cursor until has_more=false. 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 structured with clear labels (Purpose, Triggers, When to call, etc.) and stays on-topic, but the detailed 'Output:' block overlaps with the existing output schema, adding length. Still, every section contributes operational guidance, so the redundancy is mild.

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 paginated bulk export with temporal-linkage caveats, the description covers purpose, triggers, parameter limits, pagination mechanics, linkage fidelity, disclaimer behavior, and a next-step cross-check. Output schema exists, but the description still provides enough context for safe offline 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 0%, so the description must carry parameter semantics. The Args section explains market values, cursor semantics as 'last trade id from previous page (0 = start)', limit max 500, and days as exit-time window max 120 — going well beyond the bare schema 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 opens with a specific verb phrase 'Cursor-paginated bulk export of the prediction -> trade -> outcome chain' and names paper trades with realized P&L, making it distinct from siblings like get_trade_history and get_resolved_predictions. It explicitly says it is for pipeline consumers, not conversational snippets.

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 provides explicit trigger phrases, a 'When to call' list (offline verification, periodic ingestion, auditing), and a direct alternative for the prediction ledger via get_resolved_predictions. It also excludes conversational use by saying 'not conversational snippets.'

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 annotations already declaring readOnlyHint, openWorldHint, and idempotentHint, the description adds context beyond them: the wrapper behavior (min_pnl=0.01), the caveat 'paper-trading data only', and a disclaimer. It does not contradict annotations and provides useful additional behavioral context, though it omits details like pagination which are likely covered by the output 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 well-structured with clear labels (Purpose, Triggers, When to call, etc.) and front-loaded with the core purpose. Each section earns its place, though the extensive trigger examples and disclaimer could be seen as slightly verbose. Overall, efficient and scannable.

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 purpose, usage scenarios, prerequisites (none), next steps, caveats, parameter semantics, and limitations. Combined with the annotations and output schema, it is fully complete for this simple 2-parameter 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%, but the description compensates fully: it explains market_id values ('crypto, kr_stock, us_stock; aliases coin/kr/us accepted') and limit's meaning ('Max results (default 10)'). This adds significant meaning beyond the bare 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 starts with a specific verb and resource: 'Winning paper trades only (P&L > 0)' and further clarifies it is a wrapper around get_trade_history(min_pnl=0.01). This clearly distinguishes it from siblings like get_losing_trades and get_trade_history.

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

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

Provides explicit triggers ('what worked?', 'show me the winners'), when to call ('success-pattern review'), and next steps ('analyze_trades for breakdowns'). It also identifies it as a wrapper around get_trade_history, implying when to use the alternative.

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

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

Beyond annotations (readOnly, openWorld, idempotent), the description discloses critical behavior: corpus rebuilds every 10 minutes, empty results mean no match, and the output envelope shape. It also clarifies caveats and prerequisites, adding substantial value for an agent.

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

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

The description is well-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Output, Args, Disclaimer). Every sentence provides relevant information, and the purpose is front-loaded.

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 central role in discovery, the description covers purpose, trigger conditions, alternatives, prerequisites, next steps, caveats, output shape, and parameter semantics. It is fully complete for an agent to decide when and how to call it.

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 zero description coverage, but the description compensates by explaining that `query` is a free-text search string supporting English/Korean and symbols like BTC/AAPL. This provides meaningful context beyond the bare schema type, though it could be slightly more detailed about expected length or formatting.

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 discovery search over OneQAZ's live surface for tools, resources, and signals, and explicitly differentiates from siblings by saying it returns result ids consumable by the `fetch` tool. This is a specific verb+resource with clear scope.

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 explicit when-to-use guidance: it is the first step of connector-style discovery, automatically triggered by ChatGPT connectors, and suggests alternative approaches like browsing tools/list plus resources/list for MCP-native clients. It also names `fetch` as the next step, giving clear alternatives.

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