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

Beyond the read-only/idempotent annotations, the description discloses the cost model assumptions (unleveraged, bid prices, no spread, fees, overnight costs, or dividends) and confirms nothing is placed or prepared. It also previews the return payload (invested, units, average cost, end value, result, worst fall, dca comparison). This is rich behavioral context that annotations alone cannot convey.

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 front-loaded with the core behavior and the strategy definitions, and every clause carries information. It loses a point for redundancy: 'It places nothing and prepares nothing' is restated at the end as 'Nothing was sent to eToro and nothing was prepared,' and the simulation disclaimer is somewhat padded.

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 complex 8-parameter tool with no output schema, the description fully compensates by enumerating the returned metrics and the dca comparison, and by stating the data source and cost assumptions. Nothing an agent needs to call or interpret this correctly is missing.

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?

With 75% schema coverage the baseline is 3, but the description adds meaning the schema lacks: it explains the strategy enum values (one purchase at start vs. amountUsd every everyDays days) even though the schema's strategy field has no description. It restates amountUsd and everyDays semantics that are already documented, adding marginal value.

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 verb (backtest/simulate a buying rule) and resource (past prices for a symbol/window), and enumerates the two concrete strategies ('buy_and_hold' and 'dca') with their mechanics. It also implicitly separates itself from real-trade siblings by stressing it 'places nothing and prepares nothing.' An agent can tell exactly what this does without opening the schema.

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 rather than stated: the reader can infer this is for historical 'what-if' simulation, and the disclaimers ('not a prediction, a recommendation or financial advice') clarify intent. However, no explicit when-to-use or when-not guidance is given, and no sibling alternatives (e.g. etoro_simulate_position) are named or contrasted.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial value beyond them: it discloses side effects ('two small read requests and places nothing'), a security guarantee ('never key values'), the masked account reference, the server mode with its caps, and whether the client can prompt for confirmation. That is rich behavioural context an agent needs before trusting the result.

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-loaded with the core purpose, then enumerates the checks and the return shape. The second sentence is dense and long, packing four return elements plus a security note, but every clause carries information and nothing is redundant.

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?

There is no output schema, so the description carries the burden of explaining the return value — and it does, listing per-check results, the masked account reference, server mode/caps, and prompt capability. The only missing piece is prerequisite context (when this should be run, what 'configured' means in practice).

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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies that inputs are external configuration (the 'configured API keys' and 'configured environment') rather than call arguments, which prevents an agent from hunting for parameters that do not exist.

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?

Names a specific verb (verifies) and a specific resource (the API keys/environment behind the configured connection), and spells out exactly what is checked: authentication, environment, permissions, and account-to-environment match. No sibling tool in the list performs a connectivity/diagnostic check, so it is unmistakable among the portfolio, order, and instrument tools.

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 only implied — the phrase 'makes two small read requests and places nothing' signals this is a safe, cheap call worth running before real work, but the description never says when to call it (startup? before trading?) or when to prefer it over just calling etoro_get_balances and observing failure. Adequate but no explicit when/when-not guidance or named alternatives.

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

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

Annotations already cover readOnlyHint, idempotentHint, destructiveHint and openWorldHint, so the safety profile is known. The description still adds genuine value by stating 'Computes only; places nothing' and by describing the returned decision fields (settlement types, permissions, limits), which no output schema provides. It does not, however, cover auth scope or any per-call limits beyond input count.

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?

