FlashAlpha

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

Annotations provide readOnlyHint=true, and the description adds that it uses Black-Scholes model with no market data, but does not disclose model assumptions or potential limitations, though not critical.

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?

Very concise: one clear sentence and a fragment, no redundancy, front-loaded with key action and output.

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

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

No output schema exists, but description hints at return values by listing greeks. Parameter documentation is fully covered in schema. Sufficient for a simple computation tool.

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

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

Schema coverage is 100%, and description does not add beyond listing output greeks. Baseline 3 is appropriate since schema already explains 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 calculates Black-Scholes option greeks, listing specific ones and emphasizing 'pure math — no market data needed,' which distinguishes it from siblings like solve_iv or get_option_chain that involve 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?

Implicitly, it is for theoretical greeks calculation when no market data is required, but there is no explicit directive on when to use vs alternatives like solve_iv or get_option_chain.

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, which matches the description's computation focus. The description adds minor context about using BSM expected value but does not disclose other behavioral traits like authentication needs or rate limits. With annotations covering the safety profile, a score of 3 is appropriate.

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

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

The description is two sentences, front-loading the purpose and adding method context. Every sentence is valuable with no redundancy 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?

The tool has no output schema, and the description does not mention the return format (e.g., single number, percentage). Given low complexity, the description is adequate but incomplete regarding output. A 3 is fair.

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

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

Schema coverage is 100% with all parameters well-described. The description mentions 'BSM expected value vs premium' but adds no extra semantics beyond the schema. No parameter relationships or examples are provided, so baseline 3 is correct.

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

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

The description clearly states it computes the Kelly criterion optimal position sizing for an option trade. The verb 'compute' and resource 'Kelly sizing' are specific, and it distinguishes from sibling tools like calculate_greeks which focus on other aspects.

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 option trades but provides no explicit guidance on when to use this tool vs alternatives such as solve_iv or calculate_greeks. No exclusion scenarios or when-not-to-use are mentioned.

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

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

The readOnlyHint annotation declares safety. The description adds details on the returned data but does not disclose additional behavioral traits beyond that.

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 with a clear structure, listing key fields. No unnecessary words.

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

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

For a simple account info retrieval tool with no output schema, the description adequately describes the returned fields and the tool's purpose.

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

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

The schema fully describes the one parameter (apiKey). The description provides no additional parameter information beyond the schema.

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

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

