get_support_resistance

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, but it only states the core calculation and return value. It does not disclose that this is a read-only, side-effect-free analysis operation—important given siblings that place orders and close positions—nor does it explain the calculation methodology or data source (daily vs. intraday, live vs. delayed). The word 'Calculate' implies non-mutation, but that is inference, not 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?

The description is tightly structured: a front-loaded one-sentence purpose followed by a compact Args/Returns layout. Every line earns its place—ticker examples, the lookback_days default, and a one-line return summary—with no wasted words or repetition of the schema.

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 low-complexity tool (2 parameters, only 1 required, output schema present), the description covers the essential call contract: what it does, both parameters, and the return shape, with the output schema handling return detail. The gaps are the missing read-only/side-effect disclosure (no annotations) and no methodology or selection context relative to get_technical_indicators. Adequate for invocation, but incomplete for confident routing.

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, and it does: it defines ticker with concrete examples ('AAPL', 'MSFT') and lookback_days as 'Number of days to analyze' including the 60-day default, enriching the schema's bare titles. It could add constraints like min/max lookback or how the window affects level reliability, but the essential meaning of both parameters is covered.

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-plus-resource statement, 'Calculate support and resistance levels for a stock,' which clearly identifies the tool's function and is naturally distinct from siblings like get_quote, get_historical_prices, and get_technical_indicators. However, it never explicitly names or contrasts a sibling, so differentiation is implicit rather than stated.

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 offers no guidance on when to choose this tool over the 24 siblings. It does not mention alternatives such as get_technical_indicators or get_historical_prices, nor does it state exclusions or selection criteria, leaving the agent to infer usage purely from the tool's name and purpose.

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