longbridge

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the return format (balances[]{...}) and the filter behavior, which is useful but does not go beyond what annotations already imply. It does not contradict the annotations.

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

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

Two concise sentences. The first states the purpose and return fields, the second gives filter guidance. Front-loaded, no redundant wording.

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

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

For a simple read-only tool with annotations covering safety, the description is nearly complete. It lists return fields and filter behavior. The main gap is the undocumented '_jq' parameter and lack of explanation for terms like 'risk_level' or 'margin_call', but these are likely self-explanatory in a financial 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 schema describes only the 'currency' parameter (50% coverage); 'currency' is also explained in the description with examples, adding meaning beyond the schema. However, '_jq' is not described in either the schema or the description, leaving a gap. The description partially compensates for the coverage shortfall but not completely.

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 account cash balance and asset summary.' It specifies the resource (account) and the verb (get), and lists the exact return fields, making it distinct from siblings like stock_positions or bank_cards.

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 does not provide guidance on when to use this tool versus alternatives. It mentions filtering by currency but gives no exclusions or alternative recommendations, leaving the agent to infer usage from the purpose. With over 100 siblings, some differentiation would be helpful, but the purpose is clear enough for basic 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?

The description goes beyond the annotations by stating exactly what the returned items represent (premium percentage) and their field structure. Since annotations already flag readOnly/openWorld/idempotent and non-destructive, the description does not need to restate safety; it adds useful payload-level context that the structured data alone would not provide.

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 that names the operation, object, and purpose, then gives the minimal return contract. There is no filler or backtracking, and all needed high-level information is visible without scrolling.

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

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

For a simple read-only historical K-line tool, the description covers the endpoint role, the time-field semantics, and the return item shapes, which is especially important given there is no output schema. The main missing element is an explicit note about the closely related intraday sibling, but that absence is more of an usage-guidance gap than a completeness gap for this simple tool.

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

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

Schema coverage is 75%, so symbol, period, and count are already documented at the JSON-schema level. The description adds no parameter-specific details beyond the general notion of a period, and it leaves the '_jq' parameter undocumented in both the schema coverage and the prose. Baseline 3 fits because the schema carries most of the semantic weight.

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 deliverable ('A/H share premium historical K-line data') and provides a concrete return shape ('items[]{timestamp, open, high, low, close}'). The word 'historical' distinguishes it from the sibling ah_premium_intraday without requiring the agent to inspect either schema.

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

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

The word 'historical' and 'over the given period' imply this tool is for a retrospective K-line view, and the schema further clarifies period and count. However, no explicit exclusions are given—such as 'use ah_premium_intraday for real-time data'—and no alternative is referenced, leaving the caller to infer when this tool is preferred.

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

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

Annotations already mark this as read-only and idempotent, covering side effects. The description adds that it returns minute-by-minute items with timestamp and premium_rate, but it does not disclose potential quirks like market-hours availability, timezone, or whether data is delayed.

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 that front-load the core purpose ('Get A/H premium intraday time-share data') and immediately follow with the output shape. No wasted words, though the response format detail is 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?

For a simple read-only data fetch, the description plus schema covers the essentials: symbol parameter, output array, and field names. Missing are operational details like time range, timezone, and whether the data is delayed, but these are not critical for basic 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 documentation covers only 'symbol' with an example, while '_jq' is undocumented. The description adds no parameter-level meaning, so an agent gets no help understanding the '_jq' parameter or accepted symbol formats 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-resource pair ('Get A/H premium intraday time-share data') and names the return shape, which clearly identifies this as the intraday variant of an A/H premium endpoint. It is distinguishable from the sibling 'intraday' tool by the 'A/H premium' qualifier, though it does not explicitly contrast itself with non-intraday A/H premium 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?

No guidance is given on when to use this tool versus sibling tools such as 'intraday' or other premium-related endpoints. There are no example use cases, prerequisite conditions, or notes on symbol formats beyond the schema.

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=false, destructiveHint=false, and idempotentHint=false, indicating this is a non-read, non-idempotent operation. The description adds that it 'Returns created alert object,' which is useful behavioral context. However, it doesn't disclose side effects like whether adding an alert overwrites existing alerts, whether there are limits on the number of alerts, or whether the operation requires authentication. The description doesn't contradict annotations, but it doesn't add much beyond what annotations already imply.

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: it starts with the action ('Add a price alert'), then explains the key parameters in a compact format. Every sentence earns its place, and the return value is mentioned at the end. No 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 creation tool with no output schema, the description covers the essential aspects: what it does, the key parameters, and the return value. It doesn't mention error cases, rate limits, or prerequisites (e.g., authentication), but these are not typically required for a simple alert creation tool. The description is complete enough for an agent to invoke the tool correctly, though it could benefit from noting that the alert is created for the authenticated user.

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

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

Schema description coverage is 80%, so the schema already documents most parameters. The description adds value by explaining the semantics of 'condition' (price_rise/price_fall vs percent_rise/percent_fall) and 'frequency' (once/daily/every), which clarifies the meaning of the 'price' parameter (threshold price or percentage value). The description also clarifies that 'price' is the threshold value, which is not fully explicit in the schema. The only undocumented parameter is '_jq', which is likely a query parameter and not critical for the agent's understanding.

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: 'Add a price alert.' It specifies the resource (price alert) and the action (add), and distinguishes it from sibling tools like alert_delete, alert_disable, alert_enable, and alert_list. The description also enumerates the condition and frequency options, making the tool's scope 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?

The description provides clear context for when to use this tool: when creating a price alert. It explains the condition and frequency parameters, which are essential for correct usage. However, it does not explicitly state when not to use it or mention alternatives (e.g., for managing existing alerts, use alert_list/alert_delete/alert_enable/alert_disable). The sibling names imply these alternatives, but the description itself doesn't route the agent away from them.

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 destructiveHint=true and idempotentHint=true, so the description correctly avoids repeating those. It adds value by specifying that it returns the upstream API response on success and errors on an invalid alert_id, which is useful behavioral context beyond the annotations. No contradictions found.

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 fluff. The core action and identifier are front-loaded, and the error/return behavior is stated efficiently. Every word earns its place.

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

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

For a simple delete operation, the description covers the essential details: what to pass, where the ID comes from, what to expect on success, and the error condition. Annotations already handle the destructive and idempotent hints. No output schema exists, so the return value description is sufficient. It is complete enough for an agent to call correctly.

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

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

Schema description coverage is only 50% (alert_id has a minimal schema description, _jq has none). The description compensates for alert_id by clarifying it is a numeric string from alert_list, but it does not explain the optional _jq parameter. While the main parameter is well covered, the secondary one remains undocumented, so the description only partially bridges the gap.

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

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

States a specific verb (delete), resource (price alert), and key identifier (alert_id). It also tells the agent where the ID comes from (alert_list), which clearly distinguishes it from siblings like alert_disable, alert_enable, and alert_add. 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?

The description implies the use case (permanently remove an alert) and even points to alert_list as the source of the ID. However, it does not explicitly contrast with alert_disable (which might be a non-destructive alternative) or state when not to use this tool. The guidance is adequate but leaves comparison to the agent's inference.

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

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

The annotations already cover the key behavioral traits: readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds no behavioral detail beyond stating the disabling action itself, which is appropriate but not enriching enough to justify a higher score.

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 contain the core action and a concrete lookup direction with no redundant wording. The description is small and front-loaded, serving its 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, requires only one parameter, and its annotations cover idempotency and mutability. The description is adequate for invocation; the only notable omission is guidance on choosing between similarly named alert operations, but that gap is minor for the agent to successfully call this tool.

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

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

The schema only describes alert_id as 'Alert indicator id', while the description adds the valuable detail that the alert_id is numeric and can be obtained via alert_list. This helps the agent construct a correct call, though the optional _jq parameter remains unexplained.

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 the specific action ('Disable') and the resource ('a price alert') and identifies the key parameter by name. It does not explicitly differentiate this from sibling tools like alert_delete and alert_enable, but the verb 'disable' is semantically clear enough for basic selection.

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 practical guidance by telling the agent to use alert_list to discover the numeric alert_id. However, it does not explain when to choose this tool over alert_delete or alert_enable, so usage context among the alert siblings is only implied 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?

Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds no additional behavioral context, such as what happens if the alert is already enabled, whether it requires specific permissions, or what the response contains. It simply restates the action, so it adds little beyond the annotations.

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

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

The description is two short sentences with no wasted words. The primary action is stated first, and the helpful hint about alert_list follows. It is efficiently structured.

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 enable operation with one required parameter, the description provides the essential information: the action and how to get the ID. However, it does not describe the return value or error conditions, which might be useful since there is no output schema. The idempotency is covered by annotations, so it is reasonably complete but could benefit from a note about the expected result.

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

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

