FlashAlpha

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

Beyond the readOnlyHint annotation, the description adds crucial behavioral context: it specifies the Black-Scholes model and enumerates the ten specific greeks returned. The 'no market data' disclosure clarifies this performs local computation without external API calls.

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?

Two sentences with zero waste: first establishes the action and complete output set, second delivers the critical behavioral distinction. Front-loaded with the verb and resource, every word earns its place.

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

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

For a calculation utility with 100% schema coverage and readOnlyHint declared, the description adequately covers outputs (explicit greek list) and operational model. Minor gap: lacks return format description, though no output schema exists to mandate this.

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 100% schema description coverage, the structured documentation already explains all six parameters (spot, strike, dte, sigma, type, apiKey). The description provides mathematical context (Black-Scholes) but does not elaborate on individual parameter semantics, meeting the baseline expectation.

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

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

The description explicitly states 'Calculate Black-Scholes option greeks' with a comprehensive list of outputs (delta through color). The 'Pure math' qualifier distinguishes it from market-data siblings like get_option_quote.

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?

'Pure math — no market data needed' provides clear context for when to use this (theoretical calculations) versus alternatives that fetch live prices. While it doesn't explicitly name sibling tools, the distinction is unambiguous.

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 valuable methodological context (BSM expected value calculation) beyond the readOnlyHint annotation, but does not disclose output format, rate limits, or error conditions that would help an agent handle the response appropriately.

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 two-sentence structure is optimally front-loaded: the first declares the purpose and domain, the second explains the computational methodology. No words are wasted.

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?

While input parameters are fully documented via the schema and the mathematical approach is explained, the absence of an output schema and lack of description regarding return values (e.g., whether it returns a fraction, percentage, or dollar amount) leaves a significant gap for an invocation 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 100% schema description coverage establishing a baseline, the description adds context by indicating parameters are used in a BSM calculation comparing expected value to premium, though it does not elaborate on individual parameter constraints or relationships beyond the schema 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 explicitly states the tool computes 'Kelly criterion optimal position sizing for an option trade' and specifies the methodology ('Uses BSM expected value vs premium'), clearly distinguishing it from sibling tools like calculate_greeks which focus on different metrics.

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?

While the description implies usage through explaining the Kelly criterion methodology ('edge-maximizing bet size'), it lacks explicit guidance on when to use this sizing approach versus fixed-position alternatives or prerequisites for valid inputs.

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

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

Annotations declare readOnlyHint=true, confirming this is a safe read operation. The description adds valuable behavioral context by specifying exactly what data is returned (plan, daily quota limit, usage today, remaining calls), which compensates for the lack of an output schema.

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

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

The description is a single, efficient sentence with the action verb front-loaded. The colon-separated list of return fields provides maximum information density with zero waste.

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

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

For this simple, single-parameter read-only tool, the description is complete. Crucially, since no output schema exists, the description explicitly lists the returned fields (plan, quota, usage, remaining calls), providing the necessary context for the agent to understand what data will be retrieved.

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 100% schema description coverage for the single apiKey parameter ('Your FlashAlpha API key'), the schema carries the full burden of parameter documentation. The description adds no parameter details, meeting the baseline score of 3 for high-coverage schemas.

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 uses a specific verb ('Get') and resource ('account info'), and clearly distinguishes this tool from its siblings (all financial market data tools like get_stock_quote, calculate_greeks, etc.) by focusing on account metadata rather than market 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?

While the distinction from financial data siblings is clear from the description's focus on account metadata (plan, quota, usage), there is no explicit guidance on when to use this versus alternatives, or prerequisites like needing to check rate limits before heavy usage.

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

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

Annotations declare readOnlyHint=true, and the description aligns with this read-only 'Get' operation. The description adds valuable behavioral context beyond annotations: the 'Alpha tier required' constraint (pricing/auth tier), and detailed enumeration of returned data types (arbitrage detection, greeks surfaces) that compensate for the missing output schema. Does not mention rate limits or caching behavior.

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

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

Two sentences total with zero waste. First sentence front-loads the capability with a dense but readable list of specific outputs. Second sentence provides the critical auth constraint. Every word earns its place; no redundant phrases or 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 lack of output schema, the description effectively enumerates specific return values (SVI parameters, variance swap fair values, etc.) to set expectations. It covers the auth requirement (Alpha tier). With only 2 parameters at 100% schema coverage and read-only annotations, the description provides sufficient context for invocation, though rate limits or data freshness could strengthen it 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?

Input schema has 100% description coverage for both parameters (symbol and apiKey are fully documented). The description focuses on output features rather than input parameters, adding no semantic clarification beyond what the schema already provides. With high schema coverage, this meets the baseline expectation.

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 opens with specific verb (Get) and resource (advanced volatility analytics), then enumerates specific outputs (SVI parameters, forward prices, greeks surfaces, variance swap fair values) that clearly distinguish it from the sibling 'get_volatility' tool. The 'Alpha tier required' clause further differentiates it as a premium offering.

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 the prerequisite 'Alpha tier required' which signals authentication constraints. However, it lacks explicit guidance on when to choose this tool over the sibling 'get_volatility' (e.g., no 'use this when you need X instead of Y' guidance). The feature list implies advanced use cases but doesn't explicitly direct the agent.

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

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

Beyond the readOnlyHint annotation, the description adds valuable interpretation context explaining that CHEX reveals 'how dealer delta hedging changes as time passes' and identifies the output as 'time-decay-driven flows,' helping the agent understand what the data represents conceptually.

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 consists of two highly efficient sentences with zero waste. The first identifies the resource and scope, while the second explains the behavioral insight, front-loading the essential action 'Get charm exposure' immediately.

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 read-only data retrieval tool with three parameters, the description adequately explains the domain-specific concept (charm exposure) and its financial significance. Given the lack of output schema, it appropriately describes what the returned data represents rather than its structure.

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

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

With 100% schema description coverage, the baseline is 3. The description mentions 'by strike' which hints at output organization but adds no specific guidance about input parameters (symbol, expiration, apiKey) beyond what the schema already provides.

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 'charm exposure (CHEX) by strike' and distinguishes it from sibling exposure tools (get_gex, get_dex, get_vex) by explaining it specifically relates to 'time-decay-driven flows' and dealer delta hedging changes over time.

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 through explaining the financial insight provided (time-decay analysis), but lacks explicit guidance on when to choose this over sibling exposure tools like get_gex or get_dex, and states no 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?

Annotations already declare readOnlyHint=true. The description adds 'VWAP-weighted buy vs write across the full flow tape' and 'Alpha tier' but does not disclose potential pitfalls (e.g., data latency, window constraints). No contradiction with annotations.

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

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

Description is one sentence with dash-separated clause, front-loaded with key concept. It is efficient but includes 'Alpha tier' which is not essential. Could be slightly more structured but overall 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?

No output schema provided, and description only says 'shows whether dealers are net long or short premium' without detailing return format (e.g., numeric, boolean). Lacks explanation of 'Alpha tier'. For a simple tool, more output context is needed.

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

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

Schema coverage is 100%, so baseline is 3. The description mentions 'configurable window' but adds no significant meaning beyond the schema's parameter descriptions. No enum or nested objects.

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 tool name and title clearly indicate 'Get Dealer Net Premium'. The description explains it calculates net dealer options premium (VWAP-weighted buy vs write) and shows dealer net long/short position. This distinguishes it from siblings like get_gex, get_dex, etc.

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

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

The description implies usage for checking dealer positioning but does not explicitly state when to use versus alternatives. Siblings like get_flow_dealer_risk, get_chex, get_dex exist, but no guidance on selection 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?

While annotations indicate the tool is read-only, the description adds crucial interpretive context that the data represents 'dealer delta' and 'directional bias from options hedging,' helping the agent understand this reflects market maker positioning rather than customer flows. It does not disclose rate limits or error behaviors.

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 two-sentence structure is optimally efficient: the first establishes the resource and grouping dimension, while the second clarifies the financial interpretation. No redundancy or extraneous text 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?

Given the complete input schema, the description adequately covers the tool's conceptual purpose but lacks output specification (e.g., whether it returns a list of strikes with delta values). For a financial data tool without an output schema, additional context on return format would improve 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?

With 100% schema description coverage, the baseline is appropriately met. The description mentions 'by strike' hinting at the data structure, but does not augment parameter semantics—for example, explaining what occurs when expiration is null or how strike granularity is determined.

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 defines DEX as delta exposure and specifies it is organized 'by strike' with 'net dealer delta,' effectively distinguishing it from sibling tools like get_gex (gamma) or get_vex (vega). However, the verb 'Get' is generic and lacks the precision of more specific actions like 'Calculate' or 'Retrieve'.

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 no guidance on when to select this tool versus alternatives such as get_exposure_summary or get_gex. It fails to specify scenarios where analyzing delta exposure is preferable to other Greeks or aggregate exposure metrics.

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

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

Annotations declare readOnlyHint=true, and the description aligns with that. It adds value by detailing the computational outputs (correlation premium, dispersion setup, etc.) and the access requirement (alpha tier). 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?

