Stocklake — AI Stock Intelligence

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context: ideas expire daily, pro tier cost attached, and a disclaimer that it's not financial advice. This goes 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 sections for parameters and returns, and is front-loaded with the tool's purpose. It is concise but could be slightly tighter, e.g., some redundant explanation in the returns section.

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 5 parameters and no schema descriptions, the description provides thorough parameter details and return structure. However, it lacks mention of error handling, pagination beyond limit, or behavior when no ideas match. Output schema exists but is not shown, which might reduce 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 description coverage is 0%, so the description fully compensates by detailing each parameter: direction with allowed values, min_conviction and min_flag_score with ranges and defaults, source with filter options, and limit with default and max. All parameter semantics are clearly 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 it returns 'AI-screened stock ideas actively flagged by the Stocklake pipeline', specifying sources like news analysis, sector screening, and sentiment signals. This verb-resource pair is specific and distinct from sibling tools like get_screener or get_sentiment_profile.

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

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

The description implies usage for obtaining AI-screened stock ideas but does not explicitly provide when to use this tool versus alternatives like get_screener or get_market_movers. No exclusion criteria or guidance on selection 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?

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable context: 'Dates sourced from market data — treat is_estimate=true dates as approximate.' It also outlines the return structure, going 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 concise, front-loads the purpose, and presents the return structure in a clear list. Every sentence adds value with 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 tool has an output schema (not shown) and one optional parameter, the description covers purpose, parameter, return structure, data quality, and tier availability. It lacks error handling or boundary behavior, but overall it is reasonably 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 single parameter 'days' has no description in the input schema (0% coverage), but the tool description fully explains it: 'look-ahead window in days (default 7, max 30).' This adds complete 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 clearly states the tool's purpose: 'Upcoming earnings dates for stocks in the Stocklake universe.' It uses a specific verb-resource pair and distinguishes itself from sibling tools like 'get_earnings_intelligence' by focusing on upcoming dates.

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 details on the 'days' parameter and a data quality note about is_estimate, but it does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied but not guided relative to siblings.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds that it uses nightly AI pipeline data, is Pro tier with attached cost, and is not financial advice. No contradictions; additional context is provided 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 structured with a title, a summary paragraph, parameter list, and return fields list. It is front-loaded with the main purpose. While slightly long, every sentence adds value and there is 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 presence of an output schema and the detailed listing of all return fields in the description, the tool's behavior is fully documented. No gaps in what the tool returns or how parameters affect 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?

All three parameters are explained in the description: days_ahead (default 14, max 30), sector (filter), min_flag_score (optional). This fully compensates for the schema's lack of property descriptions (0% coverage). Each parameter's meaning and constraints are clear.

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 upcoming earnings with AI context, combining the earnings calendar with AI pipeline data. It specifies key outputs like flag scores, verdicts, and risk factors, distinguishing it from siblings like get_earnings_calendar (plain calendar) and get_stock_ai_summary (single stock AI).

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 context: it's for upcoming earnings with AI insights, and mentions it's Pro tier with a cost. However, it does not explicitly tell when to use alternatives (e.g., get_earnings_calendar for a simple calendar, or get_stock_ai_summary for a single stock summary).

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, idempotentHint=true, destructiveHint=false. The description adds that the assessment is produced every ~4 hours, is a point-in-time snapshot (not live), and is Pro tier only with AI pipeline cost. 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 detailed but well-structured with bullet points and clear sections. It front-loads the purpose and then enumerates fields. While every sentence adds value, the length could be slightly reduced 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 that an output schema exists, the description comprehensively covers all output fields, usage context, limitations, and the single parameter. It leaves no ambiguity about what the tool returns and how to use it.

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

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

The input schema has one parameter with no description (0% coverage). The description explains history_count (0-3, default 0) and thoroughly describes all output fields including regime_*, indicators.*, market_context, outlook_*, etc. 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?

