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

With no annotations, the description carries the transparency burden. It discloses meaningful behavior: transactions are flagged as regular, grouped by counterpart and direction, and enriched with detected payment interval and average amount. It does not mention scan limitations or heuristic caveats, but it goes beyond a bare 'list transactions' statement.

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, front-loaded with the operation, followed by output grouping and then concrete example use cases. Every phrase earns its place; no fluff or 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?

The description gives enough about the return shape (grouped by counterpart/direction, interval, average amount) for a tool with no output schema. It covers the main use cases and parameter intent. It could mention that scanning is capped (perPage up to 500), but that lives in the schema, so the description is adequately 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 coverage is 100%, so the schema already documents all five parameters well. The description adds domain context like 'salary, rent, subscriptions' to the direction semantics, but that mostly mirrors the enum descriptions. It does not substantially extend parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'List transactions flagged as regular' and immediately enumerates examples (salary, rent, subscriptions, standing orders). It also states the output grouping and computed fields, clearly distinguishing it from a generic raw transaction list such as list_transactions.

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 provides concrete use cases: 'Use this to answer "what subscriptions do I have?" or "what are my fixed costs?"'. This is clear guidance on when to invoke the tool. It does not explicitly name alternative tools or exclusions, but the context is strong enough.

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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It adds the key constraint that only cash accounts are supported and depots are not, which is valuable. However, it does not disclose return format, error behavior for invalid IDs, pagination, or whether it is read-only (though 'Get' implies it).

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 sentences, front-loaded with the main purpose and followed by the key constraint. No redundancy or filler; 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?

The description sufficiently explains the tool's scope for a 3-parameter, no-output-schema tool. It covers the account type restriction and date range. However, it leaves unspecified what the returned balance history looks like (e.g., daily balances, currency), which would be useful given no 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?

Schema description coverage is 100%, with each parameter (id, to, from) having clear descriptions. The tool description adds minimal extra parameter meaning beyond restating 'cash accounts' and 'date range', 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 uses a specific verb ('Get') and resource ('balance history') with clear scope ('one or more cash accounts over a date range'). It also distinguishes itself from siblings by explicitly limiting to cash accounts (type '02_cash') and excluding depots, which sets it apart from tools like get_portfolio_valuation or list_accounts.

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 states when the tool is applicable ('Works only with cash accounts... not depots'), giving a strong contextual constraint. It does not explicitly name alternative tools for depot balances, but the exclusion and sibling list imply when not to use it, so it earns a 4 rather than a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the non-obvious sign convention (inflows positive, outflows positive, net = income − spending), which adds value. However, it lacks disclosure of other potentially important behaviors such as data freshness, currency, or whether transfers are excluded (though the schema notes a default), leaving some ambiguity.

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 concise and front-loaded with the core purpose. The first two sentences are slightly redundant ('Monthly income vs. spending' and 'Answers ...'), but the third sentence adds essential sign convention detail. Overall, it is compact with minimal waste.

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?

Since there is no output schema, the description should explain what the response contains. The phrase 'Monthly income vs. spending' is ambiguous about whether the result is a monthly breakdown or a single aggregate over the date range. This omission could lead an agent to incorrectly assume the return format, making the description inadequate for a tool with multiple parameters and no structured output 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?

The schema covers 100% of the parameters with descriptions, so the baseline is 3. The description does not significantly augment the parameter semantics; it only implies that the date range and cash accounts are relevant. It does not elaborate on how excludeTransfers affects results or how accountId scopes the data beyond what the schema already provides.

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's function: summarizing monthly income vs. spending for cash accounts. It uses a specific verb and resource, and the sign convention detail further clarifies exactly what is measured, distinguishing it from sibling tools like get_account_balances or get_savings_rate.

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 use case ('Answers how much did I earn and spend? over a period') but does not explicitly state when to use this tool over alternatives or mention any exclusions. There is no comparison to sibling tools that might also relate to cash accounts, so the guidance is implicit rather than 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?

