Stocklake — AI Stock Intelligence

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

Even with annotations declaring read-only, idempotent, and non-destructive behavior, the description adds valuable context: results are sorted by earnings date, dates are approximate when is_estimate is true, and data comes from market data. It also discloses availability to all tiers, 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 well-organized with a clear opening, parameter detail, output structure, and data quality caveat. Each line contributes necessary information, and no redundant or filler content is present.

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 only one parameter, and the description explains it fully. Despite the presence of an output schema, the description lists all return fields, ordering, and the meaning of is_estimate. This makes the tool self-sufficient and 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?

The input schema only shows a 'days' integer with a default of 7. The description explains that 'days' is a look-ahead window, its default, and its maximum (30). This fully compensates for the 0% schema description coverage, adding meaning beyond the raw schema.

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

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

The description clearly states the tool provides 'Upcoming earnings dates for stocks in the Stocklake universe.' It uses a specific verb ('get') and resource ('earnings calendar'), and the scope is defined. It also distinguishes from the sibling 'get_earnings_intelligence' by focusing on dates rather than broader intelligence.

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 clear context for when to use the tool: to retrieve upcoming earnings dates within a configurable look-ahead window. It does not explicitly mention when not to use it or highlight alternatives, but the context is evident from the purpose and return fields.

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

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

Beyond the readOnly/idempotent annotations, the description discloses sorting behavior, date estimation flag, cost implications ('Pro tier only — AI pipeline cost attached'), and a disclaimer ('Not financial advice'). It also mentions the data source combination, giving a richer behavioral picture.

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 one-line summary followed by parameter and return sections. It is slightly lengthy and repeats return fields that are also in the output schema, but remains easy to parse and every section adds practical 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 covers the tool's purpose, parameters, output details, sorting, cost, and limitations. It is sufficient for an agent to select the tool and understand its behavior, especially with the output schema also present.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter: days_ahead with default and max, sector with an example, and min_flag_score with its meaning. This goes well beyond the bare schema fields.

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 with AI context — flag scores, verdicts, and risk factors per stock.' It names the resource (earnings intelligence) and distinguishes from sibling tools like get_earnings_calendar by emphasizing the AI pipeline integration.

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 when to use it by noting it 'combines the earnings calendar with AI pipeline data to surface which upcoming earnings events are worth monitoring.' It does not explicitly name alternatives or exclusions, but the use case is clear and the 'Pro tier only' cost warning adds practical 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 readOnly, idempotent, and non-destructive. The description adds substantial behavioral context: max and default days, data source, edge case behavior, Pro tier restriction, and a disclaimer. No contradiction with annotations.

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

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

The description is well-structured: purpose first, then parameter behavior, followed by a clear field list. Each sentence adds value, and the length is appropriate given the number of fields and caveats.

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

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

For a tool with many output fields, the description covers the full output shape, edge cases, access tiers, and usage context. It is complete even with an output schema present, as it explains the semantics of each field and the data source.

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 explains the `days` parameter thoroughly (max 730, default 90) and implies `symbol` via 'for a stock'. It could explicitly state the symbol format, but the context is sufficient for a standard 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 it returns historical daily indicator snapshots for a stock, with a specific verb and resource. It focuses on indicators, which inherently distinguishes it from siblings like get_stock_history, but it does not explicitly name that alternative.

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 usage context ('ideal for charting and trend detection') but does not explicitly state when not to use the tool or name alternatives. It leaves the decision to the agent without exclusionary 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 mark the operation as read-only, idempotent, and non-destructive. The description adds meaningful context: AI synthesis, output composition, data sources, Pro tier cost, and a 'not financial advice' disclaimer. This goes well beyond the structured fields.

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 four sentences, front-loaded with the core purpose, followed by output details, data sources, cost caveat, and disclaimer. Each sentence adds value and the structure is logical and concise.

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

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

Given one parameter, an output schema, and strong annotations, the description covers the tool's function, return value components, data sources, access restrictions, and legal caveat. It is fully sufficient for an agent to select and invoke the tool correctly.

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

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