The description clearly states it provides a combined AI market assessment covering macro regime and market outlook. It distinguishes itself from sibling tool get_market_pulse by noting that get_market_pulse provides live prices, whereas this tool returns a point-in-time snapshot.

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 explains when to use each part: regime for position sizing and asset allocation, outlook for sector preference and directional bias. It also advises to use get_market_pulse for live prices, providing a direct alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the returned fields (symbol, name, sector, price, etc.) and confirms availability to all tiers, providing useful context beyond annotations. No side effects or additional behaviors are disclosed, but the annotations cover safety adequately.

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 brief and well-structured with a bulleted list of parameters followed by a line on returned fields and tier availability. Every sentence is informative with 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 tool's simplicity (3 optional parameters, no required fields, no enums in schema) and the presence of annotations and an output schema (described in text), the description covers all necessary aspects: parameter details, return values, and accessibility. It is complete for an agent to select and invoke correctly.

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

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

Schema description coverage is 0%, so the description fully explains each parameter: category with explicit enum options ('gainers', 'losers', 'most_active', 'all'), limit with default and max, and min_market_cap_b with units format. This adds significant meaning beyond the schema's bare type 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 clearly states the tool retrieves top market movers (gainers, losers, most active) from the Stocklake universe. The title and name align, and the description differentiates from sibling tools like get_market_assessment or search_stocks by specifying the exact categories of movers.

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

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

The description implies usage for fetching market movers by category, but it does not explicitly state when to use this tool over siblings like search_stocks for general stock queries or get_market_pulse for sentiment. It notes availability to all tiers, which is helpful but not a usage guideline.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by disclosing that the tool reads live data directly from the market data feed (no AI cost), and details the output fields including 'updated_at' for freshness. This goes beyond the annotations by explaining the live nature and output structure.

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

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

The description is concise and well-structured: a one-sentence summary followed by a bulleted list of return fields. Every sentence adds value—purpose, cost/no-AI hint, availability, and detailed output. 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 zero parameters, rich annotations, and an output schema (not shown but present), the description is complete. It covers all return fields, the data freshness indicator (updated_at), and notes universal availability. No gaps are apparent for a single-snapshot 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 tool has zero parameters, so the input schema adds no meaning. The description compensates fully by detailing the rich output structure (VIX, fear/greed, breadth, indices, bonds, updated_at), which is essential for the agent to understand what data it will receive. Baseline for zero parameters is 4, and the description meets that standard.

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

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

The description clearly states the tool provides a 'live market health snapshot' with a specific verb 'get' and resource 'market pulse'. It enumerates the exact aggregated indicators returned (VIX, fear/greed, breadth, indices, bonds), making the purpose highly specific and distinguishable 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 implies the tool is for a quick, single-call aggregation of market indicators ('without requiring multiple tool calls') and notes no AI cost and universal tier availability. However, it does not explicitly state when to use this tool versus siblings like get_market_assessment or get_market_movers, nor does it provide when-not-to-use 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 mark the tool as readOnly, idempotent, and non-destructive, so the description adds context: it is Pro tier only with AI pipeline cost, articles are ranked by AI flag score, ordered newest first within tiers, and includes a financial advice disclaimer. No contradictions. Could mention pagination or rate limits, but overall good.

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?

Every sentence adds value: tool definition, contrast with sibling, three usage scenarios, parameter breakdown, pro tier note, and disclaimer. No unnecessary words. Structured clearly with bullet-like lines for parameters and use cases.

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 scenarios, parameter details, output fields, cost implications, and legal disclaimer. Output schema exists, so return values are already documented. For a news feed tool with no required parameters, this is complete and actionable for an AI agent.

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

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

With 0% schema coverage, the description fully explains all three parameters: min_flag_score with value meanings (8=notable, 9=high-impact, 10=exceptional), days with default and max, limit with default and max. It also describes per-article fields including ai_flag_score scale. Adequately compensates for lack of schema descriptions.

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

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