Two sentences, front-loaded with purpose. Efficient but slightly dense; could be split for readability. 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?

Describes all computed outputs (correlation premium, dispersion setup, implied vol, per-constituent vol contribution) despite no output schema. Mentions access requirement. Fully covers what the agent needs to know 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 100%, so the schema already documents each parameter. The description adds high-level context (e.g., 'index anchors implied correlation', 'horizon for realized correlation') but does not provide significant extra detail beyond the schema descriptions.

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

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

The description clearly states that the tool computes implied vs realized correlation, dispersion trade setup, implied vol of index vs basket, and per-constituent vol contribution. It uses specific verbs ('Returns', 'Use for') and uniquely identifies the resource (dispersion/correlation) among many 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?

Explicitly states use cases ('Use for dispersion trading, correlation premium sizing, or cross-asset vol arb') and a prerequisite ('Alpha tier required'). Does not explicitly mention when not to use or alternatives, but the context is clear enough among siblings.

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

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

Annotations already set readOnlyHint=true. The description adds valuable behavioral context by detailing what each kind computes (e.g., 'splits front-expiry straddle into jump vs baseline-diffusion', 'IV-crush distribution: live crush estimate and median/p25/p75/best/worst'). 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 dense but well-structured, using a bullet-like list for the six enum values. Every sentence adds value. It could be split into a summary sentence and a list for better readability, but it's concise enough.

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 no output schema, so the description should convey return format. While it describes the conceptual output for each kind (e.g., 'EV/implied/actual moves'), it lacks details on the structure (e.g., what fields are returned). Given the complexity, more output context would help.

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 100%, so the description is not required to repeat param details, but it adds significant meaning by explaining each enum value of 'kind' (expected_move, history, etc.) in business terms. This goes beyond the schema's one-line descriptions.

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

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

The description clearly states it 'get earnings analytics for a symbol across six lenses', enumerating each kind with a concise explanation (e.g., expected_move, history, iv_crush). This is specific and distinguishes it from sibling tools like get_earnings_calendar or get_expected_move.

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 earnings analytics but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_earnings_calendar for listing events, get_expected_move for a single lens). No when-not or alternative tool references.

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 state readOnlyHint: true, so the tool is read-only. The description adds behavioral context by listing return fields and parameter details (e.g., default days-ahead window, filter semantics). It does not contradict annotations and provides useful transparency beyond 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 two sentences with no redundant information. Front-loaded with the core purpose, it efficiently covers functionality, parameters, and return fields. Every sentence earns its place.

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

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

With no output schema, the description compensates by listing all return fields. It explains all parameters and their constraints. However, it does not mention pagination or result limits, which could be relevant for large calendars. Overall, it is sufficiently complete for a filterable list 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 100%, so baseline is 3. The description adds value by explaining parameter purposes in context (e.g., days as 'forward window', symbols as comma-separated list, importance as minimum rating, apiKey usage with OAuth vs direct key). This extra context elevates the score.

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 an upcoming earnings calendar over a configurable forward window, listing specific fields (event date, session, confirmation status, fiscal period, importance rating, consensus EPS, implied-move percent) and filtering options (symbols, minimum importance, days-ahead window). This fully distinguishes it from siblings like 'get_earnings' (likely single event) and 'get_earnings_screener' (different focus).

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 explains what the tool does but does not explicitly state when to use it over alternatives. It implies usage for upcoming earnings with filtering, but lacks direct comparisons or 'when not to use' guidance. Given the large sibling list, more explicit guidelines would improve clarity.

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 the description adds specific computed fields (implied-move percent, premium ratio, etc.) and configurable parameters, which are not captured in annotations. This provides useful behavioral context beyond the annotation.

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 two sentences, front-loaded with the core purpose, and every word adds value. No redundant or vague phrasing. Excellent conciseness.

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

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

Given the complexity (5 parameters, no output schema), the description covers the tool's purpose, input parameters, and return fields adequately. While it doesn't detail return format, the mentioned fields provide sufficient expectation. Minor gap in not describing the importance filter more precisely.

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 100%, so baseline is 3. The description adds meaningful context beyond schema descriptions by explaining the purpose of each parameter (e.g., 'forward window in days', 'ranking options' with defaults) and compactly summarizing the output fields, which adds 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 the tool is a cross-sectional earnings screener that ranks events by specific criteria (VRP richness, cheapest implied move, etc.) and lists returned fields. This distinguishes it from sibling tools like 'get_earnings' or 'get_earnings_calendar' which focus on raw data.

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

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

The description implies usage for screening upcoming earnings events with configurable ranking, but does not explicitly state when to use this tool versus alternatives. No exclusions or comparative guidance are provided.

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. The description adds that the tool computes the expected move from a straddle, implying a read-only calculation without side effects. It explains the output fields and purpose, which is consistent with the read-only annotation and adds value beyond the structured field.

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 two sentences: the first states the purpose and outputs, the second provides usage guidance. Every word is meaningful; no redundancy or filler. Front-loaded with key information.

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

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

For a tool with 3 parameters, no output schema, and moderate complexity, the description covers the output fields and use cases. It does not explain return format or pagination, but given the tool's simplicity (single symbol, optional expiry) and the listing of output items, it is sufficiently complete.

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

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

Schema coverage is 100% with each parameter having a description. The description does not add detail beyond the schema (e.g., it says 'per expiry' but schema already describes expiry). Baseline 3 is appropriate since the schema does the heavy lifting.

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 a 'straddle-implied expected move per expiry' and enumerates the specific fields (1-sigma range, bounds, straddle price, ATM IV). This is a precise verb+resource definition that distinguishes it from sibling tools like get_volatility or get_option_chain.

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 second sentence explicitly tells when to use the tool: 'Use to size trades, evaluate premium levels, or compare market-implied move vs realized range.' This provides clear context, though it does not mention when to avoid it or name alternative tools.

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, confirming read-only. The description adds behavioral details: equal weights when omitted, normalization to sum 1, and a 50-symbol limit. This goes beyond the annotation's binary flag, though no destructive behaviors or side effects need disclosure.

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 consists of two concise sentences. The first sentence defines the core function, and the second lists use cases. There is no fluff; every word serves a purpose. It is front-loaded with the most critical information.

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

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

Given the tool's moderate complexity and no output schema, the description provides key input details and use cases. However, it does not describe the output format (e.g., single aggregated value or per-symbol breakdown). Adding a brief note on return shape would make it fully complete.

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

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

Schema coverage is 100% with descriptive parameter descriptions. The description adds value by explaining weight handling (equal weights by default, normalized to sum 1) and the maximum symbol count. This clarifies behavior beyond the schema's basic type descriptions.

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

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

The description clearly states it provides a weighted cross-symbol aggregate of GEX, DEX, VEX, CHEX across up to 50 symbols. This specific verb-resource combination distinguishes it from single-symbol exposure tools like get_gex, get_dex, etc., differentiating 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 explicitly lists use cases: portfolio/basket scanner, sector exposure roll-up, custom index dealer positioning. This provides clear context for when to use. However, it does not explicitly state when not to use (e.g., for single-symbol queries), which would strengthen guidance further.

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

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

Annotations already indicate readOnlyHint=true, so the description does not need to disclose safety traits. It lists output components but does not add behavioral context like data freshness or rate limits, making it adequate but not rich.

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?

A single sentence front-loads the core purpose and lists all key output elements. Every phrase adds value, with 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?

Without an output schema, the description outlines the main return components (GEX, DEX, VEX, etc.) and mentions optional parameters. It is nearly complete but could specify the output format (e.g., JSON structure) for full clarity.

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 100% description coverage, so all parameters are documented. The description adds no additional parameter-level meaning beyond the schema, warranting a baseline 3.

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 a unified per-strike exposure sheet with GEX, DEX, VEX, CHEX, DAG, and additional flags, differentiating it from individual sibling tools like get_gex or get_dex. The verb 'get' and resource 'exposure_sheet' match the name and title perfectly.

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 recommends using this tool 'to scan all greeks at every strike in a single call', which implies a comprehensive scan use case. While it does not explicitly mention when not to use it or name alternatives, the context of sibling tools makes the distinction clear.

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

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

With readOnlyHint=true in annotations confirming safe read access, the description adds valuable behavioral context by detailing exactly what financial data is returned (specific exposure types and breakdowns). Since no output schema exists, listing these specific return components (gamma regime, hedging estimates, zero-DTE breakdown) provides crucial transparency about the tool's scope 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 a single, information-dense sentence that is perfectly front-loaded with the action ('Get full exposure summary') followed by a precise enumeration of specific data components. Every term (GEX/DEX/VEX/CHEX, gamma regime, zero-DTE) earns its place by conveying specific financial metrics 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 simple 2-parameter input schema with complete coverage and read-only annotations, the description adequately compensates for the missing output schema by enumerating the specific exposure metrics and breakdowns returned. It is complete enough for an agent to understand the tool's data scope, though mentioning data freshness or update frequency would make it fully comprehensive.

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

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

