OneQAZ Trading Intelligence

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

Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds value by stating caveats (max 30 days, empty result if no trades) and the aggregation behavior. 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?

Description is well-structured with sections but somewhat verbose (includes example triggers and next steps). Could be more concise, but still clear and 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?

With only 2 parameters and an output schema present, the description covers usage context, prerequisites, caveats, and next steps adequately. The note about empty results is useful.

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

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

Schema coverage is 0%, so description must explain parameters. It describes market_id with accepted aliases and days with default and max, adding meaning beyond the input 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?

Description explicitly states 'Aggregate paper trades by day / pattern / symbol', providing a specific verb and resource. It clearly distinguishes from siblings like get_trade_history (raw rows) and get_daily_brief, ensuring the agent understands its unique function.

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

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

Triggers are shown as casual questions, and 'When to call' specifies pattern audits and performance reviews. Prerequisites (get_trade_history) and next steps (signals/feedback) are included. Does not explicitly exclude alternative tools, but the guidance is strong enough for correct invocation.

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's burden is lower. The description adds valuable context: it states the output is research evidence, not a recommendation, and the symbol must be lowercase to match signal store filenames. This goes beyond annotations but does not delve deeply into internal behavior.

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

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

The description is well-structured with clear sections (Purpose, triggers, when to call, prerequisites, next steps, caveats, args) and is front-loaded with the core purpose. However, it includes multiple example trigger questions which, while helpful, add verbosity. Overall, it earns its length but could be slightly tighter.

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 (multi-layer explanation combining several data sources), the description is comprehensive. It covers what the tool does, when to use it, prerequisites, caveats, and parameter details. Since an output schema exists, return values are already documented, so the description need not cover them.

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

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

The input schema has no descriptions for its two required parameters (0% coverage). The description compensates by explaining market_id with aliases (crypto, kr_stock, us_stock; coin/kr/us) and symbol as a lowercase string. This adds essential semantics that the schema lacks.

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: providing a multi-layer explanation for a single symbol's recent research signal. It explicitly distinguishes itself from siblings by mentioning it combines technical score_trace, Thompson and regime scores, and news causality context, which is not covered by other tools like get_signal_detail or get_signals.

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

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

The description provides explicit when-to-use guidance: when the user asks 'why is this signal bullish/bearish?' and gives example triggers. It also lists prerequisites (identify symbol via get_signals or get_latest_decisions first) and states that no next steps are needed, making it clear how to integrate into a workflow.

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, openWorld, and idempotent. The description adds caveats like uncovered resource URIs return description-only text and that text is a JSON document for resource/signal ids, providing useful behavioral context beyond annotations.

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

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

The description is relatively lengthy but well-structured with labeled sections (Purpose, Namespaces, Triggers, etc.). It is front-loaded with the main purpose and earns its place, though minor trimming could improve conciseness.

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 namespaces, output schema exists), the description covers purpose, usage, caveats, and output shape. It also mentions next steps and disclaimer, making it complete and self-contained.

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?

With one parameter (id) and 0% schema description coverage, the description compensates by explaining the id can be 'tool:{name}', 'resource:{uri}', or 'signal:{market}:{symbol}', adding significant meaning beyond the schema's 'string' type.

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 fetches documents by id from search results, with specific namespaces (tool:, resource:, signal:). It distinguishes itself from sibling tools like search (which returns ids) by clarifying it retrieves full content.

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 specifies when to call ('whenever full content behind a search result id is needed'), triggers (after search), and prerequisites (valid id). It lacks explicit exclusions but provides clear 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 indicate readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds the caveat 'returns most recent first' and a disclaimer, providing useful behavioral context beyond what annotations cover.

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, etc.) and is front-loaded with purpose. While it is somewhat verbose, every sentence adds value, so it earns a 4.

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

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

The tool has an output schema (not shown), so returning values need not be detailed here. The description covers filtering, ordering, caveats, and prerequisites. For a simple retrieval tool, it provides complete context for an agent to use 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 description explains each parameter: target_market as an optional filter with example values (coin_market, kr_market, us_market) and limit as max predictions with default 20. This adds significant meaning beyond the input schema, especially given 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 explicitly states 'Purpose: Currently pending predictions (outcome IS NULL)' and explains that the tool shows active forecasts in real time. It clearly distinguishes from siblings like get_prediction_accuracy by focusing on pending 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?

The description includes a 'When to call' section (to verify ongoing prediction activity), lists triggers for casual questions, states no prerequisites, and suggests next steps (get_prediction_accuracy). This provides excellent guidance on when and how to use the tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds value with a disclaimer ('Information only, not investment advice') and a caveat about the `last_backtest` timestamp indicating tuning freshness. No contradictions.

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

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

The description is well-structured with clear sections (Purpose, Triggers, When to call, etc.) and front-loaded with the core purpose. While slightly verbose, every sentence adds value. Could be shortened slightly but still effective.

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

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

Given the tool's simplicity (2 optional params, no required fields, no enums) and the presence of an output schema, the description covers purpose, usage triggers, prerequisites, next steps, caveats, and parameter semantics comprehensively. Nothing essential 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 description explains each parameter as 'Optional category filter' and 'Optional target market filter', providing context beyond the minimal schema (which only has names and defaults). Despite 0% schema coverage, the description compensates adequately.

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 parameters. This distinguishes it from siblings like get_prediction_accuracy or get_monthly_accuracy_trend, which focus on performance rather than calibration 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?