The description states it returns 'Top AI-flagged news across all tracked stocks — the market-wide news briefing,' clearly defining the tool as a market-wide feed. It explicitly contrasts with get_stock_news (per-symbol), distinguishing it from siblings. The verb 'get' and resource 'news feed' are specific and unambiguous.

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

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

Three specific use cases are listed: morning briefing, catalyst scanning, and event monitoring. It explicitly differentiates from get_stock_news by noting the per-symbol vs market-wide scope, guiding when to use each. No other alternatives are provided, but the contrast is 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=true and idempotentHint=true. The description adds valuable behavioral context: pro-tier feature behavior (silently ignored for free), preset definitions, and parameter interactions. It does not contradict annotations and provides additional clarity on rate-limiting or result structure (though output schema likely covers the latter).

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 lengthy but well-structured with clear sections for parameters and pro-tier notes. It is front-loaded with the key purpose and sibling comparison. While every sentence adds value, it could be slightly more compact without losing information.

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

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

Given the tool's complexity (15 optional parameters, tier differences, presets), the description covers all necessary aspects: parameter semantics, tier limitations, sibling differentiation, and usage contexts. The presence of an output schema leaves return structure well-documented, so the description is sufficiently complete for an agent to invoke correctly.

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

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

With 0% schema coverage, the description fully compensates by explaining all 15 parameters with examples, ranges, and special values (e.g., 'min_rsi=30, max_rsi=50 = post-oversold recovery zone', presets expanded). Every parameter's meaning and usage is clearly 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 states 'filter stocks by technicals, fundamentals, and AI signals' and explicitly differentiates from sibling 'search_stocks' by being 'more capable'. It specifies the resource (stocks) and the action (screening/filtering) with concrete parameter examples.

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

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

The description provides contexts for using this tool over alternatives (e.g., 'More capable than search_stocks') and explains pro-tier limitations and presets. However, it does not explicitly state when not to use it or fully enumerate alternatives, leaving some implicit 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 read-only, idempotent, non-destructive behavior. Description adds useful context: refresh interval (~4 hours), pro tier restriction, and disclaimer. This goes beyond annotations.

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

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

Description is front-loaded with metrics list and structured in clear sentences. However, the disclaimer 'For informational purposes only. Not financial advice.' adds minimal value and could be condensed.

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

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

Given output schema exists (not shown), description doesn't need to detail return values. Covers tool purpose, usage modes, refresh rate, tier restriction, and disclaimer. Lacks error handling info, but acceptable for a read-only 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%, but description fully explains the only parameter: pass a sector name for single sector, omit or None for all 11 sectors. No ambiguity.

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 provides 'AI-assessed sector intelligence' and lists specific metrics (signal, cycle stage, rotation signal, etc.). It distinguishes from sibling tools like get_sector_rotation by focusing on comprehensive per-sector statistics rather than just rotation 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?

Description explains usage modes (single sector vs all sectors) and notes pro tier availability and informational purpose, but does not explicitly state when to avoid this tool or mention alternatives like get_sector_rotation.

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 non-destructive behavior. The description adds valuable behavioral context: return sorting by signal strength, the history_count parameter range, Pro tier restriction, and a 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 purpose first, then alternative, use cases, return fields, and parameter. Efficient but could be slightly more terse; however, all information is valuable.

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

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

Given the output schema exists and the description details all return fields, the description is complete. It also covers tier requirements and a disclaimer, leaving no ambiguity for an AI agent.

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

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

Though the input schema has 0% description coverage for the only parameter, the tool description explains history_count's purpose, valid range (0-3), and default (0). This fully compensates for the schema gap.

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

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

