OneQAZ Trading Intelligence

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

Annotations already indicate readOnly and idempotent, but description adds specific behavioral traits (max 30 days, empty result behavior), which is useful context beyond annotations.

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

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

Structured with clear headings, front-loaded purpose, and no redundant sentences. Each section earns its place.

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

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

Given the tool's simplicity (2 params, output schema exists), the description covers purpose, usage, prerequisites, caveats, and parameters, making it fully adequate.

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

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

Schema has 0% description coverage, but the description explains market_id aliases (coin/kr/us) and days default/max, adding significant meaning beyond the bare schema.

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

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

The description clearly states it aggregates paper trades by day, pattern, and symbol, distinguishing it from sibling tools that retrieve raw data (get_trade_history) or specific subsets.

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 (pattern audits, performance review), recommends a prerequisite (get_trade_history), and provides caveats (max 30 days, empty results).

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the tool is safe and read-only. The description adds value by stating the output is research evidence, not investment advice, and detailing the combination of data sources, which aligns with annotations.

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

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

The description is well-structured with clear sections (Purpose, When to call, Prerequisites, etc.) and is informative without being overly verbose. Minor length but earned by content.

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, the description fully covers purpose, usage, prerequisites, caveats, and parameter meanings. Output schema exists, so omitting return details is acceptable. No gaps for the defined scope.

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 coverage, the description provides useful parameter descriptions: market_id (with aliases) and symbol (with examples). It adds meaning beyond the schema but lacks details on allowed values or constraints.

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

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

The description clearly states the tool's purpose: providing a multi-layer explanation for a single symbol's research signal, combining technical, decision log, and news causality. It distinguishes itself from siblings by offering a structured 'why' rather than a raw verdict.

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 specifies when to call (user asks 'why is this signal bullish/bearish?'), prerequisites (identify symbol via get_signals or get_latest_decisions), next steps (none), and caveats (symbol format).

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

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

Annotations already declare readOnly, openWorld, idempotent. Description adds that results are returned most recent first and includes a disclaimer. Adds moderate context beyond annotations.

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

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

Well-structured with clear headings, no unnecessary text. Every sentence serves a purpose. Front-loaded with purpose and usage.

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, prerequisites, next steps, caveats, and param details. With output schema present and 2 simple params, description is fully adequate.

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

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

Schema coverage 0%, but description enriches both parameters: target_market with example values (coin_market, kr_market, us_market) and limit with default 20. Adds meaning not in schema.

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

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

Clearly states the tool retrieves pending predictions with outcome NULL, emphasizing real-time forecasting. Distinguishes from sibling get_prediction_accuracy by mentioning its role in proving no cherry-picking.

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', 'Prerequisites: none', and 'Next steps' with a specific sibling tool. No ambiguity on when to use versus alternatives.

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

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

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context: the data represents auto-tuned parameters from backtests, and it warns about freshness via last_backtest timestamp. This goes beyond annotations and clarifies the tool's non-mutating nature.

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

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

The description is well-structured into clear sections (Purpose, When to call, Prerequisites, etc.) and is appropriately sized. Every sentence adds value, though the disclaimer could be considered extraneous for behavioral purposes.

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 (optional parameters, read-only, idempotent), the description covers purpose, output content, usage sequence, and freshness caveat. It doesn't explain the output schema's structure, but since an output schema exists and is not shown here, 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 coverage is 0%, so the description must compensate. It only adds the word 'filter' to each parameter, providing minimal additional meaning. It does not explain valid values or how they affect results. Given the low schema coverage, this is inadequate.

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

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

The description explicitly states the tool's purpose: providing continuous self-calibration evidence with auto-tuned lag_hours and sensitivity per cell. It clearly distinguishes from sibling tools by focusing on tuning state derived from backtest 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 gives explicit usage guidance: when to call (after get_prediction_accuracy) and prerequisites (get_prediction_accuracy recommended). It also suggests next steps (get_monthly_accuracy_trend). However, it does not explicitly state when not to use this tool or list alternatives.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint. The description adds a caveat: 'correlation data may be empty until enough regime changes accumulate,' providing behavioral context beyond annotations. No contradiction.

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

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