The description clarifies that alert_id is numeric and can be obtained via alert_list, which adds meaning beyond the schema's 'Alert indicator id'. However, the _jq parameter (the other parameter) is not mentioned at all, and with 50% schema coverage, the description does not fully compensate for the undocumented _jq parameter. It helps for alert_id but leaves _jq unexplained.

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 action: 'Enable a price alert by alert_id.' It identifies the resource (price alert) and the required identifier. It also points to alert_list for finding the ID, which helps differentiate from the list tool. However, it does not explicitly contrast with alert_disable or alert_add, so it doesn't fully distinguish among sibling alert tools.

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

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

The description provides no guidance on when to use this tool versus alternatives like alert_disable or alert_add. It only says to use alert_list to find the ID, which is about obtaining the parameter, not about choosing this tool. There is no statement about enabling being appropriate for existing alerts or that it should not be used for creating alerts.

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 (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false) already define the safety profile. The description adds minimal behavioral nuance ('configured', 'all'), but says nothing about pagination, completeness limits, or response format. It does not contradict annotations, and the annotation-provided context justifies a baseline score.

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 compact single sentence that focuses on the core action and object. There is no filler or redundancy, and the key information appears up front. It is appropriately brief for a tool whose burden falls only on the brief statement.

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 an undocumented parameter and no output schema, the description is insufficiently complete. An agent cannot determine whether `_jq` must be supplied or what return shape to expect, and no usage fallback is given. The description leaves the most delicate semantic gaps open.

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 single parameter `_jq` has a schema description coverage of 0%, and the description does not hint at its meaning or effect. The agent is left entirely uninformed about whether this parameter is required, optional, or what values control behavior. There is no effort to compensate for the missing schema documentation.

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 a specific resource ('all configured price alerts'), and clearly distinguishes this tool from the alert mutation siblings (alert_add, alert_delete, alert_disable, alert_enable). The intent is immediately understandable and 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?

The description gives no guidance on when to choose this tool over alternatives, nor does it mention prerequisites such as having alerts configured. It is a bare imperative statement, leaving the agent to infer usage from the tool name and sibling set.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds context about what constitutes an anomaly and clarifies the count pagination, but it does not disclose additional behavioral traits like response format or rate limits. 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?

The description is two sentences with no filler. It front-loads the purpose and then lists parameters concisely, making it easy for an agent to scan.

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

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

For a simple read-only tool with rich annotations and a small parameter set, the description covers the essential information: purpose, parameters, and pagination. It omits the meaning of _jq and return format, but given the tool's simplicity and annotations, these are minor gaps.

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

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

Schema description coverage is 75% (three of four parameters have descriptions). The description repeats the market codes, symbol example, and count defaults, adding little beyond the schema. The _jq parameter lacks any description in both schema and tool description, leaving a gap, but the overall parameter guidance is acceptable.

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 fetches market anomaly alerts and defines them as unusual price/volume changes. It specifies the resource and verb, making the purpose clear. It does not explicitly differentiate from sibling tools like alert_list or signals, but the description's specificity is sufficient for basic understanding.

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 no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It only explains parameters, leaving the agent to infer when anomaly alerts are appropriate relative to other alert and signal tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, which informs the agent that this is a safe read operation. The description adds the detail that the returned data includes masked account numbers and status, which is useful. However, it does not disclose potential limitations such as only returning cards for the current account (implying no filtering), which is a minor gap but the description already states 'linked... for the current account'.

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 that is concise and information-dense. It front-loads the action and resource, and includes the exact output shape. There is zero wasted words; 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?

For a simple read-only tool with one optional parameterasi and a clear output structure described, the description is essentially complete. It lacks explicit response limitations (e.g., pagination) but given the tool's simplicity and the presence of annotations, the description provides enough context for an agent to call it correctly. The output schema is not provided, but the description compensates by listing the fields.

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 only one parameter '_jq' with no description, and schema description coverage is 0%. The description does not explain the '_jq' parameter. However, since the parameter is optional (0 required) and likely a jq filter for output transformation, the schema itself is sparse电能; the description's lack of detail on '_jq' is not a major issue because it is optional and the core behavior is clear. The description provides a clear output structure.

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: listing linked withdrawal bank cards for the current account FAQs. It specifies the resource (bank cards) and the verb (list). Although it does not explicitly differentiate from sibling tools like 'withdrawals', the resource is distinct enough that an agent can infer it is the appropriate tool for accessing card information.

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

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

The description implies usage context: it lists linked cards for the current account, which is clear for the primary use case. However, it does not provide explicit guidance on when to use this tool over siblings like 'withdrawals' (which likely handles withdrawal records) or 'deposits'. There are no exclusions or alternative suggestions.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the data source (HKEX CCASS) and market restriction, which is useful but does not disclose return format or pagination. Given annotations carry the safety burden, the description adds some value beyond them, so 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, front-loaded sentence that conveys the core purpose, market scope, and data source with zero waste. It is concise, though it omits any usage guidance or parameter hints that might be expected for a tool with siblings.

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

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

For a simple read-only tool with three parameters and no output schema, the description covers the purpose and scope. However, given the presence of sibling tools (broker_holding_daily, broker_holding_detail, brokers) that overlap in domain, the description does not help an agent decide which one to call. This is a notable gap in completeness.

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 67% (symbol and period have descriptions, _jq does not). The description does not elaborate on any parameters, nor does it compensate for the undocumented _jq field. It adds no parameter-level meaning beyond what the schema already provides, so the score is below the baseline for full coverage.

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 ('Get') and resource ('top broker holding data for a symbol'), plus a market scope ('HK stocks only') and data source. It does not explicitly differentiate from siblings like broker_holding_daily or broker_holding_detail, but the core 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?

The description mentions that it applies only to HK stocks and is sourced from HKEX CCASS, which gives some context, but it does not state when to use this tool versus the sibling broker_holding_daily, broker_holding_detail, or brokers. There are no explicit alternatives or when-not 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so this is safely a read operation. The description adds the data source (HKEX CCASS) and coverage (daily history, HK stocks), which is useful. However, it does not disclose any potential rate limits or pagination behavior, which might matter for historical queries.

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, information-dense sentence: it states the verb (get), the resource (daily holding history), the key parameters (broker_id and symbol), and the scope (HK stocks, HKEX CCASS). No filler 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 description covers the basic purpose and source, but given that there is no output schema, it does not describe return fields or data quality. It also doesn't clarify the relationship to sibling tools like 'broker_holding' or 'broker_holding_detail', which is a moderate gap for a data-retrieval tool.

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

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

The schema describes both required parameters with good detail: 'symbol' explains format (e.g., '700.HK') and 'broker_id' as 'Broker participant number'. With 67% schema coverage, the description adds minimal extra parameter context. The optional '_jq' parameter remains undocumented in both schema and description, but being optional and likely a filter, the baseline 3 is reasonable.

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 retrieves daily holding history for a broker in a symbol, with a specific scope (HK stocks, HKEX CCASS source). It is distinguishable from sibling tools like 'broker_holding' (likely current holdings) and 'broker_holding_detail' (likely more granular), though it doesn't explicitly differentiate from them.

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

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

The description implies when to use it (historical daily data for brokers) but does not explicitly state when not to use it or which alternatives are better (e.g., 'broker_holding' for current holdings, 'broker_holding_detail' for detailed changes). An agent would need to infer the differentiation from sibling names.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds value by specifying the market restriction (HK stocks only) and the data source (HKEX CCASS), which are behavioral constraints not captured in the annotations. However, it does not describe pagination or the structure of the returned list, though this is partially mitigated by the strong 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 a single, front-loaded sentence that immediately states the tool's action and scope. It contains no filler and every word adds information (full list, symbol, HK only, source). This is an exemplar of concise, structured writing.

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 has only two parameters, no output schema, and rich annotations, the description is adequate but not complete. It covers the core purpose and market scope, but does not explain what 'full broker holding detail list' includes, nor does it document the '_jq' parameter or any prerequisites beyond HK stocks. For a detail-list tool, an agent might need more context on return fields, but the absence of an output schema shifts that burden to the description, which does not fully meet it.

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

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

Schema description coverage is 50% (only 'symbol' is documented). The description mentions 'for a symbol' but does not elaborate on the meaning or format beyond what the schema already provides. The '_jq' parameter is entirely undocumented in both schema and description, leaving an agent without guidance on its purpose or usage. The description fails to compensate for the coverage gap.

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

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

