OneQAZ Trading Intelligence

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

Despite no annotations, the description reveals key behaviors: max 30 days, empty result for no trades, and a disclaimer. This adequately informs the agent of constraints and output 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, When to call, Prerequisites, Next steps, Caveats, Args) and is concise without wasted words.

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

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

Given the presence of an output schema, the description covers usage, constraints, prerequisites, and next steps. It is complete for an analysis tool with two 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?

With 0% schema description coverage, the description adds substantial value: market_id includes alias examples (coin/kr/us), days has default 7 and max 30. This fully compensates for schema gaps.

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

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

The description explicitly states 'Aggregate paper trades by day / pattern / symbol,' which is a specific verb+resource+scope. It distinguishes from siblings like get_trade_history by specifying pattern audits and period-over-period performance review.

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, prerequisites (recommend get_trade_history first), and next steps (market://{market_id}/signals/feedback), giving clear 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?

No annotations exist, so description carries full burden. It explains the tool combines multiple data sources, notes output is research evidence not a recommendation, and includes a caveat about symbol case. However, it does not explicitly state it is read-only, though implied.

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 (Purpose, When to call, etc.). Each sentence is informative, no fluff. Front-loaded with 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 tool complexity and presence of output schema (not shown but indicated), the description covers purpose, usage, prerequisites, caveats, and parameter details comprehensively. No gaps apparent.

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 description adds rich meaning: market_id includes aliases (coin/kr/us) and symbol includes examples and a lowercase constraint. This compensates fully for the lack of schema documentation.

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

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

The description states a specific purpose: 'Multi-layer explanation for a single symbol's recent research signal.' It clearly distinguishes from sibling getter tools by emphasizing a structured 'why' rather than raw data.

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

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

Explicit 'When to call' condition ('when the user asks why is this signal bullish/bearish?') and prerequisites ('identify the symbol via get_signals or get_latest_decisions first'). Next steps are given as 'none'.

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

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

With no annotations provided, the description carries full burden. It discloses that results are sorted most recent first, adds a disclaimer that it's information only, and implies real-time activity. However, it does not mention potential empty results, rate limits, or how the NULL outcome is represented in output despite the output schema.

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

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

The description is well-structured with labeled sections (Purpose, When to call, etc.), but includes promotional language ('Demonstrates that OneQAZ is...') which is not essential for tool usage. The disclaimer at the end could be omitted. The length is adequate but could be 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 the tool's simplicity (0 required params, output schema exists), the description covers purpose, usage, parameters, and caveats. It does not need to explain return values due to output schema. However, it could clarify the meaning of 'outcome IS NULL' for non-technical agents.

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

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

The schema has 0% description coverage, so the description adds significant value. For target_market, it lists possible values (coin_market, kr_market, us_market), which goes beyond the schema's type 'string'. For limit, it explains 'Max active predictions to return (default 20)', adding context to the integer type. Both parameters are meaningfully explained.

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: retrieving pending predictions with NULL outcome. It distinguishes itself from the sibling get_prediction_accuracy by noting that combined they prove no cherry-picking. However, the purpose is somewhat buried in a longer narrative, and it doesn't explicitly differentiate from other similar sibling tools like get_latest_decisions or get_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 that specifies verifying ongoing prediction activity, and provides a next step to get_prediction_accuracy. However, it lacks explicit exclusions or comparisons to alternative tools among the many siblings, missing guidance on when not to use this tool.

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

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

No annotations present, so description carries full burden. It explains the data source (real backtest outcomes) and freshness indicator, but does not explicitly state read-only nature or authentication needs.

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

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

Structured format with clear sections (Purpose, When to call, etc.) is efficient. The Args section is terse but acceptable. Slightly verbose in purpose phrasing.

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

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

Output schema exists so return values are covered. Description explains the core output (lag_hours, sensitivity per cell). Could mention cell identification, but adequate given 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%; description merely repeats parameter names as 'Optional category filter' and 'Optional target market filter' with no additional details like allowed values, format, or examples.

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

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

The description clearly states the tool retrieves continuous self-calibration evidence showing auto-tuned parameters derived from backtest outcomes. It ties into a workflow but does not explicitly differentiate from siblings like get_structure_calibration.

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

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

Explicitly states when to call (after get_prediction_accuracy), prerequisites, next steps, and a caveat about timestamp freshness. Provides a clear usage sequence.

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 mentions a caveat (correlation data may be empty until enough regime changes accumulate), but lacks details on rate limits, authentication, or other behavioral traits. Since no annotations are provided, the description carries full burden, but it only partially discloses 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, When to call, etc.) and is concise. It covers essential information without unnecessary verbosity.

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), the description doesn't need to detail return values. It explains inputs and high-level output. Prerequisites and next steps are included, making it fairly complete for a simple two-parameter tool.

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

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