One dense clause stating what is returned, followed by a short constraint sentence and a short input instruction. Strongly front-loaded with the payload description and no filler. Slightly run-on list inside the first clause, but nothing is wasted.

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 0% schema description coverage, the description must explain both returns and inputs, and it does so competently for a two-parameter read tool. Remaining gaps are minor: behavior when neither parameter is given, and the 'demo account' scoping, which could confuse an agent unsure whether it applies to live accounts.

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 carry the parameter burden and largely does: it explains that instrumentIds and symbols are alternatives ('and/or') and imposes a 'max 100 combined' limit that is stricter and more useful than the schema's per-array maxItems of 100. It does not explain symbol format or what happens when neither is supplied.

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 enumerates exactly what the tool returns for a given instrument set (settlement types, leverage, buy/sell and partial-close permissions, minimums, SL/TP limits), which is far more specific than a restatement of the name. It is clearly distinct from the portfolio/pnl/balances siblings. It lacks an explicit verb ('check'), but the resource and scope are unambiguous.

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 rather than stated: the tool reports what an account may trade, and 'Computes only; places nothing' signals a pre-trade query. However, there is no explicit when-to-use framing, no prerequisites, and no alternative sibling is named or excluded, so an agent must infer the context.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description goes further with real behavioral context: state is persisted in SQLite, survives restarts and spans other sessions, results come newest-first, and it also returns today's executed total against daily limits. Pagination behavior is left unstated, keeping it short of a 5.

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?

Three sentences, zero filler, and the core scope is front-loaded before the persistence note, the query semantics, and the sibling redirect. Every sentence earns its place.

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 an 8-parameter, no-output-schema tool it covers the essentials, including the side-channel return of today's executed total and the ordering of results. It does not explain pagination (limit/offset) or the status/environment filters, which an agent must infer from the schema.

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 63%, so some parameters (limit, offset, status) are undocumented. The description compensates meaningfully by explaining what `query` actually matches (summary, action name, and order/position/instrument/action ids) and implying result ordering, which is more than the schema alone conveys.

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 with scope: searches the *local* action history the server prepared and the user executed, rejected or let expire. This cleanly separates it from broker-side siblings like etoro_get_trade_history and from the UI-facing etoro_open_history.

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?

Explicitly names the alternative and the condition that selects it: 'To let the user browse and search it themselves, call etoro_open_history instead.' It also clarifies the tool's remit (actions this server prepared and the user acted on) versus other history tools.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the meaning of each status, that approval is user-driven, and that history from earlier sessions is reachable. It does not describe return shape or latency, which is acceptable given no output schema but why it is not a 5.

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 and the full status enumeration are front-loaded in the first sentence, with the secondary history note after it. Two sentences, no filler, no repetition of the title.

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 a single required parameter, rich annotations, and no output schema, the description covers what the agent needs: what the states mean and the approval-driven lifecycle. It stops short of explaining behavior for an unknown/expired actionId or how the local-history lookup applies to cross-session IDs.

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 0% (actionId has no description), but the schema does supply the UUID format and pattern. The description compensates by explaining where the actionId originates — from an action prepared by an etoro_prepare_* tool — which is the key missing semantic. It doesn't discuss expiry or lookup failures for unknown IDs.

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 the status of a prepared eToro action) and enumerates the possible states, so an agent knows exactly what comes back. It does not explicitly differentiate itself from the sibling etoro_get_action_history, and the closing note about finding actions 'from earlier sessions in the local history' slightly blurs that boundary.

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 phrase 'an action prepared by an etoro_prepare_* tool' clearly signals the workflow context: call this after a prepare tool to poll the result. It also states the important constraint that 'only the user can execute an action,' so the agent knows this is a passive status check. No explicit alternative (e.g. get_action_history for browsing) is named, so it stops short of a 5.

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

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds that balances are aggregated in a display currency and that the tool reports the account the key belongs to (not environment-specific), which is real context beyond annotations, but it says nothing about response shape or currency-conversion behavior.

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 compact sentences with the core purpose front-loaded and no filler. Slightly terse given the tool's scope, but nothing is wasted.

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 zero-required-parameter read tool with annotations covering safety, the description is adequate on purpose but incomplete: it omits the meaning of unfiltered calls (all account types?), pagination, and the shape of the aggregated result. With no output schema present, a bit more disclosure would help.

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 only 50%: accountTypes and displayCurrency are documented, while includeSubAccounts and includeZeroBalances have no description in either the schema or the description. The description mentions no parameter at all, so it fails to compensate for the coverage 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?

