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

Annotations already disclose destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=true. The description adds the 'open order' qualification, which is useful, but it does not mention side effects, error conditions, or idempotency behavior beyond what annotations provide. The description does not contradict 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, front-loaded sentence with no fluff. Every phrase earns its place by conveying the action, the target, and the source of the parameter.

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 one-parameter destructive tool, the description covers the essential information: what to cancel and how to identify it. Annotations cover the destructive/idempotent safety profile, and there is no output schema to explain. It is slightly light on error scenarios, but not incomplete for typical use.

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 compensate. It does explain that order_id must refer to an open order and where to obtain it, which adds meaning beyond the bare schema field. However, it does not describe format, length, or validation rules.

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 uses a specific verb ('Cancel') and resource ('open order') and clearly identifies the input ('order_id') and its source ('from get_orders or place_order'). This distinguishes it from all sibling tools, especially place_order and preview_order.

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 the usage context: cancel an order that was previously obtained via get_orders or place_order. It does not explicitly state when not to use it or name alternatives, but since it is the only cancellation tool among siblings, the guidance is adequate.

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 useful behavioral context beyond annotations: it writes files to a specific directory, states the default path, and explicitly says existing files are kept. This complements the idempotentHint and non-destructive annotation without contradicting them.

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 action and destination come first, and the key conditional behavior is stated efficiently. 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 tool has no output schema and four parameters with zero documented semantics. The description covers the core save behavior but leaves unclear what the tool returns, how each filter parameter works, and how saved files are named or organized. This is incomplete for confident parameter selection.

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 explain parameters. It only clarifies document_ids behavior; source, since_days, and title_contains are left unexplained. An agent would not know how these filters affect which documents are downloaded.

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?

Clearly states the action (save), resource (documents), output format (PDF), and destination (local folder TR_DOCUMENTS_DIR). It does not explicitly name a sibling for differentiation, but the PDF-saving action makes it easy to distinguish from list_documents and other read-only 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?

Provides conditional guidance: without document_ids, all documents matching filters are saved. This helps an agent decide how to invoke it, but it does not say when to prefer this tool over alternatives or explain what 'matching filters' means for each parameter.

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 annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds a little behavioral context by specifying what state is reported (login state, account number, active trading guardrails), but it does not elaborate on side effects, freshness, or permission requirements; the openWorldHint annotation covers volatility.

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 only eight words and every word is informative, so it is concise. However, it is a fragment rather than a complete sentence, which slightly weakens clarity even though the tool's name supplies the missing verb.

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, parameterless tool with a full output schema and safety annotations, the description covers the core subject matter. It omits usage context and side effects, but those are not essential given the structured metadata; the main gap is the lack of an explicit verb or usage context.

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 schema is complete with 100% coverage and the description has no parameter meanings to add. This matches the baseline of 4 for parameterless tools.

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 the tool's subject matter ('Login state, securities account number and the active trading guardrails') but lacks a main verb, leaving the name to imply the retrieval action. It is specific enough to differentiate from sibling getters like get_cash or get_portfolio, though the purpose is stated as a noun list rather than an action.

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 use this tool versus alternatives such as get_market_status or get_available_size, no exclusions, and no mention of appropriate trading contexts. The description only lists contents, so an agent gets no help choosing it.

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 and destructiveHint=false, so the safety profile is known. The description adds only the 'currently' qualifier, suggesting a time-sensitive/current value, but does not explain data source, return behavior, or open-world characteristics beyond the annotation. No contradiction.

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, direct sentence with no fluff or repetition. It is efficient, though its brevity comes at the cost of parameter and usage detail.

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?