The schema has two optional parameters with no descriptions. The description adds minimal meaning: 'source_market: Optional source market filter' and similarly for target_market. Schema coverage is 0%, so the description partially compensates, but it is still vague.

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

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

The description clearly states the tool's purpose: analyzing cross-market lead-lag relationships and decoupling events, with an example (BTC up while stocks down). It distinguishes itself from sibling tools like get_sector_correlations_tool and get_macro_influence_map.

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

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

Provides explicit when-to-use context ('when analyzing macro regime changes or divergent signals'), prerequisites ('none'), and a suggested next step (get_macro_influence_map). This helps the agent decide when to invoke this 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?

With no annotations, the description carries full burden. It discloses key behavioral traits: 24-hour window, paper-trading only (not real money), output structure, and a disclaimer. This level of detail is thorough and transparent.

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

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

The description is well-organized with labeled sections, but slightly verbose. Every sentence adds value, and the most important information is front-loaded. Minor reductions could be made without losing clarity.

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 (one parameter, no required fields, output schema present), the description covers purpose, usage, behavioral details, parameter options, and output format comprehensively. There are no gaps.

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

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

The single parameter 'market' is fully described: default value 'all', and three valid alternatives ('crypto', 'kr_stock', 'us_stock'). The schema only provides type and default (0% coverage), so the description adds crucial semantic meaning beyond the schema.

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

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

The description states a specific verb ('get') and resource ('daily brief'), and enumerates the exact contents: macro regime, top 5 strong signals, paper-trading outcomes, active forecast count, and narrative. It clearly distinguishes from many sibling tools which focus on specific aspects (e.g., explain_decision, analyze_trades) by positioning this as a 'single-call market overview' and the recommended first 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?

Explicit usage context is provided: 'morning briefings', 'how is the market today?' queries. Prerequisites are stated as 'none', and next actions are listed. While it doesn't explicitly state when not to use, the context is clear enough for an AI 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?

No annotations provided, so description carries full burden. It explains the lifecycle states, the condition for empty results, and includes a disclaimer. It doesn't explicitly state no side effects, but 'Information only' implies a read operation.

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 and clear sections. Slightly verbose but each sentence adds value. Could be tightened, but remains 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 output schema exists, description does not need to explain return values. It covers the purpose, lifecycle, parameters, and caveats comprehensively. No gaps identified.

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?

All three parameters (market_id, target_market, status_filter) are described, including default behavior and aliases. With 0% schema coverage, the description fully compensates by providing essential semantics.

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

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

The description clearly states the purpose: 'Current lifecycle state of external features (news, events) under 3-track statistical validation.' It explains the lifecycle states and the rationale, distinguishing it from sibling tools focused on trades and 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?

Explicitly provides 'When to call: meta-level trust audit' and 'Prerequisites: none' and 'Next steps: none (meta evidence).' Also includes caveats about empty return when no cycles run.

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

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

With no annotations, the description carries full burden. It discloses a caveat (promoter cycle runs hourly) and a disclaimer, giving reasonable transparency. However, it could be more explicit about read-only nature or potential staleness, but overall it is informative.

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, When to call, Prerequisites, Next steps, Caveats, Disclaimer). Every sentence adds value, and it is concise 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 zero parameters and an output schema (implied), the description provides sufficient context: what the snapshot contains, usage context, caveats, and links to a sibling tool for deeper detail. It is complete for the tool's purpose.

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

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

The tool has zero parameters, so schema coverage is complete. The description adds no extra parameter meaning because none exist. Baseline score of 4 is appropriate.

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

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

The description clearly specifies the tool provides a feature governance snapshot covering distribution across states (OBSERVATION, CONDITIONAL, ACTIVE, DEPRECATED) and last 7-day transitions. It also states what it surfaces (survived-validation vs deprecated features), and distinguishes itself from the sibling get_feature_governance_state tool.

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

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

Explicitly tells when to call (trust evaluation, 'which features are live right now?'), states no prerequisites, and suggests next steps (get_feature_governance_state for per-feature detail). This provides clear context and alternative usage.

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

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

With no annotations, the description carries full burden. It discloses that decisions are paper-trading only and no real-money order routing, plus a disclaimer. No contradictions. Could add more on side effects or permissions, but adequate.

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

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

