quantdata

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

Annotations already declare readOnlyHint and openWorldHint. Description adds that the output is not a forecast but descriptive statistics of past sessions, that the distribution is provisional with fewer than 18 bars, and that 'asia' session is unvalidated. 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 are concise, but the second sentence packs multiple conditions and warnings. Could be slightly more structured, but front-loads the purpose effectively. 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?

Covers purpose, statistical nature, conditional usage (live check, bar count), and parameter nuances. No output schema needed because return values are self-explanatory (probabilities). Complete for the tool's complexity.

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

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

Schema coverage is 100%. Description adds significant real-world guidance for the symbol parameter (name resolution advice) and the session parameter (when to omit, warning about 'asia'). This extra detail helps avoid common errors.

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 provides day-type probabilities for the trading session in progress, listing the five classes (trending up, trending down, range, trending range, reversal). It distinguishes itself from sibling tools (quantdata_gamma, etc.) by focusing on session classification.

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

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

Provides clear conditions: check session_is_live before calling 'today', check bar count for provisional results, and warns about the 'asia' session being unvalidated. Does not explicitly list when not to use, but the context is sufficient for correct invocation.

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

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

Annotations include readOnlyHint and openWorldHint. Description adds context: estimation method (Black-Scholes with zero rate/dividend), dealer convention (long calls, short puts), null flip handling, and that it's based on end-of-day quotes. No contradiction with annotations.

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

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

Description is lengthy but well-structured, front-loading purpose and key constraints. Each sentence adds necessary detail; could be slightly tighter but no superfluous content.

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

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

No output schema provided, but description explains return fields (net/gross GEX, zero gamma flip, heaviest strikes, flip status, as_of, spot_date). Covers behavioral nuances and error handling, making it complete for a complex tool.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds value: for 'by_strike' it warns it's large and only request when needed; for 'symbol' it reiterates the scope. Substantial extra guidance.

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 estimates dealer gamma exposure for US listed stocks/ETFs. Distinguishes from siblings like max_pain with a detailed description of the Black-Scholes estimation 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?

Explicitly says when to use (US listed stocks/ETFs) and when not (cash-settled index options like SPX, NDX, RUT, VIX), providing alternatives (SPY, QQQ, IWM). Also notes it reads prior session's settled open interest and cannot update intraday.

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?

Discloses that computation is pure arithmetic without pricing models, making it deterministic. Notes that open interest is from prior session, requiring as_of and spot_date. Annotations already indicate read-only and open-world, but description adds valuable 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?

Description is well-organized, front-loading the core definition, then adding necessary caveats and usage notes. No fluff; every sentence 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?

Despite no output schema, the description clearly states what the tool returns (put/call ratio, heaviest strikes, all expirations within 45 days) and error conditions. Sufficient for an agent to understand outputs.

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

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

Schema covers both parameters with descriptions. Description adds no new parameter-specific info but reinforces the purpose of 'distribution' as large and optional. Overall, it complements schema well.

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 the tool as computing options max pain per expiration from open interest, specifying it as the strike where option buyers lose most in aggregate. It distinguishes from siblings by focusing on a specific analytical 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?

Explicitly states when to use (US stocks/ETFs) and when not to (cash-settled indexes, recommending alternatives like SPY, QQQ, IWM). Also explains that it returns all expirations within 45 days, guiding proper interpretation.

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

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

Annotations already indicate read-only and open-world (readOnlyHint=true, openWorldHint=true). Description adds that it uses measured win rates from 16 years of S&P 500 futures data and notes two events came out reversed against tradition. Could further clarify limitations or assumptions.

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

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

Description is moderately long but each sentence adds substantive information. Front-loaded with core function. Could be slightly more concise, but 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 explains output conceptually (events and win rates). Addresses the tool's origin and data source. Leaves some ambiguity about exact output format, but covers enough 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 covers both parameters with descriptions (100% coverage). Description adds significant context: symbol examples for various asset types, and elaborates on session parameter's validation status and when to use it. Adds value 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?

The description clearly states the tool groups price into waves with volume summed and identifies five volume-price events with measured win rates. It distinguishes itself from sibling tools (day_type, gamma, max_pain) by focusing on volume-wave structure and answering 'is there volume behind this move'.

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

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

Explicitly states when to use (volume analysis) and when not (spot FX lacks volume, recommending CME currency futures). Provides context on needing real exchange volume and to quote measured numbers over folklore. Also guides on session parameter usage and its unvalidated status.

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