flashalpha

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 Black-Scholes model and listing computed greeks. However, it omits important behavioral details such as assumed model parameters (e.g., zero interest rate, zero dividends) and does not describe the output format, which is not covered by an output schema.

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

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

The description is a single sentence, front-loaded with the verb 'calculate', and contains no unnecessary words. It efficiently conveys the tool's purpose and key distinguishing feature.

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 no output schema, the description should clarify the return format (e.g., all greeks at once as an object) and underlying assumptions. The current description lists greeks but leaves ambiguity about outputs. While the schema covers inputs well, the description lacks completeness in explaining the output 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 description coverage is 100% with clear parameter descriptions (e.g., 'Days to expiration', 'Implied volatility as decimal'). The tool description adds no additional parameter semantics beyond listing output greeks, which is a baseline performance given the high schema coverage.

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

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

Description clearly states the verb 'calculate' and resource 'option greeks', listing specific greeks (delta, gamma, theta, etc.). It also distinguishes from sibling tools by emphasizing 'Pure math — no market data needed', differentiating it from market-data-dependent tools.

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

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

The description provides clear context that the tool is a pure mathematical calculation without market data, implying it should be used when no real-time data is required. However, it does not explicitly name alternative tools or provide when-not-to-use guidance.

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

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

Annotations mark it as read-only (readOnlyHint: true). The description adds that it uses BSM expected value and computes an edge-maximizing bet size, which is consistent. It 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?

The description is two sentences, front-loading the core purpose and method. No redundant 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 covers purpose and method but omits output format (e.g., returns a fraction of capital). Given no output schema, slightly incomplete for a compute 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 the baseline is 3. The description mentions 'BSM expected value vs premium' but does not add additional meaning beyond the schema's parameter 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 verb 'compute' and the resource 'Kelly criterion optimal position sizing for an option trade.' It distinguishes itself from siblings like 'calculate_greeks' by specifying the edge-maximizing bet size using BSM expected value versus 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 does not explicitly state when to use this tool versus alternatives (e.g., calculate_greeks, solve_iv). It implies usage for position sizing but lacks exclusions or alternative 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 declare readOnlyHint=true, so the tool is read-only. The description adds context by specifying the returned information (plan, quota, usage), enhancing transparency beyond the annotation alone.

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?

One short, front-loaded sentence that captures the essence without extraneous words. 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 simple read tool with one optional parameter and no output schema, the description sufficiently covers what the tool does. It could mention the return format, but it is not essential given low 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 description coverage is 100% (the single parameter apiKey is described in the input schema). The description does not add further parameter details, but given full schema coverage, a 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 'Get your account info' and lists specific fields (plan, daily quota limit, usage today, remaining calls). This distinguishes it from sibling tools, which are all about financial metrics and options data, not user account information.

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. However, its purpose (account info) is distinct from siblings (financial data), so usage is implied. No when-not or alternative naming 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 provide readOnlyHint=true, and the description adds behavioral context: it requires Alpha tier, and includes arbitrage detection. No contradiction with annotations; the description enriches understanding of what the tool does.

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 deliverables. Every sentence adds value: first lists outputs, second states tier requirement. No filler or redundancy.

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

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

Given the tool's complexity (advanced volatility with multiple output types) and no output schema, the description adequately lists what is returned. Missing details like pagination or output size limits, but sufficient for an agent to understand scope.

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 parameter-specific meaning beyond the schema, but the schema itself is sufficient. 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 retrieves advanced volatility analytics and enumerates specific outputs (SVI parameters, forward prices, etc.), distinguishing it from sibling tools like get_volatility or get_svi_params. The action verb 'Get' and resource 'advanced volatility' are precise.

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 required,' which is a clear prerequisite. While it doesn't explicitly state when not to use or provide alternatives, the listing of unique outputs implicitly guides choice among many sibling tools.

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

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

Annotations indicate readOnlyHint=true, which is consistent with the description's 'shows' phrasing. The description adds behavioral context beyond annotations by explaining that the tool reveals how dealer delta hedging changes over time, which is not present in the structured fields.

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

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

The description is two sentences, front-loaded with the primary purpose, and contains no unnecessary words. Every sentence adds value, making it concise and well-structured.

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

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

Given the tool's simplicity (1 required parameter, no output schema), the description sufficiently conveys the tool's functionality. It explains what the tool shows, though it does not describe the output format or pagination. Still, it is adequate for an agent to understand the tool's purpose and invocation context.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description does not add extra meaning about parameters beyond what is in the schema, such as how 'strike' relates to the output. 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 action ('Get'), the resource ('charm exposure by strike'), and the purpose ('shows how dealer delta hedging changes as time passes — reveals time-decay-driven flows'). It effectively distinguishes this tool from siblings like get_gex (gamma exposure) and get_dex (delta exposure) by focusing on charm and time decay.

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 analyzing time-decay-driven flows, but it does not explicitly state when to use this tool over alternatives like get_gex or get_dex. There are no exclusions or context for when not to use it.

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

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

Annotations already provide readOnlyHint=true, and the description aligns with that by describing a data retrieval operation. The description adds behavioral context (VWAP-weighted, rolling window) but does not disclose rate limits or other traits. 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 concise with two sentences and front-loads the key metric. However, the first sentence is slightly fragmented with a dash and could be more polished. It is appropriately sized for the tool's simplicity.

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 3 parameters and no output schema, the description explains the metric's meaning (net buying vs writing) but lacks information about the response format or any edge cases. It is partially complete but could benefit from specifying what the return data looks like.

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 parameters. The description adds little beyond the schema: it mentions 'configurable window' which maps to windowMinutes, but does not provide new semantic details. Baseline 3 applies since schema already covers 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 provides net dealer premium, indicating whether dealers are net buying or writing premium. It uses specific verb 'get' and resource 'dealer net premium' with details on methodology (VWAP-weighted). It distinguishes from siblings by focusing on dealer premium, but doesn't explicitly differentiate from similar tools like get_chex or 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?

The description implies the tool is for checking dealer positioning over a configurable window, but does not explicitly state when to use it versus alternatives. No exclusions or prerequisites mentioned. Usage context is derived from the description rather than direct 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 readOnlyHint annotation already indicates no destructive behavior. The description adds value by explaining the output (net dealer delta, directional bias) and implies the tool is for reading options hedging data. 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?

Two sentences efficiently convey the purpose and output. No redundant or unnecessary words, and the information is front-loaded. 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?

For a simple read-only tool with no output schema, the description covers the key output aspects. However, it could explain the meaning of 'delta exposure' or the calculation basis to aid understanding, but it is adequate for an agent familiar with options terminology.

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

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