Well-structured with labeled sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Every sentence adds value, and the format is easy to parse. No redundancy.

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

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

Covers purpose, usage, parameters, and caveats. An output schema exists but is not referenced; the description could mention the structure of the returned decisions. Overall, sufficient for an AI agent to invoke correctly.

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

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

Schema coverage is 0%, so the description must compensate. It does so thoroughly: each parameter is described with allowed values, aliases, defaults, and purpose. For example, market_id includes accepted aliases and asset types, and decision_filter lists valid filters.

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

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

The description clearly states the tool retrieves a paper-trading decision log for recent automated decisions. It uses a specific verb and resource ('review...decision log'), but does not explicitly differentiate from sibling tools like 'get_llm_trading_decisions' or 'get_trade_history', which may overlap.

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', prerequisites, and suggested next steps ('get_trade_history', 'get_signals'). Lacks explicit 'when not to use', but the context is clear given the caveat about paper-trading only.

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 states 'paper-trading only' at both the start and in Caveats, and includes a disclaimer that it is not investment advice. This clarifies the tool's safe, read-only nature despite no 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, When to call, etc.). All sentences are informative and concise with no redundant 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?

Despite no annotations, the description covers purpose, usage, parameters, caveats, and next steps. An output schema exists, so return value details are not needed. This is complete for a simple retrieval tool.

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

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

The Args section provides clear meaning for both parameters: market_id lists acceptable values (crypto, kr_stock, etc.) and symbol is described as optional. This adds significant value beyond the schema, which has 0% description coverage.

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

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

The description clearly states the tool retrieves LLM-driven paper-trading judgments, and mentions inspecting reasoning and trade calls. It distinguishes from sibling get_latest_decisions by referencing it as a comparison tool (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?

Explicit 'When to call' and 'Next steps' sections provide direct guidance on usage and when to use alternative tools. Also lists prerequisites as none.

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

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

No annotations provided, but description fully covers behavior: it's a read-only filter returning positions with ROI < 0. The 'convenience wrapper' implies no side effects. Could mention no modification, but overall transparent.

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, When to call, etc.). Concise three main sentences plus Args. No redundant information.

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

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

With only 2 parameters and an output schema present, the description covers purpose, usage, parameters, caveats, and next steps thoroughly. All necessary context is provided.

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 aliases for market_id (coin/kr/us) and clarifies default for limit. This compensates fully and adds value beyond schema.

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

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

Clearly states it returns losing paper positions (ROI < 0) and is a convenience wrapper around get_positions(max_roi=-0.01). Distinguishes itself 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?

Explicitly says when to call ('drawdown / risk review'), prerequisites none, and suggests next steps (get_position_detail, get_role_analysis). Also mentions caveat about paper-trading data only.

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?

Without annotations, the description carries the burden, and it discloses key behaviors: it's a wrapper around get_trade_history with max_pnl=-0.01, operates only on paper-trading data, and includes a disclaimer. It could explicitly mention read-only nature, but it's implied.

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

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

The description is concise yet comprehensive, with clear sections (Purpose, When to call, etc.) and no wasted words. 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 appropriately covers parameters, usage context, and caveats. It is complete for the agent to use 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%, so the description compensates well: it explains market_id accepts aliases (coin/kr/us) and limit has a default of 10, adding 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 retrieves losing paper trades (P&L < 0), explicitly distinguishing it from siblings like get_winning_trades and get_trade_history by calling it a convenience wrapper.

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

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

The description explicitly provides when to call ('failure-pattern review'), prerequisites ('none'), and next steps ('analyze_trades for breakdowns'), offering clear guidance for the agent.

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

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

No annotations are provided, but the description includes caveats: 'Pearson-based; requires >= 30 samples; p < 0.05 filter.' and a disclaimer. It does not explicitly state read-only behavior, but the name and purpose imply no side effects. Minor omission prevents a 5.

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, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). It is front-loaded with purpose and every sentence adds value. No wasted words.

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

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

Given the tool's complexity (statistical causal graph), the description covers what it returns, when to use it, prerequisites, caveats, and parameter explanations. An output schema exists, so return values are likely documented. The description is sufficient for an agent to decide to invoke.

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 only provides types and defaults, while the description's 'Args' section explains 'min_abs_corr: Minimum |corr| (default 0.15)' and 'max_p_value: Maximum p-value (default 0.05)'. This adds significant meaning beyond the schema, fully compensating for the 0% schema description coverage.

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

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