No output schema exists, and the description does not specify the return value's format or the meaning of 'available size' (e.g., holdings-based vs market liquidity). It also omits how exchange affects the result, leaving the agent to guess. Given the low schema coverage and missing annotations context, this is insufficient.

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%, and the description does not explain the isin or exchange parameters; it never mentions them by name or role. 'Instrument' is the only implicit link to isin, and exchange's optional/null semantics are entirely 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 description clearly frames the tool as a quantity query: 'How many units of an instrument can currently be sold.' It identifies a concrete resource (an instrument's sellable units) and is distinguishable from sibling tools such as get_quote or get_portfolio, though it does not explicitly carve out a sibling.

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 guidance about when to choose this over get_quote/get_portfolio or place_order. The phrasing implies it should be used when the agent needs a current sellable quantity, but no alternatives, prerequisites, or when-not-to-use conditions are provided.

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 the tool read-only and non-destructive; the description adds meaningful behavioral context by explaining that expired or cancelled orders automatically release their reservations. This goes beyond the structured annotations and clarifies state dynamics.

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 two concise sentences with no filler. The first sentence front-loads the core data elements, and the second adds a useful behavioral rule; every sentence contributes value.

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, read-only query tool with an output schema already present, the description sufficiently covers the returned ledger fields and the reservation-release behavior. No essential calling context 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?

The tool has zero input parameters, so schema coverage is complete and there is no parameter ambiguity to resolve. The description therefore does not need to compensate for missing parameter information.

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 (TR_BUDGET_EUR ledger) and enumerates the specific data it exposes: committed, remaining, units bought, and order fee. This distinguishes it from sibling tools like get_cash or get_portfolio, which serve different financial views.

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 the tool is for checking this agent's own budget ledger, but it does not explicitly state when to use this over siblings like get_cash or get_account_status, nor does it mention exclusions or alternative tool selection criteria.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral detail beyond that, but for a simple read-only balance lookup this is acceptable; no significant hidden behavior is expected.

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 with no filler or redundancy. Every word contributes to the meaning, making it optimally concise for a zero-parameter read-only 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?

Given the tool's simplicity, no parameters, and annotations covering read-only/open-world behavior, the description is sufficient for an agent to call it correctly. Minor details like return format or currency are not specified, but the tool's low complexity reduces the need for further elaboration.

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 parameter semantics are trivially complete. The description does not need to explain arguments, and the baseline of 4 is appropriate since there is nothing to document.

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 identifies a specific resource ('cash balance') and an implied getter action, making the tool's function clear. It does not explicitly differentiate itself from siblings like get_account_status or get_portfolio, but the resource name is specific enough for an agent to infer 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?

There is no guidance on when to use this tool compared to alternatives such as get_portfolio or get_account_status. The description only states what the tool returns, leaving the agent to infer selection criteria without explicit exclusions or recommended contexts.

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 communicate readOnlyHint and destructiveHint, but the description adds no further behavioral context such as auth requirements, rate limits, data freshness, or open-world caveats. It does not contradict 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 a single, front-loaded sentence with no filler. It communicates the core content in 10 words.

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 one-parameter read tool with annotations, this is minimally adequate: the return content is named and the parameter is inferable from the schema. However, it lacks an explicit output description and any usage context, so it is not 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?

The only parameter (isin) has 0% schema description coverage, and the description does not mention it, explain its format, or clarify that it is the lookup key. The tool name and property name carry the entire semantic 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 identifies the resource (instrument master data) and enumerates contents (name, type, exchanges, tags). It is not tautological, but it does not explicitly differentiate from similar siblings like get_stock_details.

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?