Explicit guidance is provided: 'When to call: after get_prediction_accuracy, to show the system updates itself.' It also lists triggers (e.g., 'does the system self-correct?'), prerequisites, and next steps, helping the agent choose correctly among siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds a caveat: 'correlation data may be empty until enough regime changes accumulate,' which provides behavioral context beyond annotations.

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

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

The description is well-structured with sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). It is concise, front-loaded, and every sentence adds value.

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

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

Given the tool has only 2 optional parameters and an output schema (indicated), the description covers purpose, usage, caveats, and next steps. It is complete for the complexity level.

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; the description only lists parameters as 'Optional source market filter' etc. While parameter names are self-explanatory, the description adds minimal additional meaning beyond the schema, not compensating 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 defines the tool's purpose: 'Cross-market lead-lag relationships and decoupling events.' It distinguishes from siblings like get_macro_causality_graph_tool and get_macro_influence_map by specifying it shows correlations and decoupling, and suggests next steps for causal hypotheses.

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

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

Explicitly says 'When to call: when analyzing macro regime changes or divergent signals.' Provides example triggers in both English and Korean, and suggests next steps. Lacks explicit when-not-to-use, but context is clear.

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

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

Annotations indicate readOnly, openWorld, idempotent. Description adds caveats: 24-hour window, paper-trading only, and provides output structure. No contradiction.

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

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

Well-structured with sections: Purpose, triggers, when to call, prerequisites, next steps, caveats, output, args, disclaimer. Every sentence adds value, front-loaded with 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 simplicity (1 optional param) and presence of output schema, the description fully covers all aspects: purpose, usage, parameters, behavior, and disclaimers.

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?

Single parameter 'market' with default 'all' is explained in description with allowed values and meaning. Schema has no enums, so description fully compensates.

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 'Single-call market overview' and lists components (macro regime, strong signals, paper-trading outcomes, etc.). It distinguishes from siblings by positioning as the first call and mentions deep-dive 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?

Extensive guidance on when to call: morning briefings, specific queries like 'how's the market?', and triggers list example questions. Also states prerequisites none and suggests next steps.

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 the lifecycle (OBSERVATION -> CONDITIONAL -> ACTIVE or DEPRECATED) and the statistical validation context, adding significant value beyond annotations (readOnlyHint, openWorldHint, idempotentHint). It explains what the tool proves and includes a caveat about emptiness. No contradictions.

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

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

The description is well-structured with clear sections (Purpose, Lifecycle, Triggers, etc.) and front-loaded with the core purpose. While slightly verbose, each section serves a purpose and there is no redundant wasted text.

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

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

The description covers purpose, behavior, parameters, caveats, and triggers comprehensively. Given the presence of an output schema (so return values need not be described), this is complete for a tool with 3 optional parameters and a complex lifecycle.

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?

With 0% schema description coverage, the description compensates fully: it documents market_id with default 'coin', explains target_market as an alias, and lists possible values for status_filter. This provides meaning beyond the bare schema, enabling correct parameter usage.

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

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

The purpose is clearly stated: 'Current lifecycle state of external features (news, events) under 3-track statistical validation.' It describes what the tool returns (lifecycle states) and the resource (features). However, it does not explicitly differentiate from the sibling tool 'get_feature_governance_status_tool', leaving potential ambiguity.

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?

Usage guidelines are explicit: 'When to call: meta-level trust audit' and lists example triggers. It provides context for when to use the tool. However, it does not specify when not to use or name alternatives. The caveat about emptiness when not yet run is helpful.

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 convey read-only, open-world, and idempotent hints. Description adds a caveat about the promoter cycle running hourly, which is valuable behavioral context beyond annotations. No contradictions.

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

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

Well-structured with clear sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Disclaimer). Each sentence is informative and not redundant. Front-loaded with the most critical 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 no parameters and presence of an output schema (not shown but indicated), the description adequately covers the tool's purpose, usage, behavioral notes, and next steps. It provides enough context 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?

No parameters (0), so schema coverage is 100%. Description adds value by explaining the output content (distribution and transitions), which goes beyond the empty schema. Baseline 3, raised to 4 for added context.

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 provides a snapshot of feature governance status distribution (OBSERVATION/CONDITIONAL/ACTIVE/DEPRECATED) plus 7-day transitions. Differentiates from sibling tool get_feature_governance_state by specifying it gives a distribution overview, not per-feature 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?

Explicitly describes when to use (trust evaluation, 'which features are live?'), provides trigger questions, lists prerequisites (none), and suggests next steps (use get_feature_governance_state for full detail).

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 define read/write safety (readOnlyHint, idempotentHint). Description adds critical context: 'paper-trading decisions only — no real-money order routing', plus disclaimer. Doesn't contradict annotations.

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

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