Well-structured with clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Concise but covers all essential aspects 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 low complexity (2 optional params, output schema exists, annotations present), the description covers purpose, usage, caveats, next steps, and includes a disclaimer. It is complete and actionable.

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; the description adds only generic labels: 'source_market: Optional source market filter' and 'target_market: Optional target market filter.' No details on format, allowed values, or examples, which is insufficient for a tool with 2 parameters.

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

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

The description clearly states the tool's purpose: 'Cross-market lead-lag relationships and decoupling events.' It explains what it shows (correlations and decoupling) and references a sibling tool (get_macro_influence_map) in 'Next steps,' aiding differentiation.

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

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

Explicitly states 'When to call: when analyzing macro regime changes or divergent signals,' provides 'Prerequisites: none,' and suggests 'Next steps: get_macro_influence_map for the static causal hypotheses.' This gives clear guidance on when and what to do next.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. Description adds behavioral context such as 24-hour window and paper-trading data source, which are not in annotations. No contradiction.

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

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

Well-structured with clear sections but somewhat lengthy. Redundancy exists between 'Triggers' and 'When to call'. Could be slightly more concise while maintaining 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?

Covers purpose, usage, parameters, output structure (full_data), caveats, and next steps. Completeness is high for a tool that returns a complex overview.

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

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

Only one parameter 'market' with default 'all' and enumerated values (crypto, kr_stock, us_stock). Schema coverage is 0%, but description fully explains the values, including that 'all' blends three markets.

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

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

Clearly states the tool provides a single-call market overview covering macro regime, strong signals, paper-trading outcomes, and narrative. It distinguishes itself from sibling tools by being the first call for market questions, while siblings handle deep-dives.

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

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

Provides explicit triggers, when to call, prerequisites (none), and next steps. Also includes a disclaimer and caveats (24-hour window, paper-trading only). Guides the agent to prefer this over training data.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds behavioral context like lifecycle progression, trust validation philosophy, and caveat about empty results if feature_gate_evaluator hasn't run. Marginal additional value.

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

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

Well-structured with clear sections; front-loaded purpose. Some minor redundancy (e.g., 'Proves OneQAZ only trusts...' could be trimmed). Efficient overall.

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

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

Given complexity (lifecycle with statuses, 3 params, output schema present), description covers purpose, lifecycle, caveats, and parameters. Output schema exists so return values need not be explained. Adequate 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 includes Args section explaining market_id (defaults to coin), target_market (backward compat alias), and status_filter with possible values. Adds 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 states specific verb 'get' and resource 'lifecycle state of external features' with clear lifecycle stages (OBSERVATION -> CONDITIONAL -> ACTIVE/DEPRECATED). Distinguishes from sibling tool get_feature_governance_status_tool by focusing on state under statistical validation.

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: meta-level trust audit' and lists prerequisites and next steps as 'none'. Provides clear context but does not mention alternative tools or when not to use.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context: the data is a snapshot updated hourly ('promoter cycle runs hourly'). No contradictions. It provides additional transparency about update frequency beyond annotations.

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

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

The description is well-structured with labeled sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Disclaimer). It is front-loaded and concise. The disclaimer is slightly extraneous but does not detract significantly. Each 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 zero parameters, the presence of an output schema, and the tool's complexity, the description is complete. It explains the output distribution categories (OBSERVATION, CONDITIONAL, ACTIVE, DEPRECATED) and the time window (last 7-day transitions). No gaps remain.

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

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

The input schema has zero parameters with 100% coverage, so the description does not need to explain parameters. According to the rubric, zero parameters yields a baseline of 4. The description adds no parameter details, which is appropriate.

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

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

The description clearly states the tool's purpose: providing a feature governance snapshot with distribution and transitions. It explicitly distinguishes from sibling tool get_feature_governance_state, which offers per-feature detail. The verb 'get' matches the resource 'feature governance status'.

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 scenarios ('trust evaluation, which features are live right now?') and next steps ('get_feature_governance_state for full detail'). It also notes no prerequisites. However, it lacks explicit when-not-to-use guidance, but the context is sufficiently clear.

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

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

Annotations already indicate read-only, open-world, idempotent. Description adds critical context: paper-trading only (no real-money routing) and disclaimer. No contradictions.

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

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

Well-structured with labeled sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args). Each sentence adds value; no fluff.

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

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