The description clearly states the action ('Get'), the resource ('full broker holding detail list'), and the scope ('for a symbol' with 'HK stocks only'). It also specifies the data source (HKEX CCASS participant disclosure), which differentiates it from sibling tools like broker_holding or broker_holding_daily. This is a precise and specific statement of purpose.

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

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

The description provides useful context (HK stocks only, data source) but does not explicitly guide when to use this tool versus alternatives such as broker_holding or broker_holding_daily. There is no mention of exclusions or conditions that would route an agent to a sibling, so usage guidance is implied 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?

Annotations already convey readOnlyHint=true and idempotentHint=true, so the description only adds scoping ('HK stocks only') and a data dependency ('Map broker IDs to names via participants'). These add some behavioral context, but the description does not disclose response format, pagination, or any limitations beyond the scope note.

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, action first, with no filler or redundant details. The key scope restriction is front-loaded and the participants hint is included efficiently.

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 its simplicity and the annotations provided, the description is adequate for understanding what it does, but it leaves the output shape unexplained and assumes the agent knows which 'participants' tool or resource to use. Without an output schema, this is a noticeable gap.

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

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

Schema description coverage is 50%; symbol has a description with an example, but _jq has none. The description indirectly constrains symbol to HK stocks, which adds some meaning, but it provides no information about the _jq parameter and does not compensate for the missing schema documentation.

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 ('Get broker queue'), adds an explicit scope restriction ('HK stocks only'), and references a companion step ('Map broker IDs to names via participants') that distinguishes it from sibling tools like broker_holding or broker_holding_detail. An agent can immediately understand what this tool does and how it fits into a workflow.

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

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

It gives a context clue ('HK stocks only') but does not explicitly say when to use this tool versus alternatives, nor does it name any sibling tools as superior for other cases. The 'map via participants' hint implies a workflow, but there is no explicit when-to-use/when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the operation's safety profile. The description adds useful context by enumerating the returned fields and the 'current-period' temporal scope, but does not disclose behaviors such as period definition, data availability, or input format normalization.

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

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

A single sentence, front-loaded with the primary action and scope, and every word contributes. It is appropriately compact for a simple read-only query tool with no nested objects or output schema.

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 tool with strong annotations and only one required, documented parameter (symbol), the description supplies the essential output fields and the current-period scope. It could further clarify what 'current-period' means or describe _jq, but the tool's simplicity makes this level of detail adequate.

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

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

Schema description coverage is only 50%; symbol is documented with an example, but _jq has no description. The tool description only restates 'for a symbol' and does not explain _jq or add any format/validation details beyond the schema. It fails to compensate for the missing parameter documentation.

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' with a clear resource: 'business segment revenue breakdown'. It also states the scope ('current-period', 'for a symbol') and lists the key output fields (name, percent, total, currency). The 'current-period' qualifier distinguishes it from the sibling business_segments_history without ambiguity.

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 'current-period' qualifier gives clear context that this tool is for present-period data, implying that historical data should be retrieved elsewhere (e.g., business_segments_history). However, it does not explicitly name that alternative or state when not to use the tool, stopping short of full routing guidance.

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

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

The annotations already declare this as read-only, idempotent, and non-destructive. The description adds only the idea of 'revenue trends by period and category' but does not explain output shape, pagination, or any other behavioral details that the annotations do not cover.

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 that leads with the action and resource, then adds the key dimensions. No filler or redundant restating of the tool name.

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 annotations covering side effects and the schema covering required parameters. However, the description omits any mention of return shape or how results are organized (e.g., chronological order, units), and does not clarify edge cases like missing segment data. It is adequate but thin.

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 3 of 4 parameters with descriptions, and the tool description's mention of 'period' and 'category' lightly reinforces the `report` and `cate` parameters. However, it does not add meaningful meaning beyond the schema, and `_jq` remains unexplained.

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 a clear resource ('historical business segment revenue trends'), and the parenthetical ('by period and category') adds useful dimensions. It does not explicitly contrast with the sibling tool `business_segments`, but the word 'historical' and 'trends' provide a reasonable distinction from the likely current-snapshot tool.

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

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

The description implies this is for historical trend retrieval, but it does not explicitly state when to choose this over `business_segments` or other alternatives. There is no 'when to use' or 'when not to use' guidance beyond the implied historical focus.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavior beyond that: the full default index list and the precise normalization semantics for Greek indexes (theta per-day, vega per 1% IV, rho per 1% rate). No contradiction with annotations.

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

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

The description is moderately long but every sentence serves a purpose: purpose, parameters, defaults, output, and Greek normalization. The default list repeats schema content but functions as a convenient reference; there is no unnecessary 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 read-only calculation tool, it adequately covers required inputs, optional inputs with defaults, output shape, and special behavior for Greek indexes. Since there is no output schema, the statement 'Returns per-symbol index values' gives sufficient but not exhaustive return-value 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 schema already describes symbols and indexes, but the description enriches the indexes parameter with concrete examples, the default set when omitted/empty, and special interpretation for Greek indexes. It leaves _jq undocumented, but schema coverage is still 67% and the description adds meaningful guidance 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: 'Calculate financial indexes for symbols,' and later clarifies it returns per-symbol index values. This distinguishes it from many siblings, though it does not explicitly name an alternative tool.

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

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

The description explains how to invoke the tool: pass symbols, optionally indexes, and what happens when indexes is omitted or empty. However, it does not explicitly state when to prefer this tool over siblings like quote or now, nor does it mention 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?

The description discloses a critical behavioral trait that annotations do not fully capture: the tool is a dry run unless a confirmation code is passed. It explains the generated code is order-specific, single-use, expires in 10 minutes, and that changing any field invalidates it. The destructiveHint is true, but the description goes beyond by specifying the exact safety protocol, which is essential for safe invocation.

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

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

The description is dense but well-structured, front-loading the core action and then the critical confirmation requirement. It is longer than ideal, but every sentence serves a purpose (e.g., dry-run mechanics, code properties, leg cancellation). The structure is logical: action, success response, confirmation protocol, special case, and safety rules.

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 that there is no output schemaторit, the description adequately explains the return value ('plain text order cancelled') and error conditions. It fully covers the tool's behavior, including the dry-run preview echo and the distinction between parent and attached-leg cancellation. An agent has all information needed to call the tool correctly without external 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 already has high coverage (75%) with detailed parameter descriptions, including the purpose of 'execute' and 'is_attached'. The description adds value by explicitly tying the confirmation code to the dry-run flow in prose form)Skip, reinforcing the two-step protocol beyond the schema's parameter-level explanation. It clarifies the parent-leg behavior that is partially in the schema but reiterated for emphasis.

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 ('Cancel') and resource ('an open order by order_id'), and immediately distinguishes two use cases: cancelling a parent order versus an attached leg. This differentiates it from siblings like 'replace_order' and 'grid_cancel' and tells the agent exactly what it acts on.

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 states the mandatory two-step confirmation protocol: first call without execute to get a preview, show it to the user, then call again with the confirmation code after explicit approval. It also names the alternative for cancelling a single leg (is_attached=true) and clarifies that cancelling a parent also cancels legs, which addresses common ambiguity.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds a meaningful behavioral detail: when the entitlement caps out, the tool returns as many candles as allowed instead of erroring, and it advises checking the array length. This goes beyond what annotations convey and is valuable 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 concise and front-loaded with the core purpose. It lists defaults and edge-case behavior in a structured manner without unnecessary fluff. Every sentence provides useful 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 read-only tool with 6 parameters and no output schema, the description covers the defaults, allowed values, and an important edge case. However, it omits the _jq parameter entirely and does not describe the response structure beyond 'candlestick data (OHLCV)', which is vague. Given that there is no output schema, this is a notable gap.

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

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

Schema description coverage is high (83%), so the schema already documents all parameters except _jq. The description repeats defaults and enum-like values that are also in the schema, but it does add the clarification that only symbol is required and explains the entitlement behavior. However, it does not explain _jq, which is undocumented in both schema and description. Overall, the description adds little 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 verb 'Get' and the resource 'candlestick data (OHLCV)', making the purpose specific and unambiguous. It also lists the default values and required field, but it does not explicitly differentiate from sibling tools like history_candlesticks_by_date or history_candlesticks_by_offset, which likely serve a different purpose (historical vs. periodic).

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 no guidance on when to use this tool versus alternatives. It does not mention that this is for recent/periodic data, nor does it point to sibling tools for historical queries. The only usage hint is the behavior when the entitlement caps out, but that is not a usage guideline.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses a non-obvious edge case: symbols like indices produce data_available=false while other fields remain present but as meaningless zeros. This directly prevents an agent from misinterpreting zeros as real data, which is substantial added behavioral transparency.

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: the first states the action and object, the second delivers the critical caveat. No filler or repetition of schema content; the structure is front-loaded with the core 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?

