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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context: it explains what each report mode returns, notes the default report is summary, and describes the timeseries contents. No contradictions with 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?

Three sentences with no filler: purpose first, then the two report modes, then period selection. Every sentence adds distinct necessary information and is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description gives a reasonable high-level view of what each report returns. However, it doesn't specify behavior when neither standardPeriod nor a date range is provided, nor the interaction rules between those parameters. These are minor gaps for an otherwise clear 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 only 67%, with report and standardPeriod lacking schema-level descriptions. The description compensates by explaining the enum meanings and the choice between standardPeriod and explicit dates. It does not dwell on accountKey/wholeClient, but those already have schema descriptions.

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 'Historical account performance' with explicit verb+resource, and distinguishes two report modes with distinct outputs. It differentiates from siblings like get_account_summary by focusing on historical data rather than current summary.

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 context is implied by 'Historical' and the mention of period selection, but there are no explicit when-to-use or when-not-to-use statements, nor named alternatives. The description never excludes get_account_summary or get_balances, leaving the agent to infer when this tool is preferred.

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, and non-destructive behavior. The description adds that the data is about the logged-in user and includes account fields, which is useful context, but it does not disclose additional behavioral details such as auth requirements or response shape beyond the listed 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?

Two sentences, no filler. The purpose is front-loaded and the usage directive is placed immediately after, making the description easy to parse and act on.

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-parameter bootstrap tool, this is complete: it states what is returned, names the key field used by other tools, and explains when to call it. The annotations cover safety characteristics and there is no output schema requirement to compensate for.

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 has zero parameters, so the schema already covers everything. The description adds no parameter-specific detail, but none is needed; the baseline of 4 is appropriate.

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 clearly identifies the resource: basic information about the logged-in user, the client entity, and all accounts, including concrete fields like AccountKey, currency, and type. It is clear and distinct from balance/position/order tools, though it does not explicitly name sibling tools in the purpose statement.

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 explicitly tells the agent to call this first and explains that other tools take an optional AccountKey from here. This is a strong, actionable usage directive that reduces ambiguity about sequencing and data flow.

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 the description's safety burden is low. The description adds useful scope behavior (default account vs whole client) and enumerates returned data, but it does not describe aggregation details, error conditions, or response shape. This is acceptable but not rich behavioral 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?

The description is a single compact sentence that front-loads the main returned fields and then states the scoping option. Every part earns its place, with no redundancy or 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 two-parameter read-only tool, the description covers the returned categories and the account-scoping behavior, and it links to get_account_summary for account-key context. No output schema exists, but the field enumeration gives a workable picture of the response despite the absence of detailed return-structure documentation.

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%; both accountKey and wholeClient are already documented in the schema. The description's mention of 'default account' and 'whole client' largely paraphrases the schema without adding new semantic meaning. 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?

The description clearly identifies the resource (balances) and enumerates the specific data returned: cash balance, account value, margin, unrealised P&L, and position/order counts. It also distinguishes between a single account and the whole client, making the tool's purpose recognizable even without an explicit comparison to sibling 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?

The description explains the main usage decision: one account by default or the whole client via wholeClient, and points to get_account_summary for account keys. It does not explicitly say when to avoid this tool in favor of siblings like get_positions or get_orders, but the clear scoping guidance covers most practical use.

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?

The description adds significant behavioral context beyond the annotations: it notes volume is only available where applicable, FX returns bid/ask OHLC, the max bars per call (1200), and how to page further back. These details are not in the annotations and are crucial for correct invocation and interpretation.

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 compact, using only two sentences. It front-loads the core purpose, then efficiently lists horizon values and paging behavior, with no wasted words or redundant 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?

The description covers the main return content (OHLC, volume, FX specifics), the bar-size enumeration, and paging mechanics, which are sufficient for a read-only tool. It does not explicitly describe the exact response structure (e.g., array of bar objects), but that is reasonably implied and not critical given the lack of an output 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?

