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

No annotations are present, so the description carries the full behavioral disclosure burden. It does not explain what 'unadjusted/repaired' means, whether data is adjusted for splits/dividends, whether any access restrictions or rate limits apply, or what side effects exist. The operation appears read-only based on 'Get,' but this is not explicitly confirmed.

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 or repetition. It directly states the core function. The slight ambiguity of 'unadjusted/repaired' costs some clarity but does not add unnecessary length.

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

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

Although an output schema exists, the description is too thin for a tool with four parameters and two sibling tools. It omits usage context, clarifies neither 'unadjusted/repaired' nor 'prepost,' and gives no indication about which technical indicators are included. An agent would have to infer too much from the schema alone.

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 75%, with symbol, period, and interval documented directly in the schema. The tool description adds no parameter-level meaning and does not clarify the undocumented 'prepost' parameter. However, the schema's enums and descriptions carry most of the semantic weight, so the description's lack of contribution is only a moderate gap.

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

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

The description uses a specific verb 'Get' and names a clear resource: 'unadjusted/repaired price history and technical indicators.' This distinguishes it from get_options_chain_v2, which is clearly for options data. However, it does not explicitly differentiate from get_stock_data_v2, which could plausibly also return price-related 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?

There is no guidance on when to choose this tool over get_stock_data_v2 or get_options_chain_v2. The phrase 'price history' implies past data, but no explicit context, prerequisites, or exclusions 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the useful detail that Greeks are theoretical European Black-Scholes, but it does not explain defaults for expiration_date, whether the chain covers all expirations when null, what 'option chain' includes (calls/puts/strikes), or any limitations or side effects. This falls short of transparent behavioral disclosure.

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

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

A single, front-loaded sentence that states the primary action and the optional enhancement with zero filler. Every word earns its place; it is 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?

For a 3-parameter tool with no annotations and only 33% schema coverage, the description is too thin. It does not clarify the meaning of expiration_date, the default behavior when it is null, the scope of the returned chain, or any caller expectations. The output schema exists, but key input semantics and usage context are missing.

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 only 33% — only the symbol parameter is described. The description helps clarify include_greeks by tying it to theoretical European Black-Scholes Greeks, but expiration_date receives no semantic explanation beyond the schema's type/format. With low schema coverage, the description should compensate more fully.

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 and resource — "Get an option chain" — and clearly distinguishes this tool from its siblings, which cover stock and historical data. The optional Greeks clause adds further precision without ambiguity.

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 context is implied by the domain: use this tool when you need option chain data, versus stock data or historical data for the siblings. However, there is no explicit when-to-use guidance, no mention of when to set include_greeks versus leave it false, and no stated exclusions 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It conveys a read operation and hints at optional inclusions, but it does not mention output structure, side effects, rate limits, or behavior when flags are false. The output schema helps with return shape but not with 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?

The description is a single front-loaded sentence that leads with the core purpose and then lists optional variations. There is no filler, repetition, or unnecessary context.

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 presence of an output schema, return-value details are covered elsewhere. However, the description lacks usage guidance and sufficient elaboration on the optional data categories, making it minimally adequate but not fully self-sufficient for an agent deciding between this and sibling 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 low at 25%, with only 'symbol' documented. The description adds some meaning by mapping the boolean flags to 'statements, analysis and calendar data,' which helps associate include_financials, include_analysis, and include_calendar, but it stops short of explaining what each included dataset contains.

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 verb and resource: 'Get stock metadata' plus optional statements, analysis, and calendar data. It is specific enough to distinguish the tool from historical-data and options-chain siblings by resource type, though it does not explicitly name those 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_historical_data_v2 or get_options_chain_v2. The phrase 'stock metadata' implies a use case, but the description does not state selection criteria or mention sibling tools.

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