Well-structured with sections (Purpose, Triggers, When to call, etc.), but includes some extraneous content like trigger phrases. Slightly verbose but front-loaded with essential info.

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 aspects: purpose, usage, parameters, prerequisites, caveats, and next steps. Output schema exists to handle return values. Complete for a read-only tool with robust annotations.

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 description fully explains all 4 parameters: market_id with aliases, limit default, decision_filter options, hours_back meaning. Provides clarity beyond schema structure.

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 explicitly states 'Track-B (signal-driven) paper-trading decision log' and distinguishes from Track A (get_llm_trading_decisions). Provides trigger phrases and clear verb-resource pairing.

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

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

Explicitly states when to call ('review recent automated decisions'), prerequisites ('market://{market_id}/status'), and next steps (get_trade_history, get_signals). Differentiates from sibling tool via Track A/B distinction.

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

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

Annotations already cover readonly and idempotent hints. Description adds specific behavioral context: chain inception date, daily UTC computation, append-only nature, and verification hint—adding value beyond annotations.

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

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

Well-structured with labeled sections; front-loaded purpose. Slightly verbose (disclaimer may be unnecessary) but clear and organized.

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

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

Completely covers purpose, usage, caveats, parameter, and output fields. Feels thorough despite the tool's complexity.

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

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

Only one parameter 'days' with a default. Description explains its purpose (number of recent entries) and max limit (400), compensating for the 0% schema 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?

Description clearly states the tool is for tamper-evidence using SHA-256 hash chain, distinguishing it from sibling tools by focusing on integrity verification.

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, when to call (first step of audit, periodically), prerequisites, and next steps, guiding the agent on proper invocation.

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

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

Annotations already indicate readOnlyHint and idempotentHint. The description adds meaningful context beyond annotations: explains the tool's role in a two-track system (Track A vs Track B), notes the data is paper-trading only and applied as a capped bias. 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?

Description is well-structured with labeled sections (Purpose, Triggers, When to call, etc.), front-loaded with purpose. Every sentence adds value, though slightly verbose. Good balance.

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 existence of an output schema and the simplicity of the tool (2 parameters), the description covers the essential context: the two-track system, paper-trading nature, and how to use the parameters. No major gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It provides examples of valid market_id values and explains symbol is optional, but does not list all possible values exhaustively nor give detailed formatting rules. Adequate but not detailed.

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

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

The description explicitly states the tool retrieves the LLM-driven paper-trading judgement log (Track A), with a clear verb 'get' and resource 'LLM trading decisions'. It distinguishes from the sibling tool get_latest_decisions by contrasting Track A vs Track B.

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 ('inspect LLM-generated reasoning and trade calls'), triggers (casual questions), prerequisites (none), and next steps (compare with Track B via get_latest_decisions). It also includes caveats (paper-trading only), offering comprehensive guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds caveat about paper-trading data only and disclaimer. No contradiction.

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

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

Well-structured with purpose, triggers, usage, prerequisites, next steps, caveats, and parameter descriptions. Concise and 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 simple 2-parameter tool with output schema and rich annotations, description covers all necessary context: purpose, usage, parameters, and caveats.

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 0%, but description explains market_id with aliases (coin/kr/us accepted) and limit default. Adds meaningful info beyond schema.

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

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

Clearly states it returns losing paper positions (ROI < 0) and is a convenience wrapper around get_positions. Distinguishes from siblings like get_profitable_positions and get_positions.

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 (drawdown/risk review), prerequisites (none), and next steps. Lacks explicit when-not-to-use, but context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's disclosure of being a read-only wrapper is consistent and adds context (paper trading only, filter behavior). No contradictions; description enriches understanding.

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, usage, arguments) and front-loaded with key info. It could be slightly more concise, but every sentence contributes value.

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

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

Given the tool's simplicity (2 params, wrapper) and existence of output schema, the description covers all necessary aspects: purpose, usage, parameters, limitations, and next steps. It is complete for effective tool 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?

With 0% schema description coverage, the description fully compensates by explaining both parameters: market_id with accepted values and aliases, limit with default. This adds critical meaning beyond the schema's type/default.

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 retrieves losing paper trades with P&L < 0, and explicitly distinguishes itself as a wrapper around get_trade_history with a specific filter, differentiating it from siblings like get_winning_trades or 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 triggers in Korean and English, specifies when to call ('failure-pattern review'), prerequisites ('none'), next steps ('analyze_trades for breakdowns'), and caveats ('paper-trading data only'). Also mentions the alternative get_trade_history with parameter for broader usage.

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

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

Beyond the annotations (readOnly, openWorld, idempotent), the description adds caveats: Pearson-based, requires >=30 samples, p<0.05 filter, and that it returns only significant pairs. This fully discloses the statistical behavior.

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

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

The description is well-structured with clear sections (Purpose, triggers, When to call, Caveats, Args) and no superfluous information. Every sentence adds value.

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

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

Given the presence of an output schema, the description covers all relevant aspects: purpose, usage context, prerequisites, next steps, caveats, and parameter details. It is complete for this tool's complexity.

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

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

The description includes an 'Args' section that explains both parameters with defaults and brief meanings, compensating for the 0% schema coverage. However, it lacks examples or ranges.

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

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

The description clearly states it returns a lag-aware causal graph of macro categories, listing specific examples and distinguishing from the sibling tool get_macro_influence_map via the 'Next steps' section.

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' and 'Prerequisites: none' provide clear context. However, it does not state when not to use this tool or mention alternatives other than a next step.

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

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds value by describing it as 'highest-transparency tool' and noting that the causal reasoning is visible and measurable, plus clarifying that it's a static hypothesis. No contradictions.

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

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