Covers tool purpose, parameters, and key caveat. Output schema exists so return format not needed. Could better differentiate from many similar sibling tools beyond paper-trading note.

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 Args section thoroughly explains each parameter: market_id aliases, limit default, decision_filter options, hours_back meaning. Adds significant value beyond schema.

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

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

Clearly states the tool is for reviewing recent automated paper-trading decisions. Includes specific resource ('paper-trading decision log') and action ('review'). Distinguishes from siblings with caveat about paper-trading vs real-money.

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 ('review recent automated decisions and their outcomes') and prerequisites (market status recommended). Also gives next steps. Lacks explicit when-not-to-use or comparison to similar siblings like get_llm_trading_decisions.

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

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

Annotations already mark readOnlyHint, openWorldHint, idempotentHint. The description adds that it's 'paper-trading only' and includes a disclaimer that it's 'not investment advice,' which are important behavioral traits beyond the annotations.

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

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

The description is well-organized into labeled sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). It is concise without unnecessary words, though slightly lengthy due to multiple sections.

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 two parameters and existence of an output schema (which covers return values), the description covers purpose, usage, parameters, and behavioral caveats. It also mentions Track-A and Track-B, providing context, though deeper explanation of these tracks is absent.

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 meaningful descriptions: market_id lists possible values (crypto, kr_stock, us_stock, commodity, forex, bond) and symbol clarifies it's optional and that omitting returns entire market. This compensates for the 0% schema description coverage.

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

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

The description clearly states it retrieves 'LLM-driven paper-trading judgement log' (Track-A). This is a specific verb and resource. While it doesn't explicitly differentiate from all siblings, the 'Next steps' mention of get_latest_decisions for Track B hints at 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 'When to call' section says 'inspect LLM-generated reasoning and trade calls,' and 'Next steps' suggests comparing with Track B. This provides clear context for usage, though no explicit 'when not to use' is given.

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?

Adds value beyond annotations: specifies paper-trading data only, convenience wrapper nature, and includes disclaimer. Annotations already indicate readOnly, openWorld, idempotent, but description provides further behavioral context.

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

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

Well-structured with labeled sections (Purpose, When to call, etc.). Every sentence is informative and earns its place. No redundancy.

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

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

Given the existence of an output schema, the description covers purpose, usage, parameters, and caveats thoroughly. No gaps for this tool's complexity.

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

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

Schema coverage is 0%, but description compensates by describing both parameters meaningfully: market_id with alias examples and limit with default. This adds semantic value beyond the bare schema.

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

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

Clearly states it returns losing paper positions (ROI < 0) and explicitly identifies itself as a convenience wrapper around get_positions(max_roi=-0.01), differentiating it from siblings like get_profitable_positions and get_positions.

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

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

Provides explicit 'When to call' (drawdown / risk review) and 'Next steps' (get_position_detail, get_role_analysis), giving good context. Lacks explicit when-not-to-use but purpose is clear enough.

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

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

Annotations already mark readOnly, openWorld, idempotent. The description adds value by specifying data source (paper trading only) and a disclaimer, going beyond annotations.

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

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

Structured with clear sections (Purpose, When to call, Prerequisites, etc.), front-loaded, and every sentence is informative without 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?

Given available annotations and output schema, the description covers purpose, usage, parameter details, caveats, and next steps, making it fully actionable.

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

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

With 0% schema description coverage, the description fully explains both parameters: market_id includes accepted aliases, and limit specifies default value. Compensates completely.

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

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

The description clearly states it retrieves losing paper trades (P&L < 0) and explicitly positions itself as a wrapper around get_trade_history, distinguishing it from siblings like get_winning_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?

Provides explicit when-to-call context (failure-pattern review) and a next step (analyze_trades), but lacks explicit when-not-to-call or alternatives beyond the sibling list.

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

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

Disclosures beyond annotations: returns only statistically significant pairs, Pearson-based, requires >=30 samples, p<0.05 filter. Annotations already indicate readOnly, openWorld, idempotent; no contradiction.

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

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

Well-organized with sections, but the disclaimer is somewhat extraneous. Still efficient overall, no repetitive or redundant sentences.

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 tool purpose, inputs, behavioral notes, and caveats. Adequate for a simple tool with two optional params.

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?