With only one required parameter 'symbol', the description's phrase 'for a stock' makes the parameter's purpose clear despite 0% schema coverage. It does not specify format or case sensitivity, but the semantic is obvious, so the description partially 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 retrieves AI-synthesized insider and institutional activity for a stock, specifying the combined signal, flag_score, confidence, and source breakdown. This distinguishes it from sibling tools like get_stock or get_signals by emphasizing insider transactions (SEC Form 4) and institutional holdings.

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 for when to use the tool—when insider/institutional activity insight is needed—and notes it is Pro tier only with AI pipeline cost. However, it does not explicitly state when not to use it or mention alternatives, stopping short of the top tier.

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 meaningful context: production cadence (~4 hours), cost implications (Pro tier, AI pipeline cost), and the point-in-time snapshot nature of the data, which goes beyond the safety profile.

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

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

The description is long but exceptionally well-structured, with a clear opening summary, bulleted field explanations, and a logical flow. Every sentence adds value, and the formatting makes it easy to scan despite the length.

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

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

The description thoroughly covers the tool's outputs, key fields, caveats about data freshness, and cost implications. Given the output schema already exists, the description complements it well without redundancy, making the tool's behavior and limitations clear.

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 only one parameter and no schema description, the description fully compensates by explaining history_count's purpose (include last N prior assessments), valid range (0-3), and default (0). This provides all necessary context for correct use.

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

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

The description clearly identifies the tool's purpose: a combined market assessment providing both a macro regime and market outlook in a single call. It differentiates from siblings by explicitly noting that prices are point-in-time snapshots and mentioning get_market_pulse for live 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 provides explicit usage guidance by mapping each perspective to a decision type: REGIME for position sizing/asset allocation and OUTLOOK for sector preference/directional bias. It also names an alternative tool (get_market_pulse) for live price needs, clarifying when not to use this tool.

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

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

Annotations already establish readOnly/idempotent/non-destructive behavior. The description adds valuable context: atr_pct is omitted when data is missing/corrupted, default category behavior, and availability to all tiers. 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 front-loaded and scannable, using a concise bullet list for parameters. The return-field list slightly overlaps with the output schema, but the note about atr_pct omission is a useful non-obvious 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?

For a read-only tool with three optional parameters and an output schema, the description covers purpose, all parameter semantics, output caveats, and access level. Nothing critical is missing.

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

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

Schema description coverage is 0%, but the description fully documents all three parameters: category with enumerated values and default, limit with default and max, and min_market_cap_b with a concrete example. This completely compensates for the sparse 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 delivers 'Top market movers from the Stocklake universe' with specific categories: gainers, losers, most active. This specific verb-resource-scope combination distinguishes it from sibling tools like get_market_pulse or get_screener.

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 on what the tool returns and gives default/limit behaviors for parameters. It does not explicitly mention when to use this tool instead of siblings, but for a simple read-only movers list the context 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, idempotentHint, and destructiveHint. The description adds valuable behavioral context: it 'reads live data directly from the market data feed,' notes 'No AI cost,' and explains the returned snapshot fields. This goes beyond the annotations but does not address potential delays or staleness, so a 4 is appropriate.

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

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

The description is well-structured with a brief introductory sentence followed by a clear bulleted list of return values. It is concise and every element adds value, effectively conveying the tool's output without unnecessary 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 tool's moderate complexity and zero parameters, the description thoroughly explains what the tool returns, including specific fields (vix, fear_greed, breadth, indices, bonds, updated_at). An output schema is indicated, but the description still provides a complete overview, making it fully self-contained for an 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 tool has zero parameters, so per the rubric, the baseline is 4. The description does not need to explain parameters since there are none, and the schema already covers this perfectly.

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: 'Live market health snapshot in a single call' with a specific verb ('gets') and resource ('market pulse'). It distinguishes itself from sibling tools by positioning as a single-call aggregator of market indicators, which is unique among the listed 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?

The description provides clear context for when to use the tool: when a quick market overview is needed without multiple calls. It mentions 'No AI cost' and 'Available to all tiers' as accessibility guidance. However, it does not explicitly state when not to use it or name alternative tools (e.g., get_market_assessment), so it falls just short of a 5.

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

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

Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds valuable context such as the Pro-tier cost, ranking by AI flag score with newest-first ordering within tiers, and the informational (non-advice) nature. This goes beyond annotations, though it stops short of covering rate limits or pagination.

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

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

The description is well-structured and front-loaded with the core purpose. The use-case bullets and parameter explanations are concise and earn their place, with no redundant content. It is appropriately sized for 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?