The description clearly states the tool retrieves all 11 market sectors with signals, breadth, and momentum for rotation analysis. It explicitly distinguishes itself from the sibling tool get_sector_intelligence which provides deep analysis for a single sector.

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 context for when to use this tool vs. get_sector_intelligence, listing specific use cases such as identifying sector rotation and allocating capital. Lacks explicit when-not-to-use scenarios, but the differentiation is strong.

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 and idempotent. The description adds significant context: data sources (SEC Form 4, institutional holdings), tier/cost implications, return structure (signal, flag_score, confidence, per-source breakdown, summary), and a 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 relatively concise, front-loading purpose and return values, then adding data sources, tier info, and disclaimer. Each sentence adds value, though some redundancy could be trimmed.

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 provides sufficient context: data sources, tier, cost, and return fields. It lacks mention of error handling or limitations, but overall covers the essential aspects for an AI agent.

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

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

The single parameter 'symbol' is standard and obvious from context. With 0% schema description coverage, the description compensates by explaining the tool's purpose, though it does not explicitly describe the parameter format or constraints. Baseline 4 is appropriate for a 1-param tool where the parameter is clear.

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 AI-synthesized insider and institutional sentiment for a stock, which distinguishes it from sibling tools like get_stock_ai_summary or get_technical_signals.

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

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

The description mentions 'Pro tier only' implying a prerequisite, but does not explicitly state when to use this tool versus alternatives or when not to use it.

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=true and idempotentHint=true. The description adds value by disclosing the comprehensive set of fields returned, including analyst ratings, technical indicators, and company details, which goes 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 front-loaded with the main purpose and uses bullet points effectively. It is somewhat lengthy but each line adds value. A few redundant phrases could be trimmed.

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

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

The description provides a complete overview of all returned data, including a list of key fields, which is helpful despite the existence of an output schema. It covers all necessary aspects for a composite stock data 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% for the single 'symbol' parameter. The description does not explicitly define 'symbol', but given the context, it is implicitly understood as a stock ticker. Minimal compensation for low coverage, but the parameter is trivial.

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 'Price, fundamentals, technical indicators, and company profile for a stock.' It specifies the exact data categories and lists key fields, making the purpose distinct 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?

No explicit guidance on when to use this tool vs alternatives like get_stock_ai_summary, get_stock_history, or get_stock_rating. The description only mentions 'Available to all tiers' but lacks when-to-use and when-not-to-use 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 goes beyond annotations by detailing the nightly refresh cycle, the AI pipeline source, and the cost attached to the Pro tier. It also lists all return fields, giving the agent a clear picture of what to expect. Annotations already indicate it's read-only and idempotent, and the description adds complementary context.

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

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

The description is concise and well-structured, starting with the main purpose, then adding context about the pipeline and tier, followed by a clear bulleted list of return fields. 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 has only one parameter and an output schema (though not provided), the description is complete: it lists all return fields, explains the nightly refresh, mentions the Pro tier restriction, and adds a disclaimer. No additional context seems necessary for the agent to understand 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?

The input schema has 0% parameter description coverage (only 'symbol' listed without details). The description compensates by stating it provides a summary 'for a stock,' implying the symbol parameter is a stock ticker. This is sufficient for a single obvious parameter, but could be more explicit.

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

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

The description clearly states it provides an 'AI research summary' for a stock, listing specific outputs like verdict, confidence, key points, and risk factors. It distinguishes itself from sibling tools like get_stock_rating or get_stock_news by focusing on AI-generated 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 mentions it is 'Pro tier only' and 'for informational purposes not financial advice,' providing some usage context. However, it does not explicitly state when to use this tool over alternatives like get_stock_rating or get_stock, nor does it explain when not to use it.

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. The description adds behavioral details such as default days=90, max 365, and the return format with daily OHLCV fields, providing useful context 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 concise, with a clear front-loaded purpose, followed by parameter details and return format. Every sentence adds value, and there is no redundancy or 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 simplicity, the description covers purpose, parameters, and return format adequately. It lacks mention of error conditions or data source, but the presence of an output schema (implied by the return description) reduces the need for further detail.

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

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