For a simple read-only symbol lookup with one required parameter, the description covers the key gotcha (missing data yields data_available=false with meaningless zeros). However, it doesn't enumerate the returned capital distribution fields, so an agent must infer the payload structure beyond the single flag. Given no output schema, this leaves minor uncertainty about the response shape.

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 already documents symbol and its format. The description reiterates 'for a symbol' but adds no parameter-specific semantics for the undocumented _jq parameter axes. With 50% schema coverage, this lack of additional explanation leaves _jq ambiguous.

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 the clear verb 'Get' with the object 'capital distribution for a symbol', making the tool's purpose immediately understandable. It doesn't explicitly contrast against sibling tools like capital_flow, but the scope ('for a symbol') is specific enough that a caller can infer what this endpoint returns.

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

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

The description gives no guidance on when to choose this tool over siblings. It only explains a data-availability edge case (data_available false for indices). Without explicit routing to alternatives such as capital_flow, an agent gets limited conditional context but no decision framework.

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

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

Annotations already declare readOnly/idempotent/openWorld. The description adds a meaningful behavioral caveat ('same-day data') and specifies the item shape (timestamp, inflow, outflow, net_flow), which helps set expectations without contradicting the annotations.

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

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

A single sentence that front-loads the core action and return shape with zero 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?

Returns fields and same-day caveat are stated, and the read-only profile is already covered by annotations. It is slightly light on how the time series is bounded (default range, intraday vs. historical daily), but for a simple read tool this is nearly 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 ~50% since symbol is documented but _jq is not. The description only restates 'for the symbol' and does not clarify the _jq filtering parameter. At this coverage level, the description needed to compensate but largely repeats what the schema already conveys.

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

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

The description uses a specific verb+resource: 'Get capital flow time series' and lists the exact return fields (items[]{timestamp, inflow, outflow, net_flow}), making the tool's purpose clear. However, it does not differentiate itself from the sibling 'cash_flow' tool, which could plausibly be confused with it despite being a different concept.

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 on when to use this tool versus alternatives. Given the large sibling set including cash_flow and capital_distribution, the description provides no exclusions or routing hints that would help an agent choose between them.

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?

Read-only and non-destructive behavior is already covered by annotations. The description adds useful behavior context by listing the returned items[] fields and the RFC3339 date format, but does not disclose pagination, result limits, or response envelope details.

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

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

Two tight sentences deliver purpose, allowed record types, return shape, and date format with no filler 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?

The description provides the return fields and date format, which is valuable given there is no output schema. Still, it omits context an agent may need such as pagination, maximum date range, ordering, and why an agent should choose this instead of the sibling deposit/withdrawal/dividend 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?

The schema documents start_at and end_at, and the description reinforces the RFC3339 format. However, the _jq parameter is left undocumented, and no parameter relationships, constraints, or defaults are explained. With 67% schema coverage, the description partially compensates but not fully.

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

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

States a specific action and resource ('Get cash flow records') and enumerates the record types (deposits, withdrawals, dividends). This is clear about what the tool does, but it does not differentiate itself from sibling tools like deposits, withdrawals, or dividend_detail, which may already cover those subsets.

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?

Implies it is a unified view of deposits, withdrawals, and dividends, but never explicitly says when to choose cash_flow over the dedicated deposits/withdrawals/dividend sibling tools. No guidance on exclusions, prerequisites, or alternatives.

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

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

The description adds a useful behavioral disclosure beyond the read-only annotations: the region is auto-detected from the account, and US accounts get a variant with specific fields. It doesn't describe the non-US behavior, which is a minor gap.

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 with no filler. The core purpose is front-loaded, and the conditional variant is explained efficiently.

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, low-complexity overview tool, the description is mostly complete: it covers the main purpose and an important conditional behavior. The lack of an output schema and any detail on non-US responses is a minor gap, but not critical given 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?

The description does not mention parameters at all. The symbol parameter is covered by the schema with an example, but the optional _jq parameter remains undocumented in both schema and description, so the description does not compensate for the coverage gap.

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

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

The description states a clear action ('Get company overview') and resource, with a specific verb. It does not explicitly name or contrast sibling tools like static_info or security_facts, so the differentiation is left to the agent's inference.

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 versus alternatives. The only conditional context is the US-specific variant, which is a behavioral detail rather than a routing rule.

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 read-only, idempotent, non-destructive behavior. The description adds meaningful runtime behavior: US accounts querying .US symbols receive a different response shape (ai_summary plus details[] instead of items[]). This is useful beyond the annotations.

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

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

Two concise sentences, front-loaded with the core purpose. The regional variant is stated immediately after the main behavior, and there is no filler or redundant restating of the tool name.

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 essential context is present: what is returned, the regional variant, and automatic account-based region detection. Since there is no output schema, a bit more detail about the general response structure for non-US accounts would improve completeness, but the description covers the main agent decision points.

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

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

Schema coverage is only 50% (symbol is described; _jq is not). The description does not add meaning for either parameter beyond what the schema already provides, so it fails to compensate for the undocumented _jq parameter.

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 retrieves consensus estimates for upcoming periods, with a specific verb and resource. It does not explicitly distinguish this from related tools like forecast_eps or institution_rating_history, but the regional variant detail adds useful 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?

No explicit guidance on when to use this tool versus sibling alternatives such as forecast_eps, institution_rating_history, or finance_calendar. The only usage nuance is the US-account variant, which is a behavioral note rather than a selection guideline.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, lowering the bar for the description. The description goes beyond that by detailing the response structure: for indices it returns constituents[] with specific fields, and for ETFs it returns info[] grouped by asset_type (1-4), including nested details like holding_detail and report_date. This gives the agent a precise understanding of what to expect without needing an output 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 long but every sentence contributes meaningful detail. It front-loads the core purpose, then systematically explains the index case and the four ETF asset-type groups, including field names and nested structures. While it is more verbose than a minimal definition, the complexity of the output justifies the length, and it remains well-organized.

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

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

With no output schema, the description carries the full responsibility for explaining return values. It does so thoroughly: it covers both index constituents (listing all fields) and ETF asset allocation (explaining the four groups, their fields, and nested objects). No critical information about the response is missing, making the tool callable correctly without additional schema guidance.

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 exactly 50%: the 'symbol' parameter has a description, but '_jq' does not. The tool description adds value for 'symbol' by providing concrete examples (HSI.HK, QQQ.US) and explaining how the symbol determines index vs ETF behavior. However, it does not address '_jq' at all, and the overall parameter documentation is not complete. Since coverage is borderline and the description partially compensates, a baseline 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 clearly states the tool's purpose: 'Get the constituents of an index or the asset allocation of an ETF.' It provides specific examples (HSI.HK, .DJI.US for indices; QQQ.US, 2800.HK for ETFs) and explains the distinct outputs for each case. This unambiguously distinguishes it from any sibling that might handle similar data, such as fund_positions or etf_docs, without needing to name them.

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

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

The description gives clear context for when to use the tool: whenever you need index constituents or ETF asset allocation. It does not explicitly list when not to use it or name alternative tools, but the usage context is well-defined through the index/ETF distinction. This meets the 'clear context, no exclusions' level.

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 mark the tool as read-only and open-world, so no side-effect warning is needed. The description is consistent with those annotations and provides basic examples. It does not disclose any additional behavior such as time range, pagination limits, or how current data is, but for a simple read-only lookup this is acceptable.

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, direct sentence that front-loads the verb and resource. It wastes no tokens and the parenthetical examples add useful detail without bloat.

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 tool with annotations and a simple schema, the description is close to adequate, but it omits when this is the right tool (vs dividend_detail/capital_distribution) and what the response format looks like. No output schema exists to fill that gap, so a bit more context would help.

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

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

The description does not explain how to use the parameters, and the schema only documents 'symbol' while '_jq' has no description. With 50% schema coveragethe description should compensate but does not mention either parameter.

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 verb 'Get' and the resource 'corporate actions' with concrete examples (splits, buybacks, name changes). This makes the primary purpose evident and distinguishes it from related tools like dividend_detail or cash_flow, though it doesn't explicitly contrast with those alternatives.

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

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

No guidance is provided about when to use this tool versus sibling tools such as dividend_detail, capital_distribution, or company. The description implies it covers various corporate actions but gives no use-case context, exclusions, or 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 indicate readOnlyHint=false and destructiveHint=false, and the description adds that securities can optionally be passed to pre-populate the group. However, it does not disclose duplicate-name behavior, ownership requirements, or other side effects. No contradiction with annotations.

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

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