States a specific verb+resource ('aggregated balances across the user's eToro accounts') and clarifies scope with 'trading, cash, ...'. It hints at differentiation from portfolio siblings via 'Not environment-specific', but never names a sibling like etoro_get_portfolio, so an agent must still infer the boundary.

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?

There is no explicit when-to-use guidance and no named alternative among the many portfolio/PnL siblings. The only routing clue is the negative statement that it is not environment-specific, which does not tell the agent when to prefer this over etoro_get_portfolio or etoro_get_portfolio_breakdown.

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

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.

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

Annotations already cover readOnly, idempotent, non-destructive and open-world. Beyond that, the description discloses ordering (newest first), the returned fields, the pagination token flow, and the non-environment-specific scoping behavior, adding genuine context the annotations do not carry.

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-loaded with what is returned, then prerequisites, scoping, pagination and safety. Every sentence carries information except the trailing 'Read-only.', which duplicates readOnlyHint; slight redundancy, but otherwise tight.

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 names the returned fields and ordering, and with no annotation about pagination it documents the token flow. For a read-only list tool it supplies everything an agent needs to call and consume it 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 coverage is 0%, so the description must compensate. It explains accountId's meaning and provenance and explains pageToken's role in retrieving older movements, but leaves pageSize (default 25, max 100) unaddressed. Good compensation for the two meaningful parameters, with a minor 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?

States a specific verb and resource (cash account transactions) and enumerates the exact movement types (card payments, bank and internal transfers), which cleanly distinguishes it from sibling history tools like get_trade_history or get_action_history. An agent can identify the resource and its contents without opening the schema.

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?

Provides a concrete prerequisite path: the accountId must come from etoro_get_balances for accounts of type Cash, and it explains the pagination pattern (follow nextPageToken with pageToken). It gives clear context for use but does not state explicit exclusions or when to prefer it over other history tools.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavior: exact-match-only semantics, the ETF exchange-suffix convention, and the argument-exclusivity constraint. It does not cover pagination behavior (pageSize) or empty-result handling, keeping it just below a 5.

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?

Four tight sentences: what it does and returns first, then the disambiguation, then the edge-case formatting note, then the constraint. No filler, nothing repeated from 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 compensates by listing the return fields (instrumentId, symbol, displayName, type, exchangeId). Combined with the disambiguation and formatting guidance, an agent has everything needed to invoke this 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 25%, so the description must carry weight: it explains symbols (exact tickers, with a .L ETF example), instrumentIds, and type-based listing, and forbids combining symbols with instrumentIds. Only pageSize is left unexplained, which the schema's default/max partially covers.

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 (look up / list) with named resources (instruments by ticker symbol, instrument id, or type) and enumerates the returned fields. It explicitly distinguishes itself from the sibling etoro_search_instruments, so an agent can route without opening either schema.

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?

Explicitly says this is an exact lookup and names the alternative for name/partial text ('for example apple') — etoro_search_instruments — plus the mutual-exclusivity rule ('Provide symbols or instrumentIds, not both'). Both when-to-use and when-not-to-use are covered.

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

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

Goes well beyond the annotations by disclosing partial-failure behavior ('A section that fails is reported in `errors` without losing the others'), the read-only scope ('it places nothing'), and an explicit prompt-injection warning to treat investor free text as untrusted data. These are non-obvious behavioral traits an agent must know to use the result safely.

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-loaded with the core purpose and section semantics, and every sentence is broadly useful. The disclaimer sentences ('Past performance is not a forecast…') and 'Other investors' public data from eToro' are slightly redundant filler that dilute an otherwise tight paragraph.

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 carries the return-value burden and does so: it describes the content of every section, the default selection, and how errors are surfaced. An agent has everything needed to call this correctly and interpret partial results.

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 only 33%, and the description compensates meaningfully: it names and defines all five `sections` values (including return-shape details like portfolio 'grouped by instrument and sorted by weight, top 25') and ties `period` to tradeinfo statistics. It does not explain interaction effects, e.g. that `period` is meaningful only when tradeinfo is selected.

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+resource+scope: 'Public information about one investor by username', which cleanly distinguishes it from the plural-search sibling etoro_search_investors. It then enumerates exactly what each readable section returns, so an agent knows what it will get without opening the schema.

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?

Gives clear guidance on when to use each `sections` value and what the defaults are, plus the scope limit ('Public data only; it places nothing'). However, it never names an alternative (e.g. etoro_search_investors) for the case where the caller does not already know a username, even though username is required and pattern-constrained.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), so the description earns credit for adding real behavioral context: sample statuses (WaitingForMarket, Filled) and the 404 lag for just-placed orders. That timing caveat is exactly the kind of non-obvious behavior an agent needs.

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?