The input schema has 100% description coverage (symbol and apiKey are both fully documented). The description focuses entirely on output semantics and does not mention input parameters, but with complete schema coverage, no additional parameter explanation is necessary to meet baseline expectations.

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

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

The description clearly states it retrieves a 'full exposure summary' and explicitly lists the specific metrics returned (net GEX/DEX/VEX/CHEX, gamma regime, key levels, hedging estimates, zero-DTE breakdown, top strikes). This effectively distinguishes it from siblings like get_gex, get_dex, get_vex, get_chex, and get_zero_dte by positioning this tool as the comprehensive aggregation of those individual metrics.

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 this is the tool for comprehensive exposure analysis (via 'full exposure summary'), suggesting use when multiple metrics are needed versus individual sibling tools. However, it lacks explicit guidance on when to prefer individual tools (get_gex, get_dex, etc.) over this aggregated view, or any prerequisites/limitations.

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, so the description adds no behavioral context beyond that. No mention of authentication needs, rate limits, or side effects.

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 a single dense sentence that efficiently lists the key outputs. It is concise and front-loaded, though it could benefit from slight restructuring for readability.

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?

Without an output schema, the description adequately explains the tool's return values: adjustment, percent shifts, direction classifier, and plain-English description. This is sufficient for an agent to understand what the tool provides.

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 100%, so the schema already documents all three parameters (apiKey, expiry, symbol). The description does not add additional semantic meaning beyond the schema, meeting the baseline.

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 that the tool returns settled vs live dealer risk shift, GEX/DEX adjustment, percent shifts, direction classifier, and plain-English description. This distinguishes it from sibling tools like get_gex and get_dex by adding adjustment and classification.

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_gex, get_dex, or get_flow_summary. The description lists outputs but does not provide context for when this is the preferred choice.

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 provide readOnlyHint=true for a read operation. The description adds behavioral context: it is 'simulation-aware', computed on effective OI, and more current. No contradictions or hidden side effects are disclosed.

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 two sentences, front-loaded with key metrics and distinguishing feature ('more current'). Every word 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?

No output schema is provided, but the description enumerates the returned metrics (gamma flip, call wall, etc.). It offers enough context for an agent to understand the output, though return structure is not detailed.

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 100% with each parameter described. The description adds no additional semantics beyond the schema; it only explains computation details (effective OI, simulation). Baseline 3 is appropriate.

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

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

The description clearly states the tool provides live, simulation-aware flow levels including gamma flip, call wall, put wall, and max pain. It distinguishes from sibling tools like 'get_levels' by emphasizing it is more current and computed on effective OI.

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 indicates this tool is preferred during the session for more current data than '/v1/exposure/levels'. It implies usage context (live, simulation-aware) but does not explicitly state when to avoid or list alternatives.

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

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

Annotations declare readOnlyHint=true, and the description adds behavioral context by listing the bundle components and the view parameter's behavior. It does not contradict annotations. It could mention data freshness or limitations, but overall transparent.

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

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

Two sentences, no redundant words, front-loaded with the main purpose. Every sentence adds value.

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

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

Without an output schema, the description lists the bundle components, giving the agent a good idea of return values. It could be more specific about the structure of each component, but sufficient for a bundle 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 100% with descriptions for all parameters. The description elaborates on the view parameter ('full simulation-aware live GEX surface' etc.), adding nuance but not essential new meaning. Baseline 3 is appropriate.

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

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

The description clearly states it returns a 'headline flow bundle' listing specific components (effective OI state, live levels, GEX/DEX totals, pin-risk, dealer-risk). It distinguishes from sibling tools by offering a combined bundle and explicitly describes the view parameter's effect.

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 indicates when to use the tool (for the combined live bundle) and when to use specific views (gex, dex, oi). However, it does not explicitly contrast with sibling tools like get_gex or get_dex for individual surfaces, which could clarify when to use this over those.

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 set readOnlyHint=true, confirming no mutation. The description adds behavioral context by specifying it computes using 'effective (simulation-aware) OI' and reflects 'intraday flow changes to dealer positioning,' which goes beyond what annotations convey. 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?

Two concise sentences delivering key information upfront. Every word serves a purpose: stating the tool's output, underlying computation, and dynamic nature. There is no extraneous text or repetition of schema/annotations.

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 mentions a 'full sub-score breakdown' but does not specify what those sub-scores are or the output format, which leaves some ambiguity. Given the tool's complexity and lack of output schema, more detail would improve completeness. However, it is adequate for an agent with basic understanding.

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

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

Schema coverage is 100% (all 3 parameters described). The description does not add extra meaning to the parameters beyond what the schema already provides. It refers to the overall computation but does not elaborate on parameter constraints or formats, so baseline 3 is appropriate.

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

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

The description clearly states it provides a live pin-risk score with a full sub-score breakdown, computed on effective OI. It uses specific verbs and resource names, and the detail about intraday flow changes to dealer positioning helps distinguish it from sibling tools like get_flow_dealer_risk or get_gex.

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 explains what the tool does but provides no guidance on when to use it over alternatives. There is no mention of scenarios, prerequisites, or what distinguishes this from other flow-related tools in the sibling list. An agent would have to infer usage from the purpose alone.

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, indicating a safe read operation. The description adds that it produces a leaderboard or outlier scan, but does not disclose other behavioral traits such as data freshness, rate limits, or pagination behavior.

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

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

The description is two sentences, front-loading the purpose and then succinctly defining the key parameters. Every word adds value; no redundancy or 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?

With no output schema, the description could hint at return values (e.g., list of symbols with net notional). It describes the scan types but lacks details on output format or structure, leaving some ambiguity.

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

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

The input schema is fully described (100% coverage), and the description adds meaningful context: it explains that 'kind' maps to ranked net notional buyers/sellers for leaderboard and absolute net notional for outliers, and clarifies the limit parameter's behavior per scan kind.

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 as a cross-symbol flow leaderboard/outlier scan, specifying asset classes ('options' | 'stocks') and scan kinds ('leaderboard' | 'outliers'). It distinguishes itself from sibling flow tools by explicitly focusing on cross-symbol ranking and outlier detection.

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 scanning across symbols but does not provide explicit guidance on when to use this tool over alternatives like get_flow_live or get_flow_summary. No when-not or alternative references are 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 declare readOnlyHint: true, and the description aligns with that by describing a read-only data feed. The description adds behavioral context by specifying the two output modes (full feed vs summary) and the type of data (score breakdown, greeks, delta-notional). No contradictions; the additional detail complements 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 exactly two sentences, front-loading the core purpose and then highlighting the key option. Every word contributes meaning; no fluff or repetition. It is optimally concise while remaining informative.

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 there is no output schema, the description does a good job of summarizing what the tool returns for both modes (full feed has score, greeks, delta-notional; summary has net bullish/bearish and opening/closing premium). It covers the main use cases and parameter effects. However, it could mention data freshness or any limitations to be fully 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?

All 7 parameters are documented in the schema (100% coverage). The description adds value by explaining the summarize parameter's purpose ('cheap net bullish/bearish + opening/closing premium roll-up'), which goes beyond the schema's description. For other parameters, the description does not add extra semantics, but the baseline is 3, so a 4 is justified due to this enhancement.

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 'scored, classified unusual options activity feed' and lists specific components like sweeps, blocks, smart money, and intent classification. It distinguishes itself from other flow tools by emphasizing scoring, greeks enrichment, and two modes (full feed vs summary). This sufficiently differentiates it from siblings like get_flow_live or get_flow_summary.

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

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

The description gives explicit guidance on when to use the summary mode via the summarize parameter, but does not compare to alternative flow tools or state when not to use this tool. While the distinct features (scored, classified) imply its niche, explicit exclusion of raw flow scenarios would improve clarity.

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

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

Annotations set readOnlyHint=true, consistent with description's read-only nature. Description adds useful behavioral context: simulation-awareness, low cost to poll, and specific output fields. 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?

Two sentences, no wasted words. The first sentence front-loads the purpose and output fields. Concise and well-structured.

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?

Although no output schema is provided, the description lists output fields (flow direction, delta, GEX). It could mention potential error conditions or relationship to other detailed tools, but overall sufficient for a summary 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 100% with all parameters described. Description does not add additional parameter semantics beyond the schema, so baseline score of 3 applies.

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 'at-a-glance simulation-aware flow card' with specific fields (flow direction, intraday delta, live GEX). It differentiates from siblings like get_flow_live or get_gex by emphasizing 'summary' and 'cheap to poll'.

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

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

Explicitly says 'cheap to poll across a watchlist', implying suitability for frequent checks and bulk monitoring. However, it does not explicitly contrast with alternatives or state when not to use.

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

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

With annotations covering readOnlyHint, the description adds valuable behavioral context about output semantics—specifically what the data represents (dealer positioning, support/resistance levels) and domain concepts (gamma flip, walls). Does not contradict the readOnly annotation.

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 tightly constructed sentences with zero waste. Front-loaded with the core action (Get GEX), followed by specific data points returned, and closing with the analytical insight (support/resistance). Every phrase earns its place.

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

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