No guidance is given on when to use this tool instead of alternatives such as search_instruments, get_quote, or get_stock_details. The implied use is for instrument master data lookup, but no when-not or alternative routing is provided.

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=true and destructiveHint=false, so the safety profile is known. The description adds specifics on what factors influence the result (quote freshness, spread, TR trading status), providing useful behavioral context beyond the annotations. It does not contradict 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, well-formed sentence that front-loads the core purpose and immediately follows with the key discriminating factors. No filler, no redundancy. Perfectly concise.

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 tool is simple (2 params, read-only) and has an output schema, which presumably describes the response structure. The description captures the essential semantics. The only missing piece is parameter-level explanation, but that is a separate dimension; overall, the definition is adequate 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 description coverage is 0%, so the description must compensate. It does not explain either 'isin' or 'exchange' in any way. While the parameter names are self-evident, the description adds no guidance on format, defaults, or how 'exchange' affects the result. This is a significant gap for an optional parameter with a null default.

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-resource pair ('Whether an instrument is tradable right now') and defines the output via concrete factors (quote freshness, spread, Trade Republic trading status). This clearly distinguishes it from siblings like get_quote (price) or get_instrument (metadata), so an agent can immediately tell what this tool does.

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 it—whenever tradability is the question—by stating its focus. It does not explicitly name alternatives or exclusions, but the context is clear. No misdirection, but no explicit 'use this instead of X' guidance either, which keeps it at a 4.

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 and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by noting the news is 'in the app language, TR_LOCALE', but it does not disclose return format, pagination, or any additional limits beyond the schema.

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 15-word sentence that front-loads the core purpose ('Recent news about an instrument') and adds the locale qualifier without any fluff or redundancy.

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 read-only tool, the description conveys the core purpose and locale behavior, but because there is no output schema it leaves the return structure unspecified. It also does not clarify what 'limit' controls, which an agent would need 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 description coverage is 0%, so the description must compensate for parameter meaning. It only loosely maps 'instrument' to the isin parameter and says nothing about the limit parameter's semantics, such as whether it caps the number of news items returned.

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 ('recent news') and the subject ('an instrument'), and the tool name supplies the verb. It distinguishes get_news from siblings like get_quote, get_price_history, and get_stock_details by data type, though it does not explicitly contrast with any sibling.

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 through the purpose: an agent would call this when it needs recent news about an instrument. However, there is no explicit guidance on when to prefer get_news over related tools like get_stock_details or get_instrument, nor any 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 mark the operation read-only and non-destructive, so the description only needs to add behavioral context. It adds the key behavior that include_terminated changes the returned set from open orders to finished/cancelled/expired orders; however, it does not mention ordering, pagination, or whether duplicate/replacement orders are consolidated.

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 front-load the primary behavior and then add the parameter nuance. There is no filler or repetition of schema or annotation 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 one-parameter read-only list tool, the description gives the essential invocation semantics and result scope. It is slightly thin on output expectations and doesn't disambiguate from get_transactions, but that is a minor gap given the simple input 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?

With 0% schema description coverage, the description compensates by explaining that include_terminated=true returns finished, cancelled and expired orders instead of open ones. It covers the only parameter sufficiently for a boolean, though it leaves 'open' statuses unenumerated.

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 orders and the primary scope as open ones, with the include_terminated flag broadening scope to finished/cancelled/expired. It is distinguishable from siblings like place_order or cancel_order, though it uses a noun phrase rather than an explicit verb like 'list'.

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 that the default call returns open orders and setting include_terminated=true retrieves terminated statuses, which tells an agent how to switch modes. It does not explicitly state when to prefer get_orders over get_transactions or other order-related siblings, nor give exclusion conditions.

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 that the operation is read-only and non-destructive. The description adds only a vague behavioral point—that results are price changes over 'usual reference periods'—without defining those periods or the response format. This is acceptable but not rich extra 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 with no filler or repetition. The phrase 'usual reference periods' is vague, but that is more a precision issue than a conciseness issue.

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 parameter details, the description should clarify what the reference periods are, how exchange affects results, and what the return value looks like. It does none of these, so the agent must already know the domain-specific conventions.

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 tool description carries the full burden of explaining parameters, but it never explains isin or exchange. 'Instrument' only loosely maps to isin, and the optional exchange parameter is not addressed at all.

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 that the tool returns price changes for an instrument over reference periods, which gives a clear sense of the resource and outcome. However, it is a noun phrase rather than an explicit verb+resource statement, and it does not distinguish itself from siblings like get_price_history or get_quote.

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?

No guidance is given about when to use this tool instead of alternatives. There is no mention of get_price_history, get_quote, or get_stock_details, so the agent must infer the appropriate context solely from the tool 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?

The annotations already declare this a safe read-only operation (readOnlyHint=true, destructiveHint=false). The description adds useful behavioral details beyond annotations: it returns all positions and groups them by instrument type. It does not disclose potential output shape, pagination, or whether positions reflect current market values, but for a simple read tool with strong annotations this is adequate.

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 conveys what is returned and how it is organized. No filler or repetition; appropriate for a zero-parameter read 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 zero-parameter, read-only portfolio listing tool, the description is sufficient: it states scope ('all positions'), context ('securities account'), and output organization ('grouped by instrument type'). A more complete description might clarify what fields are included per position, but the tool is simple and annotations cover safety semantics.

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 no parameter burden for the description to carry. With 100% schema coverage and an empty properties object, there is nothing more to explain.

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 ('positions of the securities account') and the key grouping ('by instrument type'), making it distinguishable from siblings like get_cash and get_orders. However, it lacks an explicit action verb such as 'retrieve' or 'list,' so it stops just short of a perfect 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?