Three tight sentences, front-loaded with the core purpose, then lookup keys, then the operational caveat. No filler and every clause carries information.

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 two-param read tool with no output schema and no enum coverage, the description supplies purpose, both parameter roles, example statuses, and a timing quirk. It could say more about the returned structure, but nothing essential to correct invocation is missing.

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 0%, so the description must carry the load, and it does reasonably well: it identifies both lookup keys, clarifies that orderId originates from order placement, and enforces 'provide exactly one'. It omits format/syntax detail (e.g., referenceId string shape), but the semantics are otherwise clear.

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: 'Status and execution details of one order', and pins the lookup keys to orderId or referenceId. This clearly separates it from history/action siblings, though it does not name an alternative tool explicitly.

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?

Explains where orderId comes from ('returned when an order is placed') and that exactly one identifier must be supplied, which implies usage. But it offers no when-to-use vs when-not guidance relative to siblings like get_action_status or get_trade_history.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new traits beyond that: the data is specifically the demo account, the default view is compact, mirror data lives in a separate view, and results are paged like the portfolio breakdown.

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, zero waste. The returned-data scope is front-loaded, and the second sentence efficiently bundles view defaults, the mirror-view caveat and the paging analogy in one clause.

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 carries the return-value burden and does state the shape (account total plus per-position fields) and paging. Only minor gaps remain, e.g. whether this covers real as well as demo accounts and any freshness or rate-limit notes.

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 100%, so the schema already documents view, limit, offset and mirrorId in more detail than the description does (including the raw view sizing warning). The description's view/paging remarks largely restate schema content, so the baseline 3 applies.

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?

It names a specific resource (unrealized PnL) and enumerates the per-position fields returned (profit/loss, exposure, margin, current rate), plus the account scope (demo). It references etoro_get_portfolio_breakdown only to borrow its view/paging semantics, so it never explicitly separates its purpose from that sibling's.

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 explains which view to pick for copied-trader data ('copied traders' positions are in the mirror view') and notes the compact default, which is real routing guidance. But it gives no explicit when-to-use/when-not-to-use versus etoro_get_portfolio_breakdown or etoro_get_portfolio, leaving the choice to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description usefully scopes the call to the 'demo account' and sketches the aggregation shape, but discloses nothing about pagination, latency, or auth requirements beyond the API reference link.

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?

Three short sentences, all front-loaded: what it returns first, the sibling alternative second, the reference link last. No filler or restatement of the title.

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 carries the burden of describing the return shape, and it does so adequately (totals, positions grouped by instrument, mirrors). The 'demo account' framing answers an important scope question, though the absence of any note on the aggregate-vs-breakdown trade-offs for filtering remains a small gap.

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 100%, so pnlLevel and instrumentIds are already documented in the schema, including the enum values and maxItems constraint. The description adds no additional meaning about these filters, so the baseline of 3 applies.

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 ('aggregated snapshot of the demo account') and enumerates exactly what the payload contains: account totals, open positions grouped by instrument, and copy-trading mirrors. It explicitly contrasts itself with the sibling etoro_get_portfolio_breakdown, so an agent can distinguish the two without opening schemas.

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?

Names an alternative and the condition that selects it ('For individual open positions with their position ids and pending orders use etoro_get_portfolio_breakdown'), which is genuine routing guidance. It does not, however, say when to prefer this aggregated view over other sibling reads like etoro_get_pnl or etoro_get_balances, which overlap in scope.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: the default view is compact, copy-trader positions live in the mirror view and are paged, and the raw view is 'very large' with shortened arrays.

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-loaded with the returned payload, then follows with view semantics and sibling routing in a tight block with no filler. The parenthetical field list replaces a longer enumeration that would otherwise sprawl.

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 carries the burden of describing returns and does so by listing the position fields, pending orders and available credit. The demo-account scope and the view-dependent behavior are both stated, leaving nothing essential unstated for a 4-param, zero-required read tool.

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 100%, so the schema already explains view, limit, offset and mirrorId, including the mirrorId-is-in-summary-view dependency. The description largely restates the paging behavior rather than adding syntax or format detail beyond the schema, so the baseline 3 applies.

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 the specific resources returned (open positions, pending orders, available credit) and enumerates the position fields, so an agent knows exactly what comes back. It also distinguishes itself from siblings etoro_get_pnl and etoro_get_portfolio by name.

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 routes the agent explicitly: use etoro_get_pnl for current P/L per position and etoro_get_portfolio for an account overview, and it flags the downstream dependency that position ids feed etoro_prepare_close_position. The mirror-view prerequisite (mirrorId from the summary view) is also called out.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), so the description's added value is the caveat that these are eToro's own quotes rather than the underlying venue's prices, which is genuinely decision-relevant for an agent. It does not discuss failure behavior for unknown ids or rate limits, keeping it short of a 5.

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, no waste, with the core operation stated first and the important quote-source caveat second. Both sentences earn their place.

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 names the returned fields (bid and ask) and the quote provenance, so an agent knows what comes back. Only minor gaps remain around id validity and error behavior for a tool this simple and well-annotated.

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% for the single instrumentIds parameter, so the description must carry the load. It conveys the id-based array and the 100-item ceiling, matching the schema's maxItems, but adds no clarification on id format, ordering, or error handling for invalid ids.

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 (current bid and ask) plus a scope limit (up to 100 instruments by id), which separates it from sibling lookups like etoro_get_instruments or etoro_get_trade_history. It stops short of naming an alternative sibling explicitly, so it is clear but not fully differentiated.

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?

