Get eToro price candles

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds substantial behavior: a window may exceed `limit` and trigger pagination via hasNext/nextCursor, the response includes a computed summary, summaryOnly skips the row-by-row payload, and prices are eToro quotes (bid by default) rather than the underlying venue's. These are exactly the kinds of non-obvious traits that save an agent from misreading results.

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 dense and front-loaded, leading with what the tool returns before moving to windowing, summary, and pagination. Most sentences carry operational value; the trailing 'Past performance is not a forecast' is mild filler, and the density pushes it toward the long side for an 8-parameter tool.

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, the description still characterizes the return payload (candles plus a computed summary with first open, last close, high, low, percentage change, volume) and the pagination envelope. Combined with coverage of defaults and the quote-source caveat, an agent has everything needed to call and interpret the tool correctly.

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 50% (to, from, cursor, summaryOnly documented; side, limit, interval, instrumentId not), but the description compensates by explaining the interval range (1m to 1w), the from/to ISO 8601 window, the `limit`-bounded default behavior, summaryOnly, and the default bid side. It adds real meaning beyond the schema, though instrumentId and the numeric bounds of limit remain unaddressed.

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 opening sentence states a specific verb+resource+scope: historical OHLCV candles for one instrument sourced from eToro market data. This is unambiguous and clearly distinct from siblings like etoro_get_rates, etoro_get_instruments, or etoro_get_trade_history, which serve different resources.

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?

It gives clear operational context: choose an interval, optionally supply a from/to window, otherwise the latest `limit` candles are returned, and it explains how to continue with pagination.nextCursor. It does not, however, name any alternative tool or state when another tool would be preferable, so it stops short of the top band.

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