stock_extended_hours

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

Annotations already mark the tool read-only and non-destructive, and the description adds valuable behavioral details beyond that: null post_market during regular hours, weekend/holiday behavior, 'most recent valid print' per window, and the computed percentage changes relative to appropriate baselines. No contradictions with annotations exist.

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 front-loaded with the core purpose and usage trigger, followed by concise structured Args and Returns sections. Every sentence adds value, and the format is easy for an agent to scan and apply.

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 single-parameter, read-only tool with no output schema, the description is complete: it explains inputs, outputs, null semantics, session timing, and market-condition behavior. An agent has everything needed to select and invoke the tool correctly and interpret its results.

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 provides only the parameter name and type with no description, so the description carries the full burden. It explains symbol as a US stock symbol and supplies concrete examples including tickers, index symbols, and the ^GSPC format. This fully compensates for the 0% schema description 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?

The description clearly states the tool's function: retrieving real-time pre-market and after-hours prices for a US stock symbol. It uses a specific verb-resource combination ('returns real-time pre-market and after-hours prices') and distinguishes itself from regular-session price tools like stock_prices and yahoo_price by explicitly limiting scope to extended-hours sessions.

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 gives explicit when-to-use guidance: 'Use this when the user asks about a stock outside the regular 9:30am-4pm ET session' and provides concrete example queries. It also explains edge-case behavior during regular sessions and weekends/holidays, which helps the agent decide correctly without ambiguity.

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