Schema coverage is 100%, so the schema documents all three parameters. The description adds 'by strike' which clarifies the output grouping but does not elaborate on parameter usage. Baseline of 3 is appropriate as the description provides no extra parameter details 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 verb 'Get' and the resource 'delta exposure (DEX) by strike', and specifies what it shows ('net dealer delta and directional bias'). This distinguishes it from sibling tools like get_gex (gamma exposure) and get_chex (charm 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?

No guidance is provided on when to use this tool versus alternatives such as get_gex or get_chex. There are no exclusions, context conditions, or recommendations for usage, leaving the agent without direction for selection.

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. The description adds behavioral context by listing the specific return values (correlation premium, dispersion setup, etc.) and the required Alpha tier. It is consistent with annotations and adds value beyond them.

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

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

The description is concise with two sentences and no redundant information. It front-loads the core function and ends with usage guidance and requirements. Every sentence contributes 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 the complexity of dispersion analysis and the absence of an output schema, the description adequately covers what the tool returns (correlation premium, dispersion setup, etc.) and the required tier. It lacks an example of usage or output format, but the schema provides sufficient parameter detail for an agent to construct a call.

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 each parameter has a clear description in the schema (e.g., index, symbols, weights, horizon_days, apiKey). The tool description does not add significant new meaning for the parameters beyond the schema, hence 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 explicitly states the tool computes 'Index vs single-name implied correlation and realized correlation across a user-supplied basket' and lists specific outputs (correlation premium, dispersion trade setup, implied vol, per-constituent vol contribution). This clearly distinguishes it from sibling tools like get_spot_vol_correlation or 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 provides explicit use cases: 'Use for dispersion trading, correlation premium sizing, or cross-asset vol arb.' It also mentions the prerequisite 'Alpha tier required.' However, it does not specify when not to use this tool (e.g., for simpler correlation metrics) 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, so the safety profile is known. The description adds value by detailing the six lenses but does not disclose response format, pagination, or any additional behavioral traits. Acceptable but not standout.

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 crisp list of enum values. Front-loaded verb+resource, no filler. Every sentence and line 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?

For a complex tool with six analytics sub-types, the description covers each kind adequately. No output schema, but the operation is read-only and the return format is somewhat inferable. Minor gap in not describing the response 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 description coverage is 100%, so baseline is 3. The description explains the kind enum values beyond the schema's brief 'Analytics kind' but does not add meaning for symbol or apiKey. Marginal added 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 'Get earnings analytics for a symbol across six lenses' and enumerates each kind with a brief explanation. This verb+resource combination is specific and distinguishes it from sibling tools like get_earnings_calendar or get_earnings_screener.

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

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

The description implies when to use each kind via the enum list but provides no explicit guidance on when not to use this tool or alternatives among siblings. No mention of context or exclusion criteria.

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

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

Annotations provide readOnlyHint=true; description adds value by detailing the returned fields, filter capabilities, and the configurable window (1-90 days). No contradictions. Rate limits or auth details are not addressed, but the description improves 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 filler. First sentence describes output, second describes filters and window. 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?

For a calendar tool with no output schema, listing return fields and filters is adequate. Could mention limits (e.g., max events) but not necessary given the simplicity.

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 description adds meaning by explaining the days range (1-90) and default (14), and how to use symbols/importance filters. This complements the schema effectively.

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

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

Description clearly states the tool provides an upcoming earnings calendar over a configurable forward window, listing specific return fields (event date, session, etc.) and filter options (symbols, importance, days). This distinguishes it from sibling tools like get_earnings and get_earnings_screener.

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

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

The description implies usage context: use when wanting an upcoming earnings calendar with consensus estimates and filters. It does not explicitly exclude alternatives or provide when-not guidance, but the context is clear enough.

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 tool is read-only. The description adds context about the computed metrics (e.g., richness assessment, historical IV crush) and configurable parameters, going beyond annotations to explain what results contain.

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 efficient sentences: purpose, output, and configuration. Every sentence is necessary and front-loaded with key information. 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?

For a screening tool, the description adequately covers the output fields (even without output schema) and configurable filters. It could mention data freshness or limitations, but overall it provides sufficient context for an agent to understand the tool's capability.

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

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

Schema has 100% coverage with descriptions for all 5 parameters, each clearly stating default values and options (e.g., 'days: Forward window in days (1–60, default 14)'). The description summarizes but does not add significant new meaning beyond the schema. 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 defines it as a cross-sectional earnings screener that ranks upcoming events by multiple criteria, and lists output fields. It distinguishes itself from sibling tools like get_earnings (individual ticker) and get_earnings_calendar (date list) by being a screener with ranking.

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

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

No explicit guidance on when to use this tool versus alternatives. It implies usage for ranked lists but doesn't mention get_earnings or get_earnings_calendar for other specific needs. The description could be improved by noting that it's for comparing multiple events.

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 need not reiterate safety. The description adds value by detailing the returned data (1-sigma range, upper/lower bounds, straddle price, ATM IV). No mention of rate limits or authentication beyond the API key parameter, but overall transparent enough. 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?

Two sentences: first defines what the tool returns, second lists use cases. No redundant words, all content earns its place. Highly concise and front-loaded.

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 sufficiently explains the return value (1-sigma range, bounds, straddle price, ATM IV). Use cases are provided. For a tool with three simple parameters and straightforward output, this is complete enough for an AI agent to understand.

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% (all three parameters described). The description does not add new parameter-level information beyond what the schema already provides, such as format or defaults. Baseline 3 is appropriate as the schema carries the burden.

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' with specific fields like 1-sigma range, bounds, straddle price, and ATM IV. It also lists use cases (size trades, evaluate premium, compare vs realized range), making its purpose distinct from sibling tools like get_volatility or get_term_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 provides explicit usage scenarios: 'Use to size trades, evaluate premium levels, or compare market-implied move vs realized range.' However, it does not explicitly state when not to use this tool or provide alternatives among the many sibling tools, leaving some ambiguity for the AI 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 provide readOnlyHint, and description adds key behaviors: default equal weights when omitted, weight normalization to sum 1, max 50 symbols. 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 filler. Crucial details front-loaded. 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?

No output schema, but description mentions weighted aggregate and which exposure types are included. Could mention return format, but current info is sufficient for an agent to understand input/output.

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 3. Description adds beyond schema: explains comma-separated syntax for symbols, clarifies optionality of weights and default behavior, and distinguishes API key usage per auth flow.

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

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

Description uses strong verb 'get' and specific resource 'exposure basket'. Clearly defines it as a weighted cross-symbol aggregate of GEX, DEX, VEX, CHEX across up to 50 symbols. Distinguishes from siblings like get_gex (single symbol) and 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?

Explicitly lists use cases: portfolio/basket scanner, sector exposure roll-up, custom index dealer positioning. Does not directly exclude single-symbol usage or mention alternatives, but context implies it's for multi-symbol and siblings cover single symbol.

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. Description adds value by detailing the content of the response (chain totals, inflection strike, gamma peaks, OPEX flags). 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 key information, no redundant 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 response includes (multiple Greeks, chain totals, flags). It is adequate for agent understanding, though format details are omitted.

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 does not add parameter-specific details beyond what the schema provides; it focuses on output content.

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 unified per-strike exposure sheet including GEX, DEX, VEX, CHEX, and DAG. It distinguishes from siblings like get_gex and get_dex by emphasizing comprehensiveness.

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 'Use to scan all greeks at every strike in a single call,' implying when to use. It lacks explicit when-not-to-use or alternatives, but the purpose is clear enough.

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 detailed behavioral context beyond the readOnlyHint annotation, specifying the exact metrics returned (GEX, DEX, VEX, CHEX, regime, levels, etc.). It does not contradict annotations and provides a clear picture of the tool's output without mentioning side effects or authentication specifics.

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 core purpose and lists specific outputs. Every part is informative and there is no redundant or unnecessary information.

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

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

Given the tool's complexity (multiple exposure metrics) and the absence of an output schema, the description provides a thorough list of returned data items, making it complete for an agent familiar with options terms. It covers the essential aspects and is consistent with the annotations.

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 does not add any additional meaning or clarification for the parameters (apiKey, symbol). The schema already sufficiently describes the symbol as 'Stock/ETF ticker' and the apiKey usage, so no extra value is provided.

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 full exposure summary including net GEX/DEX/VEX/CHEX, gamma regime, key levels, hedging estimates, zero-DTE breakdown, and top strikes. It specifies a verb 'Get' and resource 'exposure summary', distinguishing it from sibling tools like get_gex (only GEX) or get_dex (only 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 explicit guidance on when to use this tool versus alternatives. The description implies it is for a comprehensive summary, but does not mention when it is preferable to use sibling tools like get_gex or get_exposure_basket. Usage is implied only by the nature of the output.

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 safety profile is clear. The description adds behavioral context about the output (shift values, classifier, plain-English description) but does not discuss data freshness, rate limits, or side effects beyond what annotations imply.

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 concisely lists all output components, front-loading 'Settled vs live dealer risk shift'. Every part 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?

For a tool with no output schema and three well-documented parameters, the description adequately covers the return value components. It provides enough detail for an agent to understand the tool's purpose and expected output, though some specifics about format are omitted.

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 three parameters (apiKey, expiry, symbol). The description does not add additional parameter-level information beyond what the schema provides, so it meets the baseline expectation.

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

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

The description clearly specifies the tool returns settled vs live dealer risk shift, GEX/DEX adjustment, percent shifts, direction classifier, and plain-English description. It distinguishes from sibling tools like get_dex or get_gex by focusing on intraday shifts and combined metrics.

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

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

The description implies the tool is for intraday dealer risk shift analysis but does not explicitly state when to use it over alternatives or when not to use it. No exclusions or alternative tool mentions 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?

Adds behavioral context beyond the annotations: it is simulation-aware, computed on effective OI, and more current during the session. No contradiction with annotations (readOnlyHint: true).

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. Every word adds value. No redundancy or wasted 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?

Given tool complexity, no output schema, and rich annotations, the description sufficiently explains what the tool returns and its key advantage. Complete for an agent to understand and invoke.

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 does not elaborate on individual parameters but provides general context about the computation. Not adding significant parameter-level meaning.

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 provides live flow levels (gamma flip, call wall, put wall, max pain) and specifies it is simulation-aware and more current than an alternative. Distinguishes from siblings by mentioning unique computation method.

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?

Indicates it is more current than /v1/exposure/levels during the session, giving a clear alternative. However, it does not explicitly state when to use this tool over other siblings like get_levels or get_exposure_summary.

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

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

Annotations declare readOnlyHint=true, and the description does not contradict it. The description adds value by listing the exact components returned, which is behaviorally informative beyond a simple 'read-only' label.

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 redundancy. The first sentence lists components efficiently; the second clarifies parameter behavior. Every phrase earns its place.

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

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

Given no output schema, the description adequately describes the output as a bundle of listed items. It covers the parameter semantics. It could mention that the symbol must be valid or that results are for the current time, but for a read-only bundle tool, this is sufficient.

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 enhances these by explaining the concrete effects of 'view' values (e.g., 'view='gex' for full simulation-aware surface'), adding meaning beyond the schema's 'Optional view' text.

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 returning a 'headline flow bundle' with specific enumerated components (OI state, live levels, GEX/DEX totals, pin-risk, dealer-risk). It distinguishes this tool from siblings by being a comprehensive aggregate, not a single metric.

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 how the 'view' parameter selects between three specific sub-views or omitting for the combined bundle. It does not explicitly state when to prefer this over individual tools (e.g., get_gex), but the sibling list implies the 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 annotation readOnlyHint: true indicates it is read-only. The description adds value by explaining the computation is 'simulation-aware OI' and reflects intraday flow changes, which is behavioral context beyond the annotation. 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 sentence that is concise and front-loaded with the key purpose. Every word earns its place; no redundant information.

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

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

For a simple tool with no output schema, the description covers the essential: what it returns (pin-risk score with sub-score breakdown) and what it uses (simulation-aware OI). It could optionally mention the output format, but it's sufficient for an AI to understand 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning to individual parameters beyond what the schema already provides. The overall context helps but not parameter-level detail.

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 title and description clearly state the tool returns a live pin-risk score with sub-score breakdown, computed on simulation-aware OI. The verb 'get' and resource 'flow pin risk' are specific, and the description distinguishes it from sibling tools like get_flow_dealer_risk by mentioning 'simulation-aware OI' and 'full sub-score breakdown'.

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

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

The description implies the tool is for pin risk analysis but does not explicitly state when to use it versus alternatives like get_flow_dealer_risk or get_flow_levels. No exclusions or context for when not to use it 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 declare readOnlyHint=true, and the description does not add behavioral context beyond that. It omits details like rate limits, authentication nuance beyond the apiKey parameter, 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-loads the core purpose, and efficiently explains parameters. Every sentence contributes value with no redundancy.

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

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

Given no output schema, the description should mention the response structure (e.g., list of symbols, net notional). It only says 'ranked net notional buyers/sellers' and 'ranked by absolute net notional', which is somewhat informative 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 coverage is 100%, so the input schema already documents all parameters. The description adds marginal value by clarifying the meaning of 'asset' and 'kind' but essentially repeats what's in 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 provides a cross-symbol flow leaderboard and flow outliers for options/stocks. It distinguishes from siblings like get_option_flow which is single-symbol, and explicitly lists the two kinds ('leaderboard' and 'outliers').

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 cross-symbol flow ranking but does not explicitly state when to use this tool versus sibling tools (e.g., get_option_flow, get_stock_flow). No when-not-to-use or alternative 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. The description adds valuable behavioral context: signals include score breakdown, greeks enrichment, and delta-notional, and explains how the summarize parameter changes behavior. 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 pack key information: what the tool returns and a usage tip. No wasted words. Front-loaded with the most important details.

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 outlines return contents (score breakdown, greeks, delta-notional). However, an agent may need more structural detail to effectively parse the response. Adequate but not comprehensive.

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

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

Schema coverage is 100% with each parameter described. The description mentions the summarize option's effect, which is already in the schema, so it adds no new parameter-level 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 the tool returns a 'scored, classified unusual options activity feed' listing specific signal types (sweeps, blocks, smart money, etc.). However, it does not differentiate from sibling tools like get_flow_scan or get_option_flow that likely serve similar purposes.

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 specific usage tip for the summarize parameter but lacks guidance on when to prefer this tool over siblings, prerequisites, or when not to use it. The tip is helpful but minimal.

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. Description adds value by noting 'simulation-aware' and 'cheap to poll,' disclosing behavioral traits beyond annotations, though it does not detail any side effects or reentrancy concerns.

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

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

The description is a single, information-dense sentence with no wasted words. It front-loads the core purpose and key characteristics ('at-a-glance,' 'simulation-aware,' 'cheap to poll').

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 and minimal annotations, the description adequately covers outputs but does not explain 'simulation-aware' or provide any example. It is sufficient for a simple summary tool, though edges could be sharper.

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 the description does not mention parameters. Since the schema already documents them adequately, no additional value is added; 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?

Description clearly states the tool provides a 'simulation-aware flow card' with specific outputs (headline flow direction, intraday delta, live GEX with percent shift). The verb is implied ('get'), and it distinguishes from siblings by emphasizing the 'at-a-glance' summary nature, though not explicitly named.

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 as a lightweight summary ('cheap to poll across a watchlist') but provides no explicit guidance on when to use this tool versus alternatives like get_gex or get_flow_live, nor 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 include readOnlyHint=true, so the description does not need to re-state safety. However, it adds context about dealer hedging and support/resistance beyond annotations. No behavioral traits like data freshness or rate limits are disclosed, so score 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?

Two concise sentences that are front-loaded with the primary purpose and then explain the output value. No filler or redundant information.

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

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

Given the schema covers all parameters and annotations are present, the description is mostly complete. It lacks details on return format or edge cases, but for a read-only tool with well-documented parameters, this is sufficient.

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. The description does not add any additional meaning beyond the schema, so 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 'Get', the resource 'gamma exposure (GEX)', and specifies what the tool shows (dealer gamma positioning, gamma flip, call/put walls). It distinguishes from siblings like get_dex or get_chex by focusing on gamma exposure and its market impact.

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 reveals but does not provide guidance on when to use it over alternatives like get_dex or get_exposure_summary. No explicit when/when-not or context for selection.

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 give readOnlyHint=true; description adds: data availability per minute since April 2018, daily EOD updates for SVI fits. No mention of rate limits or volume, but sufficient behavioral context.

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

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

Two sentences, no filler. First sentence lists analytics and time range, second adds update frequency and tier. 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?

List of included analytics compensates for missing output schema. Doesn't address pagination or limits, but 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 parameters are fully documented. Description adds no additional semantics beyond schema (e.g., 'at' format). 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 replays advanced volatility analytics with specific components (SVI parameters, forward prices, etc.) at any minute since April 2018. It distinguishes from siblings by specifying 'advanced' and '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?

Provides context: historical replay, EOD-stamped, Alpha tier. Implies use for historical analysis rather than live data, but doesn't explicitly state when not to use or name alternatives like get_advanced_volatility.

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 limited behavioral context. It mentions the time range and granularity (minute-level since 2018) but omits auth details (handled by schema) and response format.

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

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

Two sentences: the first sentence clearly states the purpose, the second is a minor note ('Alpha tier') that could be omitted or integrated. No wasted words, but not perfectly front-loaded.

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

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

Given the simple parameter set and no output schema, the description provides enough context: it specifies the resource (CHEX), scope (by strike, historical), and time range. Lacks details on return format or pagination, but acceptable for this tool.

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

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

Input schema has 100% coverage of parameter descriptions, so the description adds no new meaning. It does not elaborate on the parameters (e.g., timestamp format or optional apiKey purpose 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 uses a specific verb ('replay') and resource ('charm exposure (CHEX)') and clearly defines the scope ('by strike at any minute since April 2018'). This distinguishes it from siblings like get_historical_gex or 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 implies when to use the tool (when historical CHEX data is needed) but provides no explicit guidance on when not to use it or alternatives (e.g., get_chex for current data). No comparison to other 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 declare readOnlyHint=true; the description adds that it checks coverage windows, day counts, and gaps, which is useful behavioral context. 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. First sentence states the action, second provides usage guidance. 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?

Describes the return values (coverage windows, day counts, gaps) adequately for a list tool. No output schema, but the description gives enough context. Could mention pagination or limits, but this is a minor omission.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description does not add 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?

Clearly states it lists symbols backfilled in the historical archive with coverage windows, day counts, and gaps. Distinguishes from siblings by specifying the historical archive focus and the queryability check purpose.

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 tells users to call this first to check queryability before sending a replay request. Provides clear context but does not explicitly mention when not to use it or alternatives.

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

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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds minimal extra behavioral context, such as the 'Alpha tier' access hint, but does not disclose rate limits, pagination, or output format. Given the annotation, 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 a single sentence with an additional accessibility note ('Alpha tier'), no fluff, and every word contributes meaning. It 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?

The description covers the core purpose but lacks details about output format, pagination, or the meaning of 'Alpha tier'. Given the schema covers all parameters and annotations handle safety, the description is adequate but not fully complete 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?

The input schema has 100% description coverage, so parameters are well-documented. The description adds 'by strike' which might imply a strike parameter, but the schema only includes symbol, at, and apiKey. The description does not enhance parameter understanding beyond the schema, 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 uses the specific verb 'Replay' and clearly identifies the resource 'delta exposure (DEX) by strike' with a time range 'any minute since April 2018'. It distinguishes from sibling like 'get_dex' (current DEX) 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 DEX replay but does not explicitly state when to use this tool versus alternatives like 'get_dex' or when not to use it. The context from sibling names provides some guidance, but the description itself could be more explicit.

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 context on what data is returned (components and time range). No contradictions; description adds value 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?

Extremely concise one-sentence description that front-loads purpose and key details. No wasted words.

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

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

Given 3 parameters with full schema coverage and no output schema, the description is mostly complete. It could add a note on data limitations (e.g., only since April 2018) but is sufficient.

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 parameters are already documented. The description adds minimal extra meaning beyond the schema (e.g., 'any minute since April 2018' relates to 'at' but adds no new format info).

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 full exposure summary (net GEX/DEX/VEX/CHEX, regime, etc.) at any historical minute since April 2018. It distinguishes this from siblings like get_exposure_summary (current data) 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?

Usage is implied (historical data at a specific timestamp), but there is no explicit guidance on when not to use or mention of alternatives like get_exposure_summary 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 provide readOnlyHint=true, and the description adds that the tool returns the same shape as the live endpoint and covers the historical range since April 2018. This adds some behavioral context beyond annotations, but does not detail response format or access restrictions beyond the 'Alpha tier' mention, which is not a behavioral trait.

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 efficiently convey the tool's function, return format, and tier. No extraneous words, and the most critical information is front-loaded.

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

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

Given the lack of an output schema, the description does not fully describe the return data fields, relying instead on reference to a live endpoint. It also does not mention data availability limitations or rate limits. While annotations and schema are present, the missing output details reduce completeness for agent interpretation.

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 covers all parameters with descriptions, so baseline is 3. The description adds value by specifying 'any minute' granularity and the historical start date (April 2018), which gives additional context to the 'at' parameter beyond what the schema provides. This justifies a slightly higher 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 replays gamma exposure by strike for any minute since April 2018, using specific verbs and resources. It distinguishes itself from siblings like get_gex by noting it returns the same shape as the live endpoint, making its purpose unmistakable.

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

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

The description implies when to use this tool (for historical GEX) versus the live counterpart via 'Returns same shape as live /v1/exposure/gex', but does not explicitly state when not to use it or name alternatives directly. Context is clear but exclusions are missing.

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 context about the specific levels replayed, the time range (any minute since April 2018), and access tier (Alpha tier), which aids agent understanding 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 a single, front-loaded sentence that efficiently conveys the tool's purpose and key details. 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 types of levels returned but omits details about output format or structure, especially since there is no output schema. This leaves agents uncertain about what to expect in the response.

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 all parameters (at, apiKey, symbol). The description does not add any additional meaning to these parameters, so 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 tool replays historical key options levels, listing specific level types (gamma flip, call/put walls, highest OI strike, 0DTE magnet) and the time range (since April 2018). This distinguishes it from siblings like get_levels (current 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?

The description implies usage for historical analysis but does not explicitly state when to use this tool versus alternatives like get_levels for current data. No exclusions or prerequisites are mentioned.

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

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

Annotations declare readOnlyHint=true, and description's 'Replay' aligns. However, description adds minimal behavioral context beyond annotations (e.g., no mention of authentication, rate limits, or data size). With annotations present, 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 concise sentences, front-loaded with action and scope. 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?

Reasonably complete for a historical data retrieval tool with readOnly annotations. Could mention return format or data volume, but overall sufficient given complexity and schema coverage.

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 does not add additional meaning to parameters beyond what the schema provides. Acceptable but no extra 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?

Clearly states the action 'Replay' and the resources 'max pain, pain curve, dealer alignment, and pin probability', providing a specific verb and resource scope. Distinguishes from current max pain tool and other historical 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?

Implies use for historical data replay, but lacks explicit guidance on when to use this vs alternatives like 'get_max_pain' or other historical tools. No when-not or exclusion criteria mentioned.

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

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

Annotations already declare readOnlyHint=true, so the agent knows it is a safe read operation. The description adds behavioral context: it replays verbal analysis, is alpha tier (suggesting potential instability), and covers a specific time range. However, it does not disclose any additional side effects, rate limits, or return behavior 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?

The description is a single sentence that efficiently conveys the action, content, scope, and tier. It is front-loaded with the core purpose and contains no extraneous information. Every word earns its place.

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

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

Given the tool has no output schema, the description partially explains what the tool returns (verbal narrative analysis including regime, commentary, comparison). However, it does not specify the output format (e.g., text or JSON) or structure, which would help the agent process the result. It is sufficient for an agent to understand the conceptual output but lacks full details.

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 input schema already documents all three parameters (symbol, at, apiKey) with descriptions. The description does not add new semantic detail about the parameters beyond what is in the schema. Baseline 3 is appropriate when schema covers all parameters adequately.

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 ('Replay') and resource ('verbal narrative analysis') and details what is included (regime, key-level commentary, prior-day comparison). It also specifies the temporal range ('at any minute since April 2018'), clearly distinguishing it from the likely current narrative tool `get_narrative` among siblings.

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

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

The description implies usage context by specifying historical scope and content, but does not explicitly state when to use this tool versus alternatives (e.g., `get_narrative` for current data, or other historical tools). The phrase 'at any minute since April 2018' provides clear context but no exclusionary guidance.

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

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

Annotations already indicate readOnlyHint=true. The description adds that it returns BSM greeks, IV, OI, and mentions the time range and filters. No destructive actions are implied, and the description 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?

Two concise sentences that front-load the core purpose and key filters. No unnecessary words or redundancy.

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

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

The description covers core functionality and return contents (greeks, IV, OI), but with 8 parameters and no output schema, more details on data structure or filtering behavior would be beneficial. Still adequate for a well-annotated 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 each parameter documented. The description adds a high-level summary ('Filter by expiry, strike, and type') but does not elaborate beyond what the schema already provides. 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 replays the full option chain with BSM greeks, IV, and OI for any minute since April 2018, and mentions filtering by expiry, strike, and type. This distinguishes it from sibling tools like get_option_chain (likely 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 it is for historical data ('at any minute since April 2018'), but does not explicitly state when to use it versus alternatives like get_option_chain for current data. The context signals list many siblings, but no direct comparison is made.

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. Description adds date range and tick detail (since April 2018, minute granularity, Alpha tier access). No rate limits or further behavioral details 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?

Very concise (12 words), efficient, and front-loaded. Could be slightly more structured but appropriate for a simple tool.

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?

Adequate for a low-complexity tool with good schema and annotations. Lacks description of output format or limitations (e.g., max date range). No output schema exists to compensate.

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 schema adequately documents parameters. Description does not add new semantics beyond what schema provides (symbol, at, apiKey).

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' specifying historical stock quote data (bid/ask/mid). Distinguishes from sibling 'get_stock_quote' by emphasizing historical minute-level data since April 2018.

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 when historical minute-level quote data is needed, but no explicit when-to-use or when-not-to-use guidance. With many sibling tools, explicit alternatives would help.

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, consistent with 'replay'. Description adds context: data availability since April 2018, Alpha tier restriction, and the set of metrics included.

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 core purpose, then time range and tier identifier. 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?

Covers time range and access tier but omits output format or structure. Given no output schema, description could hint at return fields or 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?

Input schema covers 100% of parameters with clear descriptions. Description adds no new parameter-level information, remaining at baseline for high 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?

Verb 'replay' and resource 'comprehensive stock summary' clearly state the action and object. Lists components (price, IV, VRP, exposure, flow, macro) and time range, distinguishing it from 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?

Implied usage for point-in-time historical summaries, and mentions 'Alpha tier' access constraint. No explicit guidance on when to use versus sibling tools like get_historical_volatility or get_historical_exposure_summary.

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

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

Annotations provide readOnlyHint=true, and description adds detail about EOD stamping and daily SVI parameter refresh, which explains data behavior beyond annotations. 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, front-loaded with action and resource, no wasted words. Efficient and clear structure.

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

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

No output schema and minimal annotations; description lacks explanation of output format, data structure, or pagination. For a historical data tool, more context would be helpful but still minimally 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 coverage is 100% so schema already describes all parameters. Description adds no additional parameter-specific meaning beyond what's in the schema, so 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 uses specific verb 'Replay' and resource 'implied volatility surface grid', with time scope since April 2018 and data freshness note. It distinguishes from siblings like get_surface (current) and get_historical_volatility (different metric).

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 vs. alternatives. Implies historical analysis but doesn't state when not to use or mention sibling tools like get_surface 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 safety is covered. Description adds value by specifying historical replay capability per strike and data availability since April 2018. 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?

One concise sentence with optional tag 'Alpha tier'. No wasted words, 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?

No output schema, and description only hints at returning vanna exposure by strike. Lacks detail on response format (e.g., time series, array). With complex sibling set and no output schema, description could be more 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 descriptions cover 100% of parameters with format and purpose. Description adds no extra parameter information beyond what schema provides. Baseline score 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 verb 'replay' with specific resource 'vanna exposure (VEX) by strike' and temporal constraint 'since April 2018'. Distinguishes from siblings like get_vex (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?

No guidance on when to use this tool versus alternatives. Mentions 'Alpha tier' but does not explain usage context, prerequisites, or 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?

Annotations already declare readOnlyHint: true. The description adds behavioral context by specifying it replays analytics at any minute since April 2018, which is an important constraint. It also lists the included metrics. This goes beyond annotations, earning a 4.

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: one sentence with a brief note on tier. Every word adds value, and the purpose is front-loaded. No wasted exposition.

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

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

Given the lack of an output schema, the description should hint at the return format (e.g., single data point vs. time series). It also does not mention that the symbol must be currently valid. These gaps lower completeness, though the core purpose and time range are covered.

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, providing clear definitions for all three parameters (symbol, at, apiKey). The description adds no additional parameter-level meaning, so the 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 replays volatility analytics (ATM IV, realised vol, IV-RV spreads, skew, term structure) at any minute since April 2018. This specific verb and scope distinguishes it from sibling tools like get_volatility for current data and get_historical_advanced_volatility for more complex metrics.

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

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

The description implies usage for historical volatility analysis by mentioning the replay capability and time range, but it provides no explicit guidance on when to use this tool versus alternatives like get_volatility (current) or get_historical_advanced_volatility (advanced metrics).

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

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

The annotation readOnlyHint=true is complemented by the description's explanation of leak-free backtesting, which adds behavioral context beyond the annotation. No contradiction between description and 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: the first clearly states the purpose and key metrics, the second adds important behavioral detail (leak-free). No redundant information, 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?

For a tool with no output schema, the description names the metrics returned (z-score, percentile, regime, strategy scores), but does not detail the structure or format. Given the complexity and many sibling tools, it is largely complete but could specify output 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 coverage is 100%, but the description adds meaning beyond the schema by explaining that the `at` timestamp is used for date-bounded, leak-free queries. This enhances 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 the tool replays the VRP dashboard with specific metrics (z-score, percentile, regime, strategy scores) at any minute since April 2018. This verb+resource+scope is specific and distinguishes it from siblings like get_vrp (current data) and get_vrp_history (historical series).

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 context for backtesting by emphasizing leak-free behavior, but does not explicitly state when to use this tool versus alternatives like get_vrp or get_vrp_history. It implies usage for historical replay, but lacks explicit exclusions or alternative names.

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, so the description adds limited behavioral context beyond listing the analytics provided. While it mentions 'Alpha tier', this is more about access level than behavioral traits. There is no contradiction with annotations.

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

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

The description is a single, information-dense sentence that includes the tool's function, examples of analytics, time range, and tier. No wasteful words; it is perfectly front-loaded.

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

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

Despite no output schema, the description comprehensively explains what the tool retrieves (0DTE analytics), the time range (since April 2018), and provides concrete examples of the data (pin risk, expected move, gamma acceleration, dealer hedging estimates). This is sufficient for an agent to understand the tool's utility.

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 extra meaning beyond the schema, mentioning only the timestamp and symbol implicitly. Baseline 3 is appropriate as 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 replays 0DTE analytics (pin risk, expected move, gamma acceleration, dealer hedging estimates) for same-day expiry at any minute since April 2018. The verb 'replay' and the specific resource 'historical zero-DTE' make the purpose unambiguous and distinguish it from siblings like get_zero_dte (likely current data).

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

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

The description implies usage for historical data analysis via 'since April 2018' and 'replay', differentiating from get_zero_dte which likely provides live data. However, it does not explicitly state when not to use it or mention alternatives, leaving room for clearer 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 provide readOnlyHint=true. The description adds value by disclosing the specific computed levels and their significance, but does not discuss side effects, auth requirements, or rate limits. This is sufficient given the annotation, so a score of 4 is appropriate.

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

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

Two sentences, no wasted words. The first sentence lists the output items, and the second adds their context. Front-loaded with the 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 explains what the tool returns and its significance, but lacks details on output format (e.g., list vs object). Given no output schema and only two parameters, it is nearly complete, but could explicitly state the return 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%, so baseline is 3. The description does not add additional meaning to the parameters beyond what the schema provides; it only implies use of a ticker but does not elaborate on apiKey. No improvement over 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 key options levels and lists specific examples (gamma flip point, call wall, put wall, max pain, highest OI strike). The verb 'Get' and resource 'key options levels' are precise, and the context of support/resistance from dealer hedging distinguishes it from sibling tools like get_max_pain 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 implies the tool is for obtaining dealer hedging-based support/resistance levels, but does not explicitly state when to use it versus alternatives like get_flow_levels or get_flow_pin_risk. No 'when not to use' guidance is provided, only implied 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. The description adds behavioral detail by listing the output metrics and scoring labels (tight, normal, wide, illiquid), providing 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 extremely concise, using two sentences to convey all necessary information. It front-loads the output components and ends with usage guidance. No redundant 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?

With no output schema, the description fully explains the return values (liquidity score, spreads, depth, quality, labels) and provides usage context. For a tool with two parameters and no output schema, it is 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% for the two parameters (apiKey, symbol). The description does not elaborate on parameters beyond what the schema already provides, but this is acceptable since the schema is sufficient.

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 exact data returned: per-expiry liquidity score (0-100), ATM bid-ask spread percent, OI-weighted spread, ATM OI depth, and chain-level execution quality. It also defines labels, clearly distinguishing it from sibling tools like get_option_chain or get_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?

The description explicitly states use cases: select most liquid expiry, assess execution quality, or screen for tight spreads. It does not mention when not to use or alternatives, but the context provided is clear and actionable.

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 no additional behavioral traits (e.g., error handling, data freshness, or what happens with invalid symbols).

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

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

Single sentence front-loads key terms; no fluff, but could be slightly more structured 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?

Lists returned data components, which compensates for lack of output schema, but still incomplete without usage context or limitations.

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

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

Schema has 100% parameter coverage with descriptions; the description does not add any extra meaning or constraints beyond what the schema provides for 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?

Description clearly states the verb 'Get' and the resource 'max pain' with specific components (strike, curve, ratio, etc.), distinguishing it from siblings like get_dex 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?

No guidance on when to use this tool versus alternatives, such as get_dex or get_gex, nor any 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 declare readOnlyHint=true, and the description aligns as a read operation. The description adds value by detailing output contents (gamma regime, dealer positioning) beyond the annotation, though it omits potential auth nuances or rate limits.

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 efficiently convey purpose and output. No redundant words; information is front-loaded.

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

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

Despite no output schema, the description adequately describes return type as verbal narrative with specific elements. Could mention if output is plain text or JSON, but 'plain English' implies readability.

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 apiKey and symbol. The description does not add extra parameter context, meeting the baseline for adequate schema documentation.

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

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

Description clearly states the tool retrieves a verbal narrative analysis of GEX, specifying contents like gamma regime and key levels. It distinguishes from sibling tools like get_gex, which returns numeric data, and get_historical_narrative.

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 the large sibling list including get_gex and get_historical_narrative, the description should indicate use cases, e.g., when a plain English summary is needed instead of raw numbers.

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. Description adds behavioral context: output structure and tracking intent. 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 front-loaded sentences with no redundant 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?

Covers purpose, output format, and use cases. No output schema but explanation is sufficient for agent understanding.

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

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

Schema coverage is 100% with adequate descriptions for all parameters. Description does not add new semantic info beyond schema.

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

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

Explicitly states 'Day-over-day open-interest deltas' and lists output components (per-contract changes, top-N sorted, call/put totals). Distinct from siblings like get_flow_summary or get_exposure_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?

Provides use cases: 'track new positioning, unwinding, and block print intent.' Does not explicitly mention when not to use or contrast with alternatives, but context is clear enough.

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 safe read nature is known. The description adds that it returns expirations and strikes, which is additional context, but it does not disclose pagination, rate limits, or the exact return format beyond 'metadata.'

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 verb and resource. Every word is necessary, and there is 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?

Given the tool's simplicity (2 params, no output schema), the description adequately explains that it returns expirations and strikes. However, it lacks details on the response structure (e.g., list format, date format), which would be helpful for an agent to process the result without example.

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) fully described. The description does not add further meaning beyond what the schema already provides, so it meets the baseline but does not exceed.

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 'option chain metadata' specifically 'available expirations and strikes for a ticker.' This distinct verb-resource combination differentiates it from siblings like get_option_flow or get_option_quote.

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

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

The description implies use when needing expirations and strikes for a ticker but offers no explicit guidance on when to use this tool versus alternatives (e.g., get_option_quote for detailed quotes, get_option_flow for flow data). No when-not or alternative tool mentions.

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 read-only nature is clear. The description adds the scope 'one underlying' and the views, but does not disclose any other behavioral traits (e.g., data latency, ordering of results, pagination behavior beyond what the schema explains). Since annotations carry most of the burden here, 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?

The description is a single sentence that covers the core functionality and view options. It is relatively concise, though the view list is a bit dense. It could be improved with a bulleted list, but it is not wasteful.

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 6 parameters, no output schema, and annotations only for read-only, the description explains the views but does not describe the return format or how the data is structured. It provides sufficient context for basic usage but lacks completeness for advanced understanding.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds marginal value by listing the view options in prose, but it doesn't provide additional meaning beyond the schema. 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 returns 'raw intraday option trade-flow for one underlying' and enumerates the five views. This gives a specific verb+resource. However, it does not explicitly distinguish itself from sibling tools like get_flow_summary or get_flow_scan, which also deal with trade flow, so it is not a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when to avoid it, or which sibling tools to use for other scenarios. This leaves the agent without decision-making 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 adds value by detailing the returned data (bid, ask, mid, IV, greeks, open interest, volume). No contradictions. However, it does not elaborate on rate limits, authentication nuances, or error handling, which would increase transparency further.

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 that front-loads the core action (Get live option quote) and immediately lists key data fields and filter options. No unnecessary words; it is concise and structured efficiently.

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

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

Given the tool's low complexity (5 parameters, no nested objects, no output schema), the description adequately covers the primary data returned and filter criteria. It could minimally improve by noting that the quote is for a single contract, but overall 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 descriptions for all parameters. The description adds that expiry, strike, and type are filters, which reinforces their purpose but does not add significant new meaning 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?

The description clearly states the tool retrieves a live option quote and lists the specific data fields (bid, ask, mid, IV, greeks, open interest, volume). It distinguishes itself from siblings like get_option_chain (multiple options) and get_historical_option_quote (historical data) by specifying 'live' and the exact data points.

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. No mention of when not to use or trade-offs with siblings like get_option_chain or get_flow_live. Adequate for basic understanding but lacks explicit 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 declare readOnlyHint=true, which matches the description's implied read nature. The description adds behavioral context beyond annotations: the efficiency advantage (5-8× more efficient) and 'Alpha tier' access level hint.

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 concise sentences, front-loading key information (estimators, windows) and providing usage guidance in the second sentence. No redundancy.

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

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

Given no output schema, the description does not detail return structure, but it explains what the tool returns (estimators). For a simple data retrieval tool with 2 params, this is fairly complete, though return format could be mentioned.

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 adds no additional parameter semantics 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?

The description clearly states the tool provides range-based realized volatility estimators over 10/20/30-day windows, naming specific estimators (close-to-close, Parkinson, Garman-Klass, Rogers-Satchell, Yang-Zhang). It distinguishes from siblings like get_volatility by emphasizing range-based and higher efficiency.

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

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

The description provides explicit use cases: 'measure realized vol robustly, compare estimators, or feed a vol-risk-premium calc.' It does not explicitly say when not to use or name alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint=true. The description adds no additional behavioral traits (e.g., data freshness, pagination, limits). For a data retrieval tool, more transparency about output nature would be helpful.

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 wasted words. First sentence front-loads the core data returned, second gives use cases. Efficient 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?

Cover the data elements and use cases. With no output schema, it could explicitly state the output structure (e.g., list of objects per expiry) for full completeness, but it's nearly complete.

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

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

Schema description coverage is 100% (both apiKey and symbol described). The description does not add 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?

The description clearly states the tool returns 'volatility skew term structure per expiry' and lists specific metrics (ATM IV, risk reversal, butterfly spread, etc.). It is specific and distinct from siblings like get_term_structure and get_surface.

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

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

Provides explicit use cases: put/call skew, 25-delta risk reversal, butterfly convexity, comparing near-term vs far-term skew. Lacks explicit when-not-to-use or alternative tools, but the guidance is clear enough.

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 significant behavioral detail beyond the readOnlyHint annotation: it explains the calculation method (Pearson, specific windows, log-returns vs first-differences) and typical sign for equity indices. 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?

Three well-structured sentences: definition, typical behavior, use cases. No wasted words, 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?

Given no output schema, the description sufficiently describes the tool's function and purpose. It covers the metric, windows, interpretation, and applications. Minor gap: doesn't specify if multiple symbols can be queried or if output is a single number or pair.

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 add new meaning to the parameters beyond what the schema already provides (symbol as ticker, apiKey as optional).

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

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

The description clearly states the specific metric: 20-day and 60-day Pearson correlation between spot log-returns and ATM IV first-differences. It gives a concrete example (equity indices) and distinguishes from sibling tools like get_volatility or get_surface.

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?

Explicit use cases are provided: assess leverage effect strength, calibrate vanna/vol-of-vol hedges, or classify correlation regime. While it doesn't mention when not to use or alternative tools, the context is clear and actionable.

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, so the tool is clearly non-destructive. The description adds useful behavioral details like ordering ('newest first', 'oldest first' for bars) and the specific nature of each view, providing context beyond annotations without contradiction.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and lists views efficiently. Every part adds value 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?

Given the complexity of six views and six parameters without an output schema, the description adequately covers view selection but lacks details on return value structure. The mention of 'OHLCV+flow bars' hints at output but is insufficient for full output understanding.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds marginal value by elaborating on view purposes (e.g., 'for live chart feeds') but does not significantly enhance understanding of parameters beyond what the schema already provides.

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

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

The description clearly states 'Raw intraday stock trade-flow for one symbol' with a specific verb and resource. It lists six distinct views, each with a brief explanation, distinguishing it from sibling tools like get_option_flow 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 lists various views but does not explicitly guide when to use this tool over alternatives such as get_option_flow or get_flow_scan. It implies usage through view descriptions but lacks when-not-to-use or comparative 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, establishing it as a safe read operation. The description adds the returned data fields (bid, ask, mid, last price) and the 'real-time' nature, which provides some behavioral context beyond annotations. However, it does not disclose auth requirements (apiKey usage) or potential rate limits.

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 that immediately conveys the tool's purpose and key details. No filler or redundancy.

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

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

For a simple read-only stock quote tool with no output schema, the description adequately lists the primary return fields. However, it could be more complete by mentioning additional details like data format, pricing precision, or associated timestamps, given the absence of an 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?

The input schema has 100% description coverage for both parameters, so the description adds no additional parameter meaning beyond what the schema provides. The description does mention the output fields (bid, ask, mid, last) but these are not 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 fetches a real-time stock quote with specific fields (bid, ask, mid, last price). It distinguishes from siblings by focusing on 'stock quote' and 'real-time', but does not explicitly compare to similar tools like get_option_quote or 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?

No explicit guidance on when to use this tool versus alternatives. The description implies it is for current price needs, but fails to mention when not to use it or point to sibling tools. An agent would need to infer context from the tool name 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?

The annotations already declare readOnlyHint=true, so the read-only nature is clear. The description adds a list of return elements but no additional behavioral traits like auth flow or rate limits, which is adequate though not exceptional.

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 is front-loaded with the verb and key purpose. Every word adds value, no filler.

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

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

Given the complexity of the output (multiple data types), the description provides a thorough list. However, it lacks details on format or structuring of the response, and with no output schema, a bit more context could 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 description coverage is 100% (both apiKey and symbol are described). The description does not add extra meaning beyond the schema, so a 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 gets a comprehensive stock summary and lists many data categories. It implies a combined view but does not explicitly differentiate from sibling tools like get_stock_quote or get_volatility, so it falls short of a 5.

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

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

No guidance is given on when to use this tool versus alternatives (e.g., pulling individual data points from other tools). There is no 'when-not' or alternative mention.

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 known. Description adds context about returning a 'strategy decision envelope' and lists signals, but does not disclose any additional behavioral traits like output format or limitations.

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

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

The description is lengthy due to the signal enumeration, but it front-loads the purpose. Could be more concise without losing meaning.

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, and the description only mentions 'strategy decision envelope' without detailing its structure. Does not explain the apiKey parameter's authentication context. Incomplete 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%, but the description enhances the signal parameter by providing the question each signal answers, adding value beyond the enum list.

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

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

The description states 'Get a strategy decision envelope for one of 10 options-based trading signals,' clearly specifying the verb, resource, and domain. It distinguishes from siblings by listing the unique signal types.

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

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

No guidance on when to use this tool vs alternatives such as get_gex or get_flow_signals. Does not mention prerequisites or when to avoid using 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, indicating it's a read operation. The description adds behavioral details: grid is live, uses bilinear interpolation, and is constructed from OTM option IVs. This provides meaningful context beyond the annotation alone, though it omits rate limits or auth specifics.

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 wasted words. It immediately conveys the core purpose and key features, making it efficient for an AI agent to parse.

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

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

Given no output schema, the description does a good job explaining the output structure (50x50 grid over tenor and log-moneyness) and construction method. It is mostly complete, though additional details about value ranges or units could further improve usability.

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 adequately describes both parameters (apiKey and symbol). The description does not add new information about parameters beyond what the schema provides, so it meets the baseline expectation.

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

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

The description clearly states the tool retrieves a live 50x50 implied-volatility surface grid with specific axes (tenor, log-moneyness), and mentions it's built from OTM contract IVs with bilinear interpolation. This distinguishes it from siblings like get_volatility or get_historical_surface.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools, such as get_volatility or get_option_quote, explicit usage context is missing, reducing the agent's ability to decide correctly.

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 known safe. Description adds output details but no additional behavioral traits like data frequency, freshness, or error handling. Adequate but not enhanced 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?

Four sentences, front-loaded with core output ('Live SVI-fitted volatility surface per expiry'). Each sentence adds value: output components, use cases, and access requirement. Compact but could merge some phrases for brevity.

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 2 parameters, 100% schema coverage, and read-only annotation, the description adequately covers output and use cases. Lacks details on number of expiries or format, but for a data-retrieval tool, it provides sufficient context for an agent.

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

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

Input schema has 100% coverage for both parameters (symbol and apiKey). Description repeats symbol purpose but adds no meaning beyond schema. The apiKey usage note is already in schema. Baseline 3 since schema is sufficient.

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 live SVI-fitted volatility surface parameters (a, b, rho, m, sigma), ATM total variance, and ATM IV per expiry. It specifies exact data and use cases like surface reconstruction and arbitrage checking, distinguishing it from surface or volatility 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 lists use cases (surface reconstruction, SVI arbitrage checking, variance swap pricing, quant vol-model inputs) and required access level ('Alpha tier required'). Does not explicitly state when not to use or compare to siblings like get_surface, but context implies it's for SVI-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?

Adds context beyond the readOnlyHint annotation by specifying the data is 'live data cached in the system' (i.e., real-time). 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 fluff, front-loaded with purpose. 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?

Fully explains what the tool does and how it can be used. No output schema, but the simplicity of the tool (list of symbols) means the description is sufficient.

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?

Only one parameter (apiKey) with 100% schema coverage. Description adds no parameter info, but the schema already handles it; 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?

Clearly states it lists symbols currently queried with live data cached. Verb (list) and resource (symbols) are specific, and the scope (live, cached) is well-defined.

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

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

Provides three explicit use cases (check active real-time data, check if a ticker is warmed up, enumerate tracked symbols). No direct mention of when not to use, but the guidance is clear and actionable.

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