The description clearly states it returns a 'lag-aware causal graph between macro categories' with specific categories listed, and provides an example ('forex -> vix 7d rho=-0.41'). It distinguishes from siblings like get_macro_influence_map by mentioning it as a next step.

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

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

Explicitly states 'When to call: assess pre-emptive cross-category impact after a macro event.' and lists 'Prerequisites: none' and 'Next steps: get_macro_influence_map for category -> market impact.' This provides clear when-to-use and alternatives.

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

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

With no annotations, the description carries full burden. It discloses the tool's static nature, high transparency, and includes a disclaimer. It does not mention permissions or rate limits, but provides sufficient behavioral context for a read-only information tool.

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

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

The description is well-structured with clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Every sentence adds value, and no unnecessary information is present. It is appropriately sized.

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

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

Given the tool's simplicity and presence of an output schema, the description covers all essential aspects: purpose, usage context, parameter details, limitations, and next steps. It is complete for an AI agent to decide when and how to use this tool.

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

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

The single parameter (market_id) is described with specific possible values (coin_market, kr_market, us_market), adding meaning beyond the schema's type-only definition. Schema coverage is 0%, so the description compensates well, though it could be more detailed on behavior when 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: exposing a pre-defined causal hypothesis map. It specifies the verb-resource (expose causal hypothesis map) and differentiates from siblings by highlighting that it is the highest-transparency tool with visible causal reasoning.

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

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

The description explicitly says 'When to call: when an AI wants to understand WHY we make certain predictions.' It provides context and suggests a next step (get_backtest_tuning_state). It does not explicitly exclude other cases, but the guidance is clear for primary 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?

No annotations provided, but description covers key behaviors: excludes 'all' month aggregate, empty result condition, and adds disclaimer. Does not detail return format or any side effects, but output schema likely covers return structure.

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

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

Well-organized into labeled sections. Every sentence serves a purpose with no redundancy. Efficient use of space to convey usage context and caveats.

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

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

Covers purpose, usage chain, caveats, and parameters. With output schema existing, missing details like time granularity and date range are less critical. Nearly complete for a trust-chain data retrieval tool.

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

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

Input schema has 0% description coverage; description briefly explains each parameter as optional filters, which adds marginal value beyond the schema. Could provide more detail on valid values or formats.

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?

Explicitly states the tool returns a monthly accuracy time series per category, target_market, and lag_bucket. Distinguishes from siblings by positioning it as completing the trust chain after get_prediction_accuracy and get_backtest_tuning_state.

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

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

Provides clear when-to-call instructions (after get_prediction_accuracy and get_backtest_tuning_state), prerequisites, and next steps (none, trust chain complete). Also lists caveats about empty results when backtest_results is unpopulated.

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

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

With no annotations provided, the description carries the burden of behavior disclosure. It includes a caveat about the window being limited to recent days, and the classification logic is explained. It does not explicitly state read-only or destructive nature, but the context implies a read operation. No contradictions with annotations as none exist.

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

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

The description is structured with clear headings (Purpose, When to call, Prerequisites, Next steps, Caveats, Args) which improves readability and scanning. It is front-loaded with the core purpose. While it could trim some repetitive phrasing, it remains efficient and 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?

Given the tool's complexity and the presence of an output schema, the description covers essential aspects: purpose, usage context, parameter details, and a caveat. It does not need to explain return values due to the output schema. A note on potential behavior (e.g., rate limits or data freshness) would be beneficial, but overall 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?

The schema coverage is 0%, so the description compensates by listing the two parameters with their purposes: market_id as market identifier, days as lookback window with default 7. This adds meaning beyond the schema's simple type/default definitions, though it could be slightly more 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 clearly defines the tool's purpose: a three-bucket news classification distinguishing anticipated vs surprise events, with explicit definitions for each category. It differentiates from siblings like 'get_news_leading_indicator_performance' by being a subsequent step, and from other causality tools by focusing on news events rather than macro or structure.

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', providing a clear usage sequence. It also lists prerequisites and next steps. However, it does not explicitly mention when not to use this tool or compare it to alternative tools, so a 4 is appropriate.

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

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

With no annotations, description carries full burden. Discloses behavioral traits: returns evidence, empty when no news events in window, and includes disclaimer. Does not discuss auth needs or rate limits, but given read-only nature, transparency is sufficient.

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

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

Well-structured with labeled sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args). Front-loaded with purpose. Each sentence adds value; no redundancy. Slightly verbose but appropriate 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?

Output schema exists, so description needn't cover return values. Covers purpose, usage, parameters, caveats (empty window). Given 0 required params and 3 optional, and sibling context, description is complete enough for correct invocation.

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

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