Both parameters have descriptions in the description text despite 0% schema coverage. Adds meaning: 'min_abs_corr: Minimum |corr| (default 0.15)' and 'max_p_value: Maximum p-value (default 0.05)'.

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 states specific verb+resource: 'Lag-aware causal graph between macro categories' and lists categories. Clearly distinguishes from sibling 'get_cross_market_correlation' by specifying lead-lag pairs and statistical significance.

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: assess pre-emptive cross-category impact after a macro event.' Also provides prerequisites (none) and next steps. Lacks explicit when-not-to-call but context is clear.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds that the tool exposes static hypotheses only, is the highest-transparency tool, and includes a disclaimer (not investment advice). No contradictions with annotations.

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

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

The description is well-structured with clear headings (Purpose, When to call, Prerequisites, Next steps, Caveats, Args) and uses concise language. 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 tool's complexity (8 macro categories) and the presence of an output schema, the description covers purpose, usage, caveats, and next steps comprehensively. It explains what the tool returns and how to use the results.

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

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

The schema has one optional parameter (market_id) with 0% description coverage. The description adds example values ('coin_market, kr_market, us_market') and states it's an optional filter. This adds useful meaning beyond the schema, though default behavior when omitted is not explicitly stated.

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

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

The description explicitly states the purpose: exposing OneQAZ's pre-defined causal hypothesis map. It lists the macro categories and what the mapping includes (lag_hours + sensitivity). It also distinguishes itself as the highest-transparency tool, setting it apart from siblings.

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

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

The description provides clear when-to-call guidance ('when an AI wants to understand WHY we make certain predictions'), states no prerequisites, and suggests a next step (get_backtest_tuning_state). It does not explicitly exclude use cases, but the context makes it clear.

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

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

Annotations already indicate readOnlyHint=true, so the tool's safety is clear. The description adds value by disclosing caveats: excludes the 'all' month aggregate and returns empty when backtest_results is unpopulated. These behavioral details go beyond the annotations.

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

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

The description is well-structured with clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args) and is concise. Every sentence serves a purpose, and the disclaimer is a minor addition that does not detract.

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

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

The tool has an output schema, so the description does not need to explain return values. It mentions 'lag_bucket' in the purpose, which is likely an output field. Given the tool's moderate complexity (2 optional params, no required), the description covers essential aspects like prerequisites and behavior when data is missing. A minor gap is the lack of explanation about the output structure, but the output schema fills that.

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

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

The input schema has 0% description coverage, so the tool description must compensate. However, the description only restates the parameter names and marks them as optional without providing additional meaning (e.g., valid values, formats, or behavior when omitted). The schema itself provides no descriptions, so the description adds negligible value beyond labeling.

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

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

The description clearly states the tool's purpose as providing a 'Monthly accuracy time series per (category, target_market, lag_bucket)', which is a specific verb and resource. It distinguishes itself from siblings like 'get_prediction_accuracy' by positioning itself as a trend analysis tool that completes the trust chain, and the 'Caveats' section adds clarity about what is excluded.

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 this tool: 'after get_prediction_accuracy and get_backtest_tuning_state — completes the trust chain'. It also notes prerequisites ('get_prediction_accuracy recommended') and next steps ('none'), providing comprehensive usage guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the caveat 'window limited to recent days', explaining data recency constraints. It also details the classification logic, providing behavioral context beyond annotations.

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

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

The description is well-structured with labeled sections: Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer. It is concise, front-loads key information, and every sentence adds value.

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

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

The description provides usage context, parameter info, and caveats. An output schema exists (though not shown), so return values need not be described. It is complete enough for an agent to understand when and how to call the tool.

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

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

With 0% schema description coverage, the description provides the only parameter explanations: 'market_id: Market identifier', 'days: Lookback window in days (default 7)'. These are clear and concise, but could benefit from additional detail like accepted values or ranges.

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

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

The description clearly states the tool's purpose: a three-bucket classification to discriminate between anticipated and surprise events. It specifies the verb 'get' and resource 'news causality breakdown', and differentiates from the sibling 'get_news_leading_indicator_performance' by noting it as a prerequisite.

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: after get_news_leading_indicator_performance', providing clear context. It also lists prerequisites ('none') and next steps. However, it does not explicitly mention when not to call or contrast with other causality-related siblings like get_macro_causality_graph_tool.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds the caveat that results may be empty when no news events processed, and includes a disclaimer. This provides additional context beyond annotations.

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

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