Given the tool has an output schema (per context signals), the description needn't detail return structure, but it still lists output fields. It covers scope, ranking behavior, cost, use cases, parameters, and limitations. The description is comprehensive for a read-only, parameterized news feed 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 contains only types and defaults with 0% description coverage. The description fully compensates by explaining each parameter: min_flag_score with its value scale (5-10, default 8, 8/9/10 meanings), days look-back window, and limit with defaults and maximums. It also describes output fields per article, adding depth 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 function as a market-wide news briefing with AI-flagged news across all tracked stocks, using a specific verb and resource. It explicitly distinguishes itself from sibling get_stock_news by contrasting per-symbol vs. whole-universe scope.

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

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

The description provides explicit use cases (morning briefing, catalyst scanning, event monitoring) and directs users to get_stock_news for per-symbol queries. This gives clear when-to-use and when-not-to-use guidance relative to alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to rehash that. It adds significant behavioral context: 'min_flag_score (pro tier only — silently ignored for free)' and 'preset (pro only)' explain tier-based behavior, and it details the return structure including pro-tier additions. It also explains preset compositions (e.g., 'oversold = RSI≤35 + above SMA200'), which is valuable 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 front-loaded with the purpose, then systematically lists parameters with concise inline explanations, and finishes with the return structure. Every line is informative and directly relevant. Despite its length, it is well-organized and avoids filler, earning full marks for structure.

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 18 parameters, tier-specific behavior, and a detailed output schema, the description covers all essential aspects: parameter semantics, presets, pro/free differentiation, return fields, and defaults. It even clarifies the unit for market cap (billions) and the meaning of score values. No significant 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?

With 0% schema coverage, the description carries the full burden for parameter meaning, and it does so thoroughly. Every parameter is explained with concrete examples and enum values: sector/country examples, RSI bounds with oversold/overbought interpretation, sma_trend values, macd_signal definitions, performance/volume/market cap constraints, rating values, preset formulas, sort options, and limit range. This adds critical 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 'Filter and rank stocks from the Stocklake universe — fundamentals, technicals, and AI signals in one tool.' This provides a specific verb (filter/rank), resource (stocks in Stocklake universe), and scope (fundamentals, technicals, AI signals). It distinguishes itself from sibling tools like get_stock or get_stocks by focusing on multi-criteria screening and ranking.

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 clear context for use through its detailed parameter list and preset definitions, implying it is the comprehensive stock screening tool. However, it does not explicitly mention when not to use it or name alternatives like get_stock for individual quotes or get_stock_history for historical data. Thus it lacks explicit exclusions but provides clear context, meriting a 4.

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 meaningful behavioral context beyond the readOnly/idempotent annotations: refresh cadence ('Refreshed every ~4 hours'), access restriction ('Available to pro tier only'), and disclaimer ('Not financial advice'). It also discloses that some parameters are ignored in single-sector mode, which is useful behavioral nuance.

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 every sentence adds value. It is front-loaded with a clear summary, then organized parameter notes, then operational context. There is no filler or repetition of schema basics.

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

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

For a tool with 3 optional parameters and a rich output domain, the description is complete. It covers the two primary invocation modes, parameter constraints, sorting/rotation use case, refresh schedule, access tier, and disclaimer. With an output schema present, it doesn't need to enumerate return fields further.

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%, and the description compensates thoroughly. It explains the 'sector' parameter behavior (single vs. all), the effect of 'sort_by_strength' (LEADING→LAGGING ordering, ignored for single sector), and 'history_count' (0-3, prior signal states, all-sectors only). This goes well beyond the raw schema types and defaults.

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

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

The description clearly states the tool's purpose: 'AI-assessed sector intelligence: signal, cycle stage, rotation signal, drivers, alerts, and computed statistics per sector'. It lists the exact outputs and distinguishes itself from sibling tools by focusing on sector-level intelligence and rotation views.

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: pass a sector name for a single sector, or omit/None for all 11 sectors. It also explains when to use sort_by_strength and history_count, and notes that the all-sectors call doubles as the rotation view. The pro-tier-only note adds clear access 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?

Despite annotations already declaring readOnlyHint and idempotentHint, the description adds valuable context: signals expire daily, there are cost implications (Pro tier only), and it includes a legal disclaimer. It also clarifies score thresholds (e.g., 9+ = high conviction), which goes beyond the annotation hints.

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 for description, parameters, returns, and notes. While it is somewhat lengthy, every sentence serves a purpose—providing parameter details, return structure, expiry information, and legal disclaimers. No fluff or repetition.

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

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