There is no guidance on when to use this tool instead of nearby alternatives like get_available_size, get_transactions, or get_cash. The name and description imply 'get all positions,' but no explicit context or exclusion criteria is provided.

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 that this is read-only, open-world, and non-destructive. The description adds that the result is OHLC aggregates rather than raw ticks or a single quote, which is useful context. However, it does not disclose availability limitations, default-range behavior, or exchange handling, so it adds only marginal value beyond 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 a single short sentence with no filler and the key phrase 'price history' is front-loaded. It is appropriately concise for what it contains, though it earns no extra credit because it omits context that other dimensions penalize.

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?

This is a simple read operation and the annotations cover its safety profile, but there is no output schema and the description does not clarify exchange semantics, range options, or what an OHLC aggregate response contains. An agent can probably call it with just isin and rely on schema defaults, but the description alone is not fully 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 0%, and the description only hints that the required 'isin' identifies the instrument. It says nothing about the range enum or the optional exchange parameter, so it does not compensate for the missing property descriptions. The schema's enum and default carry the actual parameter meaning, not the description.

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—price history in OHLC aggregate form—and ties it to an instrument. The verb is only present in the tool name rather than the description, and it does not explicitly contrast with siblings like get_quote or get_stock_details. Overall, it is specific and understandable, 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?

No guidance is given for when to use this tool versus get_quote, get_stock_details, or get_performance. The intended use is implied by the phrase 'price history,' but there are no exclusions, prerequisites, or alternative routing cues. This leaves the agent to infer selection from the tool 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 establish that the tool is read-only and non-destructive, so the description only needs to add behavior beyond that. It does add that the result is a current price expressed as ask/bid in EUR, but it does not disclose behavior such as market-closed handling, default exchange behavior, or whether side affects which price is returned.

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 with no filler or repeated schema information. Every word contributes meaning, and the core point is immediately visible.

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 three parameters whose descriptions are absent, this terse description leaves too much to inference, especially the role of side and exchange and the distinction from related quote/price tools. The small amount of information about the return values is helpful but not sufficient for a new agent.

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 needed to explain how isin, side, and exchange affect the result, but it does not mention any of them. It only says 'an instrument' and the output fields, adding no semantic value over the bare schema property titles.

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 that the tool returns the current order price for an instrument and names the two key output fields (priceAsk/priceBid in EUR), so an agent can tell this is a quote retrieval tool. It lacks an explicit verb and does not contrast itself with price-related siblings such as get_price_history or wait_for_price, which keeps it below the top score.

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 get_quote instead of get_price_history, get_stock_details, or wait_for_price. The word 'current' implies a point-in-time snapshot, but no exclusions, alternatives, or context are stated.

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 and destructiveHint=false, so the side-effect profile is covered. The description adds a useful contextual trait: the data is Trade Republic's own editorial company details rather than user data. However, it does not discuss availability, staleness, or response behavior, so the added value is modest.

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 with no filler. The parenthetical efficiently enumerates the return content, and every word contributes to the tool's meaning.

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 tool is simple with one parameter, and annotations cover the safety profile. However, with no output schema, the description's content list is the only return-value guide, and the lack of usage or parameter detail leaves some ambiguity. The parenthetical helps but does not fully compensate for those 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 schema has one required ISIN parameter with 0% description coverage, and the description does not explain its format, validity, or exact role beyond tying it to 'a stock.' Since the schema only supplies the title 'Isin', the description needed to compensate for the missing parameter documentation and did not.

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 ('company details for a stock') and the content it contains ('description, key figures, analyst ratings'), so an agent can tell what the tool does. It does not use an explicit retrieval verb and does not contrast with similar siblings like get_instrument or get_quote, so it stops just short of a top score.

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 use this tool versus alternatives such as get_quote, get_instrument, or get_news, nor any mention of prerequisites or context. The phrase 'stock details' implies a use case, but with 21 siblings an agent is left to infer the appropriate choice.

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 indicate readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds the pagination behavior (cursor-based `after`) and that it returns a timeline, which is useful context beyond the annotations. It doesn't cover open-world nuances (e.g., data may change between calls) beyond the annotation hint.

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 one sentence, dense with information: what it retrieves, it's a timeline, and how to use the cursor for pagination. No fluff, front-loaded with the key purpose.

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 tool is simple (one optional parameter) and the description covers the core purpose and the only parameter's semantics. It doesn't mention return format, but without an output schema and given the simplicity, the description is mostly complete. The only minor gap is not specifying what 'transactions' includes (e.g., types), but that's not critical for basic use.

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 explain the parameter. It does explain `after` as a cursor from a previous answer, which is essential for correct invocation. This adds meaning beyond the schema's minimal definition even though the schema is simple.

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 retrieves 'Latest account transactions (timeline)', identifying the resource (transactions) and the temporal scope. It distinguishes itself from siblings like get_orders or get_portfolio by specifying 'transactions' and timeline, though it doesn't explicitly name a sibling alternative.

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 tells when to use it (to get latest transactions) and how to paginate ('Pass the cursor from a previous answer as `after` for older ones'). It implies this is the go-to tool for transaction history, but doesn't explicitly state when not to use it or mention alternatives like get_orders.

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 the tool as read-only and non-destructive, so the description does not need to restate that. It adds useful behavioral context about time-window filtering and source filtering, but does not describe output shape, pagination, or document availability 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?