The description is two concise, front-loaded sentences with no filler. It states the core action first and the optional behavior second.

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 and the schema covers the main parameters, but with no output schema the description does not mention what the tool returns or how success/failure is signaled. It also omits behavior around duplicate group names or whether an empty group is created when securities are omitted.

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 already documents 'name' and 'securities' with descriptions and an example. The description reinforces the securities example and adds the 'pre-populate' intent, but the '_jq' parameter remains undocumented, and no additional semantic detail beyond the schema is provided.

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 ('Create') and resource ('watchlist group'), and clarifies the optional pre-population behavior with securities. This clearly distinguishes it from sibling tools like update_watchlist_group and delete_watchlist_group.

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 tool's purpose clear, but it does not explicitly state when to use this tool versus updating or deleting a watchlist group. The usage context is implied by the name and siblings rather than spelled out.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, so no side-effect warning is required. The description adds little behavioral detail beyond that, such as return format or handling of unsupported symbols, but it does not contradict the annotations.

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

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

A single sentence carries the full purpose with no filler, and the key object (`symbols`) appears early. It is easy to parse and every word earns its place.

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

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

For a simple read-only check the description is close to adequate, but there is no output schema and no statement of what the tool returns, such as a boolean, per-symbol status, or filtered result. It also does not explain how unsupported or unknown symbols are reported, leaving some ambiguity.

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 documents `symbols` with an example, and the description only restates 'given symbols' without adding parameter-level detail. `_jq` is entirely undocumented in both the schema and the description, so the 50% coverage gap is not compensated.

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 predicate operation: it checks whether given symbols support DCA recurring investment. This is plainly distinct from sibling DCA actions such as dca_create, dca_history, or dca_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?

No explicit when-to-use or when-not-to-use guidance is provided, and no alternative tool is named. The description implies its use as a preflight eligibility check, but it does not say to use it before dca_create or distinguish it from dca_list or dca_history.

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

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

Annotations already supply readOnlyHint=false and idempotentHint=false, so 'Create' correctly signals mutation and non-idempotency. The description adds the recurring nature of the plan but does not mention consequences such as automatic later investments or duplicate-plan creation on repeated calls.

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

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

Three short clauses front-load the verb and then map directly to frequency, day_of_week, and day_of_month with no filler. Slightly telegraphic, but every fragment carries useful parameter 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 description covers the core inputs and frequency values, but with no output schema it leaves the return shape unstated. It also does not explicitly explain conditional dependencies such as 'day_of_week applies only when frequency=Weekly' beyond a parenthetical, though the schema already conveys much of this.

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 86%, so the high-coverage baseline applies. The description largely restates schema fields ('Daily, Weekly, Monthly', 'Mon/Tue/Wed/Thu/Fri', '1-28') rather than adding new meaning such as conditional-required logic or interaction with allow_margin.

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

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

States a specific verb ('Create') and resource ('DCA recurring investment plan'), immediately distinguishing it from management siblings like dca_update, dca_pause, and dca_stop. The scheduling parameters reinforce the tool's domain and scope.

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 use when setting up a new DCA plan, but it never names alternatives or says when not to use this tool. With a large DCA family (dca_update/dca_stop/dca_resume), an explicit routing note would elevate this dimension.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that records are scoped by plan_id, which is useful. However, it doesn't disclose pagination behavior, ordering, or what fields the records contain. 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, efficient sentence that front-loads the action and resource. It's concise and to the point. It could add a bit more context about pagination or return format, but for its length it's well-structured.

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

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

For a read-only list tool with annotations covering safety and schema covering most parameters, the description is adequate. However, there's no output schema, and the description doesn't mention what the execution history records contain, how they're ordered, or how pagination works. An agent could call it correctly with plan_id, but might not know what to expect in the response.

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%: plan_id, page, and limit have descriptions, while _jq has none. The description adds minimal value beyond the schema—it confirms plan_id is the key filter. The _jq parameter is undocumented in both schema and description, which is a gap, but the core parameters are already well-described in 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 states a specific verb ('Get'), a resource ('execution history records'), and a scope ('for a DCA plan by plan_id'). It clearly identifies what the tool does. It doesn't explicitly distinguish from siblings like today_executions or history_executions, but the DCA plan scoping is a clear differentiator.

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

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

The description implies usage context: use this when you need execution history for a specific DCA plan. It doesn't explicitly state when not to use it or name alternatives like history_executions or today_executions. The context is clear enough for an agent to infer, but no explicit routing guidance 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the filtering behavior (by status or symbol) and the fact that omitting filters returns all plans, which is useful. It does not disclose pagination behavior beyond the schema's page/limit defaults, but that is a minor gap given the annotations carry the main behavioral burden.

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

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

Two sentences, zero filler. The main action and resource are front-loaded, and the filter options are stated compactly. Every word earns its place.

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

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

For a read-only list tool with no output schema, the description plus annotations cover the essential call context: what it lists, how to filter, and that it is safe/idempotent. Pagination defaults are in the schema. It could mention that the response is a paginated list, but the schema's page/limit parameters already imply that. Slightly more detail on return shape would push this to 5, but it is not necessary 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 80%, so the schema already documents most parameters. The description adds the meaning of the status filter (Active/Suspended/Finished) and the symbol filter example ('AAPL.US'), which slightly enriches the schema. The _jq parameter is undocumented in both schema and description, but at 80% coverage the description is not required to compensate fully. 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 states a specific verb ('List') and resource ('DCA recurring investment plans'), and immediately distinguishes itself from sibling tools like dca_history, dca_stats, dca_update, dca_create, dca_pause, dca_resume, dca_stop, and dca_check. It also names the two filter dimensions (status and symbol), which makes the tool's scope 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 clearly implies when to use this tool: when you need a list of DCA plans, optionally filtered by status or symbol. It does not explicitly name alternatives or exclusions, but the sibling set is large and the description's filter hints (status/symbol) plus the title 'List DCA Plans' make the use case clear. It could be improved by explicitly saying 'use dca_history for past executions' or similar, but the context is sufficient.

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 discloses the core behavioral effect: the plan stops executing until resumed. It also mentions the return value ('Returns upstream API response'). The annotations already indicate readOnlyHint=false and idempotentHint=true, so the description adds context about reversibility and the specific effect on executions. It does not contradict the annotations and adds meaningful behavior beyond 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 two sentences with no filler. The primary action is front-loaded, and each sentence contributes either the purpose, the effect, or the pointer to the resume tool. It is minimal yet complete.

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 state-change tool, the description covers the key points: what it does, the effect, and the path to undo (via resume). It does not discuss required parameters beyond plan_id or error handling, but given the schema and annotations are available, it is fairly complete. A mention of the difference from dca_stop or the _jq parameter would have made it more robust.

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

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

The description references plan_id as the identifier ('by plan_id') but does not explain the second parameter _jq, which is present in the schema and lacks a description (schema coverage is only 50%). The description adds value for plan_id by clarifying its role but fails to compensate for the undocumented _jq parameter. It would need to mention _jq or its purpose to be more helpful.

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 action ('Pause (suspend)'), a specific resource ('a DCA plan'), and the mechanism ('by plan_id'). It also differentiates from the sibling tool by explicitly naming dca_resume as the restart counterpart. This leaves no ambiguity about what the 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 tells the agent when to use this tool (to pause a plan) and points to an explicit alternative ('Use dca_resume to restart'). However, it does not mention the sibling dca_stop, which is a related but distinct operation. Since it names one clear alternative and implicitly contrasts pause with resume, it provides solid guidance, but a mention of dca_stop would have made it more complete.

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

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

The description adds useful behavioral context beyond the annotations: it states that execution resumes on the configured schedule and that the result is an upstream API response. It still withholds details like error cases or what happens when the plan is not already suspended, but the annotations already cover the basic mutation/idempotency profile.

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 short and front-loaded: the first sentence gives the core action, and the second gives the behavioral outcome. No filler is present, though the third sentence about the upstream response is useful but slightly generic.

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 relatively simple one-required-input tool and the available annotations, the description provides adequate context on what it does and what is returned. It does not fully explain the undocumented `_jq` parameter, possible error conditions for non-suspended plans, or details about the upstream response structure, so the overall picture remains partially 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 description mentions 'by plan_id' but this only repeats the schema, adding little meaning beyond the parameter name and type. Schema description coverage is only 50% because `_jq` has no description, and the tool description does not clarify the purpose or whether it should be provided, leaving a significant gap for agent understanding.

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 action ('resume'), the resource ('DCA plan'), and the key input ('plan_id'), which is enough to understand the tool's core purpose. It differentiates from obvious siblings by the resume/suspend relationship, but it does not explicitly name any sibling it is distinct from.

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 'Resume a suspended DCA plan' implies the appropriate condition for use, and 'resumes automated execution on the configured schedule' clarifies the expected effect. However, there is no explicit guidance about when not to use this tool or which sibling alternatives (e.g., dca_pause, dca_stop, dca_update) should be selected instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond the word 'Get', but it does not contradict the annotations. Since the annotations carry the behavioral burden, this is minimally acceptable.

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 zero filler. Every word contributes to identifying the operation, and it is appropriately sized for such a simple tool definition.

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

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

