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?

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?

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?

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?

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, 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?

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?

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 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?

The readOnlyHint=true annotation establishes the safety profile, allowing the description to focus on other traits. It adds valuable context by specifying 'live' data freshness and 'all available' scope, but omits behavioral details like pagination for large lists, rate limit implications, or the specific return format since no output schema 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 consists of a single, efficient sentence of nine words that places the primary action 'List' at the forefront. No words are wasted, and the structure immediately communicates the core value proposition without redundant phrases or filler content.

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

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

Given the tool's low complexity (single string parameter) and high schema coverage, the description is minimally viable. However, the absence of an output schema means the description should ideally characterize the return value (e.g., array of ticker strings), and the lack of usage guidance leaves critical gaps for agents navigating the extensive 20+ sibling toolset.

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 single apiKey parameter is fully documented as 'Your FlashAlpha API key'—the description appropriately relies on the structured schema. The description itself adds no additional parameter semantics or usage examples, meeting the baseline expectation 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 tool 'List[s] all available stock/ETF tickers' with a specific verb and resource. The phrase 'with live options data' effectively narrows scope to options-enabled securities, implicitly distinguishing it from general stock endpoints among siblings like get_stock_quote. However, it lacks explicit differentiation against other discovery-oriented 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 guidance on when to use this tool versus alternatives or prerequisites for invocation. It fails to indicate that this should be used to discover valid inputs for sibling tools like get_option_chain or get_stock_quote before querying specific symbols. No exclusions or error conditions 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?

While annotations confirm readOnlyHint=true (safe read), the description adds crucial behavioral context: 'by strike' reveals the data is organized by strike price (output structure), and 'dealer hedging changes with volatility moves' explains the financial interpretation of vanna exposure. This disclosure goes beyond the safety annotations to describe what the data represents.

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 action and resource ('Get vanna exposure'), second sentence adds interpretive value ('Shows how dealer hedging...'). 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 read-only data retrieval tool with 100% schema coverage, the description is appropriately complete. It compensates for the missing output schema by hinting at the 'by strike' data structure and explaining the financial meaning of the metric. Could mention the optional expiration filtering behavior, but adequate for the complexity level.

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 parameters (symbol, apiKey, expiration) are fully documented in the schema. The description does not explicitly discuss parameter semantics or provide examples, meeting the baseline expectation 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?

Clearly states it retrieves 'vanna exposure (VEX) by strike' and explains it shows 'how dealer hedging changes with volatility moves.' The specificity of 'vanna' and 'dealer hedging' distinguishes it from generic greek calculators (calculate_greeks) and other exposure metrics (get_gex, get_dex), though it doesn't explicitly name sibling alternatives.

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

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

Provides domain context by explaining the financial significance (dealer hedging behavior relative to volatility), which implies when an agent might use this (analyzing dealer positioning). However, it lacks explicit guidance on when to choose this over calculate_greeks or other exposure tools, and mentions no prerequisites beyond the obvious 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?

While annotations confirm readOnlyHint=true, the description adds valuable behavioral context by detailing the specific analysis components returned (GEX by DTE, theta by DTE, hedging scenarios, liquidity metrics). This helps the agent understand the scope and richness of the data payload despite 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?

Extremely dense and efficient single-sentence structure. Front-loaded purpose ('Get comprehensive volatility analysis') followed by a colon-delimited list of specific outputs. Zero wasted words.

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

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

Given the lack of an output schema, the description compensates well by listing ~10 specific metrics and analysis components returned. While it does not describe the data structure or nesting format, the comprehensive enumeration of return values provides sufficient context for tool selection.

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 both parameters (symbol and apiKey), the baseline is appropriately met. The description does not add parameter-specific guidance, 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 clearly states the tool retrieves volatility analysis and enumerates specific metrics returned (ATM IV, realized vol, VRP, skew, etc.). However, it does not explicitly differentiate from the sibling tool 'get_advanced_volatility' or clarify when to use this versus more specific tools like 'get_vrp'.

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 comprehensive tool versus alternatives like 'get_advanced_volatility' or single-metric tools (e.g., 'get_vrp', 'get_gex'). There are no stated prerequisites, exclusions, or workflow recommendations.

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 declaring the safe read-only nature, the description adds value by disclosing what the dashboard contains (term structure, macro context, percentiles). However, it omits operational details like rate limits, caching behavior, or error responses 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, efficiently structured sentence that front-loads the action ('Get volatility risk premium dashboard') and uses a colon-delimited list to specify returned data components without redundant phrasing.

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

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

Despite the absence of an output schema, the description compensates by enumerating seven specific data components returned (IV, realized vol, percentiles, term structure, regime, strategy scores, macro context), giving sufficient expectation of the payload structure for a financial analytics tool.

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

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