The description is well-structured with headings (Purpose, Triggers, When to call, etc.), making it easy to scan. It is slightly lengthy but efficient, with every sentence providing useful information.

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

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

Given the output schema existence, the description does not need to explain return values. It covers purpose, usage, parameters, caveats, and prerequisites. For a read-only, low-complexity tool, the description is complete.

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

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

Despite 0% schema description coverage, the tool description explicitly lists the parameter market_id with three filter values (coin_market, kr_market, us_market), which the schema lacks. 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 clearly states the tool exposes a causal hypothesis map, listing specific macro categories and mapping details. It distinguishes itself from siblings by focusing on causal reasoning, as evidenced by trigger questions like 'how do rates affect crypto?'.

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

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

The description explicitly states when to call ('when an AI wants to understand WHY we make certain predictions'), provides trigger examples, and suggests a next step tool (get_backtest_tuning_state). It also includes caveats about static hypotheses.

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, idempotentHint. The description adds specific behavioral constraints: excludes the 'all' month aggregate and empty when backtest_results is unpopulated. No contradiction.

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

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

Well-structured with labeled sections (Purpose, Triggers, When to call, etc.), front-loading the purpose. Every sentence adds value, though slightly verbose in triggers list.

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

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

Given an output schema exists, the description covers the input purpose, triggers, prerequisites, caveats, and high-level output (time series). It is complete for understanding what the tool does and when to use 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%, but the description adds basic meaning for both parameters: 'Optional category filter' and 'Optional target market filter'. While not exhaustive, it compensates partially 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 explicitly states the purpose: 'Monthly accuracy time series per (category, target_market, lag_bucket).' It distinguishes itself from siblings by noting its place in the trust chain and providing triggers like casual question examples.

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?

Clearly states when to call (after get_prediction_accuracy and get_backtest_tuning_state), provides triggers, prerequisites, next steps, and explicit when-not-to-use via caveats. This is model guidance.

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

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

Annotations already indicate read-only, idempotent, and open-world. The description adds behavioral context such as the classification logic and the caveat 'window limited to recent days.' It does not contradict annotations.

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

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

The description is well-structured with labeled sections (Purpose, Triggers, When to call, etc.). It is appropriately detailed without being verbose, though the trigger questions add some extra length.

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

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

Given the tool has 2 simple parameters, annotations covering safety, and an output schema, the description covers key aspects: purpose, classification details, usage context, prerequisites, and caveats. It is sufficiently complete.

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

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

Schema coverage is 0%, so the description must compensate. It provides minimal semantics: 'days: Lookback window in days (default 7)' and 'market_id: Market identifier'. This adds some meaning but does not explain valid values or ranges.

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 provides a three-bucket news classification (Anticipated, Surprise with Precursor, Surprise) to systematically discriminate between anticipated and surprise events. It includes specific trigger questions that clarify usage scope and distinguishes itself from sibling tools by referencing get_news_leading_indicator_performance as a prior call.

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

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

The description explicitly states 'When to call: after get_news_leading_indicator_performance' and provides example trigger questions. It does not list explicit when-not-to-call conditions or alternatives, but the context is clear.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds a caveat about empty results when no events processed, which is valuable beyond annotations. No contradictions.

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

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

While well-structured into sections, the description is verbose with promotional language (e.g., 'Strongest Trust Layer A evidence', casual questions). Some sentences could be trimmed for conciseness.

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, parameters, caveats, usage guidelines, and next steps. With an output schema existing, the description need not detail return format further. Complete for a tool with 3 optional parameters.

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

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

Schema coverage is 0%, but the description includes an 'Args:' section explaining each parameter (market_id, target_market, min_sample_count) with purpose and defaults. This adds significant meaning beyond the minimal schema.

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

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

The description explicitly states the tool's purpose: it returns leading_score, avg_lead_time_minutes, and accuracy_pct per event type, and positions it as evidence of anticipatory capability. It also distinguishes from siblings by mentioning get_news_causality_breakdown 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?

Clear 'When to call' section states 'when an AI is evaluating predictive capability'. Provides example triggers/questions and prerequisites ('none'). Includes next steps, giving explicit guidance on usage.

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

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

Annotations already indicate readOnly and idempotent. The description adds critical context: it uses paper-trading data under a synthetic fixed-book capital model, account_type 'live' returns an error until real-money records exist, fixed window ensures reproducibility, and the response includes a capital_model structure. This goes beyond annotations.

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

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

The description is well-structured with clear sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args). It is slightly long but every sentence adds value. Could be marginally more concise, but overall excellent organization.

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

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

Given 5 parameters, no output schema visible (though indicated present), the description covers all aspects: what metrics are returned, parameter details, caveats about synthetic data and account_type, and the fixed-window reproducibility. It is complete for an agent to understand 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?