The description provides essential meaning for the horizon parameter, which is completely undocumented in the schema, by listing all valid minute values and their daily/weekly/monthly equivalents. It also clarifies paging behavior with time and mode, adding value beyond the schema's brief descriptions.

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 clearly identifies the tool as returning historical price bars (OHLC, volume) and explains the horizon meanings, which is specific and unambiguous. However, it does not explicitly distinguish this tool from sibling get_instrument_price, though the title 'Historical OHLC bars' and the focus on historical data imply the difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage guidance for paging (pass time + mode) and explains horizon values, but it does not mention when to use this tool vs alternatives like get_instrument_price. There is no explicit 'use this for historical data, use that for current price' guidance, leaving the agent to infer the distinction from 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, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful context about the returned content, including trading sessions and trade size fields, but does not detail response behavior beyond that. No contradiction exists.

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 front-loaded sentence. It begins with the core purpose and then enumerates the relevant specification fields without redundant wording.

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 read-only reference-data lookup, the description gives enough content detail to convey what the tool returns. It relies on the schema for parameter prerequisites and defaults, which is acceptable since schema coverage is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents uic, assetType, and includeTradingSchedule. The description lists output content rather than parameter semantics, so it adds little beyond the schema; 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 clearly identifies the resource (one instrument) and the kind of data returned (contract specification: currency, exchange, tick size, lot size, trading sessions, etc.). It is specific enough to be distinguishable from price or chart tools, though it does not explicitly name sibling alternatives.

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 usage context is implied: after obtaining a uic and assetType, an agent would call this tool to fetch static reference data. However, the description does not explicitly state when to use this tool versus search_instruments, get_instrument_price, or other siblings.

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, and destructiveHint=false. The description adds value by listing the returned fields (bid, ask, mid, etc.) and explicitly stating 'Read-only; never creates an order,' reinforcing safety. It also mentions the delayed-price flag, adding context about data currency without contradicting 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?

A single sentence that front-loads the purpose ('Current informational quote') and then lists the fields. It's efficient with no filler, though slightly long; still, every word 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 a simple two-parameter tool with no output schema, the description adequately lists the returned data points, giving an agent a clear expectation of the response. It doesn't cover error handling or edge cases, but that's not essential for this straightforward quote 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?

The input schema has 100% coverage, with both parameters (uic and assetType) fully described including examples. The tool description adds no additional parameter semantics, 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?

The description clearly states it provides a current informational quote with specific fields (bid, ask, mid, etc.), distinguishing it from account/history siblings like get_positions or get_orders. The explicit 'never creates an order' further clarifies its non-action purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for obtaining current price data, and the context makes it clear this is for quotes versus historical data (get_chart_data) or instrument details (get_instrument_details). It doesn't name alternatives explicitly, but the purpose is unambiguous, so it meets the 'clear context, no exclusions' bar.

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, and destructiveHint=false, so the safety profile is fully covered. The description adds the behavioral detail that the server cannot place, modify, or cancel orders, which reinforces the read-only nature. It does not disclose pagination, ordering, or whether the list is sorted, but with strong annotations the bar is lower and the description adds some 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 sentences with no filler. The core purpose and the read-only constraint are front-loaded, and every sentence adds value. The description is appropriately sized for a simple list 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?

For a read-only list tool with no required parameters and full schema coverage, the description is nearly complete. It covers the purpose, the fields returned, and the behavioral constraint. It does not describe the output format or pagination, but there is no output schema and the tool is simple; the missing details are minor for an agent deciding whether to call 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?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description does not add extra meaning about the parameters beyond what the schema provides. Baseline 3 is appropriate when the schema carries the full parameter documentation burden.

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 clearly states the tool lists currently open/working orders and enumerates the fields returned (type, amount, price, status, duration). It also explicitly distinguishes itself as a viewing tool, which differentiates it from any order-management siblings. The title 'Open orders (view only)' reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says it is strictly a viewing tool and that the server cannot place, modify, or cancel orders, which implies it should not be used for order management. It does not explicitly name alternative tools for placing/modifying/canceling orders, but among the listed siblings there are no order-management tools, so the exclusion is clear enough. The accountKey parameter description references get_account_summary for the default account list, providing some cross-tool guidance.

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, and non-destructive behavior, so the bar for additional context is lower. The description adds meaningful behavior beyond those hints: it explains that view='individual' lists every position and view='net' nets positions per instrument, and it enumerates the response 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?