The input schema has 100% description coverage for both parameters ('symbol' and 'apiKey'), establishing a baseline of 3. The description provides no additional parameter context (e.g., valid ticker formats, API key acquisition), so it meets but does not exceed 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?

The description uses a specific verb ('Get') and resource ('VRP dashboard'), and distinguishes from siblings by enumerating unique analytical components: 'live IV vs realized vol,' 'regime classification,' and 'strategy scores,' which differentiate it from generic volatility tools like get_volatility or historical variants.

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 the term 'live IV,' suggesting current/snapshot data as opposed to historical, but lacks explicit guidance on when to prefer this over get_vrp_history or what prerequisites (e.g., valid ticker format) are required.

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 safe read access. The description adds significant value by detailing exactly which calculated fields are returned (5/10/20/30d realized vol, daily ATM IV, etc.), compensating for the lack of output schema and helping the agent anticipate the data 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?

Single, dense sentence that front-loads the core action ('Get historical VRP time series'), enumerates specific data points efficiently, and concludes with use cases. Zero wasted words; every clause provides necessary specificity.

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 comprehensively lists the specific financial metrics returned (including the 'daily' frequency). Given the 100% input schema coverage and readOnly annotation, this provides sufficient context for invocation, though it could optionally mention data availability 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?

Input schema has 100% description coverage (days, apiKey, symbol all documented). The description does not add parameter-specific semantics beyond what the schema provides, meeting the baseline expectation for well-documented 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?

Description clearly states it retrieves 'historical VRP time series' with specific metrics (ATM IV, realized vol, VRP, straddle price, expected move). The 'historical' and 'time series' qualifiers effectively distinguish it from the sibling tool 'get_vrp' which likely provides current/snapshot 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?

Provides explicit usage context stating the data is intended 'for charting and backtesting,' which guides the agent on appropriate use cases. While it doesn't explicitly name 'get_vrp' as the alternative for current data, the temporal scope ('historical') 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?

Annotations declare readOnlyHint=true (safe read). Description adds valuable behavioral context by disclosing specific computed analytics returned (intraday gamma, time decay acceleration, pin risk, dealer hedging pressure), which compensates partially for missing output schema. Does not cover rate limits or caching.

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 dense sentence front-loaded with specific metrics. Zero waste—every term (gamma, time decay acceleration, pin risk, hedging pressure) serves to differentiate the tool's computational behavior. Appropriate length for complexity.

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

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

Without output schema, description usefully enumerates return analytics types (gamma, pin risk, etc.) giving agents expectations of data payload. Could improve by indicating real-time vs delayed nature or data frequency, but reasonably complete given rich input schema and readOnly annotation.

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 (apiKey, symbol, strike_range all documented). Description mentions no parameters explicitly, but baseline score is 3 when schema is fully self-documenting. No additional syntax or semantic guidance provided beyond schema.

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

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

Specific verb 'Get' plus precise resource 'zero-days-to-expiration (0DTE) analytics'. Distinguishes from siblings like calculate_greeks or get_gex by specifying unique 0DTE metrics (intraday gamma, pin risk, dealer hedging pressure) and scope 'contracts expiring today'.

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 context through 'contracts expiring today', signaling this is for same-day expiration analysis. However, lacks explicit when-to-use guidance versus siblings (e.g., when to prefer this over get_option_chain for 0DTE) and no prerequisites or exclusions 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 declare readOnlyHint=true. The description adds valuable methodological context by specifying 'BSM' (Black-Scholes-Merton) as the underlying model. However, it omits behavioral details like handling of invalid inputs (e.g., prices outside arbitrage bounds) or convergence failure cases typical for IV solvers.

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. Front-loaded with the core action ('Solve for implied volatility'), followed by methodology clarification. 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?

Given 100% schema coverage and readOnly annotations, the description adequately covers the tool's purpose and methodology (BSM). Absent output schema, it could clarify the return value format (single float vs object), but 'Solve Implied Volatility' title provides sufficient 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%, establishing baseline. The description mentions 'option market price' reinforcing the price parameter, but does not add semantic depth beyond the schema (e.g., units for dte, acceptable ranges). Meets baseline expectations without additional compensation.

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 uses specific verbs ('Solve', 'Reverse-engineers') and clearly identifies the resource (implied volatility) and methodology (BSM). It distinguishes from siblings like get_volatility by emphasizing the reverse-engineering from option market price rather than fetching existing 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 phrase 'from option market price' implies usage context (when you have an option price and need to extract vol), but lacks explicit when-not-to-use guidance or named alternatives (e.g., versus get_volatility for retrieving market IV directly).

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