With 0% schema description coverage, the description fully compensates by explaining the 'days' parameter (number of trading days, default 90, max 365) and describing the return structure (symbol, days, count, history[] with per-bar fields). This adds significant meaning beyond the schema's default value.

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

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

The description clearly states 'Daily OHLCV price history for a stock', which is a specific verb and resource. It distinguishes from siblings like get_stock (current data) and get_stock_news (news) by focusing on historical price 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?

The description does not explicitly state when to use this tool over alternatives. It implies usage for price history but lacks comparison or exclusions among related tools like get_stock or get_technical_signals.

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 mark the tool as read-only and idempotent. The description adds details about the AI pipeline processing, cost implications, and the format of returned articles (sentiment, flag score, summary). This goes beyond the annotations without contradiction.

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

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

The description is well-structured and informative, starting with the core purpose, then listing return fields and important notes. It could be slightly more concise by combining some lines, but overall it's efficient and easy to scan.

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 (implied by the detailed return field descriptions), the description covers all necessary aspects: what the tool does, input parameters, output structure, constraints, cost, and a disclaimer. It is thorough for a read-only news tool.

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

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

With 0% schema description coverage, the description fully compensates by explaining the meaning of each parameter (days, limit, symbol), including defaults and constraints (max 30 days, max 10 articles). It also describes the return fields like status and per-article details.

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 'AI-analysed news for a stock, newest first' which defines both the resource and action. However, it does not explicitly distinguish this from sibling tools like get_news_feed, leaving some ambiguity about when to choose this over others.

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 note about 'Pro tier only — AI pipeline cost attached' and a disclaimer, but it does not provide explicit guidance on when to use this tool versus siblings, nor does it list any prerequisites or exclusions.

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

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

The description adds value beyond annotations by detailing the computation (specific indicators, scoring logic, direction categories, signal breakdown). Annotations already indicate read-only, idempotent, non-destructive behavior, which is consistent. It adds that it's free of AI cost and available to all tiers.

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 (three bullet points) and front-loaded with the key output (rating 0–10, direction, signals). Every sentence adds essential information: what it does, how it's calculated, and who can use it.

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 one parameter and no nested objects, the description covers the tool's purpose, indicators, scoring logic, tier availability, and cost. The output schema exists so explaining return format is unnecessary. It is fully complete for an agent to use correctly.

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

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

The schema has one parameter 'symbol' with no description (0% coverage). The description adds meaning by stating it is a stock symbol and that the rating is computed for that symbol using specified indicators. This compensates well for the missing schema description.

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

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

The description clearly states it provides a technical rating (0–10) with per-indicator breakdown, listing specific indicators (RSI, MACD, Bollinger Bands, SMA50/SMA200) and explaining the composite score, direction, and signals. This distinguishes it from siblings like get_technical_signals (raw signals) or get_stock (fundamental).

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 mentions availability to all tiers and that it's computed from stored indicators with no AI cost, guiding when to use it (for technical rating without extra cost). It does not explicitly state when not to use it or compare to alternatives, but the tier information is useful.

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

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

Annotations already provide readOnly and idempotent hints. Description adds valuable behavioral context: per-symbol call count toward daily limit, omission of missing symbols, and dict 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?

Three sentences, no fluff, front-loaded with key constraint (batch size). Every sentence adds necessary 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 output schema exists and tool is simple, description covers batch limit, omission handling, tier availability, and daily limit counting. Complete for effective use.

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

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

Schema has 0% description coverage; description adds the 50-symbol limit and missing symbol behavior, but does not specify symbol format or case sensitivity.

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 'Batch stock data for up to 50 symbols in a single call', specifying verb, resource, and constraint. Distinguishes from sibling get_stock by highlighting batch capability.

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?