There is no output schema, so the description should compensate by explaining what statistics are included, how symbol filtering behaves, and how this differs from related DCA tools. The description provides none of this, leaving an agent to infer the response shape and appropriate usage from the name alone.

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

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

Schema description coverage is only 50%, with the symbol parameter documented and _jq completely undocumented. The description does not compensate by explaining either parameter or the meaning of the returned statistics. An agent must guess what '_jq' is for and what statistical measures are provided.

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 and resource: 'Get DCA investment statistics.' It is unambiguous about what the tool does, though it does not explicitly differentiate itself from sibling tools like dca_history, trade_stats, or dca_list. The 'DCA' qualifier narrows it enough for basic identification.

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

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

The description gives no guidance on when to use this tool versus siblings such as dca_history, dca_list, or trade_stats. It does not state when it should be preferred, what it returns that others do not, or any exclusions. Given the large sibling set, this is a clear gap.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds crucial context beyond the annotations: 'This cannot be undone' and 'Returns upstream API response.' The irreversibility warning is a meaningful behavioral disclosure that the annotations alone don't fully convey. The description doesn't contradict the annotations. It could go further by noting whether the action requires special permissions or what happens to associated orders, but the irreversibility warning is strong. A 4 is appropriate because it adds value beyond annotations without fully describing all behavioral consequences.

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

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

Three sentences, each earning its place: the action and irreversibility, the alternative tool, and the return behavior. The most important information (permanent, irreversible) is front-loaded. 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 single-required-parameter mutation tool with no output schema, the description covers the essential context: what it does, that it's irreversible, the alternative for pausing, and what it returns. The annotations cover idempotency and destructiveness. The only minor gap is that it doesn't describe error conditions or side effects on related resources (e.g., pending orders), but given the tool's simplicity, this is adequate. A 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 50%: plan_id has a description ('Plan ID') but _jq has none. The description mentions 'by plan_id', which reinforces the key parameter's role. However, the description doesn't explain what _jq is for or how to format plan_id. With 50% coverage, the description partially compensates but doesn't fully close the gap. Baseline 3 is fair since the main parameter is documented in the schema and the description confirms its role.

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 ('Permanently stop'), a specific resource ('DCA plan'), and the key identifier ('by plan_id'). It also explicitly distinguishes itself from the sibling dca_pause, which is critical given the large sibling list. This is a clear, unambiguous purpose statement.

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

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

The description explicitly says when to use this tool ('Permanently stop') and when not to ('To temporarily pause, use dca_pause instead'). It names the alternative tool directly, giving the agent a clear decision rule. This is exactly the kind of usage guidance that helps an agent select between siblings.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=true mirroring the mutation intent; the description adds the return value ('Returns updated plan') but doesn't disclose any side effects, idempotency, or partial-update semantics. With no annotation contradiction ****and some description of the return, 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 dense sentence that front-loads the main action ('Update an existing DCA plan by plan_id') and then lists modifiable fields. It avoids redundancy with the schema. However, it could be slightly more scannable with bullets or a second sentence for exclusions.

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?

Annotations indicate readOnlyHint=false, idempotent=false, and destructiveHint=true, signaling a mutating endpoint with side effectsikuha—but the description doesn't warn about consequences (e.g., whether changing frequency resets the schedule, whether old values are irreversibly replaced, or whether margin changes trigger a re-evaluation). No output schema exists to describe the response. For a mutation tool, this is a notable gap.

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

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

Schema coverage is high (86%), with parameter descriptions already present. The description adds meaning by explaining the update semantics, e.g., day_of_month applies only to Monthly frequency per the 1-28 range, and frequency choices are explicit. This fills the small parametric gap (e.g., _jq) and reinforces usage.

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 ('Update') and resource ('DCA plan'), and explicitly lists the mutable fields (amount, frequency, day_of_week, day_of_month). This distinguishes it from sibling tools like dca_history and dca_pause, and the update intent 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?

No guidance is provided on when to use this tool instead of other DCA tools (e.g., dca_create, dca_pause, dca_stop). There is no mention of prerequisites, whether plans are in active status, or whether syncing is needed. The description covers what but not when or why.

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 signal destructive behavior and non-read-only status; the description adds specific context by explaining the purge side effect: removing securities from all other groups. This goes beyond the generic destructiveHint and gives the agent a clearer picture of consequences.

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 core action ('Delete a watchlist group by id') before adding the conditional purge detail. Every word earns its place, with no redundancy or filler.

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

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

For a simple delete operation with annotations and schema covering the required parameters, the description is nearly complete. It covers the key destructive nuance (purge behavior) and required inputs, though it omits details about return values/errors and the _jq parameter.

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 already describes id and purge, and the description reinforces id as numeric and clarifies purge behavior. However, it does not explain the undocumented _jq parameter, and only 67% of parameters have schema descriptions, leaving a gap the description does not fill.

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 action ('Delete a watchlist group') and the targeted resource, plus the key parameter semantics ('by id (numeric)'). It is specific enough to differentiate from generic tools, though it does not explicitly distinguish itself from create_watchlist_group or update_watchlist_group, so it stops short of a 5.

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

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

No guidance is provided about when to use this tool versus alternatives, and there are no exclusion conditions or mention of prerequisites. The only conditional instruction ('Set purge=true...') describes an option within the tool, not when to choose this tool over siblings.

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

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

The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description adds value by disclosing the exact return shape (items[]{id, amount, currency, status, created_at, updated_at}) and filter semantics (states and currencies). No contradiction with annotations exists.

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

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

Three short, information-dense sentences: purpose, return shape, and filter hints. The purpose is front-loaded, and every sentence adds value without repetition or filler.

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

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

For a read-only list endpoint with no output schema and five optional parameters, the description covers the essential invocation details: action, account scope, return fields, and filter values. It does not describe pagination behavior or sort order, but the schema already documents page and size defaults, so this is a minor gap.

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

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

The schema already describes page, size, states, and currencies, so baseline is 3. The description adds meaningful detail beyond the schema by enumerating the allowed state values (Pending/Finished/Failed) and confirming the comma-separated format for both filters. It does not cover _jq, but that is an unclear power-user parameter not essential to basic invocation.

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 deposit history for the current account.' This clearly distinguishes the tool from siblings like account_balance, withdrawals, and bank_cards, and the added return-field list makes its scope 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?

The description implies when to use the tool—when deposit history is needed for the current account—but it does not explicitly contrast it with alternatives such as withdrawals or account_balance. There is clear context and filter guidance, but no explicit when-not-to-use or sibling routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the 'up to 10 price levels' limit, which is useful behavioral context beyond annotations. However, it doesn't mention return format (e.g., bids/asks structure) or any rate limiting, so it's adequate but not rich.

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 that gets to the point quickly. It front-loads the core functionality and adds the level limit. No wasted words, but it could be slightly more detailed without much bloat.

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 tool with no output schema. The description covers the essential purpose and a key limit, but doesn't explain the response structure (bids/asks) or the '_jq' parameter. For a simple market data tool with safe annotations, it's reasonably complete, but missing the parameter explanation is a gap.

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

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

The schema covers the 'symbol' parameter well (with example '700.HK'), but the '_jq' parameter has no description in the schema (coverage 50%). The description doesn't mention '_jq' at all, leaving it undocumented. Since the description fails to explain the one undocumented parameter, it doesn't fully compensate, but the symbol is well-covered, so it's slightly above baseline.

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

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

The description states a specific verb ('Get') and resource ('order book depth'), and it mentions a key constraint ('Up to 10 price levels'). It is clear what the tool does, though it doesn't explicitly differentiate it from sibling tools like 'quote' or 'intraday', but the purpose is unambiguous given the resource name.

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

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

The description gives no guidance on when to use this tool versus alternatives. It doesn't mention context (e.g., for market analysis) or any exclusions (e.g., not for historical data). Without sibling differentiation, an agent might confuse it with quote or candlesticks, as the description lacks usage 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?

The description adds valuable behavioral detail beyond the annotations: it discloses that US accounts querying .US symbols get a US-specific variant and explains the percent-value convention (0.34 = 0.34%). While annotations already declare readOnly, idempotent, and non-destructive, this description enriches behavior and does not contradict the annotations.

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

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

