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 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 establish readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the lack of free-text search, the exchange-suffix convention for ETFs with a concrete example (CSPX.L), and the return field list (no output schema exists, so this is the only source).

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 dense sentences with no filler, front-loaded with the core action before the constraints. The return-field list and the 'not both' rule each carry weight, though the sentences are packed tightly enough that a little breathing room would help readability.

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 supplies the return shape itself, and it covers the input modes and mutual-exclusion rule. Remaining gaps are minor: it never says what happens when no parameters are supplied (full listing?) or how pageSize pagination behaves.

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 25% (just 'symbols'), so the description does meaningful compensation: it clarifies symbols are exact tickers, contrasts symbols vs instrumentIds, explains the ETF suffix format, and notes only one of the two should be supplied. pageSize and the type enum values are left to the schema, which documents them adequately.

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 ('look up instruments') and enumerates the three lookup modes (exact symbols, instrument ids, or by type). Also names the returned fields (instrumentId, symbol, displayName, type, exchangeId), so an agent knows exactly what it gets. Clearly distinct from the sibling portfolio/order/rate 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?

Gives concrete operating constraints: free-text name search is not supported, and symbols/instrumentIds should not be combined. These are real usage rules that steer the caller. It does not name an alternative tool, but none of the siblings overlaps this lookup function, so the guidance is effectively complete.

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 provenance context ('orderId returned when an order is placed') but says nothing about behavior on a missing order, pagination, or rate limits, so it adds only modest value beyond the 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?

One front-loaded sentence naming the return content, followed by a terse clause on key selection and the exactly-one constraint. Nothing is redundant and no sentence 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 two-parameter read-only lookup with no output schema, the description covers what is returned at a summary level and how to identify the order. It does not sketch the shape of 'status and execution details' or error behavior, which is the only real 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 0%, so the description must carry the parameter burden, and it does: it explains what orderId is (returned when an order is placed), that referenceId is an alternative identifier, and that exactly one must be supplied. It omits type/format constraints (positive integer, string length), keeping it short of a 5.

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 names the lookup keys, so the agent knows it fetches a single order rather than a list. The resource is distinct from every sibling (portfolio, pnl, balances, rates, watchlists), though the description never explicitly contrasts itself with them.

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 useful invocation guidance — use either orderId or referenceId and 'Provide exactly one' — which tells the agent how to call it. However, it says nothing about when this tool is appropriate versus other order- or history-related siblings such as etoro_get_trade_history, so usage context is only implied.

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), so the bar is lower, and the description still adds two useful pieces of context: that it targets the demo account specifically and exactly which data classes are returned. It stops short of noting any auth, rate-limit, or freshness/valuation caveats.

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?

A single front-loaded sentence with no filler; the subject (unrealized P/L) comes first and the enumeration is compactly parenthesized. 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 parameters and no output schema, the description must convey what comes back, and it does enumerate the returned data classes. The remaining gap is the absence of sibling differentiation, which matters given three other portfolio-style tools in the same family.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. The parenthetical clarifies what the (parameterless) response covers, which is a reasonable substitute.

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 resource and result: unrealized P/L plus portfolio details, with an explicit enumeration of contents (positions, mirrors, pending orders, orders to open/close). It is clear what the tool returns, but it never distinguishes itself from close siblings like etoro_get_portfolio, etoro_get_portfolio_breakdown, or etoro_get_balances, which an agent must choose between.

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 only scoping signal is 'demo account', which implies a context but is not framed as a when-to-use rule. No alternatives are named and no conditions for choosing this over the other portfolio/balance tools are given, leaving selection 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 establish the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false). The description then adds behavior the annotations cannot convey: the data is scoped to the demo account and the response carries position ids and units that are consumable downstream. It does not mention pagination or result size limits, but the added account scoping is meaningful context.

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 filler. Content is front-loaded (what is returned first, then the downstream-id note), 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?

With no output schema, the description must convey what comes back, and it does list the three main return groups plus the demo-account scope. It stops short of describing field-level detail or ordering, which is acceptable for a read-only breakdown tool but leaves some minor 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The description correctly spends no words on arguments and instead characterizes the returned data.

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 concrete resources returned: open positions (with ids and units), pending orders, and available credit. That is specific enough for an agent to know what it gets, but it never explicitly distinguishes itself from likely overlapping siblings such as etoro_get_portfolio or etoro_get_balances.

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 one real usage hook — the position ids are the inputs that etoro_prepare_close_position needs — which is genuinely useful workflow guidance. However, there is no statement of when to prefer this over etoro_get_portfolio, etoro_get_balances, or etoro_get_pnl, so selection among siblings 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.

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?

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.