Though schema description coverage is 0%, the 'Args' section in the description explains each parameter in detail: market aliases (coin/kr/us/all), account_type required, window_start/end with defaults, and include_daily_curve boolean. It also mentions defaults and allowed values, compensating 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 returns portfolio-level performance metrics (MDD, Sharpe, etc.) over a fixed window. It distinguishes from sibling tools by emphasizing it is the canonical computation path for the blog and external clients, which no other sibling tool claims. The verb 'get' and resource 'performance metrics' 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 triggers (casual questions like 'what's the max drawdown?'), when to call (track-record verification, blog cross-checks, risk review), prerequisites (none), and next steps (get_trade_history, analyze_trades). Also includes when not to call: 'live' account returns an error. This is comprehensive guidance.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint. The description adds value by noting the error envelope when no position exists and including a disclaimer. This goes beyond what annotations provide, though it doesn't detail other behavioral traits.

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). Every sentence adds value, and it is concise given the amount of information covered.

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 that an output schema exists (though not displayed), the description need not explain return values. It covers purpose, parameters, prerequisites, caveats, and usage context thoroughly. For a tool with 3 parameters (1 required), this is comprehensive.

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

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

With 0% schema description coverage, the description fully explains the three parameters: market_id with aliases, symbol as asset identifier, and coin as legacy alias. It adds meaning beyond the schema, though it could be slightly more explicit about the market_id enum values (crypto, kr_stock, us_stock) and the relationship between symbol and coin.

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 'per-symbol paper position deep-dive' including position, recent trades, and decisions. It distinguishes from sibling tools by focusing on a single ticker with full context, and includes example triggers that set it apart from other tools like get_positions or get_signal_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 states 'When to call: full context for one ticker' and lists prerequisites ('confirm the symbol holds a position via get_positions') and next steps. While it doesn't list explicit when-not-to-call scenarios, the prerequisites indirectly cover that, making it clear when it's appropriate.

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

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

Annotations (readOnlyHint, idempotentHint, openWorldHint) are present. Description adds behavioral context: paper-trading only (not real money), dynamic filters, triggers. No contradiction. Adds value beyond annotations.

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

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

Well-structured with sections (Purpose, Triggers, When to call, etc.). Some redundancy (e.g., 'paper-trading data only' repeated). Front-loaded and organized, but could be slightly shorter.

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 7 params (1 required), output schema present, annotations present, description covers purpose, usage, parameters, caveats, and next steps. Fully equips agent to use 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 coverage 0% but description fully explains each parameter with examples (e.g., 'Min ROI % filter (e.g., -5.0)') and default values. Compensates completely for 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?

Clearly states it lists current paper-trading positions with dynamic filters (ROI/strategy/sort). Distinguishes from siblings like get_profitable_positions, get_losing_positions, get_position_detail by specifying paper-trading 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 triggers ('what are you holding?', casual questions), when to call (dashboards, drawdown checks), prerequisites (market_id status), and next steps. Lacks explicit exclusions vs. siblings, but context is rich.

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?

Disclosures beyond annotations: mentions empty results when no backtests completed, advises filtering by sample_count and horizon_type, and explains the edge_cells/anti_predictive_cells views. No contradiction with annotations (readOnly, idempotent, openWorld).

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 clear sections (Purpose, Triggers, When to call, etc.) and front-loaded with essential purpose. Slightly verbose 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 tool's complexity and the presence of an output schema, the description covers caveats, filtering guidance, and the significance of edge_cells/anti_predictive_cells. It provides a complete picture for an agent to use 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?

Input schema coverage is 0%, but the description lists and explains the optional filters (category, target_market) with example values, adding meaning beyond the simple string type. However, no detailed parameter descriptions beyond listing.

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 retrieves long-term hit rate per cell with sample count and Wilson 95% CI, distinguishes from siblings by being the primary credibility evaluation tool, and includes triggers for common questions.

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

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

Explicitly says 'AI agents evaluating OneQAZ credibility should call this FIRST', provides prerequisites (none), and lists next steps like get_ledger_integrity. Also includes trigger questions to help decide when to call.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint. Description adds that it uses paper-trading data only and is a convenience wrapper, which are behavioral traits not fully 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 clear headers (Purpose, Triggers, etc.) and front-loaded purpose. Some redundancy in examples, but overall efficient for the information 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?

Given a simple tool with 2 parameters, full annotation coverage, and an output schema, the description covers purpose, usage, parameters, caveats, and next steps comprehensively.

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 schema description coverage being 0%, the description adds meaningful details: market_id aliases (coin/kr/us) and explanation of limit default. While the schema already specifies limit's default, the aliases are valuable.

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 'Profitable paper positions (ROI > 0)' and 'Convenience wrapper around get_positions(min_roi=0.01)', providing a specific verb and resource. Differentiates from sibling tools like get_positions and get_losing_positions.

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 lists triggers, when to call, prerequisites, and next steps. Includes multilingual example queries, making it easy for the AI to decide 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral details: cursor pagination (id-ordered, follow next_cursor), disclaimer about paper research, and output structure. This goes beyond annotations but does not contradict 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, etc.) and front-loaded with the core purpose. While comprehensive, it is somewhat verbose; a slightly more concise version would earn a 5.

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

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

Given the tool has 6 optional parameters, no required ones, and an output schema, the description covers purpose, usage, parameter details, and next steps thoroughly. It lacks only minor details like error handling or performance, but overall is sufficiently complete.

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

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

