get_tech_analysis

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description goes further by documenting the return structure (one item per interval with timestamp and indicator-specific value keys) and defaults like the 90-day lookback and inclusive to_date, which the annotations do not supply.

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?

Front-loads purpose and return shape, then presents parameters as a clean labeled list. It is on the long side, but for an 11-parameter tool with no schema descriptions nearly every line carries required information, so the length is justified.

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 output schema and 11 parameters, the description covers both the return payload shape and all argument semantics, including defaults and per-indicator applicability. An agent has everything needed to construct a valid call and interpret the response.

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 carries the full burden and does so comprehensively: it defines every one of the 11 parameters, names the enum values for indicator_type, interval, and type_of_price, gives defaults, and flags indicator-specific applicability (deviation = BB only, fast/slow/signal_smoothing = MACD only, MACD ignores length).

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 and resource ('Get technical analysis indicators') and enumerates exactly which indicators (SMA, EMA, RSI, MACD, BB) for an instrument. It is immediately distinguishable from siblings like get_candles or get_last_prices.

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 is implied by the indicator taxonomy rather than stated: there is no explicit 'use this when you need X' or exclusion against get_candles/get_stock_snapshot. It does add one cross-tool hint (the interval naming differs from get_candles and CANDLE_INTERVAL_* names are also accepted), which is genuinely useful routing information, but no when/when-not framing.

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