With no annotations, the description carries the full burden. It discloses the scope ('this year's', 'current holdings') and output fields (expected and received payouts, dates, amounts, yields). However, it does not disclose data freshness, per-account vs. aggregate behavior, or potential edge cases, leaving some ambiguity.

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 that names the tool's purpose, scope, output content, and a use case. Every word earns its place with no filler.

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

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

Given the simple one-parameter schema and no output schema, the description covers the key elements: what is returned (dates, amounts, yields), the scope (this year, current holdings), and the intended use. Minor omissions (e.g., whether results are combined across accounts or per-account) prevent a 5.

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 fully describes the only parameter (accountIds as 'Depot ID(s) to include') with 100% coverage. The description adds no additional parameter semantics, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('dividend calendar for current holdings'), then elaborates with expected and received payouts, dates, amounts, and yields. It clearly distinguishes from siblings like get_dividend_history (historical) and get_portfolio_yield (yield only) and includes a concrete use case: 'when are my next dividend payments?'

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 a clear use case ('Use this for when are my next dividend payments?') which tells the agent when to invoke it. However, it does not explicitly name alternatives or state when NOT to use it, so it misses the 'exclusions' component for a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals aggregation behavior (per-year totals, per-month breakdown for the current year) and distinguishes gross vs. net amounts. This goes beyond a generic 'get dividends' statement, but it omits details like return format or how cutoffDate interacts with the year grouping, so it is not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, followed by a relevant usage example. Every word earns its place, with no redundancy or fluff.

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 lack of an output schema, the description adequately conveys the return structure (per-year gross/net, with a per-month breakdown for the current year). It also provides enough context to differentiate from sibling tools. Minor gaps remain about sort order and handling of multiple accounts, but the description is reasonably complete for a simple dividend history 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 description coverage is 100%, so the baseline is 3. The description does not add new meaning to the parameters beyond what the schema already provides (accountIds and cutoffDate). It mentions 'current year' but that is not parameter-specific, so no extra value is added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Get dividend income per year (gross and net)', with an additional detail about per-month breakdown for the current year. It distinguishes itself from sibling tools like get_dividend_calendar (upcoming dividends) and get_portfolio_yield (percentage yield) by focusing on historical income amounts.

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 a concrete use case: 'Use this for how much dividend income did I get in 2024?' This gives clear context for when to invoke the tool. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.

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

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

Without annotations, the description carries the full burden of behavioral disclosure. It does clarify the mode behavior (today's change vs total return), but it doesn't mention what the output looks like, sorting order, or edge cases. The description is adequate but not rich in behavioral context beyond the obvious.

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 sentences with the core action front-loaded ('Get the top gainers or losers'). Every word earns its place, and it's appropriately compact for a simple 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?

Despite having no output schema and no annotations, the description is minimal. It describes the main use case and the two modes, but it doesn't mention anything about the return format or how account filtering works. For a tool with three parameters and no output schema, a bit more context would be helpful, but it's not critically incomplete.

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% description coverage, so the baseline is 3. The description reinforces the mode meanings in plain language but doesn't add new information about 'max' or 'accountId'. No redundancy or contradiction, but no added value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the top gainers or losers' with a specific verb and resource. It further distinguishes two modes ('by today's change' or 'by total return since purchase'), which is specific and differentiates it from sibling tools like get_portfolio_performance or get_quotes.

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 a clear usage guideline: 'Use this for 'best/worst performers'.' This gives a concrete context for when to apply the tool. However, it doesn't explicitly mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

No annotations are provided, so the description must disclose behavioral traits. It implies a read-only aggregation but does not explicitly state read-only status, return format, or any limitations (e.g., whether cash is included, how accounts are aggregated). The description lacks behavioral depth beyond its purpose.

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 concise sentences. The first states the action and scope; the second provides practical use cases. No wasted 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?

The tool is simple with two well-described parameters and no output schema. The description covers purpose and use cases, and the schema covers parameters. It could benefit from a hint about response format, but overall it is sufficiently complete for this tool's complexity.

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 covers both parameters with descriptions, including the dimension enum and accountIds default behavior. The description does not add additional parameter details but the schema already provides full coverage, so baseline 3 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 states the tool breaks down portfolio market value by region, industry, or asset type. It includes example use cases that distinguish it from sibling tools like get_portfolio_valuation or get_risk_metrics.

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 clear usage context with example questions ('how diversified am I?', 'what's my US exposure?'), but it does not explicitly name alternative tools or state when not to use this tool.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It states it returns a timeseries, which is useful, but does not mention read-only nature, pagination, date handling nuances, or any limitations. It is not misleading, but it only minimally addresses behavior beyond the tool's name.

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. The first sentence states the core function, the second provides a use case. No filler content, front-loaded and 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?

The tool is moderately simple with 4 parameters and no output schema. The description gives a clear purpose and usage context, which is sufficient for an agent to decide when to call it. It could be more complete by describing the timeseries structure, but the overall context is adequate given the sibling tools.

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 75% (3 of 4 params have descriptions), so the baseline is 3. The description adds little parameter-specific detail beyond 'over a date range', which aligns with startDate/endDate but does not clarify interval or accountIds semantics. It does not offset the gap for interval.

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 returns a TWROR timeseries for the portfolio over a date range. It distinguishes from siblings like get_portfolio_valuation or get_portfolio_yield by specifying 'performance' and the use case. The verb 'Get' is specific and the resource is well-defined.

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 explicitly says 'Use this to answer "how did my portfolio perform this year / last 5 years?"', which provides clear context for when to use it. It does not include when-not-to-use or alternative tool names, so it falls short of a 5.

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

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

The description states that the tool returns current total value and optionally history when 'from' is given, which is useful behavioral context. However, it does not disclose other behavioral traits such as whether cash is included by default, how interval affects the history, or the response format. Since no annotations are provided, the description carries the full transparency burden and only partially fulfills it.

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 sentences, front-loaded with the core function and followed by a concrete use case. Every sentence earns its place, with no redundant or filler 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?

For a tool with four parameters, no annotations, and no output schema, the description provides a clear purpose and use case, which is sufficient for basic invocation. It does not describe the response shape or the full behavior of history, but the schema fills in parameter-level details. The description is reasonably complete, though not exhaustive.

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% with detailed descriptions for all four parameters. The description itself adds minimal parameter-specific meaning, only referencing 'from' without further detail. Baseline of 3 is appropriate because the schema already fully documents the parameters.

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's function: to get the current total value of one or more depots, and optionally historical value when 'from' is set. It uses specific verb+resource phrasing ('Get the current total value') and the use-case phrase 'what is my portfolio worth (today / over time)?' distinguishes it from sibling tools like get_account_balances or get_portfolio_allocation.

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 explicitly provides a usage context: 'Use this for what is my portfolio worth (today / over time)?' This tells an agent when to invoke the tool. However, it does not mention alternatives or exclusions, so it lacks the full comparative guidance seen in the highest-scoring examples.

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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It reveals what outputs are produced (yield on current value and invested capital, plus CAGR) but does not explicitly state that this is a read-only operation with no side effects, nor does it mention any data access or permission requirements. For a 'get' tool this is somewhat implied, but the description could be more explicit, especially since annotations are absent.

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 sentences: the first states the core functionality and output, the second gives a concrete use-case trigger. It front-loads the verb and resource, is free of fluff, and every phrase adds 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?

The tool has no output schema, so the description's mention of 'yield per year (on current value and on invested capital) plus the dividend CAGR' is essential and sufficient for an agent to understand the return shape. It also clearly distinguishes this tool from dividend-history or performance tools. The description could momentarily mention that cagrYears and calculationType affect the returned metrics, but the schema covers those.

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 already provides 100% description coverage for all three parameters (accountIds, cagrYears, calculationType). The description adds context about yield calculation basis but does not add extra meaning for the parameters themselves. The baseline of 3 applies because the schema fully documents the parameters, and the description's marginal addition is limited.

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 a specific verb ('Get') and resource ('portfolio's dividend yield per year') plus additional detail ('on current value and on invested capital') and the dividend CAGR. This distinguishes it from sibling tools like get_dividend_history (which fetches dividend events) and get_portfolio_performance (which covers broader performance metrics).

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 explicitly provides a use case: "Use this for 'what's my dividend yield?'." This gives clear context for when to invoke this tool, although it does not explicitly mention when not to use it or list alternatives. It could be stronger with exclusion criteria, but the use-case phrasing is helpful.

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?

With no annotations, the description must inform the agent about the tool's behavior. It does indicate the output (last price, daily change) and the source of inputs, but it does not disclose error handling, rate limits, or whether it is read-only beyond the 'Get' verb. This is adequate but minimal.

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 concise sentences that front-load the primary purpose and provide a needed prerequisite. No wasted 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 straightforward tool with 3 parameters and no output schema, the description adequately covers what is returned and how to obtain inputs. It could mention response structure or error behavior, but it is not incomplete for the tool's simplicity.

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 baseline is 3. The description adds value by explaining the provenance of securityIds and quoteProvider ('Get the IDs from search_symbols first'), linking them to a concrete workflow, which exceeds the 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 clearly states the tool's function: 'Get current quotes (last price, daily change) for securities by security ID.' It specifies both the action and the resource, and the mention of security ID differentiates it from sibling tools like search_symbols or get_security_fundamentals.

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 clear usage context by instructing to 'Get the IDs from search_symbols first,' establishing a prerequisite workflow. However, it does not explicitly mention when not to use this tool or offer alternatives, so it lacks the full 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output structure (per year, gross/net, tax refunds), which is useful, but it doesn't mention any side effects, permissions, data lag, or other behavioral caveats. As a read-only 'get' operation, the behavior is implied, yet the description adds limited context beyond what the name suggests.

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 sentences, front-loaded with the main verb and resource, and every clause adds value. It efficiently conveys the output scope and usage intent without unnecessary 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?

The tool is simple with one parameter, and the description adequately covers its functionality and return categories. It doesn't explain the exact response format, but no output schema is provided, and the description gives a good high-level view. It could mention the requirement of accountIds, but that's already in the schema. Overall, it's complete for the tool's simplicity.

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%, with the only parameter 'accountIds' described as 'Depot ID(s) to include.' The description adds no additional parameter semantics, but the schema fully documents the parameter. Baseline 3 is appropriate since the schema handles the 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's purpose with a specific verb and resource: 'Get realized gains per year' and details the breakdown into categories (trading, dividend, interest, other). This distinguishes it from sibling tools like get_dividend_history or get_portfolio_performance, which focus on different financial metrics.

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 concrete use cases: 'what did I realize this year?' and 'tax questions.' This implies when to use the tool, but it doesn't explicitly mention alternatives or when not to use it. The guidance is clear but lacks exclusionary 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?

No annotations are provided, so the description carries the transparency burden. It discloses that metrics are annualized and can be broken down per investment, adding meaningful behavioral context. However, it omits output format, calculation specifics, or any caveats about data history or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One efficient sentence that front-loads the core function, followed by a parenthetical scope and a practical use-case phrase. No filler or repetition; every word contributes purpose or usage context.

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 5 optional parameters, no output schema, and no annotations. The description covers the primary purpose and breakdown behavior but does not state what the returned metrics structure looks like or how parameters like interval and from affect results. This leaves an agent with some gaps 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?

The schema covers 80% of parameters with descriptions, and the description adds the meaningful relationship of breakdown=true to per-investment output. It does not explain default intervals or date handling, but the schema's descriptions and enums handle most parameter meaning.

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 ('Get') and identifies the resource ('annualized risk (volatility) and return metrics'), with clear scope: whole portfolio or per investment via breakdown=true. This clearly distinguishes it from sibling tools like get_portfolio_performance or get_portfolio_valuation.

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 an explicit use case ("Use this for 'how risky is my portfolio?'") that signals when to choose this tool. It does not mention exclusions or alternatives, but the use-case phrasing gives sufficient 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?

No annotations are provided, so the description must carry behavioral disclosure. It adds useful interpretive context ('Higher is better; negative means the user spent more than they earned') and notes that it uses cash flow analytics, but it does not disclose side effects, permissions, data limitations, or return format. This is adequate but not exhaustive.

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 sentences, front-loaded with the core formula and purpose, and adds a meaningful interpretation note without redundancy. Every sentence earns its place; no filler or 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?

Given the schema fully documents parameters and there is no output schema, the description provides the essential formula and interpretation. It could mention the output format or edge cases (e.g., zero income), but overall it gives enough context for an agent to select and invoke the tool correctly.

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

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

The input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description does not add parameter-specific details beyond the formula, but it does mention income and spending which map conceptually to the analytics, providing mild semantic reinforcement.

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 computing the savings rate, provides the exact formula, and states it expresses the result as a percentage. This distinguishes it from sibling tools like get_cash_flow_summary or list_transactions by focusing on a derived metric.

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

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

The phrase 'over a period' implies the need for a date range, and the formula implies a use case, but the description does not explicitly state when to use this tool over alternatives or mention any exclusions. It offers some situational context but lacks explicit guidance or alternative references.

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?

No annotations are provided, so the description carries the burden. The verb 'Get' implies a read operation, and the description lists the return contents. It does not explicitly state read-only behavior, nor disclose any edge cases, status codes, or data limitations, so it meets the minimum but lacks depth.

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 sentences: the first states the function, the second gives usage examples. It is front-loaded, has no redundant words, and 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 simple one-parameter tool without output schema, the description is nearly complete: it names the specific metrics returned and provides use cases. It could improve by mentioning what 'master data' includes, but overall it covers the essential 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?

Schema coverage is 100%, with the only parameter 'isin' adequately described as 'The security's ISIN'. The tool description adds 'by ISIN' but no extra semantic detail beyond what the schema already provides, so the baseline score 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 the tool's function: 'Get master data and valuation fundamentals (P/E, P/B, P/S, F-Score)' and specifies the input by ISIN. It also distinguishes itself from siblings by naming concrete metrics and giving example use cases, making it unambiguous among the other financial 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?

It provides clear context with 'Use this for "tell me about this holding" or "is this stock expensive?"' which tells the agent when to invoke it. However, it does not mention exclusions or alternative tools, just the intended 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?

With no annotations, the description must carry the behavioral disclosure burden. It clearly implies a read-only listing operation and enumerates account types, but does not explicitly state that it modifies nothing, nor does it mention any rate limits, auth requirements, or output format. Since 'list' is inherently non-destructive, a score of 3 reflects adequate but not rich disclosure.

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, front-loaded with the action and scope, and includes a useful usage hint. No wasted words; every clause contributes.

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 list tool with no parameters and no output schema, the description covers the essential purpose and when to use it, and even hints at the return categories. It doesn't detail the exact return structure or pagination, but given the simplicity, it is sufficiently 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 tool has zero parameters, so the schema needs no explanation. The description adds meaning by clarifying the scope ('all of the user's accounts') and providing examples, which is appropriate. Baseline for zero params is 4.

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 explicitly states 'List all of the user's accounts' with a clear verb and resource, and differentiates this tool from siblings like get_account_balances or get_portfolio_valuation by focusing on account enumeration rather than balances or valuations. The subtypes (depots, cash accounts, insurance) add specificity.

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 explicit 'when to use' guidance: 'Start here when you need to know which accounts exist before drilling in.' This clearly positions the tool as the entry point and implies alternatives for deeper dives, without listing them but providing a clear context for selection.

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?

No annotations are provided, so the description carries the burden. It discloses the nature (listing bookings) and gives an intended use, but does not mention pagination, limitations, or return behavior. The schema covers perPage limits, but the description adds minimal behavioral context beyond what the name implies.

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 concise sentences, front-loaded with the core purpose and a practical usage hint. No filler.

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

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

For a list tool with 6 parameters fully described in the schema, the description provides adequate purpose and usage context. It could clarify the distinction from list_transactions or the extra enum types, but overall it is 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 100%, so baseline is 3. The description adds context by relating filters to 'specific security or depot' (isin/accountId) and enumerates several booking types. However, it omits 'book_in' and 'book_out' from the enum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool lists investment bookings with specific types (buys, sells, dividends, splits). This distinguishes it from siblings like list_transactions and get_dividend_history.

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

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

Provides a clear use case: 'see the trade history for a specific security or depot.' It does not explicitly mention alternatives or exclusions, but the context is clear.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It lists the returned fields and indicates a read-only operation via 'List', but it doesn't mention that historic positions are excluded by default (as implied by the includeHistoric parameter) or any pagination behavior. This is a moderate gap but not a severe one.

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 concise: two sentences. The first sentence states the core purpose and return values, and the second provides usage examples. No redundant or filler content, and the most important information 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 listing tool, the description covers what it returns and when to use it. It lacks explicit mention of default filtering (historic excluded) and pagination, but the return fields and example queries make it reasonably complete. The absence of an output schema is compensated by listing the return fields. Given the sibling tools and schema richness, a score of 4 is appropriate.

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 (depotId and includeHistoric) are fully documented in the schema. The description adds no additional meaning about the parameters, so it meets the baseline of 3 but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists the user's investment holdings with specific asset types (stocks, funds, bonds, ETFs) and specifies the returned fields (name, ISIN, type, lots, market value, gain/loss). This distinguishes it from sibling tools like get_portfolio_valuation or get_portfolio_allocation, which focus on different aspects.

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 provides explicit example use cases ('what do I own?' and 'show me my biggest positions') that signal when to use this tool. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for an agent to choose it over more specialized tools like get_portfolio_performance or get_gainers_and_losers.

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?

No annotations are provided, so the description must carry behavioral transparency. It discloses the sorting behavior (largest absolute value first), which is useful. However, it omits details like pagination defaults, date handling, or response format, leaving some ambiguity for a tool with no 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 two sentences long, front-loaded with the action and resource, and the second sentence adds a practical use case. No unnecessary 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?

Given five optional parameters, no output schema, and no annotations, the description provides a clear overview and sorting behavior but lacks details on pagination limits, date boundary semantics, and error cases. It is adequate for a simple list tool but not fully comprehensive.

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?

While the schema covers all parameters (100% coverage), the description introduces transaction types (fees, transfers) not listed in the schema's 'type' description (withdrawal, deposit, interest, tax_refund, other_gains). This inconsistency could mislead agents into selecting invalid filter values, reducing clarity beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('cash transactions') with examples, making the tool's purpose clear. It distinguishes from siblings like list_accounts or get_cash_flow_summary by focusing on raw transaction listing.

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 a usage scenario ('top rows answer what did I spend most money on?') but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The guidance is indirect rather than 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?

No annotations are provided, so the description bears the burden for behavioral disclosure. It usefully discloses that the tool returns 'the security ID and quote provider needed by get_quotes,' which is key for downstream usage. However, it does not disclose behavior such as result limits, what happens with multiple matches, or error handling, making the transparency adequate but incomplete.

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 sentences, succinct and front-loaded. The first sentence states the action, and the second provides a concrete usage example, with no redundant 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?

For a search tool with four optional parameters and no output schema, the description provides the essential context: what it searches by, what it returns (ID and provider), and why that output is needed. It lacks some detail such as result format, but the combination of schema and description is sufficient for an agent to use the tool effectively.

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% with all four parameters described in the schema itself. The description adds no additional parameter-level detail beyond what the schema provides, but it does align with the search criteria mentioned (name, ISIN, WKN). Per the baseline rule, a score of 3 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 uses a specific verb 'Search' with the resource 'securities' and explicitly lists search criteria (name, ISIN, WKN). It further clarifies the tool's output's purpose by linking to get_quotes, which distinguishes it from sibling tools like get_quotes or list_investments.

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 provides an explicit use case: 'Use this to resolve ''Apple'' or an ISIN to a tradable security.' This clearly states when to use the tool. However, it does not explicitly describe when not to use it or mention alternatives beyond get_quotes, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses the output contents (name, email, member since) and implicitly indicates a read-only operation via 'Show.' While it does not discuss potential errors or authentication requirements, the simplicity of a whoami tool makes the behavior transparent enough.

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 (two sentences) and front-loaded with the core action. The first sentence states the purpose and output; the second adds usage context. Every word earns its place with no 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 zero-parameter tool with no output schema, the description fully covers what the tool does, what it returns, and when to use it. It is complete within the context of its simplicity and sibling differentiation.

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 trivially covers everything. The baseline for 0 params is 4, and the description adds semantic value by explaining what information will be returned for the session, making the purpose even clearer.

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's purpose: 'Show which wealthAPI user this session is acting as (name, email, member since).' The verb 'Show' is specific, and the resource 'wealthAPI user' is well-defined. It naturally distinguishes from sibling tools like list_accounts, which focus on account data rather than session identity.

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 explicitly says 'Use this to ground yourself or when the user asks 'which account is this?',' providing clear context for when to invoke the tool. However, it does not mention when not to use it or name alternative tools for related but distinct tasks, stopping short of full 'when/when-not/alternatives' guidance.

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