Schema coverage is 0%, but the description lists all 6 parameters under 'Args:' with brief descriptions and examples (e.g., 'target_market: filter e.g. "coin_market" / "kr_market" / "us_market"'). This compensates well for the lack of schema descriptions, though it could specify valid values more precisely.

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 is a 'raw, row-level prediction ledger' that provides 'every macro regime prediction's full lifecycle.' It explicitly distinguishes itself from sibling tool get_prediction_accuracy by framing itself as the auditable evidence behind its aggregates.

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: 'credibility evaluation (after get_prediction_accuracy), independent backtesting, or archiving.' It also states prerequisites (none), pairs with get_ledger_integrity, and suggests next steps, offering comprehensive guidance.

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

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context: dependence on hierarchy_context, potential empty results due to collector lag, and a disclaimer that it's not investment advice, 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-structured with clear sections (Purpose, Triggers, When to call, etc.). Although somewhat lengthy due to trigger examples, each part adds value and the key information 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?

With annotations and an output schema present, the description covers purpose, usage, prerequisites, caveats, and parameter semantics thoroughly. No gaps remain for an agent to invoke this 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 coverage is 0%, but the description explains all three parameters: market_id lists allowed values, symbol is the preferred identifier, and coin is a legacy alias. This compensates fully 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 clearly states the tool provides 'Role-aware signal alignment per symbol (timing / trend / swing / regime) plus hierarchy alignment', making the specific verb and resource distinct. It differentiates from siblings like 'get_signal_detail' by being a multi-timeframe analysis tool.

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

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

The description includes trigger examples, explicit 'When to call' conditions (multi-timeframe analysis, cross-role agreement checks), prerequisites ('get_signal_detail recommended'), and next steps, giving comprehensive usage guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint all true, indicating safe, idempotent read operation. The description adds valuable behavioral context: 'refreshed every 6 hours; 60-day lookback'. This goes beyond annotations and informs the agent about data freshness and recency.

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, etc.) and is front-loaded with the core purpose. It is somewhat verbose but every sentence adds value. A minor reduction for length, but overall efficient for the information conveyed.

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

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

Given the tool has an output schema (not shown but indicated), the description does not need to explain return values. It covers purpose, usage, parameters, caveats, and disclaimer. It also provides next steps, making it complete for an agent to understand and use 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?

Although schema description coverage is 0%, the description explicitly lists the two parameters with brief explanations: market_id values (coin / kr_stock / us_stock) and top_k as 'Number of top pairs to return'. This adds meaning beyond the schema's type and default, compensating for the lack of schema descriptions. Could be slightly more detailed but is sufficient.

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 that the tool quantifies intra-market ETF/group correlation matrix and auto-cluster output, using specific verb 'quantifies' and resource 'correlation matrix'. It distinguishes from siblings like 'get_cross_market_correlation' (cross-market vs intra-market) and mentions 'get_symbol_peer_links_tool' as a next step, showing awareness of 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?

Provides explicit triggers (example questions), when to call (portfolio diversification or sector concentration audits), prerequisites (none), and next steps. It also includes a disclaimer. Though it doesn't explicitly state when not to use, the context is clear and sufficient for an agent to decide.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds valuable context: snapshot is daily, observation window ~2 weeks, n is nominal with correlated trials caveat. No contradictions. Could further detail idempotency behavior but adequately supplements 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?

Description is lengthy but well-structured with sections (Purpose, Triggers, When to call, etc.) and front-loads key purpose. Could trim some trigger examples, but overall efficient for the complexity.

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

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

Given output schema exists (not shown), description covers purpose, usage, caveats, and parameter semantics sufficiently. Provides necessary context for an agent to decide and invoke the tool correctly. Small gaps in parameter descriptions prevent a perfect score.

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

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

Schema coverage is 0%, so description must compensate. It explains variant parameter well ('v1' raw heuristic vs 'v2' outcome-based shadow confidence) but market_id and interval only briefly mentioned as optional filters without format details. Additional clarity on allowed values or defaults would improve.

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

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

Description clearly states it provides reliability diagram data for Level-1 signal confidence with realized hit rate per bucket and ECE summary. It uses specific verbs ('verify', 'trust') and resource ('signal confidence calibration'), distinguishing it from sibling tools like get_signals which provide raw signals.

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

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

Explicitly states when to call ('before trusting get_signals confidence values as probabilities'), prerequisites ('none'), and next steps ('get_prediction_accuracy, get_signals'). This guides the agent on appropriate context 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?

Annotations already provide readOnly, openWorld, and idempotent hints. The description adds that it queries both the per-symbol signal store and paper-trading store, which is valuable beyond annotations. No contradictions.

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

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

The description is well-structured with labeled sections (Purpose, Triggers, When to call, etc.) and front-loaded with the most important information. Every sentence adds value, and the trigger examples are practical.

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

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

Given the tool has 4 parameters and an output schema, the description covers purpose, usage, prerequisites, next steps, and caveats. It provides sufficient context for an AI agent to decide when and how to 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter: market_id (with examples), symbol (preferred), coin (legacy alias), interval (default 'combined'). This adds meaning the schema lacks.

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 does a 'per-symbol signal deep-dive' providing 'latest signal + history + feedback', and provides example trigger questions. It distinguishes from sibling get_signals by focusing on a single ticker.

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

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