The description clearly states the tool retrieves account information including specific fields. It clearly differentiates from sibling tools which handle other data (e.g., greeks, 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?

While no explicit when-not conditions are stated, the tool's purpose as account info retrieval is clear and distinct from the many financial data tools listed as 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 declare readOnlyHint=true, confirming safe read operation. The description adds the requirement for 'Alpha tier', which is a useful behavioral constraint 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, front-loaded with a list of outputs, and a clear requirement statement. No redundant words 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?

Lacks an output schema, but the description lists a comprehensive set of returned analytics (SVI parameters, greeks, etc.), providing enough context for an agent to understand the tool's capabilities.

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% and description does not elaborate on parameters beyond what the schema already states (ticker and API key). No additional semantic value is added.

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 ('advanced volatility analytics') and differentiates from sibling tools like get_volatility by listing distinct outputs such as SVI parameters and greeks surfaces.

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 an 'Alpha tier required' requirement but does not provide guidance on when to choose this tool over siblings like get_volatility or get_svi_params, which offer overlapping functionality.

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

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

Annotations already declare readOnlyHint=true. The description adds value by explaining the behavioral output: 'Shows how dealer delta hedging changes as time passes — reveals time-decay-driven flows.' This enriches the agent's understanding of the data beyond the annotation.

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

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

The description is two sentences that front-load the purpose and efficiently add behavioral context. No extraneous words.

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

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

The tool has no output schema, and the description omits details about return format. However, given the simple nature of the tool and the presence of annotations, the description is mostly complete. Adding an indication of output structure would improve it.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (apiKey, symbol, expiration). The description does not add parameter-specific meaning beyond what's in the schema, resulting in a baseline score.

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

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

The description clearly states the tool retrieves 'charm exposure (CHEX) by strike' and explains that it shows how dealer delta hedging changes over time, revealing time-decay-driven flows. This distinguishes it from sibling tools like get_gex (gamma exposure) or get_dex (delta exposure).

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 provide explicit guidance on when to use this tool versus alternatives (e.g., get_historical_chex, get_gex). It only describes the tool's function without contextual usage advice.

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

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

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

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

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

Description is one sentence with dash-separated clause, front-loaded with key concept. It is efficient but includes 'Alpha tier' which is not essential. Could be slightly more structured but overall concise.

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

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

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

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

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

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

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

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

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

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

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

The description implies usage for checking dealer positioning but does not explicitly state when to use versus alternatives. Siblings like get_flow_dealer_risk, get_chex, get_dex exist, but no guidance on selection or exclusions.

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

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

The description adds context about output (net dealer delta, directional bias) but does not disclose behavioral traits beyond the readOnlyHint annotation. No contradiction.

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

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

Two sentences, zero waste. The description is front-loaded with the essential purpose and output.

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?

Missing output schema; description mentions output vaguely. For a tool with no output schema, more detail on return format 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?

Schema covers all 3 parameters with descriptions. The tool description adds 'by strike' context but does not significantly enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool retrieves delta exposure by strike, showing net dealer delta and directional bias. It is specific and distinguishes from sibling tools like get_gex (gamma).

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 delta exposure analysis but provides no explicit guidance on when to use it versus alternatives or when not to use it.

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

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

Annotations declare readOnlyHint=true, and the description aligns with that. It adds value by detailing the computational outputs (correlation premium, dispersion setup, etc.) and the access requirement (alpha tier). No contradictions.

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

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

Two sentences, front-loaded with purpose. Efficient but slightly dense; could be split for readability. No wasted words.

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

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

Describes all computed outputs (correlation premium, dispersion setup, implied vol, per-constituent vol contribution) despite no output schema. Mentions access requirement. Fully covers what the agent needs to know to use the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds high-level context (e.g., 'index anchors implied correlation', 'horizon for realized correlation') but does not provide significant extra detail beyond the schema descriptions.

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

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

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

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

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

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

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

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

Annotations already set readOnlyHint=true. The description adds valuable behavioral context by detailing what each kind computes (e.g., 'splits front-expiry straddle into jump vs baseline-diffusion', 'IV-crush distribution: live crush estimate and median/p25/p75/best/worst'). No contradictions with annotations.

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

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

The description is dense but well-structured, using a bullet-like list for the six enum values. Every sentence adds value. It could be split into a summary sentence and a list for better readability, but it's concise enough.

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

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

The tool has no output schema, so the description should convey return format. While it describes the conceptual output for each kind (e.g., 'EV/implied/actual moves'), it lacks details on the structure (e.g., what fields are returned). Given the complexity, more output context would help.

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

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

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

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

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

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

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

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

The description implies usage for earnings analytics but provides no explicit guidance on when to use this tool versus alternatives (e.g., get_earnings_calendar for listing events, get_expected_move for a single lens). No when-not or alternative tool references.

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

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

Annotations state readOnlyHint: true, so the tool is read-only. The description adds behavioral context by listing return fields and parameter details (e.g., default days-ahead window, filter semantics). It does not contradict annotations and provides useful transparency beyond structured fields.

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

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

The description is two sentences with no redundant information. Front-loaded with the core purpose, it efficiently covers functionality, parameters, and return fields. Every sentence earns its place.

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

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

With no output schema, the description compensates by listing all return fields. It explains all parameters and their constraints. However, it does not mention pagination or result limits, which could be relevant for large calendars. Overall, it is sufficiently complete for a filterable list tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining parameter purposes in context (e.g., days as 'forward window', symbols as comma-separated list, importance as minimum rating, apiKey usage with OAuth vs direct key). This extra context elevates the score.

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

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

The description clearly states the tool returns an upcoming earnings calendar over a configurable forward window, listing specific fields (event date, session, confirmation status, fiscal period, importance rating, consensus EPS, implied-move percent) and filtering options (symbols, minimum importance, days-ahead window). This fully distinguishes it from siblings like 'get_earnings' (likely single event) and 'get_earnings_screener' (different focus).

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

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

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

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

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

Annotations already declare readOnlyHint=true, and the description adds specific computed fields (implied-move percent, premium ratio, etc.) and configurable parameters, which are not captured in annotations. This provides useful behavioral context beyond the annotation.

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

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

The description is two sentences, front-loaded with the core purpose, and every word adds value. No redundant or vague phrasing. Excellent conciseness.

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

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

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

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema descriptions by explaining the purpose of each parameter (e.g., 'forward window in days', 'ranking options' with defaults) and compactly summarizing the output fields, which adds value.

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

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

The description clearly states the tool is a cross-sectional earnings screener that ranks events by specific criteria (VRP richness, cheapest implied move, etc.) and lists returned fields. This distinguishes it from sibling tools like 'get_earnings' or 'get_earnings_calendar' which focus on raw data.

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

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

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

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

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

Annotations already provide readOnlyHint=true. The description adds that the tool computes the expected move from a straddle, implying a read-only calculation without side effects. It explains the output fields and purpose, which is consistent with the read-only annotation and adds value beyond the structured field.

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

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

The description is two sentences: the first states the purpose and outputs, the second provides usage guidance. Every word is meaningful; no redundancy or filler. Front-loaded with key information.

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

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

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

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

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

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

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

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

The description clearly states the tool returns a 'straddle-implied expected move per expiry' and enumerates the specific fields (1-sigma range, bounds, straddle price, ATM IV). This is a precise verb+resource definition that distinguishes it from sibling tools like get_volatility or get_option_chain.

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

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

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

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

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

Annotations already declare readOnlyHint=true, confirming read-only. The description adds behavioral details: equal weights when omitted, normalization to sum 1, and a 50-symbol limit. This goes beyond the annotation's binary flag, though no destructive behaviors or side effects need disclosure.

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

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

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

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

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

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

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

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

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

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

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

The description clearly states it provides a weighted cross-symbol aggregate of GEX, DEX, VEX, CHEX across up to 50 symbols. This specific verb-resource combination distinguishes it from single-symbol exposure tools like get_gex, get_dex, etc., differentiating from siblings.

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

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

The description explicitly lists use cases: portfolio/basket scanner, sector exposure roll-up, custom index dealer positioning. This provides clear context for when to use. However, it does not explicitly state when not to use (e.g., for single-symbol queries), which would strengthen guidance further.

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

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

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

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

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

A single sentence front-loads the core purpose and lists all key output elements. Every phrase adds value, with no wasted words.

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

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

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

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

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

The input schema has 100% description coverage, so all parameters are documented. The description adds no additional parameter-level meaning beyond the schema, warranting a baseline 3.

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

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

The description clearly states the tool returns a unified per-strike exposure sheet with GEX, DEX, VEX, CHEX, DAG, and additional flags, differentiating it from individual sibling tools like get_gex or get_dex. The verb 'get' and resource 'exposure_sheet' match the name and title perfectly.

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

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

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

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

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

Annotations indicate readOnlyHint=true, so description's burden is lower. The description accurately implies a read operation but adds no extra behavioral details (e.g., data freshness, rate limits, or OAuth flow notes). Adequate but not enhanced.

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 with front-loaded purpose and a colon-separated list of return contents. Every word adds value; no redundancy or filler.

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

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

Given no output schema, the description adequately lists key return components. It covers multiple dimensions of exposure, though it omits potential fields like max pain or open interest. Overall sufficient for agent decision-making.

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

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

Schema coverage is 100%; both parameters (apiKey, symbol) are documented in the schema. The description does not add meaning 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 identifies the tool as retrieving a 'full exposure summary' and lists specific components (GEX, DEX, VEX, CHEX, gamma regime, etc.). This distinguishes it from sibling tools like get_gex or get_dex which focus on 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?

No guidance is provided on when to use this tool versus alternatives (e.g., get_gex for gamma exposure only, get_exposure_basket for basket view). Missing context on 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, so the description adds no behavioral context beyond that. No mention of authentication needs, rate limits, or side effects.

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

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

Description is a single dense sentence that efficiently lists the key outputs. It is concise and front-loaded, though it could benefit from slight restructuring for readability.

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

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

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

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (apiKey, expiry, symbol). The description does not add additional semantic meaning beyond the schema, meeting the baseline.

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

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

Description clearly states that the tool returns settled vs live dealer risk shift, GEX/DEX adjustment, percent shifts, direction classifier, and plain-English description. This distinguishes it from sibling tools like get_gex and get_dex by adding adjustment and classification.

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

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

No explicit guidance on when to use this tool vs alternatives like get_gex, get_dex, or get_flow_summary. The description lists outputs but does not provide context for when this is the preferred choice.

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

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

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

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

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

The description is two sentences, front-loaded with key metrics and distinguishing feature ('more current'). Every word adds value without redundancy.

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

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

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

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

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

Schema coverage is 100% with each parameter described. The description adds no additional semantics beyond the schema; it only explains computation details (effective OI, simulation). Baseline 3 is appropriate.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Without an output schema, the description lists the bundle components, giving the agent a good idea of return values. It could be more specific about the structure of each component, but sufficient for a bundle tool.

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

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

Schema coverage is 100% with descriptions for all parameters. The description elaborates on the view parameter ('full simulation-aware live GEX surface' etc.), adding nuance but not essential new meaning. Baseline 3 is appropriate.

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

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

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

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

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

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

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

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

Annotations already set readOnlyHint=true, confirming no mutation. The description adds behavioral context by specifying it computes using 'effective (simulation-aware) OI' and reflects 'intraday flow changes to dealer positioning,' which goes beyond what annotations convey. No contradictions.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint: true, indicating a safe read operation. The description adds that it produces a leaderboard or outlier scan, but does not disclose other behavioral traits such as data freshness, rate limits, or pagination behavior.

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

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

The description is two sentences, front-loading the purpose and then succinctly defining the key parameters. Every word adds value; no redundancy or verbosity.

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

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

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

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

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

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

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

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

The description clearly identifies the tool as a cross-symbol flow leaderboard/outlier scan, specifying asset classes ('options' | 'stocks') and scan kinds ('leaderboard' | 'outliers'). It distinguishes itself from sibling flow tools by explicitly focusing on cross-symbol ranking and outlier detection.

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

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

The description implies usage for scanning across symbols but does not provide explicit guidance on when to use this tool over alternatives like get_flow_live or get_flow_summary. No when-not or alternative references are given.

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

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

Annotations declare readOnlyHint: true, and the description aligns with that by describing a read-only data feed. The description adds behavioral context by specifying the two output modes (full feed vs summary) and the type of data (score breakdown, greeks, delta-notional). No contradictions; the additional detail complements the annotations.

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

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

The description is exactly two sentences, front-loading the core purpose and then highlighting the key option. Every word contributes meaning; no fluff or repetition. It is optimally concise while remaining informative.

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

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

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

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

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

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

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

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

The description clearly states it provides a 'scored, classified unusual options activity feed' and lists specific components like sweeps, blocks, smart money, and intent classification. It distinguishes itself from other flow tools by emphasizing scoring, greeks enrichment, and two modes (full feed vs summary). This sufficiently differentiates it from siblings like get_flow_live or get_flow_summary.

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

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

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

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

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

Annotations set readOnlyHint=true, consistent with description's read-only nature. Description adds useful behavioral context: simulation-awareness, low cost to poll, and specific output fields. No contradictions.

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

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

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

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

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

Although no output schema is provided, the description lists output fields (flow direction, delta, GEX). It could mention potential error conditions or relationship to other detailed tools, but overall sufficient for a summary tool.

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

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

Schema coverage is 100% with all parameters described. Description does not add additional parameter semantics beyond the schema, so baseline score of 3 applies.

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

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

The description clearly states it provides an 'at-a-glance simulation-aware flow card' with specific fields (flow direction, intraday delta, live GEX). It differentiates from siblings like get_flow_live or get_gex by emphasizing 'summary' and 'cheap to poll'.

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

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

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

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

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

The annotation declares readOnlyHint=true, and the description reinforces this by stating the tool 'shows' and 'reveals' information. The description adds behavioral context by specifying the nature of the data (dealer gamma positioning, support/resistance), which goes beyond the annotation.

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

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

The description is three sentences, front-loaded with the main purpose, and every sentence adds value. No redundant or extraneous information.

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

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

The description explains what the tool reveals and mentions key concepts (gamma flip, call/put walls, support/resistance). However, given the lack of an output schema, details about the return format or data structure 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?

The input schema has 100% description coverage for all four parameters (apiKey, min_oi, symbol, expiration). The description does not add additional meaning beyond what the schema already provides. Baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves gamma exposure by strike and explains the insights it provides (dealer gamma positioning, gamma flip, support/resistance). This distinguishes it from sibling tools like get_chex or get_dex which have different focuses.

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 provide guidance on when to use this tool versus alternatives such as get_chex or get_historical_gex. There is no mention of prerequisites or context for invocation.

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, which is consistent with replaying historical data. Description adds that data is EOD-stamped and refreshed daily, which is useful context beyond annotations. No contradictions.

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

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

Two sentences with key information front-loaded. Efficient and to the point, though could be slightly more 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?

Lists the types of data returned (SVI parameters, forward prices, etc.) even without an output schema. Adequately describes the tool's output. No mention of pagination or format, but sufficient for most use cases.

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

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

Schema covers all parameters with descriptions. The description does not add significant meaning beyond what the schema provides. Baseline 3 is appropriate since schema description coverage is 100%.

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 replays advanced volatility analytics (SVI parameters, forward prices, etc.) at any minute since April 2018. Distinguishes itself from siblings like get_advanced_volatility (current) and get_historical_volatility (basic) by specifying historical, advanced, and EOD-stamped refresh.

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 mentions time range ('any minute since April 2018') and data freshness ('EOD-stamped'). Implies use when historical advanced volatility data is needed. Does not explicitly state when not to use or list alternatives, but context from sibling tools 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?

The description is consistent with the annotation 'readOnlyHint: true' (replaying data is read-only). It adds context about the earliest date (April 2018) but does not disclose additional behavioral traits such as rate limits or data freshness.

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 at two sentences, with the first sentence immediately stating the purpose. No extraneous 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?

No output schema is provided. The description does not explain the return format or structure of the historical CHEX data, which is important given the many similar historical tools. Users lack information about what data the tool returns.

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% coverage with descriptions for all parameters. The description does not add significant meaning beyond the schema; the phrase 'by strike' is ambiguous as the parameter is 'symbol' (ticker), not strike.

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 uses a specific verb ('replay') and resource ('charm exposure'), and distinguishes from the sibling tool 'get_chex' by specifying 'historical' and the time range.

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 analysis but does not explicitly state when to use this tool versus alternatives like 'get_chex' for current data. No 'when not to use' guidance is provided.

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

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

Annotations indicate readOnlyHint=true, and the description provides additional details on outputs (coverage windows, day counts, gaps). No contradictions. Could mention data freshness or performance, but sufficient.

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

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

Two sentences, no fluff, front-loaded with action and outcomes, then usage context. Highly concise.

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

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

For a simple list tool without output schema, the description covers purpose, usage, and the nature of returned data. 'Alpha tier' adds minor context. Could mention sorting or pagination, but not essential.

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. Description adds no extra semantics beyond what schema already provides for apiKey and symbol.

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

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

Clearly states the tool lists symbols with coverage windows, day counts, and gaps, distinguishing it from other get_historical_* siblings by specifying its role as a prerequisite check for replay requests.

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 instructs to call this first to check queryability before sending a replay request, providing clear guidance on when to use.

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

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

Description adds 'historical' and 'Alpha tier' to readOnlyHint annotation. Does not detail data granularity, rate limits, or authentication flow beyond parameter descriptions.

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 with tier label is concise but lacks depth; could include more context without significantly expanding length.

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

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

No output schema; description omits return format, pagination, or what 'replay' entails. Incomplete for a historical data tool with 3 parameters.

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%; description adds no extra meaning beyond schema. Baseline 3 is appropriate as description does not improve 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?

Clear verb 'Replay' indicates retrieval of historical DEX data by strike, with specific time range 'since April 2018'. Distinguishes from sibling tools like 'get_dex'.

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 on when to use this tool versus alternatives (e.g., get_dex for current data, other historical tools). 'Alpha tier' hints at access but not 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 declare readOnlyHint=true, and the description confirms read-only behavior with 'Replay.' It adds useful context about the data returned (net GEX/DEX/VEX/CHEX, regime, etc.) without contradicting 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 extremely concise: two sentences, no filler. The first sentence front-loads the core purpose and scope, making it immediately useful for an agent.

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

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

With no output schema, the description compensates by listing the key metrics returned (net GEX/DEX/VEX/CHEX, regime, hedging estimates, top strikes) and the time range. It is fairly complete, though it could mention format or pagination.

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 already explained in the schema. The description adds no additional parameter-level details beyond noting the 'Alpha tier' constraint, which does not enhance parameter semantics.

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 the full exposure summary (net GEX/DEX/VEX/CHEX, regime, hedging estimates, top strikes) for any minute since April 2018. It specifies the exact resource and distinguishes it from sibling tools like get_exposure_summary and get_historical_gex by listing the unique metrics included.

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 'Alpha tier,' implying premium access, and indicates the time range (since April 2018). However, it does not explicitly state when to use this tool versus alternatives (e.g., get_exposure_summary for current data) or provide 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, so the read-only nature is clear. The description adds meaningful context: the tool replays data 'at any minute since April 2018' and returns the same shape as live GEX. The 'Alpha tier' note hints at access restrictions but does not elaborate on other behavioral traits like rate limits or data precision.

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

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

The description is two sentences long, front-loading the core action and then providing a efficiency note about output shape and tier. Every sentence adds value, with no redundant or verbose language.

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

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

The description lacks an output schema and only vaguely references the return shape as 'same shape as live /v1/exposure/gex'. For a historical data tool, it would be helpful to specify the output format, data range limitations, or whether partial data is possible. The description is adequate but incomplete for a tool with no output schema.

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 detailed descriptions for 'at' (format and default) and 'apiKey' (conditional usage). The tool description does not add any additional meaning beyond what the schema already provides, so a baseline score of 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 'Replay gamma exposure (GEX) by strike at any minute since April 2018', specifying the verb (replay), resource (gamma exposure), and scope (historical, by strike). This distinguishes it well from sibling tools like get_gex (live) and other historical variants (get_historical_chex, get_historical_dex).

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 that the tool returns the same shape as the live endpoint, providing implicit context for when to use it (historical vs. live). However, it does not explicitly specify when not to use it or direct users to alternative tools for other historical metrics, leaving some ambiguity for an 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?

readOnlyHint already set. Description adds data range and examples of key levels but no extra details on permissions, rate limits, or side effects. Adequate for read-only.

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 short sentences, no fluff. The 'Alpha tier' tag is minor but not detrimental. Very concise.

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

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

No output schema; description lists examples but not return structure. Data range and examples help but incomplete for an unfamiliar 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 100%, baseline 3. Description adds meaning by listing specific key levels (gamma flip, walls, etc.), reinforcing the historical context for the 'at' parameter.

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 verb 'replay', resource 'key options levels', and scope 'any minute since April 2018'. Distinguishes from siblings like get_levels (current) and other historical 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?

Implies usage for historical key level analysis but no explicit when-to-use vs alternatives like get_levels. No when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, indicating a safe read operation. Description adds 'replay' context but no additional behavioral details like data freshness, rate limits, or auth requirements beyond the apiKey parameter.

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

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

Two sentences, front-loaded with key information (what it does, since when). No unnecessary words; highly efficient.

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?

Missing output schema and no description of return format. Given the complexity of multiple metrics (max pain, pain curve, dealer alignment, pin probability), the description is too sparse for full 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 coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond the schema, 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?

Description clearly states the tool replays historical max pain, pain curve, dealer alignment, and pin probability since April 2018. The verb 'replay' and resource 'historical max pain' are specific, and the time range distinguishes it from current max pain 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?

No explicit guidance on when to use this tool vs alternatives like get_max_pain. The 'Alpha tier' hint is vague and does not help an agent choose between similar historical tools.

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

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

Annotations already provide readOnlyHint=true, and the description is consistent ('Replay' implies read-only). It adds 'Alpha tier' as a behavioral trait (access restriction) but does not go beyond what annotations offer or discuss other behavioral aspects like response size or potential 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?

The description is a single sentence with about 20 words, front-loading the main action and key details. Every phrase adds value, with no redundancy or filler.

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

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

Given 3 parameters, no output schema, and annotations with readOnlyHint, the description provides enough context: purpose, time range, and access tier. It could mention output nature (e.g., text report) but is largely complete for agent decision-making.

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

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

Schema coverage is 100%, so the schema documents parameters. The description adds context: 'at any minute since April 2018' clarifies the 'at' parameter's time range and format, and 'Alpha tier' hints at apiKey requirement. This adds meaning beyond the bare schema descriptions.

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

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

The description clearly states the tool replays verbal narrative analysis (regime, key-level commentary, prior-day comparison) at any minute since April 2018. This specific verb and resource distinguish it from sibling tools like get_narrative (presumably current) and other historical 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 implies usage for historical narrative retrieval with 'Replay... at any minute since April 2018', and 'Alpha tier' indicates access restrictions. However, it does not explicitly state when not to use it or mention alternatives like get_narrative for current data.

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

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

Annotations already declare readOnlyHint=true, so the description adds value by specifying the temporal scope ('any minute since April 2018') and the 'Alpha tier' access level. No contradictions or missing critical behavior.

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

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

The description is a single, concise sentence that front-loads the main action. It is efficient but could benefit from breaking out key details for scanning.

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 8 parameters and no output schema, the description covers the return content (BSM greeks, IV, OI), filtering options, time range, and tier. It provides a solid overview, though more about output format or pagination could improve completeness.

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

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

Schema coverage is 100% with detailed descriptions for all 8 parameters. The description only mentions filtering by expiry, strike, and type, which is already in the schema. No additional meaning is provided beyond the schema.

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

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

The description clearly states the tool retrieves historical option quotes with BSM greeks, IV, and OI, and specifies filtering by expiry, strike, and type. This distinguishes it from siblings like get_option_quote (current) or get_historical_volatility.

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

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

The description implies usage for historical option chain data but does not provide explicit guidance on when to use this tool versus siblings, or when not to use it. No alternatives or exclusions 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 declare readOnlyHint: true, so the description does not need to repeat that. The description adds 'Alpha tier', which may imply rate limits or access restrictions. However, it does not disclose return format, pagination, or error behaviors. The behavioral burden is partially met but incomplete.

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 very short and front-loaded, conveying the core purpose and a tier hint in a single sentence. It is not padded with unnecessary details, but could be slightly more 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?

With 3 parameters fully described in the schema and no output schema, the description is minimal but sufficient for a simple retrieval tool. However, it lacks information on return format and any rate-limiting implications of the 'Alpha tier', which could affect agent decisions.

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 provides meaning for all three parameters. The description does not add additional parameter context beyond the tier hint. Baseline 3 is appropriate.

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

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

The description clearly states the tool replays a stock bid/ask/mid at any minute since April 2018, which is a specific verb ('replay') and resource ('historical stock quote'). It also hints at its uniqueness with the time range and data type, distinguishing it from sibling tools like get_stock_quote (current) and other historical 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 its many siblings. The 'Alpha tier' hint is vague and does not clarify usage context or exclusions. Given the large sibling list, more direction is needed.

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 agent knows it's safe. Description adds no extra behavioral details (e.g., rate limits, auth specifics) beyond the schema, but does not contradict 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?

Single sentence plus tier note, no unnecessary words. Information is front-loaded and efficient.

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

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

No output schema, so description should clarify return structure. It lists components but not format or nesting. With 2 required params and no nested objects, it's partially complete but could specify response shape.

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

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

Schema covers 100% of parameters with descriptions. The description adds context for 'at' (timestamp range) and lists components, but does not substantially increase understanding beyond the schema.

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

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

The description clearly states it retrieves a comprehensive historical stock summary at a given timestamp, listing included components (price, IV, VRP, etc.). It distinguishes from siblings by being 'historical' and 'summary', but does not explicitly differentiate from other historical tools like get_historical_volatility.

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

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

No guidance on when to use this tool versus alternatives among many siblings. Only mentions time range ('since April 2018') and tier ('Alpha'), but lacks when-to-use or when-not-to-use instructions.

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, consistent with a read operation. The description adds 'EOD-stamped (SVI parameters refresh daily)' and 'Alpha tier', providing insight into data freshness and access level. 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 succinct sentences: first sentence captures core functionality, second adds essential quality details (EOD-stamped, daily refresh, tier). No filler 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?

For a simple tool with 3 parameters, no output schema, and clear annotations, the description covers purpose, time range, and update frequency. Could mention output format but is adequate.

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

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

Schema description coverage is 100%. The description mentions 'any minute since April 2018' which reinforces the 'at' parameter but does not add new meaning beyond the schema's format and purpose.

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

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

The description clearly states 'Replay the implied volatility surface grid' with a specific time range 'since April 2018', distinguishing it from the sibling 'get_surface' (current surface). Verb and resource are explicit.

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

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

The description implies historical use by mentioning 'replay' and 'since April 2018', but does not explicitly state when to use vs alternatives like 'get_surface' or exclude other tools.

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

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

Annotations already declare readOnlyHint=true. The description adds context about historical per-strike replay and Alpha tier, but does not elaborate on return format, pagination, or other behavioral traits. It provides some added value beyond annotations.

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

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

The description is a single concise sentence plus tier mention, with no wasted words. It is efficiently front-loaded but could benefit from slight restructuring for completeness.

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 absence of an output schema and the presence of 57 sibling tools, the description is too brief. It omits details about what VEX is, the resolution of 'any minute', and the nature of the returned data, making it insufficient for an agent to fully understand the tool's behavior.

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% coverage with descriptions for all 3 parameters. The tool description does not add further parameter-specific meaning beyond what is in the schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Replay' and the resource 'vanna exposure (VEX) by strike', specifying a time range ('since April 2018') and tier ('Alpha tier'). This effectively distinguishes it from siblings like get_vex (current VEX) and other historical 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 implies usage for historical VEX data and mentions the Alpha tier requirement, but does not explicitly exclude alternatives or state when not to use it. Context is clear but lacks direct comparison to siblings.

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

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

Annotations indicate readOnlyHint=true, so the description does not need to reiterate idempotency. It adds 'Alpha tier' as a behavioral constraint. However, it does not disclose other traits like error handling, rate limits, or response format. Score 3 is appropriate for adding some context beyond annotations.

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

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

Two sentences, no filler. Front-loaded with the core action and metrics. Every word serves a 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?

No output schema, but the description lists the analytics returned (ATM IV, realised vol, spreads, etc.), giving a good sense of output. It also specifies time range and tier. Missing details like whether the response is a time series or single point, but overall adequate for a historical data tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by specifying that the 'at' parameter accepts any minute since April 2018, a constraint not in the schema. This extra detail improves understanding beyond parameter names and types.

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

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

The description clearly states the tool replays historical volatility analytics (ATM IV, realised vol, spreads, skew, term structure) for any minute since April 2018. It uses a specific verb ('Replay') and resource, distinguishing it from sibling tools like get_historical_advanced_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 mentions 'Alpha tier' as a restriction but does not explicitly state when to use this tool versus alternatives. There is no guidance on when not to use it or which sibling tools might be more appropriate for specific needs.

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

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

Annotations already provide readOnlyHint=true. The description adds critical behavioral context: leak-free backtesting, date-bounded SQL, and Alpha tier. No contradictions.

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

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

Two concise sentences plus a tier label. Efficient, front-loaded with key information, and no redundant 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 no output schema, the description adequately lists returned components (z-score, percentile, etc.) and explains the leak-free property. It is complete for the tool's complexity but could explicitly differentiate from get_vrp_history.

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. The description adds no additional parameter-level detail 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 specifies 'Replay VRP dashboard' with a clear verb and resource, and includes temporal scope ('any minute since April 2018'). It distinguishes from siblings like get_vrp (current) and get_vrp_history by emphasizing the replay/backtest capability.

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

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

The description explicitly states the leak-free date-bounded nature for backtesting, implying usage for historical analysis. However, it does not directly contrast with alternatives like get_vrp or mention when not to use it.

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

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

Annotations already declare readOnlyHint=true, and the description's 'Replay' aligns with that. The description adds the 'Alpha tier' label, hinting at access restrictions, but does not elaborate on behavioral traits such as rate limits, data freshness, or what happens if data is unavailable for a specific minute. Since annotations cover the safety profile, the description adds minimal extra 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?

Two sentences, no redundant words. The first sentence immediately states the core function and scope, and the second adds a minor tier qualifier. Every word serves a 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?

The description provides the analytics types and time range but lacks details about the output structure, especially since no output schema exists. It does not mention whether results are paginated, how to handle large date ranges, or what happens if the symbol has no data at the given minute. For a historical tool with three parameters, this is adequate but incomplete.

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 documentation coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meanings or constraints beyond what the schema already provides (e.g., timestamp format, ticker expectations). No compensation needed due to full 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 replays 0DTE analytics for same-day expiry, listing specific metrics (pin risk, expected move, gamma acceleration, dealer hedging estimates) and the historical time range (any minute since April 2018). This differentiates it from sibling tools like get_zero_dte (likely current) and other historical tools by focusing on 0DTE and specific analytics.

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 historical usage ('Replay... at any minute since April 2018') but does not explicitly state when to use this tool over alternatives like get_zero_dte for current data or get_historical_gex for different metrics. No when-not or alternative tool names are mentioned, leaving the agent to infer context.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds interpretive context (support/resistance from dealer hedging) but does not disclose other behavioral aspects like error handling or required authentication beyond the schema.

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

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

Two concise sentences: first lists the key levels, second provides interpretive context. No fluff, front-loaded with essential information.

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

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

While the description identifies the returned metrics, it lacks details on output structure or data types. Given no output schema, more completeness on return format would be helpful. However, the description is adequate for basic understanding.

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

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

Schema coverage is 100% with clear descriptions for both parameters (apiKey and symbol). The description adds meaning by explaining what the output represents but does not elaborate on parameter usage or constraints beyond the schema. Baseline score of 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?

Description clearly states the tool retrieves 'key options levels' and lists specific metrics (gamma flip point, call wall, etc.), with additional context that they act as support/resistance from dealer hedging. This distinguishes it from siblings like get_flow_levels or get_historical_levels.

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

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

No explicit guidance on when to use this tool versus alternatives. Given many sibling tools (e.g., get_gex, get_max_pain, get_flow_levels), the description lacks context for selection or exclusion.

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

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

Annotations already mark the tool as readOnlyHint=true, so the description adds value by detailing the output metrics (score, spreads, depth) and the label thresholds (tight, normal, wide, illiquid). It does not contradict any annotations.

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

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

The description is extremely concise—two sentences—yet packs all essential information: metrics, labels, and use cases. Every part contributes meaningfully, with no wasted words.

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

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

The description explains the output metrics and labels, which is sufficient given no output schema. However, it does not clarify that no expiry parameter is needed (the tool returns all expiries for the given symbol), which might require the agent to infer. Slightly more explicit scoping would improve completeness.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not provide any additional parameter-specific guidance beyond what is in the schema (symbol and optional apiKey). It does not explain parameter formats or constraints further.

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

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

The description clearly states it provides per-expiry option liquidity scores (0-100) along with bid-ask spread percent, OI-weighted spread, ATM OI depth, and chain-level execution quality. It also defines liquidity labels. This distinguishes it from sibling tools like get_option_chain or get_option_quote, which do not aggregate liquidity metrics per expiry.

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

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

The description explicitly tells the agent to use it for selecting the most liquid expiry, assessing execution quality, or screening for tight spreads. However, it does not mention when not to use it or provide specific alternative tool names, leaving room for improvement in exclusion guidance.

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

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

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

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

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

The description is a single, well-structured sentence that front-loads the tool's purpose and lists key outputs. Every word adds value, and there is no redundancy.

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

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

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

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

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

Schema description coverage is 100%, and the description does not add any additional meaning to the parameters. It focuses on outputs, so it meets the baseline but does not enhance parameter understanding.

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

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

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

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

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

No guidance is provided on when to use this tool versus its siblings (e.g., get_historical_max_pain, get_option_chain, get_exposure_summary). The description only lists outputs, leaving the agent to infer usage context.

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

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

The description adds context beyond the readOnlyHint annotation by specifying the content of the output (gamma regime, dealer positioning). It does not cover rate limits or auth details, but the read-only nature is consistent.

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 only two sentences, front-loads the purpose, and contains no extraneous words. Every sentence adds value.

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

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

Given no output schema, the description explains what the output contains (e.g., 'plain English' analysis of gamma regime). It could specify format but still provides adequate context for an AI agent.

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

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

Schema coverage is 100% with both parameters described. The description does not add extra meaning to parameters beyond what the schema provides, so baseline 3 applies.

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

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

The description clearly states the tool provides a verbal narrative analysis of GEX, listing specific components like gamma regime, key levels, and dealer positioning. This distinguishes it from sibling tools like get_gex (numerical) and get_dealer_premium.

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 when a plain English explanation of gamma regime is needed, but it does not explicitly state when to choose this over alternatives, nor does it provide exclusions or prerequisites.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description clearly states the tool provides day-over-day open interest deltas, per-contract changes, top-N sorted by absolute magnitude, and call/put aggregate totals. It distinguishes from siblings like get_flow_levels by focusing on OI shifts.

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

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

The description includes a usage statement: 'Use to track new positioning, unwinding, and block print intent from OI shifts.' This gives clear context, but it does not explicitly mention when not to use or alternatives, though the context is sufficient.

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

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

Annotations already declare readOnlyHint=true, indicating safe read operation. The description adds that it returns metadata (expirations, strikes), which is useful but does not provide additional behavioral traits such as data freshness or rate limits. It is consistent with annotations.

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

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

The description is a single, clear sentence with no unnecessary words. It efficiently conveys the tool's 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?

Without an output schema, the description should clarify the return structure. It mentions 'metadata: available expirations and strikes' but omits whether results are arrays, how they are organized, or pagination. It is adequate but leaves 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 coverage is 100%, so the description is not required to add parameter details. It confirms 'for a ticker' aligns with the symbol parameter but adds no new semantics beyond the schema.

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

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

The description specifies the tool retrieves 'option chain metadata: available expirations and strikes for a ticker,' which is a specific verb and resource. It distinguishes among siblings like get_option_flow or get_volatility by focusing on the chain structure.

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 when one needs expirations and strikes for a ticker, but provides no explicit guidance on when to use this tool versus alternatives like get_surface or get_option_quote. No exclusionary context is given.

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

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

Annotations already mark the tool as readOnlyHint=true. The description adds behavioral context by detailing each view's structure (e.g., 'newest first,' 'minute buckets') and parameter constraints like limit applicability. No contradictions.

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

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

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

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

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

Given no output schema and 6 parameters with 2 required, the description explains return formats for each view and constraints like limit bounds. It lacks pagination details or error handling, but covers essential context for a complex tool.

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

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

Schema covers all 6 parameters (100% coverage). The description enhances this by clarifying view meanings, limit scope ('Only applies to recent'), and expiry filter usage, adding semantic value beyond raw schema.

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true, so safety is clear. The description adds that it returns live data and lists fields, but does not disclose behavior such as return format, error handling, or authentication nuances beyond the schema.

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

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

The description is two sentences, no fluff, front-loads the main purpose and then adds filtering options. 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 5-parameter tool with no output schema, the description covers inputs and outputs adequately. It lacks explicit output shape (e.g., single object or null), but given the listed fields, the agent can infer the 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?

Schema coverage is 100%, with each parameter described. The description reiterates filtering by expiry, strike, and type, but adds no new meaning beyond what the schema provides. Baseline of 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 option quote' and enumerates specific data fields (bid, ask, mid, IV, greeks, open interest, volume). It distinguishes itself from siblings like get_option_chain (whole chain) and get_historical_option_quote (historical).

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 filtering by expiry, strike, and type, but does not explicitly state when to use this tool vs siblings. No when-to-use or when-not-to-use guidance is provided, despite many related 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 include readOnlyHint=true, which aligns with the read-only nature. The description adds behavioral details: range estimators are 5–8× more efficient than close-to-close, and mentions 'Alpha tier' (a tier limitation). No contradiction.

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

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

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

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

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

For a tool with two parameters and no output schema, the description conveys the return types (five estimators over three windows) and intended use. It lacks explicit output structure but is sufficient for agent invocation.

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

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

Schema coverage is 100%, so all parameters are documented. The description adds context about estimators and windows but does not add specific meaning to the two parameters (symbol, apiKey) beyond the schema.

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

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

The description specifies the verb 'Get', the resource 'Realized Volatility Estimators', and lists the specific estimators (close-to-close, Parkinson, Garman-Klass, Rogers-Satchell, Yang-Zhang) with time windows. It clearly differentiates from sibling tools like get_volatility (implied vol) and get_historical_volatility.

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

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

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

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

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

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

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

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

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

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

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

The tool is simple (2 params, no nested objects, no output schema). The description fully explains what the tool returns and when to use it, making it complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100%: both parameters (apiKey, symbol) are fully described in the schema. The description adds no additional meaning to the parameters themselves; it lists the output metrics. Since the schema already documents the parameters, the baseline of 3 is correct.

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true, so the tool is known to be read-only. The description adds no new behavioral traits beyond this; it only provides domain context. No contradiction exists.

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

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

The description is three sentences, front-loaded with the core definition, and includes no unnecessary words. Every sentence provides value.

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

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

Given no output schema, the description could explain the output format or typical values, but it sufficiently describes the tool's purpose and use cases. The missing output details lower the score slightly but it is still largely complete.

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

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

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

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

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

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

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

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

The description explicitly lists three use cases: assessing leverage effect strength, calibrating hedges, and classifying correlation regimes. However, it does not mention when not to use the tool or provide explicit alternatives from the sibling list.

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no substantive parameter meaning beyond listing the view names; parameter dependencies (e.g., resolution for 'bars') are only in the schema, not in the description.

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

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

The description clearly states 'Raw intraday stock trade-flow for one symbol' and enumerates six distinct views with brief descriptions, making the tool's purpose specific and unambiguous. It distinguishes from sibling tools like get_option_flow (stock vs. option) and get_flow_summary (raw data vs. totals).

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

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

The description implies usage for intraday stock trade flow but does not provide explicit guidance on when to use this tool over alternative siblings such as get_flow_summary or get_flow_scan. There is no mention of when not to use it or prerequisites.

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

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

Annotations already indicate readOnlyHint=true. The description adds value by specifying the returned data fields (bid, ask, mid, last price). No contradictory or missing behavioral info, though it does not mention rate limits or error handling.

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

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

The description is a single, concise sentence that front-loads the essential information. No extraneous 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?

For a simple tool with 2 parameters and no output schema, the description covers the core functionality and output fields. May be slightly improved by mentioning error cases (e.g., invalid symbol) but is largely complete.

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

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

Schema coverage is 100%, with both parameters (apiKey, symbol) described. The description adds no new meaning beyond the schema; it simply restates the symbol parameter's purpose. 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 name and description clearly state the tool retrieves a real-time stock quote with specific fields (bid, ask, mid, last price) for a ticker symbol. This distinguishes it from siblings like get_historical_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 real-time usage but does not explicitly specify when to use this tool versus alternatives (e.g., get_historical_stock_quote). No exclusionary guidance is provided.

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

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

Annotations already indicate readOnlyHint=true, so the tool is safe. The description adds value by enumerating all the data types included, providing transparency about the return content beyond what annotations convey.

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

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

The description is a single sentence that packs many details. It is concise and front-loaded with the core purpose, but the long list of items slightly reduces readability. Still, it's efficient enough for an agent to parse quickly.

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 listing many data types, the description does not explain the structure of the output (e.g., whether it returns a dict with specific keys, or how data is organized). No output schema is provided, so the description should clarify the format for an agent to interpret results.

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

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

Schema description coverage is 100%—both parameters (apiKey, symbol) are described in the schema. The description does not add additional meaning or usage details for these parameters 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 specifies the verb 'get' and resource 'comprehensive stock summary', listing many distinct data categories (price, ATM IV, historical vol, VRP, skew, terms structure, options flow, exposure data, macro context). This differentiates it from sibling tools that focus on individual components.

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 tool is for a broad overview but does not explicitly state when to use it versus more specific tools (e.g., get_volatility, get_flow_summary). An agent could infer the intended use from the listed components, but no direct guidance is provided.

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

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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds behavioral context by explaining what each signal answers, going beyond the annotations. However, it does not disclose other traits like rate limits or authentication requirements.

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

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

The description is well-structured with bullet points for each signal, but it is lengthy due to detailed explanations. Important information (purpose) is front-loaded. Could be more concise, but the structure aids readability.

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

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

The description lacks any explanation of the output structure or return value, which is a significant gap given the absence of an output schema. It does not describe what a 'decision envelope' contains, limiting the agent's ability to use the result effectively.

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

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

Schema coverage is 100%, but the description adds value by extensively explaining each signal enum value, which helps the agent select the correct signal. The description does not provide additional semantics for the symbol and apiKey parameters beyond the schema.

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

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

The description clearly states the tool retrieves 'a strategy decision envelope for one of 10 options-based trading signals,' providing a specific verb and resource. It uniquely distinguishes itself from sibling tools like get_flow_signals by focusing on strategy signals with enumerated options.

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

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

The description lists the available signals but does not explicitly guide when to use this tool versus alternatives, nor does it mention prerequisites or situations where it should not be used. Usage context is implied but not directly stated.

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

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

Annotations provide readOnlyHint=true, so it's a read operation. The description adds value by detailing the output's grid size (50x50), construction method (bilinear interpolation), and the fact it's live and built from OTM contracts. No contradictions.

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

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

The description is a single, well-structured sentence that immediately conveys the tool's core function (get live surface), its dimensions (50x50), and its construction (bilinear interpolation). Every word adds value.

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

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

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

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

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

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

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

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

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

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

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

The description does not explicitly state when to use this tool versus alternatives like get_volatility or get_advanced_volatility. Usage is implied for users needing a full surface grid, but no when-not-to-use or exclusion criteria are provided.

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

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

Annotations already provide readOnlyHint: true. The description adds useful behavioral context: 'Live' data, per-expiry calibration, and access requirements ('Alpha tier required'). No contradictions with annotations.

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

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

The description is two sentences and a tier note, front-loaded with the core functionality. Every sentence adds value, with no redundancy or filler.

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

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

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

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already documents (symbol and apiKey). It mentions 'per expiry' but does not elaborate on parameters.

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

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

The description clearly states the tool returns SVI-fitted volatility surface parameters per expiry, listing specific outputs (a, b, rho, m, sigma, ATM total variance, ATM IV). It provides concrete use cases (surface reconstruction, arbitrage checking, etc.) and is distinct from sibling tools.

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

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

The description explicitly suggests use cases and notes 'Alpha tier required,' guiding appropriate usage. While it doesn't state when not to use it or mention alternatives, the context is clear enough for an AI agent to infer suitable scenarios.

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

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

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

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

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

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

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

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

The description covers purpose and usage adequately for a simple list tool with no output schema or required parameters. It is sufficiently complete for an agent to decide when to invoke it.

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

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

The only parameter apiKey has a schema description; the tool description adds no extra semantics. Since schema coverage is 100%, baseline 3 is appropriate.

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

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

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

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

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

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

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