Schema coverage is 0%, so description must add meaning. It describes three args: market_id (examples), target_market (alias/backward compat), min_sample_count (minimum sample significance, default 3). Adds context beyond schema, though doesn't detail accepted values for market_id.

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 returns evidence of anticipatory price detection with specific fields (leading_score, avg_lead_time_minutes, accuracy_pct). Distinguishes itself from sibling get_news_causality_breakdown by calling itself 'Strongest Trust Layer A evidence' and 'proves the system is anticipatory rather than reactive.'

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: when an AI is evaluating predictive capability.' Provides next steps (get_news_causality_breakdown) and prerequisites (none). Lacks explicit when-not-to-use guidance, but context is clear enough for agent selection.

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

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

No annotations provided, so description carries full burden. It includes a caveat about error envelope when no position exists, but lacks details on authorization needs, rate limits, or whether the operation is read-only. Disclosure is partial.

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, When to call, Prerequisites, Next steps, Caveats, Args). Each sentence is value-adding, no redundancy, and front-loaded with key information.

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

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

Given the tool has 2 parameters and an output schema, the description covers purpose, usage context, prerequisites, error behavior, and parameter details. It is complete for an agent to decide when and how to invoke.

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 market_id values (crypto, kr_stock, us_stock with aliases) and gives examples for coin (BTC, ETH, AAPL). This adds 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 states 'Per-symbol paper position deep-dive (position + recent trades + decisions)' which is a specific verb and resource. It distinguishes from siblings like 'get_positions' (list all) and 'get_signal_detail' (signal-focused) by specifying it provides full context for one 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 provides when to call ('full context for one ticker'), prerequisites ('confirm the symbol holds a position via get_positions'), and next steps ('get_signal_detail, get_role_analysis'). This clearly guides the agent on usage 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?

No annotations provided, so the description carries full burden. It clearly states it is paper-trading only and not real money holdings, and includes a disclaimer. It does not mention side effects or rate limits, but for a read-only list tool, the disclosure is adequate. Could improve by noting return format or pagination.

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, When to call, Prerequisites, Next steps, Caveats, Disclaimer, Args). It is front-loaded with the purpose, and every sentence adds value without redundancy. Concisely covers all needed 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 7 parameters, 1 required, and an existing output schema, the description covers purpose, usage, caveats, and parameter details comprehensively. It includes prerequisites and next steps, making it complete for an AI agent to select and invoke correctly.

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

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

Schema coverage is 0%, so description must explain parameters. It does so thoroughly with an Args section, providing examples (e.g., -5.0 for min_roi), possible values (e.g., sort_by options), and defaults (e.g., limit default 1000). This adds significant value beyond the schema.

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

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

The description clearly states it lists paper-trading positions with dynamic filters. It is specific but does not explicitly differentiate from sibling tools like get_losing_positions or get_profitable_positions, though the mention of 'paper-trading' and filters provides some distinction.

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 (position dashboards, drawdown checks, exposure audits), prerequisites (recommend checking market status), and next steps (get_position_detail, get_strategy_distribution). This provides excellent guidance for 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?

Despite no annotations, the description discloses filtering for statistical significance (sample_count >= 3), potential emptiness if no backtests have completed, and a caveat for high-confidence claims, which provides adequate behavioral context for a read-only tool.

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

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

Well-structured with clear headings and sections, though slightly verbose with the disclaimer; still efficient and easy to parse.

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

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

With an output schema present, the description appropriately focuses on input semantics, filtering logic, and usage context, leaving little ambiguity for the agent.

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

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

Schema coverage is 0% with no enum constraints, but the description lists specific valid values for category (e.g., bonds, forex) and target_market (coin_market, kr_market, us_market), adding critical meaning 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 defines the tool as returning 'Long-term hit rate per (category, target_market, lag_bucket) cell' with statistical details, and distinguishes it from siblings like get_monthly_accuracy_trend and get_backtest_tuning_state by calling it the 'Most important credibility-evaluation 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?

Explicit guidance to call this FIRST when evaluating credibility, with prerequisites (none) and next steps (other tools). Does not explicitly state when not to use it, but provides context on filtering for high-confidence claims.

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

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

Discloses it uses paper-trading data only and includes a disclaimer. With no annotations, the description carries the burden and adequately reveals the tool's scope and limitations.

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

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

The description is well-structured with labeled sections (Purpose, When to call, etc.), concise sentences, and no redundancy. Every sentence provides 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 presence of an output schema, the description covers purpose, usage, parameters, and next steps. It is comprehensive for a simple filter tool with two 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?

