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

No annotations are present, so the description carries the full behavioral burden. It implies a read-style audit, but does not disclose what readiness means, whether the tool mutates anything, how min_observations is applied, or what the result contains.

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 no filler; the verb and key scoping dimensions are front-loaded. It is appropriately compact, though its brevity contributes to the larger completeness gaps.

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

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

With 3 parameters, no output schema, and no annotations, the description needed to establish basic call semantics. It fails to explain the return format, the role of history_dir, the significance of min_observations, or what 'readiness' practically means, so an agent cannot confidently invoke it correctly.

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

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

Schema description coverage is 0%, so the description needed to compensate for all parameters. It only hints at 'symbol' via 'by symbol,' while history_dir and min_observations are never mentioned, leaving their meanings and defaults entirely unexplained.

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 provides a specific verb ('Audit') and a distinct resource ('persisted gamma history readiness') with scoping dimensions ('by symbol and daily horizon'). It stands apart from sibling retrieval/computation tools like get_gamma_snapshot or calculate_proxy_gamma, though it does not explicitly name or contrast alternatives.

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

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

There is no guidance on when to use this tool versus siblings such as get_gamma_exposure, get_gamma_snapshot, or calculate_proxy_gamma. No prerequisites, conditions, or exclusions are mentioned, so the agent must infer appropriate usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the calculation operation but does not disclose whether the operation is read-only, what inputs are required beyond the schema, whether a named proxy must already exist, or what the output looks like. This is a significant gap for a computational tool.

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 with no filler or repetition. It is concise and scannable, though the brevity comes at the cost of substantive guidance in other dimensions.

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?

This is a six-parameter tool with no annotations, no output schema, and 0% schema description coverage. The description does not define 'named durable proxy definition,' does not reference the get_proxy_definition sibling for obtaining one, and does not explain how the parameters interact or what result shape to expect. An agent would not have enough information to invoke this tool reliably.

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 0% and the description adds no meaning to any of the six parameters. It does not explain what target_symbol refers to in the context of a named durable proxy, how expirations behave, or how dividend_yield, risk_free_rate, and max_expirations affect the calculation. The description fails to compensate for the schema's lack of parameter documentation.

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

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

The description uses the specific verb 'Calculate' and identifies a distinct resource, 'GEX', further qualified by 'named durable proxy definition.' This makes the tool's core function clear, though it does not explicitly contrast it with the sibling calculate_proxy_gamma.

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

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

The phrase 'using a named durable proxy definition' implies this tool is appropriate when a durable named proxy already exists, but it does not state when to prefer it over alternatives such as calculate_proxy_gamma or get_proxy_definition. Usage context is suggested, not 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?

No annotations are provided, so the description must carry the full behavioral disclosure burden. It only indicates that this is a calculation and provides no return-format details, weighting method, or edge-case behavior. For a tool with multiple financial parameters, this is a meaningful transparency gap.

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 with no filler. Every word contributes to identifying the tool's purpose, and no redundant information is included.

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 having 7 parameters, 0% schema coverage, no annotations, and no output schema, the description provides only one sentence of context. It is enough to orient an agent but far too little to ensure correct invocation, especially since the weighting semantics and the component object's structure are not described.

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 0%, so the description must compensate. It adds some meaning by identifying 'ETF' and 'explicit components', but it does not explain target_symbol's expected format, how components should be structured, or what expirations, dividend_yield, risk_free_rate, max_expirations, and sign_convention control. The components object also uses additionalProperties: true, leaving the item structure undefined.

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 ('Calculate') and names the resource ('weighted proxy GEX for an ETF with explicit components'). The phrase 'with explicit components' distinguishes this tool from its sibling calculate_named_proxy_gamma, so an agent can identify the correct operation based on purpose alone.

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

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

The description implies usage when components are explicitly provided rather than referenced by a named proxy, but it does not explicitly say when to choose this tool over calculate_named_proxy_gamma or how to obtain a proxy definition via get_proxy_definition. The guidance is only implicit, not stated as clear when/when-not instructions.

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

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

No annotations are provided, so the description must describe behavior on its own. It hints at a dependency on persisted data ('persisted GEX') but does not disclose whether the operation is read-only, what happens with too few observations, how history_dir affects execution, or what output to expect.

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

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

The description is a single efficient sentence with no filler or repetition. It is front-loaded with the verb and object, but it is so terse that some of the missing behavioral context could have been included without hurting 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?

With no annotations, no output schema, and four parameters including a nullable path and an integer threshold, this description is not enough for correct invocation. An agent would not know valid values for history_dir, the meaning of min_observations, or the shape of the comparison result.

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 0%, and the description only maps to the horizon concept ('selected horizon'). The required symbol, history_dir, and min_observations parameters are left unexplained, forcing the agent to guess at their formats and effects.

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 names a specific verb ('Compare'), a specific resource ('persisted GEX'), and the comparison target ('daily forward returns at a selected horizon'). This is strong enough to distinguish it from sibling get/calculate/audit tools, though it never explicitly names an alternative or exclusion.

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?

There is no guidance on when to prefer this tool over siblings such as get_gamma_exposure, get_gamma_snapshot, or audit_gamma_history. The description only states what the tool does, not the condition under which an agent should choose 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?

No annotations are present, so the description carries the full burden. It reveals that the result is 'estimated' but does not disclose calculation assumptions, data requirements, sign convention effects, potential pitfalls, or any side effects. One sentence is insufficient for a computational tool of this complexity.

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 with no filler. It is concise and readable, though it sacrifices helpful detail 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 7 parameters, no annotations, no output schema, and several similar sibling tools, a one-sentence description is far from adequate. It leaves the agent without guidance on parameter interpretation, return shape, sign conventions, or differentiation from sibling gamma tools.

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 0%, and the description does not compensate. It mentions 'expiration' as part of the output granularity but provides no meaning for symbol, spot, expirations, dividend_yield, risk_free_rate, max_expirations, or sign_convention beyond what the schema titles already imply.

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 a clear action ('Calculate') and resource ('estimated GEX') with explicit output granularity ('per strike and expiration'). It distinguishes from sibling tools like get_gamma_snapshot by implying a strike/expiration-level breakdown, though it does not name alternatives.

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

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