Explicitly states when to call ('drilling into a single ticker's signal context'), prerequisites ('confirm existence via get_signals first'), and next steps (get_role_analysis, get_position_detail), offering clear guidance on 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 indicate readOnly, openWorld, and idempotent. The description adds: returns signal+score (not an order/advice) with disclaimer, and performance caveats when symbol omitted. These complement annotations without contradiction.

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

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

The description is somewhat long but well-structured: starts with purpose, then triggers, usage, prerequisites, next steps, caveats, args list, disclaimer. It is front-loaded and each sentence adds value, though could be slightly more concise.

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

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

Given 9 parameters and an output schema, the description covers: what it does, when to use, what it returns (signal+score), caveats (performance), next steps, and a disclaimer. It is complete for correct tool 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?

With schema description coverage at 0%, the description fully documents all 9 parameters: market_id, symbol, coin (alias), interval, action_filter, min_score, min_confidence, limit, hours_back. It explains defaults, aliases, and behavioral implications (e.g., scanning all DBs when symbol omitted).

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: 'Query research signals with dynamic filters' and lists specific filters (symbol, interval, action, score, confidence). It distinguishes from siblings by mentioning pairing with get_latest_decisions and next steps to get_signal_detail and get_role_analysis.

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: 'drilling into a specific signal slice; symbol-by-symbol scanning; any should I trade X? question'. It lists trigger phrases and prerequisites (market://{market_id}/signals/summary) and mentions alternatives (pair with get_latest_decisions).

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 provide readOnlyHint, openWorldHint, idempotentHint. Description adds caveat about empty distribution when no positions are open, which is helpful but not extensive. No contradiction.

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

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

Well-structured with headings but includes some extraneous content like example triggers. Still front-loaded with purpose and concise overall.

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

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

Given the presence of an output schema, the description covers purpose, usage, parameters, caveats, and next steps. Sufficient for the tool's complexity.

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

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

Input schema has one parameter with no description (0% coverage). Description adds explicit aliases and acceptable values (crypto, kr_stock, us_stock; aliases coin/kr/us accepted), greatly enhancing understanding.

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 per-strategy breakdown of current paper positions with count, avg P&L, and win rate. This distinguishes it from siblings like get_strategy_leaderboard (likely summary-level) and get_positions (raw rows).

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 mentions when to call (diversification audit, per-strategy performance check), prerequisites (get_positions recommended), and next steps. Does not explicitly state when not to call, but context is clear enough.

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

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

The description adds behavioral context beyond annotations, noting that global pool may include synthesized win_rate values and strategies are paper-tested. This supplements the readOnlyHint and idempotentHint annotations effectively.

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, etc.) and front-loads key information. It is slightly lengthy but every section adds value, so a high score is warranted.

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 (6 parameters, output schema present), the description covers purpose, usage, caveats, parameters, and even example triggers. It is complete for an agent to invoke correctly.

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

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

Despite the schema description coverage being 0%, the description includes an 'Args' section that explains all 6 parameters with their purpose, defaults, and aliases, adding significant meaning beyond the raw schema.

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

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

The description clearly states the tool returns top RL-learned research strategies from both global and per-symbol pools, specifying it's for trust-validation and Layer E evidence. It distinguishes from siblings like get_strategy_distribution by focusing on leaderboard and trust auditing.

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

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

The description explicitly says 'When to call: final trust-validation step' and lists triggers and prerequisites. However, it does not provide comparisons to sibling tools or exclusions for when not to use, leaving some ambiguity.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds that results depend on completed structure-learning cycles and that it returns aggregated metrics, providing useful context beyond annotations without contradiction.

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

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

The description is front-loaded with purpose, but includes extraneous details (triggers in multiple languages, value claims). It could be streamlined 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?

Given the output schema exists and annotations cover safety, the description covers purpose, parameters, usage context, prerequisites, caveats, and next steps. It is fully adequate for an AI agent to understand 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?

With 0% schema description coverage, the description compensates by explaining market_id (market filter like crypto, kr_stock, us_stock) and group_name (group/sector filter like layer1, defi). This adds clarity that the schema alone does not provide.

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 provides prediction calibration at the sector level (Level 2) returning hit_rate_ema with sample counts. It uses specific verb+resource and mentions the hierarchical context (Level 1 vs Level 2), but the jargon and layered terminology may blur immediate comprehension.

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 'when an AI wants to see Layer D evidence' and provides trigger questions. While it does not explicitly say when not to use, it suggests get_structure_validation_history as a next step for daily trend, offering some alternative guidance.

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

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

Description adds behavioral context beyond annotations (e.g., returns overall_hit_rate summary across window, disclaimer about investment advice). Annotations already cover readonly, open world, idempotent, so description doesn't need to repeat those but adds useful caveats.

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 clear headings, concise sentences, and front-loaded purpose. Every section adds value without redundancy.

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

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

Given the presence of output schema (not shown) and only two optional params, the description covers purpose, usage, parameters, and caveats comprehensively. Some minor detail about the overall_hit_rate summary could be beneficial but likely covered by output schema.

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

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

With 0% schema description coverage, the description adds meaning for both parameters (market_id as optional filter, days as lookback window with default). However, it does not elaborate on possible values or format, which would be helpful for more precise usage.

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

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

Description clearly states verb (get validation history) and resource (Level 2 structure predictions) with specific detail on granularity and what each row shows. It distinguishes from sibling get_structure_calibration by positioning this as a daily validation 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?

Explicitly provides triggers (casual questions), when to call (after get_structure_calibration), prerequisites (none), and next steps (get_monthly_accuracy_trend). This gives clear guidance on when and how 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, idempotentHint. The description adds useful behavioral context (14-day lookback, 15-minute bars, disclaimer) 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-structured with labeled sections (Purpose, Triggers, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Every sentence 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 an output schema exists, the description covers purpose, usage, caveats, and next steps sufficiently. No major gaps for a tool of moderate complexity.

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

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

Schema coverage is 0%, so the description must compensate. It lists the three parameters with brief explanations (e.g., market_id: coin/kr_stock/us_stock) but does not detail top_k range or symbol format.

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 symbol-level lead-lag links with an example (META -> AMZN). It is distinct from sibling tools which cover trades, predictions, correlations, etc.

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

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

The description explicitly says when to call ('incorporate peer leading signals into single-symbol reasoning') and provides trigger examples. It does not explicitly contrast with siblings but the context is clear.

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

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

Annotations already indicate readOnlyHint true; the description adds valuable context beyond that by clarifying paper-trading data only, limit capped at 1000, and a disclaimer. 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 headers (Purpose, Triggers, When to call, Args, etc.), front-loaded with purpose, and every section provides essential 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?

Given the tool's complexity (7 parameters, dynamic filters), the description covers purpose, usage, all parameters with semantics, caveats, and next steps. Since output schema exists, return value details are not needed.

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 burden. It provides detailed explanations for all 7 parameters, including aliases, defaults, and valid values (e.g., action_filter: all/buy/sell), adding 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 explicitly states 'Query paper-trading history with dynamic filters,' uses a specific verb-resource combination, and distinguishes from sibling tools like analyze_trades by focusing on data retrieval and paper-trading 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 scenarios ('past trade review, single-symbol post-mortem, win-rate audits'), lists triggers, prerequisites ('none'), next steps (analyze_trades), and caveats (paper-trading only, limit capped).

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 context about temporal linkage instead of foreign key, paper trading only, and a disclaimer. This adds value beyond annotations.

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

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

Description is well-structured with clear sections (Purpose, Triggers, etc.) and front-loaded with purpose. While comprehensive, it could be slightly more concise without losing vital 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 (cursor-paginated bulk export), the description covers all necessary aspects: triggers, usage, parameters, output structure, caveats, and next steps. An output schema exists, but the description adds context for pipeline consumers.

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 lists all 4 parameters with explanations and allowed values (e.g., market enum, max for limit and days). This adds significant meaning beyond the schema's 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 clearly states the tool's purpose as 'Cursor-paginated bulk export of the prediction -> trade -> outcome chain' and specifies it is for 'pipeline consumers who need offline backtesting data, not conversational snippets'. It distinguishes itself 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?

Explicit triggers, when-to-call conditions, prerequisites, and next steps are provided. It mentions alternative tools (get_resolved_predictions) and caveats about usage. The description tells the agent 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, idempotentHint. Description adds that data is paper-trading only and includes a disclaimer. It does not contradict annotations and adds useful context, though could mention more about data freshness or limitations.

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

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

Well-organized with labeled sections, but somewhat verbose for the purpose. Could be trimmed slightly 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?

Given the presence of an output schema and clear annotations, the description sufficiently explains the tool's purpose, parameters, and usage context. It covers triggers, prerequisites, and next steps.

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 for properties, but the description explains market_id's aliases (coin, kr, us) and clarifies limit's default. 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?

Clearly states the tool returns winning paper trades (P&L > 0), explicitly names it as a convenience wrapper around get_trade_history with min_pnl=0.01, and distinguishes it from sibling tools 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), prerequisites (none), and next steps (analyze_trades). This guides the agent on appropriate usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds valuable context: corpus rebuild frequency (10 min), meaning of empty results, and disclaimer about investment 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?

Description is fairly long but well-structured with labeled sections (Purpose, Triggers, When to call, etc.). Each section adds value; no redundant sentences. Front-loaded with 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?

Covers input, output shape (flat envelope with fields), caveats (staleness, empty results), and next steps. Output schema exists but is not fully provided; description references it adequately. Missing details like pagination or rate limits, but overall complete for a search 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 description adds meaning: 'free-text search string (English/Korean, symbols like BTC/AAPL)'. This clarifies language support and provides examples, compensating for the lacking schema description.

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

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

The description clearly states a specific verb ('discovery search') and resource ('OneQAZ's live surface covering crypto/kr_stock/us_stock'). It distinguishes from sibling tools by noting that results are consumable by the `fetch` tool, and the many get_* tools are for retrieving specific data, not general discovery.

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

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

Explicitly says when to call ('first step of connector-style discovery'), notes automatic triggers by ChatGPT connectors and Deep Research, suggests alternatives for MCP-native clients ('browse tools/list + resources/list directly'), and provides next steps ('pass any result id to `fetch`').

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