Despite 0% schema description coverage, the description enriches both parameters: market_id with accepted aliases and default limit value. This adds significant meaning beyond the basic schema types.

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

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

The description clearly states it returns profitable paper positions (ROI > 0) and identifies itself as a convenience wrapper around get_positions(min_roi=0.01). This distinguishes it 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 says 'When to call: quickly surface winning tickers' and provides prerequisites (none) and next steps (get_position_detail). It stops short of explicitly naming when not to use, but the context of sibling tools implies alternatives.

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

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

No annotations provided, so description must carry full burden. It discloses a caveat: 'based on hierarchy_context — empty when collector lag is high.' However, it doesn't state whether the tool is read-only, has side effects, or requires special permissions. The disclaimer is present but not behavior-related. With an output schema (inferred), some transparency is covered, but gaps remain.

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, When to call, etc.) and clear parameter listing. Slightly verbose due to disclaimer and next steps, but each section adds value. Could be more concise by integrating some caveats into 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 purpose, usage, parameters, and caveats. Output schema (present) handles return details. Missing explanation of 'role-aware' or 'hierarchy alignment' but overall sufficient for a moderately complex tool. Prerequisites and next steps enhance completeness.

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

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

Schema coverage is 0%, but description adds meaning by listing args with examples and acceptable values: market_id examples (crypto, kr_stock, us_stock) and coin example (BTC, AAPL). This goes beyond the raw schema properties, aiding agent in constructing correct calls.

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 provides a specific verb-resource pair: 'Role-aware signal alignment per symbol' and lists aspects (timing, trend, etc.). It distinguishes from sibling tools like get_signal_detail by focusing on multi-timeframe cross-role analysis. However, the phrasing is somewhat technical and may not immediately convey the tool's core purpose to an agent.

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' states multi-timeframe analysis and cross-role checks. Lists prerequisite (get_signal_detail) and next steps (market URL, get_position_detail). This provides clear context for when to select this tool over siblings and what to do after.

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

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

No annotations exist, so description carries full burden. It discloses caveats (refreshed every 6 hours, 60-day lookback) and disclaimer (not investment advice). Could add that it's read-only, but overall adequately transparent.

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, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Every sentence adds value; no redundancy. 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 an output schema exists (not shown), the description covers purpose, usage, parameters, and caveats sufficiently. No missing critical information for an agent to invoke correctly.

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

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

Schema has 0% description coverage, but description adds clear semantics: 'market_id: coin / kr_stock / us_stock' and 'top_k: Number of top pairs to return'. This fully compensates for 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 explicitly states the tool quantifies intra-market ETF/group correlation matrices for diversification and sector-avoidance. It uses specific verbs ('quantifies', 'structural co-movement') and distinguishes from sibling 'get_cross_market_correlation' by noting intra-market vs. cross-market.

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

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

Provides clear 'When to call' (portfolio diversification, sector concentration audits), 'Prerequisites: none', and 'Next steps' pointing to a sibling tool. This gives explicit guidance on 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?

No annotations exist, so the description carries the full burden. It states 'Caveats: queries both the per-symbol signal store and the paper-trading store', disclosing data sources. However, it does not mention idempotency, rate limits, or permissions beyond a disclaimer. This is acceptable but not outstanding.

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

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

The description is structured into clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Disclaimer, Args). Each sentence adds value, no redundancy, and the most important 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?

Given the tool's simplicity (3 parameters, all simple types) and the presence of an output schema, the description covers purpose, usage, prerequisites, next steps, parameter meanings, and caveats. It is sufficient for an agent to correctly invoke the tool.

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

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

Schema description coverage is 0%, so the description compensates with an Args section: market_id (with examples 'crypto, kr_stock, us_stock'), coin (e.g., 'BTC, AAPL'), and interval ('Timeframe (default: combined)'). This provides meaningful context beyond the schema's type-only definitions.

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

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

The description starts with 'Per-symbol signal deep-dive — latest signal + history + feedback', which clearly specifies the verb (deep-dive) and resource (signal). This distinguishes it from sibling tools like get_signals (which lists signals) and get_position_detail.

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

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

The description provides explicit 'When to call' (drilling into a single ticker's signal context), 'Prerequisites' (confirm existence via get_signals), and 'Next steps' (get_role_analysis, get_position_detail). It lacks explicit when-not-to-use, 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?

With no annotations, the description carries full burden. It discloses a performance caveat (scanning all per-symbol DBs when `coin` omitted) and a disclaimer (not investment advice). However, it does not mention authentication needs, rate limits, or error handling, which are typical for a non-trivial tool.

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

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

The description is well-structured with clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args) and front-loads the purpose. While informative, it could be slightly more concise by merging redundant phrases, but overall efficient.

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

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