There is no guidance on when to use this tool versus get_gamma_snapshot, calculate_proxy_gamma, or compare_gamma_with_price. The description only explains what it does, not when it is the appropriate choice or what prerequisite conditions apply.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only hints that results are 'compact' and 'estimated,' but does not explain what estimation means, whether results are approximate, how expirations are handled, or any limitations. This is thin coverage for a tool with no annotation safety signals.

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 with no wasted words. It states the verb, resource, and key qualifier efficiently, which is appropriate for a concise tool description.

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 being a relatively simple tool, the description omits important context: what a 'GEX report' contains, how max_expirations affects results, what sign_convention means, and what the returned structure looks like. With no output schema and no annotations, this is a significant completeness gap.

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 0%, so the description should compensate by explaining parameter meaning, but it only loosely mentions 'several symbols' and says nothing about max_expirations or sign_convention. The field names and enum values are somewhat self-explanatory, but the description adds little beyond what the schema already presents.

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 ('Return'), the resource ('compact estimated GEX reports'), and the scope ('for several symbols'). It is not a tautology and conveys the core function, though it does not explicitly differentiate itself from siblings like get_gamma_exposure.

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

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

The description implies a use case—getting compact GEX estimates for multiple symbols—but provides no explicit guidance on when to choose this tool over alternatives, no exclusions, and no context about trade-offs. An agent cannot reliably decide between this and sibling gamma-related tools.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose that the chain is 'normalized' and 'delayed,' which is useful, but it doesn't clarify what normalization means, how delayed the data is, or what response shape to expect. It also doesn't disclose auth requirements or rate limits, though as a read operation this is less severe.

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 sentence, no filler, and the key qualifiers ('normalized', 'delayed', 'for one expiration') are front-loaded. 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 tool with no output schema and no annotations, the description is too thin to fully support invocation. It omits how to obtain valid expirations (get_options_expirations), what happens when `expiration` is null, and what the returned chain contains (strikes, calls/puts, etc.).

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 0%, so the description should compensate, but it doesn't define the meaning or format of `symbol` or `expiration`. The parameter names are self-explanatory to some degree, and 'for one expiration' hints at the `expiration` parameter, but no additional semantics such as default behavior when expiration is null or date format are 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?

States a specific verb ('Return') and resource ('normalized delayed option chain') with the scope constraint 'for one expiration.' It clearly indicates what the tool does, though it doesn't explicitly differentiate itself from sibling tools such as get_gamma_exposure or get_options_expirations.

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 about when to choose this tool over its siblings, and no prerequisites are stated (e.g., obtaining an expiration first). The phrase 'for one expiration' only implies that an expiration may be needed, but conditions and alternatives are left to inference.

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

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

With no annotations, the description carries the behavioral burden. It conveys that the tool returns expiration dates and that the data is 'delayed,' which is useful. It does not describe output structure, ordering, or potential failure modes, but for a read-only date lookup this is minimally adequate.

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

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

A single front-loaded sentence contains no filler and states the resource before naming the input. It is appropriately sized for the tool's low parameter count.

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

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

The tool is simple, so the description is close to adequate, but without an output schema or annotations it leaves the exact return shape and any usage context unstated. It is a minimum-viable definition.

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 0%, so the description must compensate. It restates that a symbol is needed and clarifies it is the symbol for which option expirations are returned, but adds no format, examples, or constraints beyond the schema property.

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 ('Return') and names the exact resource ('available delayed option expiration dates') for an input symbol. This clearly separates it from sibling tools focused on gamma and options chain data, despite no explicit differentiation.

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 about when to use this tool instead of get_options_chain or the gamma tools. There are no exclusions, prerequisites, or alternative routing cues.

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

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

There are no annotations, so the description carries the burden of behavioral disclosure. It does reveal that the tool returns a 'durable proxy definition' and a 'verification status,' which is useful context. It does not explain what 'durable' means, what the verification status represents, or whether any side effects or permissions are involved, but for a getter this is a moderate but not critical gap.

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 no filler words and is front-loaded with the action ('Return'). 'Durable' and 'verification status' are compact additions that convey some nuance. It is appropriately brief for a simple getter, though the brevity contributes to under-specification in other dimensions.

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, no annotations, and an undocumented required parameter, the description is too thin. It does not explain what the proxy definition actually contains, what 'verification status' means, or how this retrieval relates to the gamma calculation siblings. An agent could call it correctly by name alone, but it would be uncertain about the returned structure and the semantic role of 'target_symbol.'

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 0%, and the description never mentions 'target_symbol' or explains how to supply it. Since the schema provides no field description either, an agent is left with only the parameter name to infer meaning. The description fails to add any value beyond the structured 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 ('Return') and names a distinct resource: 'durable proxy definition' plus 'verification status.' This differentiates it from siblings like calculate_proxy_gamma and calculate_named_proxy_gamma, which imply computation rather than retrieval. However, 'durable proxy definition' itself is not explained, so the purpose is clear but slightly under-specified.

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

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

The description provides no guidance on when to use this tool versus alternatives such as calculate_proxy_gamma or compare_gamma_with_price. It does not state whether this should be called before calculations, for validation purposes, or when a saved proxy mapping is needed. Only the verb 'Return' weakly implies a retrieval-oriented use case.

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