Despite lacking an output schema, the description adequately explains the conceptual output (dealer positioning, walls, flip points) and domain-specific interpretations. Sufficient for a specialized financial tool, though could benefit from mentioning data freshness or granularity.

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 100%, with all parameters (symbol, apiKey, expiration) fully documented in the schema. The description does not add parameter-specific syntax or semantics, which aligns with the baseline score of 3 for high-coverage schemas.

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 uses specific verbs ('Get') and resources ('gamma exposure') and distinguishes from siblings by specifying unique gamma concepts like 'gamma flip,' 'call/put walls,' and 'dealer gamma positioning' that differentiate it from delta (DEX) or vanna (VEX) exposure tools.

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

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

Provides clear context for when to use the tool ('Reveals where dealer hedging creates support/resistance'), implying its utility for identifying key price levels. However, it lacks explicit comparison to siblings like get_exposure_summary or get_chex regarding when to prefer this specific exposure metric.

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 include readOnlyHint=true, so the description adds value by specifying the time range (since April 2018, minute-level granularity) and update frequency (EOD-stamped). 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?

Two concise sentences plus tier mention. Every word adds value with no repetition or 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?

Despite no output schema, the description lists the returned analytics types. It covers the essential behavioral context for a complex historical tool, though it could mention data frequency or rate limits.

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 100%, so baseline is 3. The description adds the time range for the 'at' parameter (any minute since April 2018), which goes beyond schema and helps the agent understand valid inputs.

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 replays advanced volatility analytics, listing specific components (SVI parameters, forward prices, etc.). It distinguishes from siblings like get_historical_volatility (basic) and get_advanced_volatility (current).

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 use for historical advanced volatility replay and mentions the Alpha tier. It does not explicitly state when not to use or list alternatives, but the sibling context provides differentiation.

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 provide readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the temporal scope ('since April 2018') and the 'Alpha tier' context, which suggests potential access limitations or experimental status. However, it doesn't disclose rate limits, authentication details beyond the apiKey parameter, or return format, leaving behavioral gaps.

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 front-loaded with the core purpose in the first clause. The second clause ('Alpha tier.') adds necessary context without redundancy. However, it could be slightly more structured by explicitly separating usage notes from the core purpose.

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

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

Given the tool's complexity (historical data retrieval with three parameters), annotations cover safety (readOnlyHint), and schema coverage is complete. However, there's no output schema, and the description doesn't explain return values or data format. The 'Alpha tier' note hints at limitations but lacks detail, making it minimally adequate but with clear gaps.

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

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

Schema description coverage is 100%, with clear descriptions for all three parameters (symbol, apiKey, at). The description doesn't add any parameter-specific semantics beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even without param info in the 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 the tool's purpose: 'Replay charm exposure (CHEX) by strike at any minute since April 2018.' It specifies the verb ('Replay'), resource ('charm exposure (CHEX)'), and temporal scope ('since April 2018'). However, it doesn't explicitly differentiate from sibling tools like 'get_chex' or 'get_historical_exposure_summary', which would be needed for a score of 5.

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 no guidance on when to use this tool versus alternatives. It mentions 'Alpha tier' but doesn't explain what this means for usage. There are no explicit when/when-not instructions or references to sibling tools, leaving the agent without contextual usage cues.

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 provide readOnlyHint=true, and the description adds valuable context about the tool's purpose as a coverage checker and its 'Alpha tier' status. It doesn't contradict annotations and adds meaningful behavioral information beyond what annotations provide.

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?

Two sentences with zero waste. First sentence defines purpose and output format, second sentence provides crucial usage guidance. Every word earns its place and information is front-loaded appropriately.

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 good annotations and clear purpose, the description provides sufficient context about its role in the workflow. The main gap is lack of output format details, but given the tool's straightforward purpose and annotations, it's 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?

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3.

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

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

The description clearly states the verb 'List' and resource 'symbols backfilled in the historical archive' with specific attributes like 'coverage windows, day counts, and gaps'. It distinguishes from siblings by focusing on coverage metadata rather than actual historical data queries.

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

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

Explicitly states when to use this tool: 'Call this first to check whether a symbol + date range is queryable before sending a replay request.' This provides clear guidance on its role as a prerequisite check, distinguishing it from actual data retrieval tools.

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

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

Annotations indicate readOnlyHint=true, confirming this is a safe read operation. The description adds context about the data availability ('since April 2018') and tier requirement ('Alpha tier'), which are useful beyond annotations. However, it lacks details on rate limits, response format, or potential errors, leaving behavioral gaps.

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 front-loaded with key information in a single sentence, with no wasted words. However, it could be slightly improved by structuring usage hints or distinguishing from siblings, but it remains efficient and clear.

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 lack of output schema and annotations only covering read-only status, the description is moderately complete. It specifies the data scope and tier but omits details on return values, error handling, or performance considerations. For a historical data tool with no output schema, this leaves room for improvement in guiding the agent.

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

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

