avanza_instrument_chart

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

No annotations are provided, so the description must carry the behavioral burden. It does disclose that the tool is read-only and requires authentication, which is useful. However, it does not describe return shape, session behavior, data availability caveats, or how it behaves for different periods/resolutions, so transparency is only modest.

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?

Two sentences with no filler: the first defines the operation and scope, the second adds safety and intent. Every phrase earns its place, and the most important information is front-loaded.

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?

The tool has no output schema and no annotations, and the description omits detailed return-value information and any caveats about sessions or data availability. Still, 'OHLC history' combined with the schema's enums and defaults provides enough basic context for an agent to make a plausible call; it is adequate but not fully complete.

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 40%, and the description adds no parameter-level meaning beyond implying that orderbook_id identifies the order book and period controls the history window. The parameter names and enums carry most of the meaning; undocumented semantics for orderbook_id, period, and resolution are not compensated for.

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 names a specific operation ('Read'), a specific resource ('Avanza OHLC history'), and a clear scope ('for one order book and period'). This makes it immediately distinguishable from chart-adjacent siblings such as avanza_instrument_state, avanza_instrument_transactions, or avanza_realtime_quotes.

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 frames the intended context: authenticated historical OHLC data for auditable performance and counterfactual analysis. It does not explicitly list alternatives or exclusions, but the use-case framing strongly implies this is the historical-data tool rather than the real-time or state-oriented ones.

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