The description is well-structured with clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). It is front-loaded with the most important information and every sentence adds value. No unnecessary 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 has an output schema, the description does not need to detail return values, but it still lists key fields. It covers purpose, usage, parameters, caveats, and provides next steps. The information is sufficient for an AI to understand and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining each parameter in the 'Args' section. Provides market examples, clarifies backward compatibility for target_market, and explains min_sample_count's role in statistical significance. This is highly informative.

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 leading_score, avg_lead_time_minutes, and accuracy_pct per event type, with the purpose of providing evidence that the system detects price moves before news. Distinguishes itself from siblings by specifying its role as 'Strongest Trust Layer A evidence' and implying it is unique among the many get_* tools.

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

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

Explicitly states 'When to call: when an AI is evaluating predictive capability.' Also provides a clear next step (get_news_causality_breakdown) and states no prerequisites. While it does not list when not to use, the guidance is sufficient 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds error envelope behavior when no position exists, which is useful beyond annotations.

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

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

Well-organized into clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer); every sentence adds value with no 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?

Comprehensive for a deep-dive tool: describes inputs, outputs, error case, prerequisites, and next steps. Output schema existence further reduces burden.

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% coverage, but description explains both parameters with examples and aliases for market_id, adding significant 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?

Clearly states 'Per-symbol paper position deep-dive (position + recent trades + decisions)' with a specific verb and resource, distinguishing from siblings like '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 provides when to call, prerequisites ('confirm symbol holds position via get_positions'), and next steps ('get_signal_detail, get_role_analysis').

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. The description adds that it deals with paper-trading (not real money), which is critical behavioral context. It also provides caveats and disclaimers, further clarifying the tool's nature beyond the annotations.

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

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

The description is structured with clear sections (Purpose, Triggers, When to call, Prerequisites, etc.) and reads efficiently. While a bit lengthy, every sentence adds value. Could be slightly trimmed, but remains 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?

Given 7 parameters, annotations present, and an output schema exists, the description covers all necessary aspects: purpose, usage, filters, caveats, prerequisites, and next steps. It provides a complete picture 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 must compensate. It does so by explaining each parameter (market_id, min_roi, max_roi, strategy, sort_by, sort_order, limit) with examples, defaults, and purpose. This fully clarifies their meaning and usage.

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

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

The description clearly states the tool lists current paper-trading positions with dynamic filters, using specific verbs ('List') and resource ('positions'). It distinguishes from siblings by emphasizing paper-trading and filters, and provides example triggers that clarify the scope.

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

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

The description includes triggers, when to call (dashboards, audits), prerequisites (market context recommended), and next steps (get_position_detail, get_strategy_distribution). It explicitly notes it's for paper-trading only and provides disclaimers. Alternatives are not directly named but implied via sibling tools in context.

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

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

Annotations already declare safe, idempotent behavior. The description adds caveats about empty results and filtering for high-confidence claims, enriching transparency beyond annotations.

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

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

Well-organized with labeled sections (Purpose, When to call, etc.), no redundant sentences, and front-loaded key information for quick agent parsing.

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

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

Covers purpose, filtering logic, caveats, and next steps. Given an output schema exists for return values, the description is fully adequate for an AI agent to understand and use 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 coverage is 0%, so description compensates by listing the two optional parameters with their allowed values (e.g., category options like bonds, forex), adding meaning beyond 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 defines the tool as returning long-term hit rate statistics per cell with sample count and Wilson CI, and distinguishes it from siblings like get_monthly_accuracy_trend by emphasizing this is for credibility evaluation and filtering for statistical significance.

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 'call this FIRST' when evaluating credibility, lists prerequisites as none, and recommends next steps (get_backtest_tuning_state, get_monthly_accuracy_trend), providing clear workflow guidance.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint. The description adds context beyond annotations: it is a 'convenience wrapper', 'paper-trading data only', and has specific caveats. No contradictions. Adds valuable behavioral insight.

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 is informative and necessary. No fluff.

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

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

Given the presence of an output schema (not shown) and the thorough description covering purpose, usage, parameters, and caveats, the description is complete. It addresses all likely questions an agent might have.

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 fully explains both parameters: market_id with accepted aliases (crypto, kr_stock, us_stock; coin/kr/us) and limit with default 20. This adds significant 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?