Given the output schema exists, return value details are not needed. The description covers purpose, usage context, parameter semantics, and behavioral caveats. Missing aspects include authentication requirements and rate limits, but for a query tool this is acceptable.

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 contains an 'Args' section that explains all 8 parameters with meaningful context (e.g., market_id aliases, coin optionality and performance impact, default values). This fully compensates for the schema's lack of descriptions.

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

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

The description starts with 'Purpose: Query research signals with dynamic filters', clearly stating the verb (query) and resource (research signals). It lists filter dimensions and contrasts with siblings like get_signal_detail, making it specific and distinct.

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: drilling into a specific signal slice; symbol-by-symbol scanning' and provides prerequisites (global view recommendation) and next steps (get_signal_detail, get_role_analysis). It lacks explicit when-not conditions but offers 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?

The description discloses that the distribution is for 'current paper positions' and notes a caveat about empty results. However, no annotations are provided, so the description carries full burden. Missing details like data freshness, authentication needs, or update frequency make it adequate but not comprehensive.

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

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

The description is structured with clear sections (Purpose, When to call, etc.) and is front-loaded. Every section earns its place without redundancy. The disclaimer is brief and appropriate.

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

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

Given the tool's moderate complexity (1 parameter, output schema exists), the description covers purpose, usage, prerequisites, caveats, and parameter details. Minor gaps like data source timeliness are acceptable since the output schema likely clarifies return structure.

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

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

The only parameter 'market_id' has zero schema description coverage (no enum or format), but the description explains valid values and aliases: 'crypto, kr_stock, us_stock; aliases coin/kr/us accepted'. This adds substantial meaning beyond the schema.

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

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

The description clearly states the purpose: 'Per-strategy breakdown across current paper positions (count, avg P&L, win rate per strategy).' This is specific, includes what is returned, and distinguishes from sibling tools like 'get_strategy_leaderboard'.

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' section identifies use cases (diversification audit, per-strategy performance check). 'Prerequisites' recommends 'get_positions', and 'Next steps' provides actionable paths. This offers clear 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?

No annotations exist, so description fully covers behavior: strategies are paper-tested, min_trades enforces statistical validity, global pool may have synthesized win_rates, and per-symbol is primary for trust. Includes disclaimer.

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, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Every sentence adds value, no redundancy.

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

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

Despite no annotations, the description provides purpose, behavior, parameter details, caveats, and next steps. Output schema exists but return values are not detailed, yet the description is sufficient for agent understanding.

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 description has a comprehensive Args section explaining each parameter's meaning, defaults, and aliases (e.g., target_market as alias for market_id). Fully compensates for 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 it retrieves top RL-learned research strategies with global and per-symbol leaderboards. It distinguishes from siblings by focusing on strategy leaderboard and includes specific details like Layer E evidence.

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 'final trust-validation step' for when to call, provides prerequisites (none), and suggests next steps. Lacks explicit when-not-to-use, but the context implies 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?

No annotations provided, so description carries full burden. Discloses important caveat: 'empty until structure-learning cycles complete.' Also includes a disclaimer. Does not contradict any annotations (none provided). The description reasonably informs about 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?

Description is well-organized into clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Each sentence adds value; no redundancy. Efficient and easy to parse.

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

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

Given that an output schema exists (as per context signals), description does not need to detail return values. It covers purpose, usage, parameters, caveats, and next steps adequately for a tool with two optional parameters.

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

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

Schema coverage is 0%, but description provides an 'Args:' section explaining both parameters with examples: market_id (crypto, kr_stock, us_stock) and group_name (layer1, defi, sector, broad_index). 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?

Description clearly states purpose: 'Level 2 (ETF / basket / sector) prediction calibration. Returns hit_rate_ema per (market, group, interval, regime_bucket) with sample counts. Proves systematic edge at the sector-rotation level.' It specifies the resource (structure calibration) and distinguishes from sibling tools by mentioning 'Layer D (structure) evidence'.

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

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

Includes explicit 'When to call: when an AI wants to see Layer D (structure) evidence.' Also provides 'Prerequisites: none.' and 'Next steps: get_structure_validation_history for the daily trend.' Does not explicitly list when not to use, but provides sufficient context for an AI 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?