Two sentences with no filler: the first states the resource and key fields, the second explains the view parameter's behavior. Every word earns its place, and the main purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with rich annotations and fully documented parameters, the description covers the return fields and view semantics. It does not mention pagination or empty results, but those are not critical for a straightforward positions listing and the output schema is absent, so the description carries the return-value burden adequately.

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 baseline is 3. The description adds genuine value by explaining the effect of the view enum values ('lists every position' vs 'nets positions per instrument'), which is not fully captured in the schema's one-word descriptions.

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 clearly states the resource (open positions) and the returned fields (open price, current price, exposure, P/L), making the tool's function obvious. It does not explicitly name or contrast a sibling tool, but the resource is distinct enough from get_balances, get_orders, and get_transactions that an agent can tell them apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use this tool versus alternatives, such as get_orders or get_balances. It only describes what the tool returns and the view parameter behavior, leaving the selection decision entirely to inference from the resource name.

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, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond the annotations by explaining what each type contains and that the date range defaults to the last 30 days. No contradiction exists between the description and 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?

The description is three tight sentences that front-load the core concept ('Historical transaction log') and then efficiently enumerate the type variants and the default time window. Every sentence earns its place, and there is no redundant repetition of schema property names.

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 responsibility for explaining what the tool returns, and it does a good job by describing the categories of records. It does not specify the response shape or ordering, and it leaves accountKey/wholeClient behavior to the schema, but for a read-only list tool the provided context is largely sufficient.

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%, which sets a baseline of 3, but the description meaningfully enriches the 'type' parameter by spelling out the three enum values and giving concrete examples like deposits, withdrawals, dividends, fees, and settlements. It also clarifies the default date behavior, which the schema does not state.

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 clearly identifies the resource as a historical transaction log and enumerates the three distinct transaction types (trades, bookings, order_activities), which gives the agent a concrete sense of what this tool returns. However, it lacks an explicit verb like 'retrieves' or 'lists' and does not differentiate itself from the sibling get_account_history, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool by defining each type and stating that trades is the default, and it communicates the default 30-day window. It does not explicitly name alternatives or state when not to use this tool versus get_account_history or get_orders, so the guidance is serviceable but not explicit.

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 this as read-only, idempotent, and non-destructive. The description adds useful context by listing returned fields and mentioning that other tools need the UIC + AssetType, but it does not disclose further behavioral traits such as match semantics, result limits beyond the schema's top parameter, or ordering 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 focused sentences with no filler: the purpose is front-loaded, the returned fields are listed clearly, and 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?

The description is complete enough for selecting and invoking the tool: it explains what the tool returns and why it matters for other market-data tools. Minor gaps remain around includeNonTradable and explicit routing to sibling tools, but the annotations and schema carry much of the load.

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 80%, so the schema already documents most parameters. The description adds no parameter-level detail beyond the schema and leaves the undocumented includeNonTradable parameter unaddressed, so it meets but does not exceed the baseline.

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 specific verb and resource: 'Look up instruments by name, ticker or ISIN' and clarifies the key output (Saxo UIC + AssetType). It also distinguishes this tool from sibling market-data tools by explaining that those tools depend on these identifiers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly positions the tool as the lookup step that feeds other market data tools, giving an agent a strong signal for when to invoke it. It does not explicitly name alternative tools or state when not to use them, but the intended role is clear.

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