Clearly states the purpose: 'Profitable paper positions (ROI > 0). Convenience wrapper around get_positions(min_roi=0.01).' It specifies the verb 'get', the resource 'profitable paper positions', and distinguishes itself from the sibling tool 'get_positions' by being a convenience wrapper with a default ROI filter.

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

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

Provides explicit usage guidance: 'When to call: quickly surface winning tickers.' and 'Prerequisites: none.' and 'Next steps: get_position_detail for full context.' It suggests an alternative next step but does not explicitly exclude other scenarios. Still, it gives clear direction.

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

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

Annotations already indicate read-only, idempotent, and open-world behavior. The description adds a caveat: 'based on hierarchy_context — empty when collector lag is high', disclosing potential empty results. No contradiction with annotations.

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

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

The description is well-structured with clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Disclaimer, Args). Every sentence adds value, and it is front-loaded with the core purpose.

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

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

Given the tool's complexity (multi-timeframe, role alignment) and presence of an output schema, the description provides sufficient context: purpose, usage, parameters, caveats. A slightly deeper explanation of 'hierarchy alignment' could improve completeness, but overall it covers key aspects.

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

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

With 0% schema description coverage, the description compensates by adding meanings: market_id as 'Market ID (crypto, kr_stock, us_stock)' and coin as 'Symbol (e.g., BTC, AAPL)'. Examples and domain hints help the agent, though an explicit enum would be more precise.

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 'Role-aware signal alignment per symbol (timing / trend / swing / regime) plus hierarchy alignment', specifying the verb (get) and resource (role analysis). It differentiates from siblings like get_signal_detail and get_signals by focusing on multi-role alignment.

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: multi-timeframe analysis, cross-role agreement checks.' Also includes prerequisites (get_signal_detail recommended) and next steps (market://..., get_position_detail), providing clear context for when to use and what to do next.

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

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

Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds valuable behavioral context: 'refreshed every 6 hours; 60-day lookback' and a disclaimer. This goes beyond annotations without contradiction.

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

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

Description is well-structured with labeled sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer). Each sentence adds value, no redundancy, and 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?

For a tool with 2 simple parameters, output schema present, and good annotations, the description covers all necessary aspects: purpose, usage, prerequisites, next steps, caveats, and parameter meanings. It is complete and self-contained.

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

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

Schema description coverage is 0%, but the description explains both parameters: market_id values ('coin / kr_stock / us_stock') and top_k ('Number of top pairs to return'). This adds essential meaning missing from 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?

Description clearly states the tool produces an intra-market ETF/group correlation matrix and auto-cluster output, with an example (ARKK <-> QQQ). It distinguishes from siblings like 'get_cross_market_correlation' which is cross-market, and 'get_macro_causality_graph_tool' which focuses on causality.

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 ('portfolio diversification or sector concentration audits'), prerequisites ('none'), and next steps ('get_symbol_peer_links_tool for per-symbol lead-lag inside a sector'). Provides 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds value by disclosing that it 'queries both the per-symbol signal store and the paper-trading store.' No contradiction exists.

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

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

The description is concise with clear section labels (Purpose, When to call, etc.). Every sentence adds value, and the key information is front-loaded. The disclaimer is brief and does not detract.

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 and annotations, the description fully covers purpose, usage context, prerequisites, caveats, and parameter meanings. No gaps remain 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?

With 0% schema coverage, the description provides short explanations for each parameter: market_id includes example categories, coin gives example symbols, and interval indicates default. While not exhaustive (e.g., no enum lists), it adds 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 'Per-symbol signal deep-dive — latest signal + history + feedback,' specifying the verb (deep-dive) and resource (signal detail). It distinguishes from siblings like get_signals by targeting a single ticker and including history and feedback.

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' says 'drilling into a single ticker's signal context,' and provides prerequisites ('confirm existence via get_signals first') and next steps ('get_role_analysis, get_position_detail'), offering clear guidance on when to use this tool versus alternatives.

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

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

Annotations already indicate read-only, idempotent, open world. The description adds behavioral context: it returns research signals (not orders/advice) and warns about performance when 'coin' is omitted. No contradiction with annotations.

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

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

Well-structured with labeled sections (Purpose, Triggers, When to call, etc.) and front-loaded with the main purpose. Every sentence is informative, and the length is justified by the tool's 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?