Given the tool's complexity (5 parameters, output schema, annotations), the description covers every aspect: purpose, parameter semantics, return fields, data freshness (daily expiry), pricing tier, and legal disclaimer. It leaves no meaningful gap for an agent to misuse the tool.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining each parameter in detail, including allowed values (e.g., direction: LONG/SHORT/BOTH, source types), defaults, and constraints (limit max 50, min_flag_score 9+ meaning). This is a textbook example of compensating for a sparse 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: returning AI-screened stock signals actively flagged by the pipeline. It specifies the resource (stock signals) and the action (get), and the distinction from siblings like get_market_movers or get_screener is evident through the focus on AI-flagged 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 implies when to use the tool (when you want AI-screened stocks worth attention) and explains the signal sources, but it does not explicitly state exclusions or alternatives. The context is clear, though a direct 'use this when...' statement is absent, making it a clear but not fully explicit 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 readOnly, idempotent, and non-destructive behavior, but the description adds substantial detail: raw indicators with 'no interpretation', Pro-tier interpreted blocks, 'relative_strength... null if not precomputed yet', and omission rules for missing/stale data. This goes far beyond what annotations convey.

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

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

The description is long but well-organized: a purpose sentence, a bulleted field list, and structured Pro-tier explanations. Each section carries meaningful detail, though some Pro-tier passages (e.g., the relative_strength explanation) could be trimmed without losing essential information.

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

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

Given the high complexity—many field groups, optional Pro blocks, omission/null behaviors—the description is thorough. It covers data sync timestamps, raw vs interpreted output, omission rules, and top-level field placement, making it complete for an agent to select and invoke the tool correctly.

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

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

The only parameter, 'symbol', is documented solely as a required string in the schema; the description never mentions the input or provides format examples (e.g., ticker vs ISIN). With 0% schema description coverage, the description does not compensate, though the parameter name is fairly self-evident.

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

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

The description opens with 'Price, fundamentals, technical indicators, and company profile for a stock' and states it 'Returns all data needed to understand a stock in a single call.' This clearly defines the tool as a comprehensive snapshot endpoint and distinguishes it from focused siblings like get_stock_history, get_stock_news, or get_stock_research.

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 name alternatives or when-not-to-use scenarios, but it positions the tool as the one-call comprehensive stock data source and explains tier-specific extras. This provides clear context for when to use it, though explicit exclusions or comparisons to siblings are absent.

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

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

Annotations already cover read-only and idempotent behavior. The description adds useful context like the max 365 trading days and daily bar frequency, but does not disclose other behavioral traits such as timezone, data latency, or error handling.

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 highly concise, front-loaded with the core purpose, and uses bullet points to clearly separate parameter and return structure. Every sentence adds meaningful 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?

The tool is relatively simple, and the presence of an output schema covers return value details. The description adequately covers parameters, defaults, and output fields; minor omissions like timezone or market holidays are not critical for this use case.

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 explaining 'days' as trading days with default 90 and max 365, adding meaning beyond the raw schema. The 'symbol' parameter is not explained but is self-evident from the tool's purpose.

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

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

The description clearly states the tool fetches daily OHLCV price history for a stock, specifying the verb and resource. It distinguishes from related tools by the focus on price history, though it does not explicitly name alternatives.

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 purpose implies the tool is for historical daily prices, but the description does not explicitly state when to use it versus siblings like get_stock or get_indicator_history. No exclusions or alternative tool names are mentioned.

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 substantial behavior beyond annotations: ordering (newest first), filter conditions (only AI-processed), status codes, per-article fields, and tier limits. However, there is an internal contradiction: it states days max 30 and limit max 10, but later says Pro tier allows up to 90 days and 50 articles. This inconsistency could mislead an agent regarding parameter constraints.

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 for parameters, status, output fields, and tier limitations. It is somewhat long but each line carries useful information. The main detractor is the redundant or confusing tier information that could have been more concisely integrated.

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 almost all necessary context: return fields, status, defaults, maximums, tier differences, and a disclaimer. Missing is a clear explanation of how tier affects the parameter maximums, which is a notable gap given the earlier contradictory statements. Still, it is more complete than most tool descriptions.

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

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

With 0% schema description coverage, the description compensates by explaining days and limit semantics, defaults, and maximums. However, it fails to explicitly describe the symbol parameter (though it is contextually obvious from 'stock'), and the tier-related maximums are presented inconsistently, which could confuse parameter usage.

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

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

