get_options

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

No annotations are provided, so the description bears full burden for behavioral context. It discloses that Yahoo only carries chains for US-listed instruments and that a non-US symbol yielding nothing is normal behavior. It could further describe mutability (likely read-only) but the current detail is strong given the absence of 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 three sentences, each contributing unique information: mode of operation, date format, and limitation. It is front-loaded with the core purpose. The slightly informal style ('that says nothing about the symbol') is acceptable but could be tightened 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?

Given the tool has an output schema and 100% parameter coverage, the description adequately covers behavioral context. It explains the two-step workflow and the US-instrument limitation, which is crucial for correct use. It could mention that the output is a list of options or dates, but the output schema likely handles that.

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 modest value by explaining the interaction pattern for expiration but does not introduce meaning beyond the schema's documentation. For example, it doesn't clarify whether symbol must be a Yahoo ticker vs ISIN in the description text itself.

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 the option chain for a Yahoo symbol, distinguishing it from siblings like get_quote or get_history. It specifies the two modes of operation (listing expiration dates or fetching calls/puts) and provides context about coverage limitations, making the purpose precise and unique.

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 guidance on when to use the tool: call without expiration to list available dates, then call with a specific expiration from that list. It also tells the agent when not to use it (non-US symbols will return nothing and that doesn't indicate issues) and implicitly distinguishes from financial data tools like get_fund_data.

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