Covers purpose, usage, parameters, caveats, prerequisites, next steps, and disclaimer. Output schema exists so return values needn't be described. The description is complete for the 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?

Input schema has no property descriptions, so the description's 'Args' section provides full meaning for all 8 parameters, including aliases, defaults, and filter values. This adds significant value beyond the schema structure.

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

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

The description clearly states the verb 'Query' and the resource 'research signals', and provides specific triggers and example questions. It differentiates from sibling tools like get_signal_detail and get_latest_decisions by mentioning pairing and next steps.

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 (e.g., drilling into signal slice, symbol-by-symbol scanning) and provides prerequisites and next steps. Also includes trigger examples for casual questions, making it easy for the agent to decide.

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

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

Annotations already indicate read-only, idempotent, and open-world. The description adds useful context: it operates on current paper positions, may return empty results, and includes an investment advice disclaimer. No contradictions with annotations.

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

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

The description is structured with clear sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Args, Disclaimer), is front-loaded, and contains no fluff. All sentences are necessary.

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

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

Given the presence of an output schema and one parameter, the description covers all necessary aspects: purpose, usage, prerequisites, caveats, parameter details, and disclaimer. It is complete and self-contained.

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

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

The description adds valuable meaning to the single parameter market_id by listing accepted values (crypto, kr_stock, us_stock) and aliases (coin, kr, us). Schema coverage is 0%, so description fully compensates.

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

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