States 'Available to all tiers' and implies use for multiple symbols, but does not explicitly mention when not to use (e.g., single symbol) or alternative 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, idempotentHint=true, destructiveHint=false. The description adds that 'All data is pre-computed by the Stocklake AI pipeline — no live AI calls on request', which aligns with idempotent behavior and gives extra transparency about latency.

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 a brief introductory sentence followed by bullet-pointed return fields. It is information-dense without redundancy, and every sentence adds value.

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

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

Given that an output schema exists, the description thoroughly explains the return value structure with all fields (stock, ai_summary, news, sentiment, discovery) and their sub-fields. The tool is complex, but the description covers it completely.

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 'symbol' has 0% schema description coverage, but the description does not elaborate on its meaning beyond implying it is a financial symbol. The baseline of 3 is appropriate for a simple, self-explanatory parameter, though the description could have explicitly stated it's a ticker symbol.

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 'Full research context for a symbol in one call' and explicitly lists the data categories (fundamentals, AI summary, news, sentiment, discovery). It also specifies it replaces 5 separate calls, distinguishing it from sibling tools.

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

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

The description explicitly says 'Replaces 5 separate calls: get_stock + get_stock_ai_summary + get_stock_news + get_sentiment_profile + get_discovery_ideas (for one symbol)', guiding the agent when to consolidate multiple calls into one. Additionally, it notes 'Pro tier only' and 'Not financial advice', setting usage boundaries.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral context: what signals are returned (rsi, macd, bollinger, etc.), how they are structured (flat, agent-ready), and composite logic (blended Williams %R and Ultimate Oscillator). No contradictions.

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

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

The description is front-loaded with purpose and sibling differentiation, followed by a clear, structured list of return fields. It is informative but somewhat lengthy; every sentence adds value, but it could be slightly more concise without losing detail.

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

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

Given the tool's complexity (multiple technical signals), the description is thorough, explaining each signal's output format and semantics. It covers composite logic and availability. The presence of an output schema (not shown) further compensates, but the description alone is sufficient for an agent to use the tool correctly.

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

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

The input schema has 0% description coverage for the single parameter 'symbol'. The description does not explain that symbol is a stock ticker or provide any additional semantic meaning. Given low schema coverage, the description should compensate, but it does not.

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 structured technical signal summary for a stock, using specific verbs like 'returns' and listing the flat labeled outputs. It distinguishes itself from sibling get_stock_rating by explicitly contrasting the output format (flat labeled signals vs composite score).

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 contrasts with get_stock_rating, providing some guidance on when to use this tool over that sibling. It also states 'Available to all tiers.' However, it does not provide explicit when-not or alternatives for other siblings like get_stock_ai_summary or get_market_assessment.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering basic safety. The description adds value by specifying the return format ('Returns: { count, filters, results[] }'), listing fields in results, and noting availability, which provides behavioral context 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 bullet points, front-loading the main action. It is fairly concise given the number of parameters, but some redundancy (e.g., repeated 'e.g.') could be trimmed. Overall, it earns its place without excessive 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 10 parameters, 0 required, and an output schema that exists (though not shown), the description covers the tool's input and output comprehensively. It explains all filter options, sorting, and return structure. The overview is sufficient for an agent to use 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 coverage is 0%, so the description carries the full burden. It provides detailed examples and explanations for each parameter (e.g., 'sector: e.g. "Technology"', 'min_volume: minimum daily volume (e.g. 1000000)') and clarifies the meaning of parameters like rsi_signal ('oversold (<30)') and sort_by options. This fully compensates for the empty 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 'Filter and rank stocks from the Stocklake universe,' providing a specific verb and resource. It lists examples of filter parameters (sector, country, etc.) and distinguishes from siblings by focusing on filtering and ranking, while siblings like get_stocks likely return stocks without such detailed filtering.

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 does not explicitly state when to use this tool versus alternatives like get_stocks or get_screener. It only notes 'Available to all tiers,' which is not usage guidance. The implied usage is for filtering and ranking, but without explicit context or exclusion of other tools, the guidance is lacking.

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