There is no explicit when-to-use or when-not-to-use guidance, nor any pointer to etoro_get_instruments as the source of the ids this tool requires. The 'by id' phrasing implies a prerequisite lookup, but the routing decision is left entirely to inference.

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

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds useful operation-specific context: it is limited to the demo account, returns closed trades with open/close rates, net profit and fees, and is paginated. It still does not explain pagination behavior or authentication needs.

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 short sentences with no wasted words. The core purpose, scope, return fields, and pagination caveat are front-loaded and easy to parse.

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 simple read-only listing tool with no output schema and rich safety annotations, the description covers the key facts an agent needs: demo-account scope, closed trades only, date filtering, returned fields, and pagination. It remains incomplete on pagination details and lacks sibling routing, but overall it is sufficient for correct invocation.

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 low at 33%, with only minDate documented. The description adds some semantic value: 'since a date' clarifies minDate as a start date, and 'Paginated' signals that page/pageSize exist and matter. However, it does not explain page or pageSize behavior, defaults, or limits, so the two undocumented parameters remain underspecified.

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 specific verb+resource ('Get eToro closed trades'), scope ('demo account since a date'), and returned fields. It distinguishes closed trades from generic portfolio/PnL siblings implicitly through 'closed trades' and 'open/close rates, net profit and fees', but does not explicitly say how it differs from tools like etoro_get_pnl.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative sibling is named. The description only implies usage by specifying 'closed trades of the demo account since a date', leaving the agent to infer context.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower, yet the description adds real value: it confirms nothing is placed, enumerates the fee components computed (markup, spread, transaction, overnight/weekend, stamp duty), and specifies amounts are in USD. It omits any statement about return shape or latency, but the added context is solid.

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?