The description is compact and front-loaded with the core behavior, followed by parameter guidance. No filler or redundant restatement of annotations or schema exists.

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 adequate for calling the tool with correct parameters, and annotations cover safety. However, there is no output schema and the description does not indicate what the returned document list contains, whether it includes metadata or download links, or how it relates to download_documents.

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%, but the description compensates fully: since_days is explained as the lookback window, source is given allowed values (all | postbox | transactions), and title_contains is described with a concrete example. This is strong beyond the bare 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?

The description clearly states that the tool lists documents within a time window and names the document categories (account statements, trade confirmations, etc.). It is distinct from siblings like download_documents by verb and resource, though it does not explicitly differentiate itself from any sibling.

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?

No when-to-use or when-not-to-use guidance is provided. The description explains parameters but never tells the agent when to choose list_documents over alternatives such as download_documents or get_transactions.

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 mark the action as destructive and non-idempotent, and the description adds meaningful context: it places real money, requires a previously previewed order, and rechecks guardrails. This goes beyond what annotations alone convey without contradicting them.

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 short, information-dense sentences. The real-money warning is front-loaded, followed by the essential usage constraint and safety re-check. Every sentence earns its place with no repetition.

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 one-parameter action with a rich annotation set and an output schema, the description covers the prerequisite, the parameter source, and the safety implications. Nothing critical is missing 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 description coverage is 0%, but the description compensates for the single parameter by explaining that confirmation_id comes from preview_order, is single-use, and expires. This gives the agent the key semantic constraints it needs to supply a valid 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 states a specific verb and resource: 'Send a previously previewed order to Trade Republic.' The 'REAL MONEY' warning and the reference to confirmation_id clearly distinguish this execution step from preview_order and cancel_order.

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 defines when the tool can be used: only with a confirmation_id from preview_order, and notes that the id is single-use and expires. It also warns that guardrails are rechecked before sending, giving the agent concrete preconditions and expectations.

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 and destructiveHint=false, and the description reinforces 'WITHOUT sending it' without contradicting anything. It adds useful behavioral detail: guardrail validation, single-use confirmation_id, and expiry/order-type constraints, going beyond the annotation coverage.

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 four tight sentences with the core behavior front-loaded first. Every sentence adds a distinct piece of information: non-sending behavior, parameter rules, and the produced confirmation_id. No filler exists.

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 validation tool, the description covers the main conditional relationships needed to form a valid call. It does not explain exchange or sell_fractions semantics, but these are reasonably inferable from the schema, and the output schema handles return details. The description is strong enough for an agent to invoke correctly in most scenarios.

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 compensate. It does for the most confusing parameters: size allows fractions, limit_price is required for limit, stop_price for stopMarket, expiry gtd needs expiry_date, and market orders only support gfd. A few self-explanatory params (isin, side, exchange, sell_fractions) are left to the schema, but the critical conditional semantics are covered.

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 clear verb ('Validate an order') and resource, and explicitly contrasts with sending it via place_order. It also names the output artifact (single-use confirmation_id), making the tool's role unmistakable.

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 makes the intended usage obvious: validate against guardrails without sending, then use the returned confirmation_id with place_order. It does not explicitly list when not to use it, but the context strongly implies it is the pre-send check sibling to place_order.

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 and destructiveHint=false, so the safety profile is covered. The description adds the narrow scope of 'tradable instruments' and the accepted search keys, but it does not disclose behavior such as result limits, fuzzy vs. exact matching, or whether multiple matches are returned.

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 sentence with no filler. Every word contributes to the core meaning, and the most important information (what is searched and how) 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?