The description is two purposeful sentences. The first sentence clearly states the core action, and the second adds an important regional variant. There is zero fluff or redundancy; the message is front-loaded with the primary 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 description is sufficient to invoke the tool correctly in terms of the required 'symbol' parameter, but it leaves gaps: it doesn't explain what the returned dividend history contains, doesn't touch upon the undocumented '_jq' parameter, and doesn't clarify how 'dividend' differs from 'dividend_detail'. Given no output schema, more context about return data would have been valuable.

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 description already covers 'symbol' with an example, and the description does not add any new meaning to that parameter. The _jq parameter is undocumented in the schema, and the description also fails to explain it. With 50% schema coverage, the description does little to compensate for the missing parameter semantics.

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

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

The description states a clear verb and resource: 'Get dividend history for the symbol.' This distinguishes it from a generic 'process' tool and makes its purpose obvious. However, it does not explicitly differentiate itself from the sibling tool 'dividend_detail', so it loses one point against the sibling-differentiation criterion.

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 no guidance on when to use this tool over alternatives like 'dividend_detail'. There is no mention of exclusions, prerequisites, or alternative tools. The only context is the US/US-symbol variant, which is not a usage-direction clue, so the guidance is essentially absent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not add behavioral context beyond them. It offers no information about response shape, pagination, or operational behavior, although it does not contradict the annotations.

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

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

The description is a single, direct sentence with no filler or redundant restatement. It is front-loaded and every word contributes to identifying the operation, even if the overall definition is sparse.

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

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

With no output schema, the description should clarify what 'detailed dividend distribution scheme' includes and how it differs from the sibling `dividend` tool. It provides only a vague noun phrase, leaving the agent without enough information to anticipate the response or choose confidently between related 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 coverage is only 50%: `symbol` is described but `_jq` is not. The description does not explain either parameter or how the dividend detail is keyed, so an agent cannot fully infer the meaning of `_jq`.

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 ('Get') and resource ('detailed dividend distribution scheme'), making it clear this is a read operation for dividend details. It reasonably distinguishes from the sibling `dividend` tool by emphasizing 'detailed', though it does not specify what the scheme contains.

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 sibling tools like `dividend`, nor any context about prerequisites or selection criteria. The description only implies utility through its purpose, leaving alternatives undocumented.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds no further behavioral context (e.g., that this does not place an order, or that it uses current account balances). It focuses on parameter defaults rather than disclosing non-obvious behavior, but given the annotations, it does not contradict 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 a single, well-structured sentence that immediately states the purpose and then lists the default behaviors in a compact, readable way. There is no redundancy or filler; every clause contributes to understanding the tool's usage.

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 the tool is simple and the annotations cover safety, the description does not specify what the return value represents (e.g., a numeric quantity, an error structure) or any prerequisites like market data availability. Given there is no output schema, a brief explanation of the expected result would improve completeness, but the core purpose is adequately conveyed.

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

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

Schema description coverage is 80%, with clear descriptions for side, price, order_type, and symbol. The description essentially restates what the schema already says (only symbol required, defaults for side and order_type, price optional). It adds no new parameter semantics that aren't already present in 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 a specific action ('Estimate maximum buy/sell quantity') and a specific resource ('for a symbol'). It distinguishes itself from siblings by focusing on estimation rather than order placement or other operations. It also conveys the essential input requirements compactly.

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 context on required versus optional parameters ('Only symbol is required') and notes defaults, which informs when the tool could be called. However, it does not explicitly name alternatives or conditions for using this tool over other order-related siblings, leaving the 'when to use vs. alternatives' guidance largely implicit.

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 behavioral context beyond annotations by specifying the region restriction and the exact error name (DcRegionRestricted) for AP accounts. Annotations already declare readOnly and idempotent, so no side effects need disclosure. This extra error detail is valuable and not redundant.

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 with zero filler. The primary purpose is front-loaded, followed by the region restriction. Every word serves a purpose, and the length is appropriate for the tool's simplicity.

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

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

The description covers the essential purpose and a critical region-specific behavior. The schema documents the required symbol and optional limit, which is sufficient for a read-only document retrieval tool. It does not describe return format or pagination, but for a safe, idempotent read operation these are less critical. The undocumented _jq parameter is a minor gap.

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

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

The description adds no parameter-specific information. Schema descriptions cover symbol and limit, but the optional _jq parameter has no description in either the schema or the tool description. With 67% schema coverage (moderate, not high), the description should compensate for the undocumented parameter but does not, leaving _jq ambiguous.

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 verb 'Get' and the resource 'regulatory/prospectus documents (etf-files) for a US ETF'. It is specific enough to distinguish from sibling tools like filings or financial_report, which cover broader or different document types. The US-only scope further narrows purpose.

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

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

The description explicitly states 'US accounts only' and mentions that AP accounts will error with DcRegionRestricted, giving a clear condition for when not to use this tool. However, it does not mention alternative tools or when to prefer this over other document-related tools, so it lacks a full comparison.

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, open-world, idempotent, and non-destructive, and the description's 'Get' matches those semantics. It adds the return field names and scope, which is useful, but it does not disclose behavior such as data freshness, rate basis, or whether results are static vs. real-time.

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 short sentences, front-loads the action and result, and wastes no words. The return structure and currency examples are placed immediately after the main 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?

For a simple read-only lookup, the description gives adequate scope and output shape. But it leaves the only parameter completely unexplained and provides no caveats about rate timing, supported currency list, or response size, so an agent still has open questions before calling it.

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

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

The only parameter, _jq, has 0% schema description coverage and the tool description does not mention it at all. Since the description must add meaning beyond the schema and it does not compensate for this gap, an agent has no way to know what _jq does or whether it is required.

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-plus-resource construction: 'Get exchange rates for all supported currencies.' It names the output shape (list of from/to currency, rate, timestamp) and example currency scope, so an agent can distinguish this from the many sibling market-data tools without opening the schema.

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

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

The description implies a general read-only lookup use case ('all supported currencies'), and no sibling tool appears to compete with this purpose. However, it gives no explicit guidance on when to choose this over alternatives, nor does it mention that no currency-scoping parameters are needed.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond the purpose—it does not describe the response structure, whether data is snapshot or historical, pagination, or any other implementation detail. For a tool with no output schema, this is a notable gap.

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 extremely concise—a single sentence with no filler. It front-loads the core action clearly. However, its brevity edges toward under-specification, as it omits useful detail without becoming verbose; it earns a high score for efficiency but not perfection.

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 no output schema, the description should clarify what information is actually returned. It only says 'executive and board member information,' which is vague and does not specify fields, formatting, or any prerequisites. Given the complexity of financial data tools and the large sibling set, this description is incomplete for effective agent usage.

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 describes the required 'symbol' parameter with an example, but the optional '_jq' parameter has no schema description, and overall schema description coverage is only 50%. The description itself makes no mention of any parameters, so it does not compensate for the missing '_jq' explanation or add any parameter-related context beyond what the schema 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 is a single clear sentence stating it retrieves executive and board member information. It specifies the resource type but does not explicitly differentiate it from sibling tools like 'company' or 'institutional_views', though the focus on executives/board members is distinct enough for an agent to infer.

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 provided on when to use this tool versus alternatives. The description does not mention any conditions, exclusions, or related tools, leaving the agent without context for selecting it among many similar data-query siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds the return format and scope ('for the symbol'), which is useful but not extensive. No contradiction with annotations.

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

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

Two concise sentences, front-loaded with the core purpose and return structure. No wasted words; every sentence 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?

For a simple read-only tool with annotations covering safety, the description provides the return items and scope. It lacks pagination or filtering details, but these are not critical given the tool's simplicity and the presence of annotations.

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

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

Schema coverage is only 50% (symbol documented, _jq undocumented). The description mentions 'for the symbol' which aligns with the symbol parameter, but it does not explain _jq or add any detail beyond the schema. It fails to compensate for the coverage gap.

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

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

The description clearly states the verb 'Get', the resource 'regulatory filings', and lists example types (8-K, 10-Q, 10-K). It also specifies the return structure, making the tool's purpose unmistakable and distinct from siblings like etf_docs.

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 use when regulatory filings for a symbol are needed, but it does not explicitly contrast with alternative tools or state when not to use it. The context is clear enough for a data-retrieval tool, though exclusions are absent.

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?

Adds meaningful behavior beyond the read-only annotations: it discloses default date behavior and the truncation risk for ranges over two weeks. No contradiction with readOnly/openWorld/idempotent hints.

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

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

Two compact sentences front-load the tool's purpose, then cover optional parameters, defaults, and a critical usage constraint (2-week range cap). 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?

Complete enough for a read-only calendar query: category values, date defaults, and truncation behavior are all disclosed. It does not explicitly repeat the required category parameter, but that is present in the schema, and no output schema exists to detail return values.

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?