Three short sentences, front-loaded with the purpose and the compute-only guarantee, then the currency unit and the closing hint. No filler.

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 9-parameter tool with zero schema descriptions and no output schema, the description is thin: it names the output fee components and currency but leaves nearly all input semantics undocumented, so an agent must infer which parameters pair with which action (open vs close) and what values are valid.

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% across 9 parameters, so the description carries the full burden. It only clarifies one parameter ('For closing, pass the position ids') and never explains action, symbol, leverage, amountUsd, orderType, transaction, instrumentId, or settlementType — enums and defaults exist in the schema but no semantics are added.

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 — a what-if cost breakdown for a hypothetical order — and immediately clarifies 'Computes only; places nothing', which cleanly separates it from the read-only portfolio/pnl/balance siblings and from any order-placement flow.

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 'what-if ... hypothetical order' framing plus 'Computes only; places nothing' tells the agent this is for estimation rather than execution, and 'For closing, pass the position ids' gives a concrete conditional. It stops short of naming an alternative tool or stating exclusions explicitly.

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

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

Beyond the annotations (which already cover read-only/idempotent/non-destructive), the description adds genuinely useful behavioral context: the permission scope required and the scoping rule that 'alerts belong to the account, not to demo or real'. This is real value the annotations do not convey.

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-loaded and dense but not bloated; the field list is packed into one sentence. Slightly run-on, but every clause carries information.

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 documents the return fields, plus the permission requirement and data scope. Fairly complete for a simple parameterless read tool; minor gaps are unstated ordering or volume of alerts.

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?

Zero parameters, so there is nothing to document; the baseline for a parameterless tool is 4. The description's field enumeration is return-value context rather than parameter semantics.

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?