The description clearly states the tool's purpose: providing a per-strategy breakdown across current paper positions with specific metrics (count, avg P&L, win rate). It differentiates from sibling tools like get_positions and get_strategy_leaderboard by focusing on aggregated per-strategy statistics.

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 scenarios (diversification audit, per-strategy performance check), prerequisites (get_positions recommended), and next steps (market://... , signals/feedback) are provided. Also includes a caveat about empty distributions when no positions are open.

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

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

Annotations set readOnlyHint, openWorldHint, idempotentHint to true. The description adds context beyond annotations, noting that the global pool may contain synthesized win_rate values and that strategies are paper-tested, which is valuable behavioral insight. No contradictions.

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

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

Well-structured with headings and bullet points. Every sentence adds necessary information (purpose, when to call, prerequisites, next steps, caveats, args, disclaimer). No redundant or vague statements.

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 (no need to explain return values), the description covers all essential aspects: purpose, usage context, parameter details, and caveats. It is complete for a read-only leaderboard tool.

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

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

Schema description coverage is 0%, but the description explains all 6 parameters (market_id, target_market, top_n, limit, min_trades, include_per_symbol) with their roles and defaults, adding significant 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 explicitly states the tool returns 'Top RL-learned research strategies — GLOBAL pool + per-symbol partition,' clearly identifying its purpose. It distinguishes from sibling tools, which focus on other analyses like trade history or 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?

Directly states 'When to call: final trust-validation step' and provides prerequisites ('none'), next steps, and caveats (min_trades filter, paper-tested). This gives clear guidance on when and how to use the tool relative to others.

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

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

Annotations already declare read-only and idempotent behavior. The description adds a caveat about empty results until structure-learning cycles complete, which is valuable beyond annotations. No contradictions.

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

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

Well-structured with clear 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 the availability of an output schema, the description need not detail return fields. It already summarizes output and covers usage context, parameter meanings, and caveats. Minor jargon ('Layer D') is acceptable in domain context.

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

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

With 0% schema coverage, the description compensates by describing both optional parameters with example values (market_id: crypto, kr_stock, us_stock; group_name: layer1, defi, sector, broad_index). This adds meaning beyond the bare schema.

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

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

The description explicitly states the tool returns calibration data for Level 2 predictions, with specific output metrics (hit_rate_ema per market/group/interval/regime_bucket). It distinguishes itself from siblings by targeting structure-level evidence, not other analytics like predictions or trade history.

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

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

The 'When to call' section clearly advises use for Layer D structure evidence, and 'Next steps' points to a related tool for further analysis. It does not explicitly say when to avoid the tool, but the context is sufficient for an agent to decide.

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

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

Annotations already mark the tool as read-only, open-world, and idempotent. The description adds that it returns an overall_hit_rate summary and includes a disclaimer. No contradictions. The additional caveats about return format are helpful.

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

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

The description is well-structured with separate sections for purpose, usage, args, and caveats. It is concise without unnecessary words, front-loading the purpose first. Every sentence adds value.

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

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

Given the tool has only two optional parameters and an output schema exists, the description covers purpose, usage sequence, parameter explanations, and a caveat. It is complete enough for an agent to select and invoke correctly.

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

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

The schema has 0% description coverage, so the description compensates with an Args section. It explains market_id as an optional filter and days as a lookback window with default 90. This adds basic meaning but could be more detailed (e.g., allowed 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?

The description clearly states the tool returns daily validation history with hit_rate for Level 2 structure predictions. It distinguishes from siblings like get_structure_calibration and get_monthly_accuracy_trend by positioning itself as a step after calibration and before monthly trend 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 explicitly says when to call (after get_structure_calibration), lists prerequisites (none), and suggests next steps (get_monthly_accuracy_trend). It does not mention when not to use, but provides clear context for usage.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral context beyond annotations: data window (14-day lookback), bar size (15-minute), and the nature of lead-lag links (rho values). No contradictions with annotations.

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

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

The description is well-structured with distinct sections and front-loads the purpose with an example. It covers all necessary information without excessive verbosity. The disclaimer adds little but does not detract.

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

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

The description covers purpose, usage guidelines, parameters, behavioral details, next steps, and caveats. The presence of an output schema complements the description, so return value structure is not needed. The description is complete for effective tool selection and invocation.

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

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

The input schema lacks parameter descriptions, so the tool description compensates with an 'Args' section explaining each parameter: market_id lists valid values, symbol explains anchoring, top_k explains count. This provides necessary semantic meaning, though could be slightly more precise.

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: retrieving lead-lag relationships between symbols. The example (META -> AMZN) provides concrete understanding. It also explains that filtering by symbol is possible and distinguishes from sibling tools by focusing on peer links.

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 dedicated 'When to call' section that provides context for using the tool. It also suggests a next step (get_signal_detail), implying this is a preliminary step. Although it does not explicitly compare to alternatives, the unique purpose makes this sufficient.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds caveats: paper-trading data only (not real money) and limit capped at 1000. No contradictions, but could add more about response 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?

Well-structured with clear sections (Purpose, When to call, etc.). Concise but not overly terse; could slightly reduce repetition (e.g., 'paper-trading' mentioned twice).

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 output schema, the description covers purpose, usage, all parameters, caveats, and next steps. An agent can correctly invoke this tool without ambiguity.

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

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

Schema coverage is 0%, but the description provides detailed parameter explanations in an Args section, including accepted values, defaults, and aliases (e.g., 'coin/kr/us' for market_id). 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 clearly states the verb 'Query' and resource 'paper-trading history', listing dynamic filters (action, P&L, time, symbol). It distinguishes from siblings by specifying paper-trading and providing specific use cases.

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

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

Explicitly lists when to call (past trade review, post-mortem, win-rate audits) and prerequisites (none). Provides next steps (analyze_trades, etc.), guiding the agent 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?

The description adds 'paper-trading data only' and 'Winning paper trades only (P&L > 0)' beyond the annotations (readOnlyHint, idempotentHint, openWorldHint). The disclaimer further clarifies limitations. No contradiction with annotations.

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

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

Well-structured with labeled sections (Purpose, When to call, Prerequisites, Next steps, Caveats, Disclaimer, Args). Every sentence is informative and there is no redundant or filler content.

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 2 parameters (1 required), existing output schema, and informative annotations, the description covers purpose, usage context, caveats, and parameters adequately. It also suggests follow-up actions, making it complete.

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

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

Schema coverage is 0%, so the description carries the burden. It explains market_id includes aliases (coin/kr/us) and limit has default 10. This adds meaningful detail beyond the schema's type and default declarations.

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 'Winning paper trades only (P&L > 0)' and identifies it as a convenience wrapper around get_trade_history. It uniquely specifies the resource (winning trades) and scope (paper-trading data), distinguishing it from siblings like get_losing_trades and get_trade_history.

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

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

Explicitly states 'When to call: success-pattern review' and 'Next steps: analyze_trades for breakdowns'. Prerequisites are noted as none. While it doesn't mention when not to use this tool, the context and sibling listing suggest alternatives.

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