Adds value beyond the schema by explaining that start and end default to today plus 7 days and that ranges over 2 weeks may be truncated. With 80% schema coverage, the description complements rather than duplicates the schema, though _jq remains unexplained.

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

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

Names a specific resource (finance calendar) and enumerates the exact event categories it covers, which makes its purpose immediately clear. It does not explicitly contrast itself with overlapping sibling tools like corp_action or dividend, but the category list provides enough differentiation for selection.

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: start/end are optional, default to today plus 7 days, and ranges should stay under 2 weeks to avoid truncation. It does not explicitly state when to prefer this over sibling tools, but the category-driven description gives sufficient guidance for most cases.

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, destructiveHint=false, and idempotentHint=true, so the description is not required to restate these. It adds no extra behavioral context such as rate limits, response volume, or handling of invalid symbols. The description is consistent with annotations and does not contradict them, but it does not enrich the behavioral picture.

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 that front-loads the core purpose ('Get financial reports') and then packs the parameter value definitions into a compact shorthand. There is zero fluff, and every part earns its place. It is highly concise while conveying essential 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 read-only data retrieval tool with a required symbol parameter and two optional parameters fully explained in the schema, the description covers the essential calling information. It does not describe the return format, but no output schema exists and annotations already cover safety. The main gap is the lack of usage guidance relative to siblings, but that is captured in a separate dimension. Overall, the description is sufficient for a correct call.

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%, with kind, report_type, and symbol each having descriptions. The description repeats the kind and report_type values in shorthand (IS/BS/CF/ALL, af/saf/q1/q2/q3/qf) but does not add meaning beyond what the schema already provides. It does not clarify edge cases like default values (kind defaults to ALL per schema) beyond what the schema states. Baseline 3 is appropriate given high schema coverage.

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 retrieves financial reports (income statement, balance sheet, cash flow) and enumerates the kind and report_type values. The purpose is specific and understandable. However, it does not explicitly differentiate itself from sibling tools like financial_report_latest or financial_report_snapshot, which limits sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives such as financial_report_latest or financial_statement. It does not mention prerequisites, exclusions, or conditions that would route an agent to a different tool. The agent must infer usage from the name and parameters 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false). The description adds useful behavioral context beyond that: the region restriction and the specific DcRegionRestricted error for AP accounts. 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 two tight sentences with no filler. It front-loads the core action and resource, then packs the report options and regional constraint 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?

For a read-only data retrieval tool with three parameters and no output schema, the description covers the essential invocation details: action, resource, report choices, default, and error condition. It omits return-format details and _jq semantics, but the core usage is sufficiently complete for an agent to call it correctly.

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

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

Schema coverage is 67%, with _jq undocumented. The description repeats the report option values already present in the schema and mentions the US-symbol context, but adds no substantive parameter meaning beyond the schema. A baseline 3 is appropriate since description coverage is in the mid range.

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 verb ('Get') and resource ('key financial metrics (fin-keyfactor)') for US symbols, and includes report-period terms. However, it does not distinguish this tool from sibling tools like financial_report_latest or financial_report_snapshot, so it stops short of a 5.

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

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

There is an explicit usage restriction ('US accounts only') and a concrete failure signal ('errors with DcRegionRestricted for AP accounts'), which gives some when-not guidance. But the description does not mention any alternative tool to use for non-US accounts or for other financial report needs, so the guidance is incomplete.

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, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds a modest behavioral cue by specifying a 'summary' result and 'latest' time scope, but it does not disclose what the summary contains, data freshness, or any limitations.

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 clear sentence with no filler. It front-loads the action and object, and every word contributes to the core 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?

With no output schema, the description should explain what a 'latest financial report summary' actually returns, but it does not. It also fails to route the agent among the many financial-report sibling tools, leaving a significant completeness gap for a data-retrieval tool.

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

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

Schema coverage is 50%, with the symbol parameter described and the _jq parameter left undocumented. The description only says 'for a security,' which adds little beyond the schema's symbol description and does not compensate for the undocumented parameter or clarify symbol format or requirements.

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 ('latest financial report summary') plus a target ('a security'). It clearly states what the tool does, but it does not distinguish itself from the many sibling financial-report tools such as financial_report, financial_report_snapshot, or financial_report_key_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 gives no guidance on when to use this tool instead of alternatives. With multiple closely related financial-report siblings, an agent has no basis for choosing this tool over financial_report_snapshot or financial_report_key_metrics.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds some context about the returned content (e.g., yoy/cmp, ratio types), which is useful but not behavioral in nature. No additional behavioral traits (rate limits, pagination, auth) are disclosed, so 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, compact sentence that front-loads the purpose and uses a colon and commas to organize field groups. It is efficient with no filler, though the dense comma-separated list could be slightly more readable. Still, it earns a 4 for economy and structure.

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 5 parameters, no output schema, and a moderately complex data structure, the description is only partially complete. It lists some return fields but omits how fiscal_year/fiscal_period interact or the meaning of the '_jq' parameter. It does not explain the full return shape or edge cases, so it meets the minimum but leaves 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 covers 80% of parameters with descriptions, so the baseline is 3. The description adds a redundant mention of report types ('qf/saf/af') already present in the schema, and mentions output fields (fo_revenue etc.) but not parameter specifics. It does not compensate for the undocumented '_jq' parameter, but overall it adds minimal 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 action ('Get financial report snapshot') and lists the specific data fields returned (report_desc, fo_revenue/ebit/eps, fr_* ratios). It is specific enough to distinguish from generic report tools, though it does not explicitly differentiate from close siblings like financial_report_latest or financial_report.

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 provided on when to use this tool versus the many sibling financial report tools. It neither states prerequisites nor excludes alternatives, leaving the agent to guess based on the name alone.

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

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

The readOnly, idempotent, and non-destructive hints are already provided by the annotations)Skip; the description confirms a read-only retrieval operation. It adds no extra behavioral caveats (e.g., pagination, default report period fallback), but no annotation contradiction exists.

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

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

Two compact sentences: the first states the tool's purpose Capitalization, the second explains parameter values. The list of report periods is packed but readable. No 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 readOnly and idempotent annotations, the usage context is mostly safe. However, the description does not clarify when to prefer this tool over financial_report, financial_report_snapshot, or financial_report_key_metrics, and does not describe the response shape. From a decision perspective, an agent might struggle to differentiate from those siblings.

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

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

The description explains the meaning of 'kind' (IS/BS/CF) and 'report' (af, qf, q1/q2/q3), which is valuable because the schema only describes 'symbol'. However, _jq remains unexplained, and the mapping between q1/q2/q3 and quarters is implied rather than explicit.

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'), a clear resource ('financial statements'), and enumerates the statement types (income statement, balance sheet, cash flow) via the kind parameter. This distinguishes it from broad tools like company or dividend, though it doesn't explicitly differentiate from closely named siblings like financial_report or financial_report_snapshot.

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

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

The description gives no guidance on when to use this tool versus siblings such as financial_report, financial_report_snapshot, or statement_export. It doesn't mention prerequisites, common use cases, or which statement type to request under which circumstances.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the tool returns both forecast and historical estimates, which is useful. However, it does not disclose details like whether the data is delayed, what time range is covered, or whether it requires specific market data subscriptions. With annotations covering the core behavioral traits, 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 main purpose. It is efficient and easy to parse, though it could have added a brief note on usage context without becoming verbose.

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 data retrieval tool with one required parameter and no output schema, the description is adequate but not complete. It does not explain what the returned data looks like (e.g., fields like forecast EPS, number of analysts, estimate history period) or any limitations. Given the tool's simplicity, this is a minor gap, but the description could be more helpful.

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 50%: the 'symbol' parameter is documented with an example, but '_jq' has no description. The description does not add meaning for '_jq' or clarify the expected format of the response. Since the schema covers half the parameters and the description adds no extra parameter context, 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 'Get EPS forecast and analyst estimate history' clearly states the verb (Get) and resource (EPS forecast and analyst estimate history). It distinguishes itself from siblings like financial_report_latest or consensus, though it doesn't explicitly name an alternative. The title 'Forecast EPS' reinforces the purpose, so the agent can infer what data this tool returns.

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

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

The description implies usage for retrieving EPS forecast data, but it does not explicitly state when to use this tool versus alternatives like 'consensus' or 'financial_report_latest'. There is no mention of prerequisites or context (e.g., requires a symbol, only for stocks with analyst coverage). The guidance is minimal but not misleading.

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 idempotentHint, so the safety profile is covered. The description adds that the lookup covers funds and ETFs holding a given symbol, but it does not note limitations such as pagination, date scoping, or whether only certain markets are covered.

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