With no annotations, the description carries full burden. It discloses that the tool returns an 'overall_hit_rate summary across the window' in the Caveats, and the Purpose describes per-day hit_rate rows. This adequately informs the agent of the output structure and a key behavioral trait (aggregate summary).

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, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer. It is concise (no fluff) and front-loads the core purpose. Every sentence adds value.

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

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

The tool has 2 optional parameters, no annotations, and an existing output schema. The description covers purpose, usage sequence, parameter meanings, caveats (overall summary), and a disclaimer. With the output schema providing return structure details, the description is complete for effective selection and invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It clearly explains both parameters: 'market_id: Optional market filter' and 'days: Lookback window in days (default 90)'. This adds meaningful context beyond the schema types and defaults, enabling correct invocation.

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

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

The description clearly states it retrieves daily validation history of Level 2 structure predictions with hit_rate per day, for time-series verification. It distinguishes from siblings like get_structure_calibration and get_monthly_accuracy_trend by specifying its daily granularity and focus on sustained performance.

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 'When to call: after get_structure_calibration' and 'Next steps: get_monthly_accuracy_trend', giving clear sequential context. It also states prerequisites: none. While it doesn't list alternatives or exclusions, the guidance is actionable and sufficient for typical use.

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

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

No annotations are provided, so the description carries full burden. It reveals key behaviors: 'When symbol is set, only peers that lead or follow that symbol are returned' and 'Caveats: 14-day lookback, 15-minute bars.' It does not explicitly state read-only nature or rate limits, but context implies data retrieval. The existence of an output schema reduces the need to describe return format.

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

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

The description is extremely concise and well-structured, using clear section headers (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Every sentence is informative and earns its place with zero waste.

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

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

For a tool with 3 optional parameters, no required fields, and an output schema, the description covers purpose, usage context, parameter semantics, caveats, and next steps. It is fully complete for an agent to correctly select and invoke this tool.

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

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

Schema coverage is 0%, so the description must compensate, which it does excellently. It explains market_id as 'coin / kr_stock / us_stock', symbol as 'Optional. When set, peers are anchored to this symbol.', and top_k as 'Number of top links to return'. This adds significant meaning beyond the bare type/default information in 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?

The description clearly states the tool provides 'symbol-level lead-lag links' with a concrete example (META -> AMZN, lag=15m, rho=+0.53). This explicitly defines the verb-resource and distinguishes it from sibling tools, none of which offer peer link 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 includes explicit guidance: 'When to call: incorporate peer leading signals into single-symbol reasoning.' It also lists prerequisites ('none') and next steps ('get_signal_detail for the peer's signal context'), providing clear usage 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?

No annotations are provided, so the description carries the full burden. It discloses that data is paper-trading only and imposes a 1000-row limit, which are important behavioral traits. However, it does not explicitly state read-only nature or discuss rate limits, though the 'Disclaimer: Information only' implies no financial advice.

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, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). It is front-loaded with the purpose, and every sentence adds value without redundancy.

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

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

Given the complexity (7 parameters, 1 required, array of filters) and the presence of an output schema (so return values need not be detailed), the description covers usage context, parameter details, caveats, and even suggests next steps. It is complete for effective tool invocation.

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

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

Schema coverage is 0%, so the description must compensate. It includes an 'Args' section explaining each of the 7 parameters, including aliases for market_id and valid values for action_filter. This adds significant meaning beyond the schema's type/default information.

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 queries paper-trading history with dynamic filters (action, P&L, time, symbol). It clearly distinguishes from sibling tools like analyze_trades, get_losing_trades, etc., which focus on analysis or specific outcomes.

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 'When to call' with specific use cases (past trade review, single-symbol post-mortem, win-rate audits), prerequisites (none), next steps (analyze_trades, feedback mechanisms), and caveats (paper-trading only, limit capped at 1000). This provides 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?

Discloses key caveat: paper-trading data only. Also mentions it's a wrapper. No annotations provided, so description carries full burden; some details like empty results or rate limits omitted, but overall informative.

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 headings, no fluff, each sentence adds value. Disclaimer is minor but not harmful. 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 an output schema exists, description covers purpose, usage, caveats, parameters, and next steps. No gaps for a 2-param 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 adds crucial meaning: explains market_id accepted values (crypto, kr_stock, us_stock plus aliases) and limit default. Fully compensates for schema lack.

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) and is a wrapper around get_trade_history(min_pnl=0.01). Distinguishes from siblings like get_trade_history and get_losing_trades.

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

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

Explicitly says 'When to call: success-pattern review' and provides next steps (analyze_trades). Lacks explicit when-not-to-use, but context implies alternatives.

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