Get eToro balance history

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the 'Read-only' line is redundant. The description still earns credit for the non-obvious caveat that the total-balance change includes deposits and withdrawals rather than pure gains/losses, plus the account-scoping note and the range limitation.

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 core purpose is front-loaded in the first clause, and each subsequent sentence adds a distinct fact (output composition, non-environment scoping, deposit caveat, default window, includeAccounts, safety). Dense but not padded; only the trailing 'Read-only' repeats the annotations.

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 usefully enumerates the returned series fields and the summary values, and covers the default date behavior and range limit. Only includeSubAccounts lacks any explanation in either the description or schema, a minor gap in an otherwise complete definition.

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 coverage is 83%, so the baseline is 3; the description goes beyond it by spelling out what includeAccounts adds (per-account snapshots), how displayCurrency frames the totals, and what the summary contains. It leaves includeSubAccounts unexplained, which is the remaining gap.

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 states a concrete verb and resource with scope: a day-by-day time series of total balance between two dates, broken into cash, invested amount, P&L and total. It implicitly distinguishes itself from siblings like etoro_get_balances (point-in-time) and etoro_get_cash_transactions by emphasizing the daily evolution and summary, though it never names an alternative tool.

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 the default window (last 30 days), notes eToro limits the range, and points to includeAccounts when per-account detail is wanted, which is useful operational guidance. However, there is no explicit when-to-use/when-not guidance relative to the many sibling history and balance tools, leaving the routing decision to inference.

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