Schema description coverage is 100%, with clear documentation for all parameters (symbol, apiKey, at). The description does not add any semantic details beyond the schema, such as explaining 'delta exposure (DEX)' or providing examples. Baseline 3 is appropriate as the schema adequately covers parameter meanings.

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 action ('Replay delta exposure (DEX) by strike') and resource ('at any minute since April 2018'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'get_dex' or 'get_historical_chex', which might offer similar historical data for different metrics.

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 no guidance on when to use this tool versus alternatives, such as 'get_dex' (likely for current data) or other historical tools like 'get_historical_chex'. It mentions 'Alpha tier' as a requirement but does not explain usage context or exclusions, leaving the agent to infer based on tool names alone.

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, so the agent knows this is a safe read operation. The description adds valuable context about the historical scope ('since April 2018'), data granularity ('at any minute'), and access tier ('Alpha tier'), which aren't covered by annotations. However, it doesn't describe response format, rate limits, or error conditions.

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 a single, efficient sentence that packs essential information: action, resource, historical scope, data components, and access tier. Every element earns its place with zero wasted words, making it front-loaded and highly scannable.

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 good annotations and full schema coverage, the description provides strong contextual completeness. It covers the historical nature, data components, and access requirements. The main gap is the lack of output schema, but the description compensates somewhat by listing what data will be returned (net GEX/DEX/VEX/CHEX, regime, hedging estimates, top strikes).

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 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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

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

The description clearly states the specific action ('Replay') and resource ('full exposure summary') with detailed components listed (net GEX/DEX/VEX/CHEX, regime, hedging estimates, top strikes). It distinguishes from siblings like get_exposure_summary by specifying historical capability ('at any minute since April 2018') and tier requirement ('Alpha tier').

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 this tool: for historical data replay since April 2018 with Alpha tier access. It doesn't explicitly state when not to use it or name alternatives, but the historical focus and tier requirement give sufficient guidance for selection among siblings.

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

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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful behavioral context: it specifies the temporal range ('since April 2018'), mentions the return format ('same shape as live /v1/exposure/gex'), and notes the 'Alpha tier' requirement for the apiKey. However, it lacks details on rate limits, error conditions, or pagination, which would be valuable given the absence of an output schema.

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

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

The description is extremely concise and front-loaded: the first sentence covers purpose, scope, and output format, while the second adds tier information. Every sentence earns its place with no redundant or vague language, making it efficient for an AI agent to parse.

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

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

Given the tool's complexity (historical data retrieval with three parameters), high schema coverage, and readOnlyHint annotation, the description is mostly complete. It covers purpose, temporal scope, output format, and tier requirement. However, the lack of an output schema means the description could better explain the return structure or error handling, slightly reducing 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 100%, so the schema fully documents all three parameters (symbol, apiKey, at). The description does not add any parameter-specific information beyond what the schema provides, such as examples for 'symbol' beyond 'SPY' or clarifications on 'at' format. This meets the baseline of 3 when schema coverage is high.

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 specific action ('Replay gamma exposure (GEX) by strike'), resource ('historical GEX'), and temporal scope ('any minute since April 2018'), distinguishing it from the sibling 'get_gex' tool which presumably provides current/live data. The mention of 'same shape as live /v1/exposure/gex' further clarifies the output format.

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 this tool: for historical GEX data since April 2018, with an implied alternative being the 'get_gex' tool for current data. However, it does not explicitly state when NOT to use it or name the sibling alternative directly, which prevents a perfect score.

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, indicating a safe read operation. The description adds valuable context beyond annotations: it specifies the data types returned (gamma flip, call/put walls, etc.), the historical range (since April 2018), and the access tier (Alpha). It does not disclose rate limits, auth needs beyond the API key, or output format details, but with annotations covering safety, this is sufficient for a high score.

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 a single, efficient sentence that front-loads key information: action, resources, temporal scope, and access tier. Every word earns its place with no redundancy or waste, making it highly concise and well-structured.

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 (historical data retrieval with specific financial metrics), annotations cover safety (readOnlyHint), and schema covers parameters fully. However, there is no output schema, and the description does not detail the return format or structure of the key levels. It compensates by listing the types of levels returned, but more output context would be beneficial for full 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 100%, so the schema already documents all three parameters (symbol, apiKey, at) with descriptions. The description does not add any parameter-specific semantics beyond what the schema provides, such as format details for 'at' or examples for 'symbol'. Baseline 3 is appropriate when the schema handles parameter documentation effectively.

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

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

The description clearly states the verb 'replay' and specifies the exact resources: 'key options levels (gamma flip, call/put walls, highest OI strike, 0DTE magnet)'. It distinguishes from siblings like 'get_levels' (likely current) by emphasizing historical data since April 2018 and specifying 'Alpha tier'.

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: 'at any minute since April 2018' and 'Alpha tier', indicating temporal scope and access requirements. However, it does not explicitly state when to use this tool versus alternatives like 'get_historical_volatility' or 'get_historical_stock_quote', nor does it mention exclusions or prerequisites beyond the API key.

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 provide readOnlyHint=true, indicating a safe read operation. The description adds context about the historical scope (since April 2018) and the 'Alpha tier' requirement, which hints at access restrictions. However, it doesn't disclose behavioral traits like rate limits, data format, or pagination, leaving gaps 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 key information in a single sentence, efficiently listing the metrics and historical scope. The 'Alpha tier' note adds necessary context without redundancy. It could be slightly more structured by separating usage hints, but overall it's concise and avoids waste.

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

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

Given the tool's complexity (historical financial data retrieval) and lack of output schema, the description is moderately complete. It covers what data is retrieved and the time range, but doesn't explain return values, error handling, or data granularity. With annotations covering safety, it's adequate but has clear gaps for full agent understanding.

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

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

Schema description coverage is 100%, with clear parameter descriptions in the input schema. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining the 'at' parameter's relation to the historical data or the 'apiKey' requirement. Baseline 3 is appropriate since the schema handles the heavy lifting.

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 multiple financial metrics (max pain, pain curve, dealer alignment, pin probability) with a historical scope since April 2018. It specifies the verb 'replay' and resource 'any minute since April 2018,' but doesn't explicitly differentiate from sibling tools like get_historical_option_quote or get_historical_stock_quote, which focus on different data types.

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 historical financial analysis by mentioning 'Alpha tier' and the date range, suggesting it's for premium users accessing past data. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like get_historical_volatility or get_historical_surface, which might offer related metrics.

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 provide readOnlyHint=true, indicating a safe read operation. The description adds context about the data scope ('since April 2018') and tier ('Alpha tier'), which are useful behavioral details not covered by annotations, but does not disclose rate limits, auth specifics beyond the apiKey parameter, or output format.

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

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

The description is front-loaded with the core purpose in a single, efficient sentence, followed by a brief tier note. Every word serves a purpose with no redundancy, making it appropriately sized and well-structured.

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 (historical data retrieval with 3 parameters), annotations cover safety (readOnlyHint), but there is no output schema, and the description lacks details on return values or error handling. It is minimally adequate but has clear gaps in completeness for an agent's understanding.

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

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

Schema description coverage is 100%, so the schema fully documents parameters (symbol, apiKey, at). The description does not add meaning beyond the schema, such as explaining the 'at' parameter's relation to historical data or the 'Alpha tier' implication for apiKey, resulting in a baseline score of 3.

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 specific action ('Replay the verbal narrative analysis') and resource ('at any minute since April 2018'), distinguishing it from sibling tools like 'get_narrative' (likely current) and other historical data tools by specifying the content type (regime, key-level commentary, prior-day comparison).

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 historical narrative retrieval ('since April 2018') and mentions 'Alpha tier', but does not explicitly state when to use this tool versus alternatives like 'get_narrative' (presumably for current data) or other historical tools, nor does it provide exclusions or prerequisites beyond the tier note.

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?

While annotations declare readOnlyHint=true, the description adds valuable behavioral context by specifying the data source ('ClickHouse tick archive') and confirming filtering mechanics. It does not contradict the read-only annotation.

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 with zero redundancy. The description front-loads the core purpose, follows with filtering hints, and closes with provenance context. Every sentence earns its place.

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

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

Given the 100% schema coverage and readOnly annotation, the description adequately covers the tool's purpose and data source. Minor gap: lacks description of return values, though this is somewhat mitigated by the straightforward 'quote' terminology.

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 100% schema description coverage, the schema fully documents all parameters. The description references key parameters ('expiry, strike, and type') but adds no semantic depth beyond the schema's definitions, meeting the baseline expectation.

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 core action ('Get historical option quote'), specifies the temporal scope ('from a specific date'), and distinguishes itself from siblings like get_option_quote (real-time) and get_historical_stock_quote (different asset class) through explicit resource naming.

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 filtering capabilities ('Filter by expiry, strike, and type') which implies usage patterns, but does not explicitly state when to use this tool versus get_option_quote or other data retrieval 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 declare readOnlyHint=true (safe read operation). Description adds valuable behavioral context beyond annotations by specifying 'Data from ClickHouse tick archive'—disclosing the underlying data source and implying tick-level granularity. Does not mention rate limits, data retention limits, or behavior when requested time has no trades.

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?

Two sentences with zero waste. First sentence front-loads the core action and key parameters (date/time). Second sentence efficiently adds data source attribution. Every word earns its place; no redundancy with title or schema.

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?

Appropriately complete for a 4-parameter lookup tool with full schema coverage and readOnly annotations. Missing output description (what fields are returned—OHLC, bid/ask, volume?) would elevate this further, but the 'quote' terminology provides reasonable expectation of standard stock quote fields given domain context.

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

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

Schema description coverage is 100%, providing detailed formats (YYYY-MM-DD, HH:mm) for date and time parameters. Description references 'date and time' aligning with parameters, but does not add semantic meaning, validation rules, or examples beyond what the schema already documents. Baseline 3 appropriate given schema completeness.

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?

Specific verb 'Get' with clear resource 'historical stock quote' and scope 'from a specific date and time'. Effectively distinguishes from sibling 'get_stock_quote' (real-time) via 'historical' modifier and from 'get_historical_option_quote' via 'stock' specificity. The 'ClickHouse tick archive' attribution further clarifies data provenance.

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 implied usage through 'historical' keyword and date/time references, suggesting use for past market data retrieval. However, lacks explicit guidance on when to choose this over 'get_stock_quote' (real-time) or what constitutes valid historical ranges. No mention of prerequisites like market hours or timezone handling.

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, indicating a safe read operation. The description adds useful context about the data timeframe (since April 2018) and Alpha tier requirement, but doesn't disclose behavioral traits like rate limits, pagination, or response format. With annotations covering the safety profile, the description adds moderate value without 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 a single, dense sentence with zero waste. It front-loads the core purpose ('Replay the comprehensive stock summary'), specifies the timeframe and data components, and notes the tier requirement—all efficiently packaged.

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 (historical data with multiple metrics) and lack of output schema, the description is reasonably complete. It covers the data scope and tier requirement, but doesn't explain the return format or structure. With good annotations and schema coverage, it's mostly adequate, though output details would enhance completeness.

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

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

Schema description coverage is 100%, with all three parameters well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, but mentions the Alpha tier requirement which relates to apiKey. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific action ('Replay') and resource ('comprehensive stock summary') with detailed content enumeration (price, IV, VRP, exposure, flow, macro). It distinguishes from siblings by specifying historical data since April 2018, unlike real-time tools like get_stock_summary, and mentions the Alpha tier requirement.

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 about when to use it: for historical data at any minute since April 2018. It implies usage for historical rather than current data, but doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools, though the historical vs real-time distinction is clear.

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

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

Annotations provide readOnlyHint=true, and the description adds valuable context beyond this: it specifies the historical range ('since April 2018'), data refresh behavior ('EOD-stamped', 'refresh daily'), and tier requirement ('Alpha tier'). This enhances understanding of the tool's behavior without contradicting annotations.

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

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

The description is front-loaded with core functionality, uses two efficient sentences with no wasted words, and includes essential qualifiers ('EOD-stamped', 'Alpha tier') that earn their place by clarifying scope and requirements.

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 (historical data retrieval with specific parameters), annotations cover safety (read-only), and schema fully documents inputs, the description adds necessary context like data range and refresh behavior. However, without an output schema, it could briefly hint at return format (e.g., grid structure) for slightly better 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 100%, so parameters are well-documented in the schema. The description does not add meaning beyond the schema (e.g., it doesn't explain 'symbol' beyond ticker or 'at' beyond timestamp format), meeting the baseline of 3 for high schema coverage.

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

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

The description clearly states the specific action ('Replay the implied volatility surface grid') with precise resource ('at any minute since April 2018') and distinguishes from siblings by specifying 'EOD-stamped (SVI parameters refresh daily)' which differentiates it from real-time or differently calculated volatility tools in the sibling list.

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 context through 'Alpha tier' and historical timeframe, but does not explicitly state when to use this tool versus alternatives like 'get_historical_volatility' or 'get_volatility'. It provides some guidance but lacks explicit comparison or exclusion criteria.

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

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

Annotations indicate readOnlyHint=true, so the agent knows this is a safe read operation. The description adds some behavioral context: it specifies the data availability ('since April 2018') and tier restriction ('Alpha tier'), which are useful beyond annotations. However, it lacks details on rate limits, response format, or error handling, leaving gaps in behavioral understanding.

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

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

The description is concise and front-loaded: a single sentence covers the core functionality, followed by a brief tier note. There's no wasted text, and it efficiently communicates key points. However, it could be slightly more structured by separating usage notes, but it's well within acceptable bounds.

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 (historical data retrieval with 3 required parameters), annotations cover safety (read-only), but there's no output schema. The description adds temporal scope and tier info, but lacks details on return values (e.g., data format, structure) or error cases. It's minimally adequate but has clear gaps for an agent to use effectively.

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 100%, with clear parameter descriptions in the schema (e.g., 'at' as timestamp, 'apiKey' as API key, 'symbol' as ticker). The description doesn't add any parameter-specific semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate since the schema fully documents parameters.

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

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

The description clearly states the tool's purpose: 'Replay vanna exposure (VEX) by strike at any minute since April 2018.' It specifies the action (replay), resource (VEX), and temporal scope (since April 2018). However, it doesn't explicitly differentiate from sibling tools like 'get_vex' (which likely provides current VEX) or other historical tools, missing full sibling distinction.

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

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

The description provides minimal usage guidance: it mentions 'Alpha tier,' implying access requirements, but offers no explicit when-to-use rules, alternatives, or exclusions. For example, it doesn't clarify when to use this versus 'get_historical_volatility' or other historical tools, leaving the agent without clear selection criteria.

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 provide readOnlyHint=true, indicating a safe read operation. The description adds context beyond annotations by specifying the data availability ('since April 2018'), the granularity ('any minute'), and the access tier ('Alpha tier'), which are useful behavioral traits. However, it doesn't disclose rate limits, error handling, or response format details, leaving gaps in 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 concise with two sentences that efficiently convey key information: the tool's function and its tier. It's front-loaded with the main purpose, though the second sentence 'Alpha tier' could be integrated more smoothly. Overall, it avoids unnecessary details and earns its place.

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

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

Given the tool's complexity (historical volatility analytics with 3 parameters) and the presence of annotations (readOnlyHint) but no output schema, the description is moderately complete. It covers the scope and access tier but lacks details on output structure, error cases, or how it differs from siblings, leaving room for improvement in contextual understanding.

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

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

Schema description coverage is 100%, with clear parameter descriptions in the input schema (e.g., 'As-of timestamp: YYYY-MM-DDTHH:mm:ss (ET) or YYYY-MM-DD'). The description doesn't add significant meaning beyond this, as it only mentions 'at any minute' and 'Alpha tier' loosely related to parameters. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose: 'Replay volatility analytics... at any minute since April 2018.' It specifies the action ('replay') and resource ('volatility analytics') with details like ATM IV, realised vol, etc. However, it doesn't explicitly differentiate from sibling tools like 'get_volatility' or 'get_advanced_volatility' beyond mentioning 'Alpha tier,' which is insufficient for full sibling distinction.

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

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

The description implies usage context by stating 'at any minute since April 2018' and 'Alpha tier,' suggesting it's for historical data retrieval within a specific time range and access level. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_volatility' or 'get_historical_surface,' and no exclusions or prerequisites 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?

Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context beyond annotations: it explains the 'leak-free' nature of percentiles and z-scores with date-bounded SQL logic, specifies the historical data range (since April 2018), and mentions the Alpha tier requirement. This provides important implementation details that annotations don't 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 perfectly front-loaded and concise - every sentence earns its place. The first sentence establishes the core functionality, the second explains the critical 'leak-free' implementation detail, and the third specifies the tier requirement. No wasted words or redundant information.

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

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

Given the tool's complexity (historical data replay with leak-free calculations), the description provides good context about the data range, calculation methodology, and tier requirement. However, without an output schema, it doesn't describe the return format or structure of the VRP dashboard metrics. The annotations cover safety (readOnlyHint) but more output information would be helpful.

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 100% schema description coverage, the input schema already fully documents all three parameters. The description doesn't add any additional parameter semantics beyond what's in the schema descriptions. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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

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

The description clearly states the tool's function with specific verbs ('Replay VRP dashboard') and resources ('z-score, percentile, regime, strategy scores'), and distinguishes it from siblings by specifying historical data since April 2018. It explicitly differentiates from tools like 'get_vrp' by focusing on historical replay rather than current 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 clear context for when to use this tool ('at any minute since April 2018') and mentions the 'Alpha tier' requirement, but doesn't explicitly state when not to use it or name specific alternatives among the many sibling tools. It implies usage for historical analysis but lacks explicit 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?

Annotations provide readOnlyHint=true, which the description aligns with by implying a read operation ('Replay'). The description adds valuable context beyond annotations: it specifies the historical data range ('since April 2018'), the analytics scope (pin risk, expected move, etc.), and the 'Alpha tier' access requirement, which are not covered by annotations.

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

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

The description is front-loaded with the core purpose in the first clause, followed by specific analytics and constraints, all in two efficient sentences with zero wasted words. Every sentence adds value, making it highly concise and well-structured.

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 (historical analytics with multiple metrics) and lack of output schema, the description does well by listing the analytics returned. However, it could be more complete by mentioning the return format (e.g., JSON structure) or any limitations like data granularity, though annotations cover read-only safety adequately.

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 100%, with clear parameter descriptions in the schema. The description does not add any additional meaning or details about the parameters beyond what the schema provides, such as explaining the 'symbol' ticker format or 'at' timestamp nuances. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the specific action ('Replay 0DTE analytics') and resource ('at any minute since April 2018'), listing concrete analytics like pin risk, expected move, gamma acceleration, and dealer hedging estimates. It explicitly distinguishes from sibling tools by specifying 'same-day expiry' and 'historical' context, unlike real-time tools like get_zero_dte.

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 this tool: for historical 0DTE analytics replay since April 2018, with an 'Alpha tier' requirement. However, it does not explicitly state when not to use it or name specific alternatives among siblings (e.g., get_zero_dte for real-time data), leaving some ambiguity.

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

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

The annotations already declare readOnlyHint=true, confirming safe read access. The description adds valuable financial context (dealer hedging mechanics) but does not disclose operational details like rate limits, caching behavior, or data freshness that would help an agent handle the response.

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?

Extremely efficient: two sentences with zero redundancy. The first lists the specific data points returned; the second explains their financial significance. Every word earns its place.

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

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

Despite lacking an output schema, the description compensates by enumerating the five specific data fields returned (gamma flip, walls, max pain, OI strike) and their meaning. For a simple two-parameter read tool, this provides sufficient context for invocation, though output format details would strengthen it 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?

With 100% schema description coverage (symbol and apiKey fully documented), the baseline is 3. The description does not add parameter-specific guidance (e.g., symbol format expectations or API key security handling) beyond what the schema provides.

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 specific metrics retrieved (gamma flip point, call wall, put wall, max pain, highest OI strike) and frames them as support/resistance levels, distinguishing this from sibling tools like get_gex or get_option_chain. However, it does not explicitly name sibling alternatives or contrasting use cases.

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

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

It provides clear domain context that these levels derive from dealer hedging activity and act as support/resistance, guiding when to use the tool for technical analysis. However, it lacks explicit 'when not to use' guidance or named alternatives among the many sibling options tools.

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 readOnlyHint=true, so the description adds value by detailing the output metrics (score, spreads, depth) and the label thresholds (tight, normal, wide, illiquid). It does not contradict any 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 extremely concise—two sentences—yet packs all essential information: metrics, labels, and use cases. Every part contributes meaningfully, with 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?

The description explains the output metrics and labels, which is sufficient given no output schema. However, it does not clarify that no expiry parameter is needed (the tool returns all expiries for the given symbol), which might require the agent to infer. Slightly more explicit scoping would improve 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 100%, so the baseline is 3. The description does not provide any additional parameter-specific guidance beyond what is in the schema (symbol and optional apiKey). It does not explain parameter formats or constraints further.

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 per-expiry option liquidity scores (0-100) along with bid-ask spread percent, OI-weighted spread, ATM OI depth, and chain-level execution quality. It also defines liquidity labels. This distinguishes it from sibling tools like get_option_chain or get_option_quote, which do not aggregate liquidity metrics per expiry.

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 tells the agent to use it for selecting the most liquid expiry, assessing execution quality, or screening for tight spreads. However, it does not mention when not to use it or provide specific alternative tool names, leaving room for improvement in exclusion 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?

The description adds output details beyond the readOnlyHint annotation, but does not disclose any behavioral traits such as data freshness, rate limits, or authentication requirements. The annotation already covers read-only nature, so the description's extra value is moderate.

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 a single, well-structured sentence that front-loads the tool's purpose and lists key outputs. Every word 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?

Despite lacking an output schema, the description enumerates the main return fields, making it reasonably complete for an agent to decide whether to invoke the tool. However, it omits details like data structure or units.

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 100%, and the description does not add any additional meaning to the parameters. It focuses on outputs, so it meets the baseline but does not enhance parameter understanding.

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

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

The description clearly states that the tool retrieves max pain related data including max pain strike, pain curve, put/call OI ratio, dealer alignment, pin probability, and per-expiration breakdown. It distinguishes itself from siblings like get_historical_max_pain by being about current data, but does not explicitly contrast.

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 guidance is provided on when to use this tool versus its siblings (e.g., get_historical_max_pain, get_option_chain, get_exposure_summary). The description only lists outputs, leaving the agent to infer usage context.

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

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

Annotations already establish readOnlyHint=true, confirming safe read access. The description adds valuable behavioral context by disclosing the specific content scope (gamma regime, key levels, dealer positioning, price action implications) that will be included in the narrative, helping set expectations for the analysis depth.

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 consists of two efficiently structured sentences: the first establishes the action and resource, the second details the content scope. Every word earns its place with zero redundancy or 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?

Despite lacking an output schema, the description adequately explains what the tool returns (a narrative covering specific market elements). Given the simple 2-parameter input and read-only nature, the description provides sufficient context, though it could clarify output format (e.g., whether it's a single string or structured object with text).

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 100% schema description coverage (symbol and apiKey both documented), the description appropriately doesn't redundantly explain parameters. However, it also misses the opportunity to add domain context (e.g., noting that symbol accepts US equities, or apiKey requires FlashAlpha credentials) beyond the schema's basic types.

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

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

The description uses a specific verb ('Get') and resource ('GEX narrative analysis') and clearly distinguishes from sibling tools like get_gex by emphasizing 'verbal' and 'plain English' output, indicating this returns human-readable text rather than raw numerical 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?

While the description implies usage through terms like 'verbal' and 'plain English' (suggesting it's for qualitative interpretation rather than quantitative analysis), it lacks explicit guidance on when to select this tool over siblings like get_gex or get_dex, and doesn't state 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?

Annotations already declare readOnlyHint=true. The description adds value by specifying the output shape: per-contract changes, top-N sorted, and call/put aggregates. It does not cover all behavioral nuances (e.g., pagination, data limits), but given the annotations, this is adequate.

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

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

The description is two sentences, front-loaded with the core purpose and output, followed by a usage hint. Every word adds value, no fluff.

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

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

Given no output schema, the description adequately explains the return structure: per-contract OI changes, top-N sorted by absolute magnitude, and call/put aggregates. Combined with the schema for inputs, this is complete for the tool's complexity.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions 'top-N sorted' which aligns with the topN parameter but does not add new meaning beyond the schema descriptions. No additional parameter elaboration.

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 day-over-day open interest deltas, per-contract changes, top-N sorted by absolute magnitude, and call/put aggregate totals. It distinguishes from siblings like get_flow_levels by focusing on OI shifts.

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 usage statement: 'Use to track new positioning, unwinding, and block print intent from OI shifts.' This gives clear context, but it does not explicitly mention when not to use or alternatives, though 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=true, confirming safe read-only access. The description adds useful context about what constitutes the option chain (expirations and strikes) but omits operational details like rate limits, caching behavior, or error responses for invalid tickers.

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?

Single sentence, front-loaded with the action verb, zero redundancy. Every word earns its place by defining the action, resource type, specific data returned, and target entity.

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 low complexity (2 simple string parameters), 100% schema coverage, read-only annotations, and no output schema, the description is sufficiently complete. It conceptually explains the return value (expirations and strikes) even without formal output schema documentation.

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 100% schema description coverage (symbol and apiKey both documented), the baseline is 3. The description mentions 'for a ticker' which aligns with the symbol parameter, but adds no additional semantic detail like format examples ('AAPL') or constraints beyond what the schema provides.

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 uses specific verbs ('Get') and clearly defines the resource as 'option chain metadata' consisting of 'available expirations and strikes.' This effectively distinguishes it from siblings like get_option_quote (pricing data) or calculate_greeks (calculations) by specifying this is structural/discovery 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 term 'metadata' implies this tool is for discovery (finding what expirations/strikes exist) rather than pricing, but there are no explicit guidelines on when to use this versus get_option_quote or prerequisites like needing a valid ticker symbol first.

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 readOnlyHint=true. The description adds behavioral context by detailing each view's structure (e.g., 'newest first,' 'minute buckets') and parameter constraints like limit applicability. 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?

Description is a single paragraph that efficiently lists views with brief explanations. While not overly long, it could benefit from clearer separation of view definitions (e.g., bulleted list) for quicker parsing.

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

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

Given no output schema and 6 parameters with 2 required, the description explains return formats for each view and constraints like limit bounds. It lacks pagination details or error handling, but covers essential context for a complex 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 covers all 6 parameters (100% coverage). The description enhances this by clarifying view meanings, limit scope ('Only applies to recent'), and expiry filter usage, adding semantic value beyond 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?

Description clearly states the tool returns raw intraday option trade-flow for one underlying and lists five specific views. However, it does not explicitly differentiate from sibling flow tools (e.g., get_flow_live, get_flow_scan), relying on the 'one underlying' constraint.

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 enumerates views and their outputs, implying their contexts (e.g., recent for latest trades, summary for totals). But it offers no explicit guidance on when to use this tool versus siblings or when not to use it, leaving inference up to the agent.

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

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

While annotations declare readOnlyHint=true, the description adds crucial behavioral context by specifying the exact financial metrics returned (bid, ask, mid, IV, greeks, OI, volume) and distinguishing real-time ('live') data from historical. It does not mention rate limits or error states, but covers the essential return payload structure given the absence of an output schema.

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

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

Two sentences with zero waste. The first sentence front-loads the core purpose and complete return value specification; the second addresses filtering capabilities. Every word serves a distinct function.

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 lack of output schema, the description compensates adequately by listing return fields. With 5 well-documented parameters and readOnly annotations, it covers the essential contract for a quote retrieval tool, though explicit differentiation from get_option_chain would strengthen 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?

With 100% schema description coverage, the baseline is 3. The description adds semantic value by framing expiry, strike, and type as 'filters' rather than just inputs, but does not elaborate on parameter relationships (e.g., whether providing only symbol returns all options or requires filters).

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

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

The description uses a specific verb ('Get') with clear resource ('live option quote') and enumerates exact return fields (bid, ask, mid, IV, greeks, open interest, volume). The 'live' qualifier effectively distinguishes it from sibling get_historical_option_quote, and 'option' distinguishes from get_stock_quote.

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 by noting parameters are used to 'Filter by expiry, strike, and type,' suggesting optional narrowing capabilities. However, it lacks explicit guidance on when to select this over get_option_chain (which likely returns multiple contracts) or whether all filter parameters must be provided together.

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 include readOnlyHint=true, which aligns with the read-only nature. The description adds behavioral details: range estimators are 5–8× more efficient than close-to-close, and mentions 'Alpha tier' (a tier limitation). No contradiction.

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

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

Two focused sentences plus brief fragments. No wasted words; front-loaded with the most important information (what it is, what estimators, efficiency gain).

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 two parameters and no output schema, the description conveys the return types (five estimators over three windows) and intended use. It lacks explicit output structure but is sufficient for agent invocation.

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

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

Schema coverage is 100%, so all parameters are documented. The description adds context about estimators and windows but does not add specific meaning to the two parameters (symbol, apiKey) 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 specifies the verb 'Get', the resource 'Realized Volatility Estimators', and lists the specific estimators (close-to-close, Parkinson, Garman-Klass, Rogers-Satchell, Yang-Zhang) with time windows. It clearly differentiates from sibling tools like get_volatility (implied vol) and get_historical_volatility.

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

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

The description gives explicit use cases: 'measure realized vol robustly, compare estimators, or feed a vol-risk-premium calc.' It does not explicitly exclude alternatives, but the purpose is clear enough to guide selection among many volatility tools.

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 readOnlyHint annotation already informs the agent that this is a safe read operation. The description adds context about the returned metrics (skew measures per expiry) but does not disclose additional behavioral traits such as data source, update frequency, pagination, or response format. Given the annotation's coverage, a 3 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?

Two sentences with no superfluous words. The first sentence front-loads the key output metrics, and the second provides usage guidance. Every word earns its place.

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

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

The tool is simple (2 params, no nested objects, no output schema). The description fully explains what the tool returns and when to use it, making it 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 coverage is 100%: both parameters (apiKey, symbol) are fully described in the schema. The description adds no additional meaning to the parameters themselves; it lists the output metrics. Since the schema already documents the parameters, the baseline of 3 is correct.

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

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

The description explicitly lists the metrics returned (ATM IV, 25-delta/10-delta risk reversal, butterfly spread, skew_25d, tail convexity) and clearly distinguishes it from siblings like get_term_structure (which likely returns only ATM term structure) and get_advanced_volatility. The verb 'get' with the resource 'skew term structure' is 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?

The description provides concrete use cases: 'put/call skew across expirations, 25-delta risk reversal, butterfly convexity, or comparing near-term vs far-term skew.' It does not explicitly mention when NOT to use this tool or provide alternatives, but the use cases are clearly communicated.

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, so the tool is known to be read-only. The description adds no new behavioral traits beyond this; it only provides domain context. No contradiction exists.

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

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

The description is three sentences, front-loaded with the core definition, and includes no unnecessary words. Every sentence provides 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 no output schema, the description could explain the output format or typical values, but it sufficiently describes the tool's purpose and use cases. The missing output details lower the score slightly but it is still largely complete.

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

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

Schema coverage is 100% with descriptions for both parameters. The description does not add additional meaning beyond what the schema already provides for the parameters.

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

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

The description clearly states it computes '20-day and 60-day Pearson correlation between spot log-returns and ATM IV first-differences', specifying the exact metric and time windows. It also distinguishes its use for the leverage effect, vanna/vol-of-vol calibration, or regime classification, setting it apart from siblings like get_volatility.

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 lists three use cases: assessing leverage effect strength, calibrating hedges, and classifying correlation regimes. However, it does not mention when not to use the tool or provide explicit alternatives from the sibling list.

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

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

The annotations already declare readOnlyHint=true, so the description's statement 'Raw intraday stock trade-flow' adds no further behavioral disclosure. No mention of rate limits, pagination beyond limit param, or authorization details beyond what is in the schema.

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

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

The description is a single sentence with a compact list of views, efficiently conveying core functionality without verbosity. It could be slightly more structured but is not overly long.

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

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

Given the tool has 6 parameters, 6 views, no output schema, and good schema coverage, the description sufficiently orients the user by summarizing each view. Minor gaps: return format not described, but schema covers parameters adequately.

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 100%, so the baseline is 3. The description adds no substantive parameter meaning beyond listing the view names; parameter dependencies (e.g., resolution for 'bars') are only in the schema, not in the 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 'Raw intraday stock trade-flow for one symbol' and enumerates six distinct views with brief descriptions, making the tool's purpose specific and unambiguous. It distinguishes from sibling tools like get_option_flow (stock vs. option) and get_flow_summary (raw data vs. totals).

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 intraday stock trade flow but does not provide explicit guidance on when to use this tool over alternative siblings such as get_flow_summary or get_flow_scan. There is no mention of when not to use it or prerequisites.

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

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

With readOnlyHint already true in annotations, the description adds valuable context by specifying the data fields returned (bid, ask, mid, last) and noting 'real-time' latency. However, it omits other behavioral details like rate limits, caching behavior, or error handling for invalid symbols.

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 a single, tightly constructed sentence with no wasted words. It is appropriately front-loaded with the verb and resource, and the parenthetical field list efficiently conveys return value 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 simplicity (2 parameters, 100% schema coverage, read-only annotation), the description is sufficiently complete. It compensates for the missing output schema by listing the specific price fields returned, though it could briefly mention API key requirements or error scenarios.

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 100%, providing detailed descriptions for both 'symbol' and 'apiKey'. The description mentions 'ticker symbol' aligning with the parameter, but adds no semantic information beyond what the schema already provides, meeting the baseline for high-coverage schemas.

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 action ('Get'), resource ('stock quote'), and specific data points returned ('bid, ask, mid, last price'). It implicitly distinguishes from siblings like 'get_historical_stock_quote' via the 'real-time' modifier and from 'get_option_quote' by specifying 'stock', though it does not explicitly name alternative 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 no explicit guidance on when to use this tool versus siblings like 'get_historical_stock_quote' or 'get_stock_summary'. While 'real-time' implies current data needs, there are no explicit when-to-use or when-not-to-use statements.

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

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

With readOnlyHint: true already indicating safety, the description adds valuable behavioral context by detailing exactly what data the 'summary' contains—effectively compensating for the missing output schema. It does not mention rate limits, caching behavior, or data freshness, but the enumeration of returned metrics (options flow, term structure, etc.) provides substantial 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 a single, dense sentence that front-loads the action ('Get comprehensive stock summary') and follows with a colon-delimited list of data categories. Zero wasted words; every phrase earns its place by describing output contents or scope.

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 lack of an output schema, the description appropriately compensates by listing the specific data fields returned (price, IV, VRP, macro context, etc.). With only two simple parameters fully documented in the schema, and the description covering the output richness, the tool is sufficiently documented for an agent to invoke and understand what will be returned.

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 100% for both parameters (symbol and apiKey), so the baseline score applies. The description does not add parameter-specific guidance beyond the schema (e.g., no format hints for the API key or ticker validation rules), but none is needed given the complete schema documentation.

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

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

The description uses a specific verb ('Get') and resource ('stock summary'), then enumerates the exact data categories included (price, ATM IV, VRP, skew, macro context, etc.). This clearly distinguishes it from specialized siblings like get_stock_quote (likely basic price only), get_vrp (single metric), or get_exposure_summary (single dataset) by positioning this as the comprehensive aggregation tool.

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

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

The description implies usage through the comprehensive data list (suggesting it's for full analysis rather than single metrics), but lacks explicit guidance on when to use specialized siblings instead, or when this might be overkill vs. lighter alternatives like get_stock_quote. No prerequisites or exclusions are stated.

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, indicating a safe read operation. The description adds behavioral context by explaining what each signal answers, going beyond the annotations. However, it does not disclose other traits like rate limits or authentication requirements.

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 for each signal, but it is lengthy due to detailed explanations. Important information (purpose) is front-loaded. Could be more concise, but the structure aids readability.

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 lacks any explanation of the output structure or return value, which is a significant gap given the absence of an output schema. It does not describe what a 'decision envelope' contains, limiting the agent's ability to use the result effectively.

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 100%, but the description adds value by extensively explaining each signal enum value, which helps the agent select the correct signal. The description does not provide additional semantics for the symbol and apiKey parameters 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 retrieves 'a strategy decision envelope for one of 10 options-based trading signals,' providing a specific verb and resource. It uniquely distinguishes itself from sibling tools like get_flow_signals by focusing on strategy signals with enumerated options.

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 lists the available signals but does not explicitly guide when to use this tool versus alternatives, nor does it mention prerequisites or situations where it should not be used. Usage context is implied but not directly stated.

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 provide readOnlyHint=true, so it's a read operation. The description adds value by detailing the output's grid size (50x50), construction method (bilinear interpolation), and the fact it's live and built from OTM contracts. 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 a single, well-structured sentence that immediately conveys the tool's core function (get live surface), its dimensions (50x50), and its construction (bilinear interpolation). Every word 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?

For a tool with only 2 parameters and no output schema, the description adequately explains the return structure (50x50 grid). It could optionally mention typical use cases or data freshness, but it's largely complete for most agents.

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

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

Schema description coverage is 100%: both parameters (apiKey, symbol) are described. The tool description does not add any additional parameter-level detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states it retrieves a live 50x50 implied-volatility surface grid over (tenor, log-moneyness), built from OTM contract IVs with bilinear interpolation. This is specific and distinguishes it from siblings like get_volatility.

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_volatility or get_advanced_volatility. Usage is implied for users needing a full surface grid, but no when-not-to-use or exclusion criteria are provided.

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. The description adds useful behavioral context: 'Live' data, per-expiry calibration, and access requirements ('Alpha tier required'). 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 two sentences and a tier note, front-loaded with the core functionality. Every sentence adds value, with no redundancy or 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?

The description covers purpose, usage, and access requirements. It lists specific outputs (calibrated parameters, ATM variance, IV) without an output schema. However, it could be more complete by clarifying response structure (e.g., per-expiry format).

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 100%, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already documents (symbol and apiKey). It mentions 'per expiry' but does not elaborate on parameters.

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

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

The description clearly states the tool returns SVI-fitted volatility surface parameters per expiry, listing specific outputs (a, b, rho, m, sigma, ATM total variance, ATM IV). It provides concrete use cases (surface reconstruction, arbitrage checking, etc.) and is distinct 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 suggests use cases and notes 'Alpha tier required,' guiding appropriate usage. While it doesn't state when not to use it or mention alternatives, the context is clear enough for an AI agent to infer suitable scenarios.

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

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

Annotations already indicate readOnlyHint=true. The description adds context about cached data and live tracking, which enhances understanding without contradicting annotations.

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

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

Three concise sentences with key information upfront. No redundant wording; each sentence adds value.

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

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

The description covers purpose and usage adequately for a simple list tool with no output schema or required parameters. It is sufficiently complete for an agent to decide when to invoke 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 only parameter apiKey has a schema description; the tool description adds no extra semantics. Since schema coverage is 100%, baseline 3 is appropriate.

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

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

The description clearly states it lists symbols with live cached data, specifying concrete use cases like checking active symbols or ticker warm-up. It is distinct from sibling tools that retrieve specific metrics.

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

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

It provides explicit scenarios for use (see active symbols, check ticker, enumerate tracked symbols). However, it does not mention when not to use or suggest alternatives among siblings.

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