The description clearly states the tool returns AI-analysed news for a stock, sorted newest first. It specifies the unique angle (AI pipeline with sentiment, flag score, summary) that distinguishes it from sibling tools like get_news_feed, which likely returns raw news.

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 is for stock news that has been AI-processed, and it explicitly says 'Only returns articles processed by our AI pipeline,' implying this is not for raw news. However, it does not explicitly name alternative tools or say when not to use this tool, so it falls short of a 5.

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

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

Beyond annotations (readOnly, idempotent), the description adds critical behavioral context: all data is pre-computed by the Stocklake AI pipeline with no live AI calls on request, implying potentially stale data. It also discloses that newer fields (headline, near_term, longer_term) may be null for older summaries and instructs fallback behavior. This goes well beyond the structured hints and provides deep transparency.

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

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

The description is longer than average, but the tool is a bundled aggregate with multiple return groups, so the detailed breakdown is warranted. It front-loads the core purpose in the first sentence, then uses structured bullet sections for returns, followed by key behavioral notes. Each section contributes useful information without fluffy filler.

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

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

Given the tool's complexity and the presence of an output schema, the description provides a thorough overview of all returned data groups, including field names and semantics. It also covers edge cases (null fields for older data), access restriction, and latency implications. This is complete for an agent to select and invoke the tool confidently.

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 required parameter, 'symbol,' with 0% description coverage. The description compensates by repeatedly referencing 'a stock' and 'for one symbol,' clarifying that the operation targets a single ticker. It doesn't specify format or case sensitivity, but given the simplicity of the parameter, the context is mostly sufficient; a brief format hint would make it fully 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 a comprehensive AI research bundle for a stock, listing the specific components (fundamentals, AI summary, news, insider/institutional signal, active trade signal). It explicitly distinguishes itself from siblings by noting it replaces four separate calls in one call, making its scope and resource unambiguous.

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

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

The description explicitly states when to use this tool: to get a complete stock research bundle in one call, replacing get_stock + get_stock_news + get_insider_activity + get_signals for a single symbol. It also notes 'Pro tier only,' providing a usage restriction. This clearly guides an agent on when to choose this over the 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 mark this as read-only, idempotent, and non-destructive. The description adds valuable behavioral specifics beyond that: returns a dict keyed by symbol, missing symbols are omitted, and each symbol counts as a call toward the daily limit. This helps the agent anticipate edge cases and rate-limit implications.

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?

Four short sentences, each delivering distinct information: batch capability, return shape, missing-symbol behavior, and rate-limit/tier accessibility. No filler or redundancy.

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

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

For a simple single-parameter tool with an output schema available, the description covers all essential aspects: batch size, return format, error behavior (omitted symbols), usage limits, and availability. The complexity is low, and nothing important is missing.

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

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

With 0% schema coverage, the description compensates by explaining the symbols array: it supports up to 50 symbols and results are keyed by symbol. This adds meaning beyond the raw schema, though it leaves ticker format implicit.

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 with a specific verb and resource: 'Batch stock data for up to 50 symbols in a single call.' This distinguishes it from the sibling get_stock (singular) and other stock-related tools, making the scope explicit.

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

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

The description provides clear usage context: use for batch stock data, up to 50 symbols, with each symbol counting as one call toward the daily limit. Although it doesn't explicitly name get_stock as an alternative for single queries, the batch/limit details make the intended use case 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?

The description goes beyond the annotations by disclosing the empty watchlist behavior (empty items[] if nothing starred), pointing to the dashboard for adding symbols, and specifying Pro tier access. It also enumerates all returned fields, which the annotations (readOnlyHint, idempotentHint, destructiveHint) do not cover.

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

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

The description is concise and well-structured, starting with a clear summary, followed by a bulleted list of return fields and short notes on empty behavior, Pro tier, and disclaimer. No redundant or irrelevant 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?

For a simple zero-parameter read-only tool, the description covers purpose, output schema in prose, empty behavior, access restriction, and disclaimer. The existing output schema and annotations further complement it, leaving no critical gaps.

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

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

The tool has zero parameters, and the schema is empty. The description clarifies that the tool uses the caller's implicit identity, so no explicit input is needed. This aligns with the baseline for no-parameter tools.

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

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

The description clearly states that the tool returns the caller's Stocklake watchlist (starred symbols), enriched with live price, technicals, and AI verdict. This is a specific verb+resource combo that distinguishes it from sibling tools focused on individual stocks or market-wide 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 implies usage: use this when you need the user's watchlist data. It also notes the Pro tier restriction, but it does not explicitly name alternatives or state when not to use it. The context is clear, but exclusion guidance is missing.

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