Clear specific verb+resource: 'List the user's active price alerts'. It even enumerates the returned fields (instrument, target price, bid, direction, distance). It does not name a sibling alternative, but no other price-alert tool exists among the siblings, so differentiation is not strictly needed.

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 (retrieve active alerts) rather than explicitly framed, and no when-not or alternatives are given. It does state a prerequisite ('Needs the key's price-alerts Read permission'), which is a partial usage signal.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds some value by stating that items are returned as instrument ids, but it does not explain pagination behavior, whether built-in watchlists are included, or other operational details.

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 a single noun phrase rather than a structured sentence, so it is terse but under-specified. It is not front-loaded with a clear verb or usage context, leaving important information absent.

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 two undocumented parameters, no output schema, and no usage guidance, the description is too thin for an agent to call the tool confidently. It states the broad return content but omits parameter meanings, pagination, and the role of built-in watchlists.

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% for both itemsPerPage and includeBuiltin, and the description does not mention either parameter. The definition gives an agent no way to understand the two inputs beyond their bare names and defaults.

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 the specific resource (the user's watchlists) and what each contains (items / instrument ids), so an agent can tell it is a read/list tool for watchlists. It lacks an explicit verb, but the title supplies 'List' and no sibling tool covers watchlists, making the purpose clear.

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?

There is no guidance on when to call this tool, when to avoid it, or how it relates to the portfolio and instrument siblings. The agent must infer its usage from the name alone.

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

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint/idempotentHint, and the description adds non-obvious operational context the annotations cannot convey: bound to 127.0.0.1 only, secret address expires after an hour, and it returns no history data. No contradiction with idempotentHint=false given the expiring address.

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-loaded with the action, then constraints, then routing in three efficient sentences with no filler. The parenthetical filter list and CSV mention are slightly dense but still earn their place by telling the agent what the page can do.

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 no parameters, the description supplies everything needed: what opens, where it runs, how long the link lives, and that no data comes back. An agent has no remaining ambiguity about how or whether to invoke it.

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?

Zero parameters and 100% schema coverage, so there is nothing for the description to disambiguate. The parenthetical list of filter dimensions (text, date, environment, action, status) is contextual color rather than true parameter semantics, so it stays at the baseline rather than exceeding it.

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 ('Opens a local page in the user's browser') plus the concrete capabilities of that page (search/filter history, view details, see limits, download CSV). It is clearly distinguishable from the sibling that actually returns history data, which it names explicitly.

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?

Explicitly routes the agent away from this tool for data retrieval: 'It returns nothing from the history: use etoro_get_action_history to read it yourself.' That is a clear when-not condition, though it never states the positive case (user wants an interactive browser UI) beyond the opening clause.

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

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

Annotations already cover read-only/idempotent/open-world safety, and the description adds real value on top: the return fields, the absence of images, the `limit`-bounded result count, and the non-obvious duplicate-ticker quirk (.RTH = regular-trading-hours instrument vs the plain 24/5 ticker). That quirk is exactly the kind of behavioral detail an agent cannot infer from structured fields.

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 what the tool does, then the return shape, then the ticker quirk, then the hand-off advice. Every sentence earns its place with no filler.

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 steps in to enumerate the returned fields and call out the image exclusion and duplicate-symbol behavior. An agent has everything it needs to call this correctly and to pass the result onward.

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 only 50% (limit has no description), so the description compensates: it clarifies that query matches by name or ticker and that limit caps the number of matches returned. The examples also disambiguate query format, though limit's max/min bounds are left to the schema.

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 (search) and resource (instruments) plus the search dimension (name or ticker), with concrete examples. It reads as distinct from a plain listing tool, but it never names the sibling (etoro_get_instruments) it differs from, so it stops short of explicit sibling differentiation.

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?

Gives clear context ('free-text search') and actionable downstream guidance: 'Use the instrumentId or the exact symbol with the other tools.' It does not state when NOT to use search versus a listing/lookup tool, so no explicit exclusions.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds meaningful behavior on top: 'Public data only; it places nothing', a caveat that risk score is eToro's own measure and past performance is not a forecast, and a prompt-injection warning about untrusted investor free text. It stops short of pagination/rate-limit behavior.

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-loaded with purpose and return fields, then scoping notes, then safety caveats. The dense stats enumeration is efficient, though the trailing trust/safety sentences are somewhat stacked and could tighten slightly.

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 returned stats (gain, risk scores, copiers, win ratio, drawdown, leverage mix), which covers the return side. However, for a 14-parameter tool with sparse schema descriptions, the filter semantics and paging behavior are not explained, leaving real gaps.

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 29% across 14 parameters, so the description must compensate. It explains 'period' as the stats window and 'sort' syntax, but the numerous filter parameters (instrumentPctMin/Max, maxDaily/MonthlyRiskScore bounds, countryId, page/pageSize) are left to bare schema types.

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 ('Finds investors (people others can copy) by performance and risk filters') and enumerates the returned stats, making it clearly distinct from the sibling etoro_get_investor (single lookup) and etoro_search_instruments. An agent can pick it without opening a schema.

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?

Gives concrete usage context: filters are performance/risk based, 'period' sets the statistics window, and 'sort' takes a leading minus for descending (e.g. '-copiers'). It does not, however, name any alternative tool or state when not to use it versus etoro_get_investor.

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

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

Annotations already declare this read-only, idempotent and non-destructive, and the description still goes further: it states nothing is placed or prepared, nothing is sent to eToro, and that the simulation uses bid prices with no spread, fees, overnight costs or slippage. It also discloses exactly what the result contains, which is behavior an agent could not infer from annotations.

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-loaded with the core mechanic and the return shape, and the caveats are appropriately placed. It loses a point for redundancy: 'It places nothing and prepares nothing' is restated as 'Nothing was sent to eToro and nothing was prepared', which is wasted text.

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 10-parameter simulation tool with no output schema, the description compensates by enumerating the return fields (entry/exit prices and times, exit reason, USD and percentage result, best/worst moments) and by flagging the cost-model limitations. Nothing material an agent needs before invoking it is missing.

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 70%, leaving side, leverage and instrumentId undocumented in the schema; the description covers the first two by explaining the buy/sellShort amount-with-leverage construction and the margin-hit condition for stop loss/take profit. It adds real meaning beyond the schema for the trigger parameters, though it says nothing about instrumentId or the interval enum.

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 precise verb and resource and describes the mechanics in detail: long/short of amountUsd with leverage, optional stop loss and take profit, held until a trigger or window end. An agent knows exactly what is computed, though the description never names the obviously similar sibling etoro_backtest to distinguish itself from it.

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 opening 'What would have happened if a position had been opened...' implies the hypothesis-testing use case, and the text clarifies this is retrospective simulation rather than prediction. However, no explicit when-to-use, when-not-to-use, or alternative (e.g., etoro_backtest) is named, so selection is left to inference.

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