The tool is simple, annotations are present, and the schema carries parameter names and enum values. However, the description omits return format/pagination and the surprising asset_type default, so an agent has enough to call the tool but not enough to reliably interpret or constrain 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 description coverage is 0%, so the description must compensate. It does explain that query can be a name, ticker, or ISIN, but it says nothing about asset_type, including the fact that it defaults to 'stock' and would silently restrict a search for bonds or crypto unless explicitly changed.

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: 'Search tradable instruments' by name, ticker or ISIN. This is clear and distinct from sibling tools like get_quote or get_portfolio, but it never explicitly names a sibling or contrasts itself with get_instrument, so sibling differentiation is only implicit.

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 about when to choose this tool over siblings such as get_instrument, get_stock_details, or get_quote. It is only a bare action statement; no prerequisites, use-cases, or exclusions are given.

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, so the agent knows this is a safe read operation. The description adds the maximum wait time of 300 seconds and the requirement for a fresh two-sided quote, which is useful behavioral context. However, it does not disclose what happens on timeout, whether the tool returns the quote or just a success/failure, or what 'fresh' means precisely. With annotations covering safety, a 3 is appropriate.

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 concise sentence that front-loads the action and condition. It is appropriately short and wastes no words. However, it is so brief that it sacrifices necessary detail; the conciseness is good but not backed by sufficient content.

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?

While an output schema exists, the description does not explain what the tool returns, what happens on timeout, or how 'fresh' and 'two-sided' are determined. For a tool that waits and potentially blocks, the agent needs to know behavior on failure and success. The description is incomplete for safe and correct invocation, even with annotations covering read-only safety.

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 0% description coverage, and the tool description provides no explanation of the parameters (isin, exchange, timeout_seconds). The description mentions a max of 300 seconds, but it does not link that to the timeout_seconds parameter or clarify its default of 55. The description completely fails to compensate for the lack of schema coverage, leaving parameter meaning entirely to the agent.

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 action (wait), a resource (instrument), and a precise condition (fresh two-sided quote). It is clear what the tool does, but it does not explicitly differentiate itself from the sibling wait_for_price, which could be a similar waiting operation. Still, the purpose is 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?

There is no guidance on when to use this tool versus alternatives like get_quote, wait_for_price, or get_market_status. The description implies use when a fresh two-sided quote is required, but it does not state when not to use it or point to a sibling for alternative scenarios. The usage context is left entirely to the agent to infer.

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 and destructiveHint, so the description adds value by specifying the timeout limit (max 300 s) and the return condition ('when the level is reached or the timeout expires'). This goes beyond the static schema and provides useful behavioral context for the agent.

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 and front-loaded. Two sentences convey the core behavior and termination condition without any redundant wording. Every word adds meaning, making it highly efficient.

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?

Despite having an output schema, the description leaves critical gaps: it doesn't explain what happens if both above and below are null, whether they can conflict, or the meaning of the `field` parameter (last/bid/ask). The agent may misuse the tool or fail to set parameters 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?

With schema description coverage at 0%, the description must compensate by explaining parameter meaning. It only mentions `above` and `below` in context, but fails to clarify that they are optional, mutually usable, or that other parameters like `field` and `exchange` exist. The agent gets almost no help in understanding how to set the correct input.

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 action ('Watch the live price') with a clear condition ('until it reaches `above` or falls to `below`') and a termination condition. It clearly differentiates from siblings like get_quote or get_price_history by focusing on waiting for a price level, not just retrieving data.

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 guidance on when to use this tool versus alternatives such as get_quote or wait_for_market. The purpose implies a waiting behavior, but no mention of scenarios where a simple quote fetch or market status check would be more appropriate, or how it relates to the order placement flow.

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