longbridge

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 the return structure (balances[] with fields) and the currency filter behavior, which is useful. However, it does not disclose details like pagination, rate limits, or what happens when no currencies match. With annotations covering the safety profile, 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?

Two sentences with no waste. The main purpose is front-loaded, followed by the return structure and the filter option. 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, idempotent tool with 100% schema coverage and no output schema, the description is quite complete. It states what the tool returns, the filter option, and the safety profile is covered by annotations. The only minor gap is not describing the exact shape of the balances[] array beyond field names, but that is acceptable given the description lists 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?

Schema description coverage is 100%, so both parameters (_jq and currency) are already documented in the schema. The description adds a concrete example of currency values ('USD', 'HKD') and clarifies that omitting currency returns all currencies, which slightly enhances the schema. Baseline 3 is correct since the schema does the heavy lifting.

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 balance) and the action (get), and it lists the return fields. It is distinguishable from siblings like stock_positions or fund_positions because it focuses on cash balance and asset summary, not positions.

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

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

The description provides a clear usage context: it is for retrieving account cash balance and asset summary, with an optional currency filter. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it for balance-related queries. Sibling tools like stock_positions or fund_positions are position-focused, so the distinction is 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the return contract (items[] with timestamp, open, high, low, close as premium percentages) and the 'over the given period' scoping, which is useful behavior beyond the schema.

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

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

The description is a single front-loaded sentence: the action and resource come first, followed by a compact statement of the returned fields. There is no filler, redundancy, or repeated schema content.

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

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

For a simple read-only K-line retrieval tool with fully documented parameters and no output schema, the description covers the key return structure and resource scope. It lacks an explicit note about edge cases (e.g., empty records for padded symbols), but that is already documented in the symbol parameter description, so nothing critical is missing 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 100%, so the parameters (symbol, period, count, _jq) are fully documented in the schema; the description adds no new parameter-level detail. Baseline 3 is appropriate because the schema carries the semantic burden and the description does not contradict or enrich it.

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

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

The description opens with a specific verb-resource pair ('Get A/H share premium historical K-line data') that names the exact data product and distinguishes it from the sibling ah_premium_intraday by the word 'historical'. It also states the output shape, leaving no ambiguity about what the 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 word 'historical' implies this tool is for non-intraday premium K-lines, and the sibling ah_premium_intraday provides the contrast, but there is no explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are named, so the agent must infer the selection criteria.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds specifics: returns items with timestamp and premium_rate, and implies minute-by-minute resolution. It avoids contradicting annotations and provides useful context beyond the generic 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?

The description is two sentences, clear, and front-loaded with the purpose. It includes essential return structure without fluff, earning each word.

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

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

Given the tool's simplicity (one required param, no output schema, no nested objects), the description covers the key details: what data is returned and the meaning of the fields. It lacks explicit mention of time range or pagination, but these are likely minor for a simple intraday 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 100%, so the schema fully documents both parameters. The description does mention the symbol example and warns about padded codes (which is beyond the schema), adding marginal value. Given high schema coverage, 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 retrieves intraday A/H premium data with a specific resource and time granularity. It distinguishes from the sibling `ah_premium` by specifying 'intraday' and 'minute by minute', though it could be more explicit about the exact difference.

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

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

The description implies usage for intraday data without explicit guidance on when to choose this over `ah_premium` or other data tools. It lacks direct comparison to the historical or daily counterpart, leaving some inference 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 communicate that this is a non-read-only, non-idempotent, non-destructive operation. The description adds that the tool 'Returns created alert object,' which is useful since there is no output schema. However, it does not disclose side effects, activation behavior, duplicate-alert behavior, or whether created alerts require additional setup—so it only modestly exceeds 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 compact and front-loaded: one clear action sentence, then the two most decision-relevant parameter dimensions, then the return value. Every clause earns its place and no unnecessary filler is present.

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 create tool with five parameters and no output schema, the description covers the main semantic distinctions and the return shape. The main gap is that frequency is optional but the description does not state a default behavior when the agent omits it, which could leave an agent unsure about how the alert will behave.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explicitly grouping price_rise/price_fall as absolute price and percent_rise/percent_fall as relative %, which the schema alone does not state. It also restates frequency options, though the schema already covers their detailed 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 opens with a specific verb-plus-resource statement: 'Add a price alert.' It clearly distinguishes this tool from sibling alert tools like alert_delete, alert_enable, and alert_list, and it further explains condition and frequency variants so the agent knows exactly what the tool creates.

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 on how to configure the alert by differentiating absolute-price conditions from percentage-relative conditions and defining frequency options. It does not explicitly state when not to use this tool versus alert_delete/alert_enable/alert_list, but the create-vs-manage distinction is strongly implied.

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

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

Annotations already signal destructive and idempotent behavior; the description adds that a successful call returns the upstream API response and that an invalid alert_id produces an error. It does not contradict the annotations and adds useful call outcome context, though it does not elaborate on permanence or side effects.

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, each earning its place: the first states the action and required identifier, the second summarizes success/error outcomes. No filler.

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

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

For a one-required-parameter delete operation, the description covers what is deleted, where to get the ID, and the success/error contract. Since there is no output schema, 'Returns upstream API response' is enough to set expectations, though a slightly more concrete response shape would be more 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 already documents both parameters, so the baseline is 3. The description adds the crucial fact that alert_id is a 'numeric string from alert_list', which is more specific than the schema's 'Alert indicator id' and explains the expected format/source.

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

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

Description opens with the action verb 'Delete' and names the exact resource ('price alert') plus the required identifier source ('alert_id ... from alert_list'). This clearly distinguishes it from sibling alert tools such as alert_disable and alert_enable.

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 states that the alert_id must come from alert_list, giving the agent the prerequisite lookup step. It implies deletion as opposed to disable/enable but does not explicitly say when to prefer delete over alert_disable, so it lacks formal exclusions.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the description adds little behavioral detail. It does not clarify whether 'disable' is reversible or how it differs from deletion, but the idempotency annotation partially compensates for that 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 one concise sentence with no filler. The core action and parameter are stated up front, and the helpful navigation hint follows naturally.

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 mutation tool with one required parameter and strong annotations, the description is nearly complete. The main gap is explaining the effect of disabling versus deleting an alertholistically, but the current text is adequate for a low-complexity tool.

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

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

Schema description coverage is high at 100%, so the baseline is 3. The description adds value by specifying that alert_id is numeric and telling the agent where to find it, which improves the parameter semantics beyond the schema's generic 'Alert indicator id'.

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 ('Disable') and resource ('price alert') with the identifying parameter ('alert_id'), which clearly distinguishes it from sibling tools like alert_enable and alert_delete. It is immediately obvious what this tool does and which resource 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 instructs the agent to use alert_list to find the numeric alert_id, providing useful operational guidance. It does not explicitly contrast when to use disable versus delete/enable, but the verb and id guidance make the intended usage clear enough.

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

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

The description is consistent with annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) and adds no contradicting information. However, it contributes little behavioral detail beyond the verb 'enable' — the mutation, idempotency, and non-destructiveness are already carried by the annotations, and the description adds no new facts about side effects, errors, or state changes.

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

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

Two short sentences with zero filler. The core action is front-loaded in the first sentence, and the second sentence earns its place by supplying the lookup cross-reference. Nothing could be removed without losing 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 simple mutation tool with one required parameter, no output schema, and annotations already covering idempotency and non-destructiveness, the description is essentially complete. The only minor gap is not addressing behavior when the alert doesn't exist or is already enabled — but the idempotentHint annotation partially mitigates 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 coverage is 100%, but the schema's alert_id description ('Alert indicator id') is weak and tautological. The tool description adds genuine value by specifying that the ID is numeric and by telling the agent exactly where to obtain it (alert_list). This exceeds the baseline expected when the schema already documents parameters.

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

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

States a specific verb and resource — 'Enable a price alert by alert_id' — and the verb 'enable' distinguishes it from the sibling family (alert_add, alert_disable, alert_delete, alert_list) without needing to open any schema. An agent can tell exactly what this tool does and what it is not.

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, actionable context by pointing the agent to alert_list as the source for the numeric alert_id — addressing the key precondition. However, it does not explicitly state when to choose this over alert_add (creating a new alert) or alert_disable (the inverse operation), so exclusion guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond the basic retrieval statement—no mention of return format, ordering, pagination, or whether disabled alerts are included. With annotations covering safety, the description still adds little value.

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 conveys the core purpose without waste. It is appropriately sized for a simple list operation, though it could include more 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 simple list tool with one optional parameter and no output schema, the description is minimal but adequate. However, it lacks any details about the response (e.g., whether it returns an array, includes disabled alerts, or any default behavior). Given the sibling tools, mentioning that it returns all alerts regardless of state could be helpful, but it is not critical for a straightforward list.

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 is the optional _jq filter, which is fully documented in the schema (100% coverage). The description does not need to explain it, as the schema handles it. The baseline of 3 is appropriate since the schema carries the 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 clearly states the verb 'Get' and the resource 'all configured price alerts', making the purpose unambiguous. It distinguishes from sibling alert management tools (add/delete/enable/disable) by implying a listing operation, but does not explicitly name them. The name 'alert_list' reinforces this, so it is clear enough for an agent.

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 the many alert-related siblings (alert_add, alert_disable, etc.). The description does not mention any context, exclusions, or alternatives. An agent must infer that this is for retrieval, not modification.

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

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

Annotations already mark the call as read-only, idempotent, and non-destructive. The description adds context about alert content (unusual price/volume changes) and pagination defaults, but doesn't discuss result shape, update frequency, or ordering. 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 entire description is a single compact sentence with the action first, then the parameters and defaults. No filler or redundancy; every clause adds useful detail.

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

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

For a simple read-only lookup with one required parameter, the description plus schema and annotations is sufficient to invoke the tool correctly. It omits the output shape and any mention of no-result behavior, but this is minor given no output schema and the low complexity.

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

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

Schema description coverage is 100%, so the schema fully documents market, symbol, count, and _jq. The description largely repeats those meanings rather than adding new semantics, so the baseline of 3 applies.

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

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

States a specific action ('Get market anomaly alerts') and clarifies the concept as unusual price/volume changes, with market scope. It doesn't explicitly name sibling tools like top_movers or market_status as alternatives, so it is clear but not strongly differentiated.

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

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

The description gives operational guidance — market is required, symbol optionally filters, count controls page size — but no explicit when-to-use versus alternatives or exclusions. The use case is implied by the purpose rather than stated as a decision 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail by specifying the returned shape (cards[]) and explicitly noting that account_number is masked.

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

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

Two compact sentences with the main action front-loaded and the return payload summarized in one clause. There is no filler and no repetition of structured metadata.

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 zero required parameters, no output schema, and read-only non-destructive annotations, the description is sufficient to invoke the tool correctly. It includes the core output fields and notes masking, so an agent knows 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?

The only parameter is the optional _jq filter, and the schema description covers it 100%, so the tool description does not need to restate it. The baseline of 3 applies because the schema already provides the necessary parameter meaning.

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

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

The description opens with the verb 'List', names the resource 'linked withdrawal bank cards', and scopes it to 'the current account', so the action and object are unambiguous. The resource is clearly distinct from siblings like withdrawals and deposits, which are transaction records rather than card records.

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 'linked withdrawal bank cards for the current account' supplies clear context for when to use the tool. It does not explicitly name alternatives or exclusions, but the context is sufficient for a straightforward read-only listing tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description does not need to re-state safety. It adds value by disclosing the data source and market scope, but it does not describe pagination, result ranking, or any other runtime behavior.

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

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

The description is one efficient sentence with the core verb/resource first, followed by the two most important qualifiers (market scope and data source). 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 read-only data lookup, the description plus a fully documented input schema is sufficient for an agent to select and invoke the tool. It does not define what 'top' means or describe the output shape, but given the simple query nature and strong annotations, 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?

Schema description coverage is 100%, so the parameters are already well documented. The description reinforces the symbol-centric purpose but adds no new semantic detail about period or the jq filter 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 names a specific action and resource: 'Get top broker holding data for a symbol.' It further narrows scope with 'HK stocks only' and 'sourced from HKEX CCASS participant disclosure,' which distinguishes it from sibling tools like broker_holding_daily, broker_holding_detail, and participants.

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 clear applicability boundary ('HK stocks only') and a data-source context, so an agent knows when this tool is relevant. It stops short of explicitly naming alternatives or saying when NOT to use it, which would be necessary for a 5.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds useful behavioral context beyond annotations: the data is sourced from HKEX CCASS and limited to HK stocks, and the tool returns daily history rather than current holdings. No contradictions.

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 tightly written sentence that front-loads the core operation and immediately adds the important scoping constraints (broker, symbol, HK-only, data source). Every word earns its place with no filler.

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

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

For a read-only, two-required-parameter query tool, the description plus the rich parameter schema gives an agent enough to invoke it correctly. There is no output schema, but the return concept ('daily holding history') is clear from the name and description. Date-range or pagination details would strengthen it but are not essential for a first 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 100%, and the schema already documents both required parameters, including canonical symbol format and empty-record behavior. The description merely repeats symbol and broker_id in prose without adding new parameter-level meaning, so the 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 ('Get'), a specific resource ('daily holding history for a specific broker ... in a symbol'), and scoping constraints ('HK stocks only', 'HKEX CCASS participant disclosure'). This clearly differentiates it from sibling tools like broker_holding or broker_holding_detail through the 'daily' qualifier.

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 context is clear: use this tool when you need historical daily broker holding data for a specific symbol and broker. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5, but the intended usage is unambiguous.

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

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

Annotations already establish that this is read-only, idempotent, and non-destructive, so the bar is lower. The description adds useful context about market scope and data provenance, but it does not describe response format, pagination, or size behavior, which would be needed for a fuller 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?

One sentence with no filler; the core action, market constraint, and source are all front-loaded. Every element 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 lookup with one required parameter, the description plus schema is nearly complete: it states the market, source, and what is returned. A mention of response shape or pagination would make it fully complete, but the word 'list' and the robust symbol schema cover most agent needs.

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

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

Schema description coverage is 100%, including the canonical symbol format caveat about padded codes, so the schema already handles parameter semantics. The description only repeats 'for a symbol' and adds no extra parameter detail.

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

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

The description names a specific verb ('Get') and resource ('full broker holding detail list') and adds concrete scope: HK stocks only and data sourced from HKEX CCASS participant disclosure. It is clear, but it does not explicitly distinguish this from sibling tools such as broker_holding or broker_holding_daily.

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 'HK stocks only' constraint and the HKEX CCASS source give clear context about when the tool applies, and implicitly warn against non-HK symbols. However, it never mentions alternatives or explicitly says when to choose this over sibling holding tools, leaving the routing decision to inference.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the description's added behavioral value is limited to the market-scope constraint. It does not disclose response shape, ordering, or queue-specific behavior, though annotations lower the 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 terse sentences with the verb and resource front-loaded. The second sentence adds a meaningful resolution step rather than 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 read-only, one-required-parameter tool, the description plus schema covers the essential calling contract. It doesn't describe the queue's return fields, but the participants reference tells the agent how to interpret broker IDs, which is the main interpretive gap.

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

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

Schema description coverage is 100%, so `symbol` and `_jq` are already fully documented. The description adds no parameter-level detail; the 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 names a specific resource ('broker queue') and a concrete action ('Get'), and narrows scope with 'HK stocks only'. It points to participants for ID resolution but does not explicitly contrast itself with related broker_holding* siblings.

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 'HK stocks only' qualifier gives a clear scope for when this tool applies, and the participants hint suggests a supporting data source. However, there is no explicit when-not-to-use guidance or named alternatives among the many broker-related 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful point-in-time context ('current-period') and states exactly what data is returned, which goes beyond the annotations without contradicting them.

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

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

A single front-loaded sentence that states the action, scope, resource, and output fields with no filler or repetition of schema details.

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 with one required parameter and no output schema, the description supplies the necessary output shape (name, percent, total, currency) and temporal scope. Annotations cover safety and idempotency, so nothing essential is missing.

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

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

Schema description coverage is 100% and both parameters (symbol and _jq) are already well documented in the schema. The description adds no parameter-specific meaning beyond mentioning symbol in the tool's purpose, so it meets but does not exceed the baseline.

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

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

The description uses a specific verb ('Get') and resource ('business segment revenue breakdown') and scopes it to the current period for a symbol. Listing the returned fields (name, percent, total, currency) makes the tool's output intent unambiguous and distinguishes it from the historical sibling business_segments_history.

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

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

'Current-period' gives a clear context for when this tool applies, implying the historical sibling business_segments_history is for past periods. It does not explicitly name alternatives or exclusions, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the 'trends' and period/category dimension, which is useful context beyond annotations. However, it doesn't disclose output structure or any edge cases, which is acceptable given the read-only nature but not exceptional.

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 states the action and scope with no filler. It's efficient and easily parsed by an agent.

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 is a read-only getter with well-documented parameters and safety annotations, the description is sufficient for an agent to understand the tool's purpose. It hints at the return content ('revenue trends') without needing to detail the exact structure since there's no output schema. Minor gap: it doesn't clarify whether the response is a time series or single point, but the word 'trends' implies multiple periods.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description's mention of 'by period and category' aligns with the report and cate parameters but doesn't add new meaning beyond the schema. Baseline 3 applies because the schema carries the 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 clearly states the verb 'Get' and the resource 'historical business segment revenue trends', and adds 'by period and category' which distinguishes it from the sibling 'business_segments' tool. It's specific 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?

No explicit guidance on when to use this tool vs alternatives. The word 'historical' implies it's for historical data versus current, but it doesn't name the sibling tool or provide conditions. An agent would have to infer the use case.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds non-obvious behavior beyond them: padded symbol codes return empty records rather than errors, and Greek indexes have precise normalization semantics. This goes well beyond what the schema or annotations convey.

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?

Four dense sentences cover purpose, invocation, defaults, and Greek behavior with no filler. The default list is long, but it is essential context and is placed directly after the core instruction, making the description easy to parse.

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

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

For a read-only multi-index calculator with no output schema, the description covers request construction, default behavior, edge-case symbol handling, and special index normalization. Nothing critical appears missing for an agent to invoke the tool correctly and interpret the results.

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

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

Schema coverage is 100%, but the description adds decision-relevant meaning: representative index values, the default set, the canonical symbol requirement, and the normalization of theta/vega/rho. It turns a flat list of possible parameters into semantics an agent can act on.

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 opening phrase 'Calculate financial indexes for symbols' states a specific verb, resource, and target, and the example/default index lists define precisely what kind of metrics are returned. It is distinguishable from quote-like sibling tools by its focus on computed indexes and Greek normalization, even though it does not name an alternative explicitly.

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 concrete invocation guidance: pass symbols, optionally pass indexes, and omitting/empty indexes falls back to a documented default set. It also explains how Greek index values are normalized, but it does not explicitly state when to prefer this tool over quote, option_quote, or valuation, so it stops short of a 5.

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

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

The description discloses rich behavior: plain-text success response, errors on already-filled/cancelled orders, single-use 10-minute confirmation code, dry-run preview echo, and attached-leg semantics. However, this contradicts the idempotentHint=true annotation: the code is single-use and cancelling an already-cancelled order errors, so repeated identical calls do not succeed. Per rubric, a contradiction forces a score of 1.

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?

Core purpose, success/error behavior, and the safety-critical confirmation protocol are front-loaded and clearly flagged. The description is longer than strictly necessary because it partially restates the confirmation details already present on the execute parameter, but the redundancy is acceptable for a destructive tool and nothing is ambiguous or wasted.

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

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

For a destructive, two-step tool with no output schema, the description is complete: it states the return value, failure modes, confirmation-code constraints, dry-run behavior, and parent/attached-leg semantics. An agent has everything needed to call the tool correctly.

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

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

Schema description coverage is 100%, and the schema already documents execute, order_id, is_attached, and _jq in detail, including the two-step confirmation protocol. The description reinforces the confirmation flow but adds little new parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

States a specific verb and resource: 'Cancel an open order by order_id.' It also distinguishes cancelling a parent order from cancelling an attached take-profit/stop-loss leg via is_attached=true, so an agent can tell exactly what the tool does and how it differs from related order tools.

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

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

Provides an explicit, mandatory usage protocol: call as a dry run first, show the preview, then call again with the confirmation code only after explicit user confirmation, and never quote the code back in the same turn. It also clarifies when to use is_attached=true vs cancelling a parent order. It does not name sibling alternatives (e.g., grid_cancel), so it misses the upper bound.

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 valuable behavioral context beyond that: the tool silently returns fewer candles when entitlement caps the count instead of erroring, and tells the agent to verify the returned array length. This is a meaningful edge case not present in the schema.

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

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

The description is three sentences and front-loads the purpose before diving into defaults and caveats. It is efficient and each sentence earns its place, though the middle sentence packs a long list of defaults and allowed values that is also present in the 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 data-fetching tool with no output schema, the description covers the essential operational details: required parameters, defaults, and the entitlement cap edge case. It does not explain the exact response shape or ordering, but the OHLCV naming and array-length mention give the agent enough to infer what to expect. The lack of differentiation from sibling history tools is the main gap.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description repeats the defaults and allowed values for period and trade_sessions, which does not add new meaning beyond the schema. The only extra is the note that only symbol is required, which is a minimal addition.

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 — 'Get candlestick data (OHLCV)' — making the core function immediately clear. However, it does not distinguish itself from sibling tools like history_candlesticks_by_date or history_candlesticks_by_offset, so an agent may not know which candlestick tool to choose for historical vs. period-based data.

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

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

The description gives clear context: only symbol is required, defaults are listed, and the entitlement cap behavior is explained. But it provides no explicit guidance on when to use this tool versus alternatives, nor any 'when not to use' conditions. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable nuance: for symbols without capital-flow data, data_available is false and other fields are present but meaningless zeros. This goes beyond the annotation safety profile and helps the agent interpret results correctly.

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, focused sentence that states the purpose and the key caveat about data_available. It is concise and front-loaded with the primary action. It could be slightly better structured by separating the purpose from the edge-case note, but it is efficient.

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

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

Given the tool's simplicity, no output schema, and rich annotations, the description covers the essential behavioral quirk (data_available and meaningless zeros) and the parameter caveat. It is complete enough for an agent to invoke correctly, though it could mention the return format or typical use cases, which are minor omissions.

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

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

Schema description coverage is 100%, so the schema documents both parameters. The description adds critical detail for the symbol parameter: padded codes like '00700.HK' return an empty record instead of an error, and canonical form is required. This enriches the schema's basic description and is important for correct 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 states a clear purpose: 'Get capital distribution for a symbol.' It names the resource and action, but does not differentiate from the sibling tool 'capital_flow', which is a potential alternative for similar data. This prevents a top score because the agent must infer which tool is appropriate.

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

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

The description provides a context clue about data_available being false for symbols without capital-flow data, which hints at when the tool may not be useful. However, it does not explicitly state when to use this tool versus alternatives like capital_flow, nor does it give any exclusion criteria. This is a moderate 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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful detail by specifying the return shape (items[] with timestamp, inflow, outflow, net_flow) and the same-day data constraint. There is 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 a single, focused sentence that front-loads the purpose and immediately states the exact return structure. Every clause earns its place, with no redundant or vague 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 100% schema coverage founded on a well-documented input schema, the description provides the essential return shape and the same-day temporal constraint. Pagination, ordering, and exact time ranges are not mentioned, but these are less critical for correct invocation and selection.

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

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

The input schema fully documents both parameters, including a concrete canonical-form example and the padded-code empty-record behavior for symbol. The description adds no parameter-level detail beyond what the schema already provides, so the high schema coverage supports the baseline score.

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 operation ('Get capital inflow/outflow time series') and explicitly lists the returned fields (timestamp, inflow, outflow, net_flow). However, it does not explicitly differentiate itself from similarly named siblings such as cash_flow or capital_distribution, preventing a top score.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives, and no sibling tools are referenced. The only contextual hint is 'same-day data,' which implies a limitation but does not help an agent decide between this and related capital/cash-flow siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the time-range scoping and the exact returned fields, which is useful behavioral context. It does not disclose pagination, ordering, or whether the response is limited to a certain number of records, but given the annotations cover the main 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 two sentences and front-loads the core purpose and returned fields, then adds the time-format constraint. Every sentence earns its place, and there is no fluff. It could be slightly more structured by separating the return format from the parameter note, but it is appropriately sized.

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 full schema coverage and no output schema, the description covers the essential purpose, returned fields, and time-format requirement. It is missing details like pagination, ordering, or any limits on the returned records, which an agent might need for large date ranges. Given the tool's simplicity and the annotations covering safety, the description is adequate but not complete.

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

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

Schema description coverage is 100%, so the schema already documents start_at and end_at as RFC3339 times. The description reinforces the time-range semantics by mentioning start_at/end_at in RFC3339, but it adds no new meaning beyond the schema. The _jq parameter is also fully documented in the schema. Baseline 3 is correct when the schema does the heavy lifting.

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 cash flow records and enumerates the transaction types (deposits, withdrawals, dividends), which distinguishes it from generic account tools. It also lists the returned fields, making the resource and output explicit. It doesn't explicitly name a sibling alternative, but the field list and transaction-type scope are enough to differentiate it from related tools like deposits, withdrawals, and account_balance.

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 by specifying a time range (start_at/end_at in RFC3339) and the returned record types, which tells an agent when this tool is appropriate for querying cash flow history. However, it does not explicitly state when to prefer this over siblings like deposits, withdrawals, or account_balance, nor does it mention any exclusions or prerequisites. The context is clear but the guidance is not explicit.

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

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

Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds non-obvious behavioral context: US accounts querying .US symbols receive a different variant with listed fields, and region detection is automatic.

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

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

Three short sentences with no filler: the first states the purpose, the second captures the key US-specific variant, and the third clarifies the trigger. Information is front-loaded and every sentence earns its place.

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

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

For a simple read-only overview with fully documented parameters and strong annotations, the description covers the essential purpose and a significant output-variation case. The lack of an explicit return-structure description is a minor gap, not a blocking one.

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

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

Schema description coverage is 100%, so both _jq and symbol are already fully documented, including the canonical-form caveat for symbols. The description adds no parameter-specific meaning, so the baseline of 3 applies.

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

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

The description opens with a clear verb and object: 'Get company overview.' It is specific enough to identify the tool's core purpose, though it does not explicitly distinguish itself from siblings like static_info or security_facts.

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 through 'Get company overview,' but it never states explicit use cases, exclusions, or alternatives. The US-account/.US variant note is practical output guidance, not tool-selection 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 indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context about the response variant (ai_summary plus details[] vs items[]) and automatic region detection, going beyond what annotations state. 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 sentences, front-loaded with the primary purpose and immediately followed by the most important behavioral note. Every word earns its place; no fluff or repetition.

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

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

There is no output schema, so the description should explain return values. It mentions the US variant response shape but does not detail fields, periods, or error behavior. For a tool with a single required parameter and strong annotations, this is adequate but not fully complete.

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

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

The input schema describes both parameters fully (symbol and _jq), so the baseline is 3. The description adds a minor nuance about region detection affecting the symbol interpretation, but does not materially enhance parameter meaning beyond the schema.

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

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

States a specific verb and resource ('Get financial consensus estimates') and highlights a notable US-specific variant, which helps distinguish it from other data tools. However, it does not explicitly differentiate from sibling tools like forecast_eps or institutional_views, so clarity is good but not exceptional.

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 context about when the US variant applies and that region is auto-detected, which is useful. But there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or preconditions beyond the symbol requirement.

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. The description adds substantial behavioral detail beyond that: the exact response structure, the four asset_type groups with their numeric codes, which fields each group contains, and the special holding_detail object. This is rich and accurate contextual behavior description.

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-organized, front-loading the core purpose and then systematically covering the two return shapes. Every sentence adds needed information, and the grouping by asset_type makes the structure easy to parse without unnecessary verbosity.

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 carries the full burden of telling the agent what to expect. It explains both index and ETF cases, lists the key fields, names the grouping codes, and describes nested objects. For a read-only lookup tool, this is complete enough for an agent to invoke and interpret results 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 100%, so the baseline is 3, but the description adds meaningful parameter guidance beyond the schema: it clarifies that 'symbol' can be an index code like HSI.HK or an ETF code like QQQ.US/2800.HK, and that the output varies based on this value. It also reinforces that _jq never changes the upstream request.

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 the constituents of an index or the asset allocation of an ETF') and names the exact resource types with examples. It clearly distinguishes the two modes (index vs. ETF), making its purpose unmistakable even among many sibling tools.

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

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

The description gives clear context for when to use the tool: whenever index constituents or ETF asset allocation data are needed. It provides concrete symbol examples and explains the difference between index and ETF inputs, though it does not explicitly name alternative tools or state when not to use this one.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the examples of corporate action types, which is mild context beyond the annotations, but it does not disclose additional behaviors like pagination, filtering, or output shape. It adds some value but not substantial.

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 focused sentence with no filler. It front-loads the action ('Get') and immediately clarifies scope with examples. Every word earns its place.

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

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

The tool is simple and read-only with rich annotations, but there is no output schema and the description does not hint at the return format or any usage nuances. Given the simplicity, it is mostly adequate, but it misses a note about what the response structure looks like, leaving the agent to guess.

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

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

Schema description coverage is 100%, so the schema already documents both symbol and _jq parameters thoroughly. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states a clear verb ('Get') and resource ('corporate actions'), and lists specific examples (splits, buybacks, name changes) that clarify scope. However, it does not explicitly differentiate from sibling tools like dividend or capital_distribution, which cover overlapping events.

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 is terse and gives no context about selection criteria, such as 'use this for all corporate actions, dividend for dividend-specific data'.

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 a write operation (readOnlyHint=false, idempotentHint=false). The description adds minimal extra behavior: it explicitly says securities can be passed to pre-populate, which is also echoed in the schema. It does not disclose failure modes, permissions, or side effects beyond that. Given annotations cover the safety profile, this is acceptable 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 one concise sentence with an example, front-loading the core purpose. No filler or redundant repetition of schema information. It is appropriately sized 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?

For a simple create tool with no output schema and full annotation coverage, the description covers the essential purpose and optional parameter. However, it lacks information about behavior on duplicate names, whether the group is created empty when no securities are passed, or any constraints like group size limits. In a large sibling space, more context on uniqueness or relation to sharelist could improve 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 100%, so parameters are already documented. The description adds value by explicitly stating that securities are optional and providing a concrete example format (["AAPL.US", "700.HK"]). This reinforces the schema but doesn't significantly expand semantics beyond what's already present.

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 ('Create'), a specific resource ('watchlist group'), and the optional pre-population behavior. It is not a tautology and distinguishes this from delete/update siblings by the action, though it doesn't explicitly differentiate from sharelist_create or related group 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 on when to use this tool versus alternatives. There are sibling tools like delete_watchlist_group and update_watchlist_group, but the description does not mention when to choose this one, nor does it note any prerequisites or limitations (e.g., duplicate names). It leaves usage context entirely to inference.

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

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

Annotations already convey readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the behavioral semantic that this is a support check, but does not disclose additional traits such as response format or any edge cases. Annotations cover the critical safety profile, so the description's contribution is modest.

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

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

A single, complete sentence with no filler or redundant wording. The core purpose is front-loaded and immediately actionable.

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 tool with one required array parameter and no output schema, the description provides sufficient context for a correct call. The main minor gap is that the response shape is not described, but the simple nature of the check makes this acceptable without being fully explicit.

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

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

Schema description coverage is 100%, so the parameters are already fully documented. The description mentions 'given symbols', reinforcing the main parameter, but adds no new detail beyond the schema. 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 uses a specific verb ('check') and resource ('DCA recurring investment support') and clearly identifies the input ('given symbols'). It is easily distinguished from sibling DCA tools (dca_create, dca_update, dca_list, etc.) which perform management actions rather than eligibility checks.

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 explicitly state when to use this tool or provide alternatives, but the purpose is straightforward and the sibling dca_create implies a preflight use case (verify support before creating a DCA plan). Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the agent knows this is a mutating, non-idempotent operation. The description adds scheduling constraints (frequency, day_of_week, day_of_month) but does not disclose side effects beyond that, such as whether repeated calls create duplicate plans, margin behavior, or response shape.

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

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

The description is compact, front-loaded with the action verb, and conveys the key scheduling constraints without any filler. Every clause adds 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 create tool with no output schema, the description omits details about return values, failure behavior, or consequences of non-idempotency. While required parameters are clear and schema fully documents optional ones, a mutation tool could benefit from at least a note on what a successful call returns or whether creation can be repeated.

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

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

Schema coverage is 100%, so every parameter already has a description in the input schema. The description's frequency and day_of_week/day_of_month details essentially restate the schema, adding no new semantic meaning. Baseline 3 applies because the schema does the heavy lifting.

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 'Create a DCA recurring investment plan' – a specific verb and resource that immediately identifies the action. It is clearly distinguished from siblings like dca_update, dca_stop, and dca_list by the use of 'Create'.

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 intended use case ('create a recurring investment plan') is clearly stated and leaves no doubt about when to invoke it. However, it does not explicitly list alternatives or exclusions, though the sibling group makes the contrast obvious.

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

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

Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds the scoping constraint 'by plan_id' as useful context, but it does not disclose response format, pagination behavior, or error characteristics. This is 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?

A single, front-loaded sentence that states exactly what the tool does and its required input. There is no redundant wording or filler; every word earns its place.

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

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

For a simple read-only getter, the description plus the fully documented schema and safety annotations are nearly sufficient: plan_id is required and page/limit defaults are in the schema. The main gap is the lack of an output schema or a note about what fields the execution records contain, but this is a minor omission for such a straightforward 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 100%, so the schema fully documents all four parameters. The description only restates the plan_id role and adds no extra meaning for page, limit, or _jq, so it neither harms nor enhances the schema's 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 names a specific verb ('Get'), a clear resource ('execution history records'), and the key scope ('for a DCA plan by plan_id'). This is specific enough to separate dca_history from sibling tools like dca_list or dca_stats 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 description tells what the tool does but gives no guidance on when to prefer it over alternatives such as dca_stats or history_executions, and names no exclusions or prerequisites beyond plan_id. Usage is only implied, not stated.

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

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

The annotations already declare this tool read-only, idempotent, and non-destructive. The description adds the filtering behavior and the resource scope, but it doesn't disclose additional behavioral details such as pagination behavior, response shape, or any operational constraints. With annotations covering the safety profile, the description makes a modest additive contribution, but not a rich one.

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

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

A single, focused sentence that front-loads the core action ('List DCA recurring investment plans') and immediately covers the optional filters. Every word earns its place; no filler or redundant elaboration.

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 filtered list tool, the definition is nearly complete: the schema documents all five parameters with 100% coverage, annotations cover the safety profile, and the description states the purpose and filtering options. The only shortfall is that no output schema or return format is mentioned, but an agent can reasonably infer the return is a list of DCA plans.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does restate the status filter values and symbol filter concept, but those are already present in the schema. It adds no meaningful parameter semantics 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 and resource: 'List DCA recurring investment plans', which clearly distinguishes it from DCA mutation tools like dca_create, dca_update, dca_stop, etc. It also states the filtering capabilities (by status or symbol), so an agent immediately knows what this tool offers.

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 usage context clear: call this when you need to list existing DCA plans, optionally filtered by status or symbol. However, it does not explicitly name alternatives such as dca_history or dca_stats, nor does it say when not to use it, so it stops 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?

Annotations already indicate this is not read-only, not destructive, and idempotent. The description adds valuable context beyond this: the plan stops executing until resumed and the tool returns the upstream API response. This gives the agent a clear picture of the tool's lifecycle effect and return behavior.

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

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

Three short sentences, each earning its place: the action, the behavioral consequence, and the relevant sibling for restarting. The most actionable information is front-loaded, and there is 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 single-required-parameter command, the description is nearly complete: it states the effect, the identifier, the return behavior, and the restart path. It does not detail response structure in the absence of an output schema, but for this tool's complexity the provided information is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the baseline applies. The description only references 'plan_id' without adding meaning beyond the schema, and it does not discuss the optional _jq parameter. The schema already documents both parameters adequately, so the description adds no extra semantic value.

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

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

The description states a specific verb ('Pause'), a specific resource ('DCA plan'), and the key identifier ('by plan_id'). It also clarifies the semantic difference from dca_resume by saying the plan stops executing until resumed, which distinguishes it from related lifecycle 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 clearly conveys the context: use this when you want to suspend a plan, and use dca_resume to restart it. It does not explicitly contrast with dca_stop or other sibling alternatives, so it lacks full exclusion guidance, but the core usage context is clear.

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

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

Annotations already mark this as non-read-only, non-destructive, idempotent, and open-world, so the description only needs to add context. It usefully notes that the operation affects the configured schedule and returns the upstream API response, but it does not disclose failure modes, permission requirements, or what happens if the plan is not suspended.

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?

At around 20 words, the description is compact and front-loaded: it states the action, the resource, the effect, and the return behavior in three short sentences. There is minor redundancy in saying 'Resume' and then 'Resumes automated execution,' but no wasted or unrelated content.

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

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

For a tool with one required parameter and no nested objects, the description, combined with the annotations and full schema coverage, gives an agent the core information: when it applies, what it does, and that it returns an upstream response. The return structure is generic because there is no output schema, but that is a moderate gap for an operation of this simplicity.

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

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

Schema description coverage is 100%, so plan_id and _jq are already documented in the input schema. The description only repeats 'by plan_id' and adds no additional format, constraint, or behavior details for the parameters, so the baseline 3 applies.

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

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

The description uses a specific verb ('Resume') and a precise resource ('a suspended DCA plan'), then clarifies the effect: 'Resumes automated execution on the configured schedule.' It is clearly distinguishable from siblings like dca_pause and dca_stop, though it does not explicitly name 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?

The phrase 'suspended DCA plan' conveys the intended precondition, and the scheduled-execution wording explains what resuming entails. However, it does not mention alternative tools such as dca_pause or dca_stop, nor does it caution against calling it on a plan that is already active.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only operation. The description adds no additional behavioral context, such as whether it returns aggregate data for all plans or per-plan, or if it requires authentication. With annotations covering safety, the lack of extra detail is acceptable but not exceptional.

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—extremely concise. It's front-loaded with the verb 'Get' and the resource. While it lacks detail, it's not verbose. For a simple tool, this is acceptable, but it could be slightly more informative without losing conciseness.

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 must explain what the response contains, but it doesn't. With 2 parameters and simple filters, the tool is not overly complex, but the lack of return type or example output means the agent doesn't know what 'statistics' means numerically. Sibling tools like dca_history likely provide detailed data, so a clearer distinction is needed. This is incomplete for an agent to call with confidence.

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

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

Schema description coverage is 100%, so both parameters ('_jq' and 'symbol') are fully documented. The description doesn't add meaning beyond the schema; for instance, it doesn't clarify that 'symbol' filters by ticker and that omitting it returns all plans, which the schema already states. No value added beyond 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 the tool gets DCA investment statistics, but it's vague—it doesn't specify what kind of statistics (e.g., totals, performance, breakdowns) or the output format. It distinguishes from siblings like dca_list (listing plans) but doesn't clearly differentiate from dca_history (history of contributions) or trade_stats, which may overlap in concept. A more specific description like 'Get aggregated investment statistics for dollar-cost averaging plans' would be clearer.

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 like dca_list, dca_history, or trade_stats. It doesn't state whether to use it for a summary vs. detailed history, or what filters apply. The agent must infer from the symbol parameter, but no explicit 'when to use' or 'when not to use' 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 flag destructiveHint=true and readOnly=false, and the description adds meaningful context beyond that by emphasizing irreversibility ('This cannot be undone') and noting that the tool returns the upstream API response. It does not detail response fields, but for a simple destructive action the safety profile is adequately disclosed.

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

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

Three short sentences, each earning its place: the action, the irreversible consequence, the alternative tool, and the return type. The most decision-relevant information is front-loaded and there is no filler.

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

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

For a one-required-parameter destructive tool, the description covers the essential context: what it stops, that it is irreversible, when to choose a sibling instead, and what the return value is. There is no output schema, so a little more detail about the upstream response shape would help, but the gap is modest for this level of complexity.

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

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

Schema description coverage is 100%: plan_id is already described as 'Plan ID' and _jq has a full explanation of jaq semantics. The description only reinforces that plan_id is the stop target, adding no meaningful parameter behavior beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description opens with a specific verb-resource pair, 'Permanently stop a DCA plan by plan_id,' and clearly communicates the permanent nature of the action. It also distinguishes itself from the sibling dca_pause by contrasting permanent stop versus temporary pause, so an agent can disambiguate without opening schemas.

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

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

It explicitly states the when-to-use condition and directly names the alternative for a different intent: 'To temporarily pause, use dca_pause instead.' This gives clear routing between the two closest sibling tools, with no inference required.

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 and destructiveHint=true, so the agent knows this is a mutating, potentially destructive operation. The description confirms it updates an existing plan and adds that it returns the updated plan. However, it does not clarify whether unspecified fields are preserved or reset (partial vs. full update), which is a meaningful behavioral gap. 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 sentences, with the core purpose front-loaded and a concise list of editable fields. Every word earns its place, and there is no redundant or extraneous information. This is an efficiently structured 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?

The description covers the tool's basic function and return value, and the schema explains every parameter. However, it omits important conditional dependencies: e.g., if frequency is set to Weekly, day_of_week is likely required, and similarly for Monthly/day_of_month. These cross-parameter constraints are neither in the description nor the schema descriptions, leaving an agent to infer them. The presence of an output schema is false, but 'Returns updated plan' suffices for return-value clarity.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description repeats the allowed values for frequency, day_of_week, and day_of_month exactly as in the schema, providing no additional semantic value. It does not add constraints or clarify relationships between parameters, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Update an existing DCA plan by plan_id.' It then enumerates the mutable fields (amount, frequency, day_of_week, day_of_month), which clearly differentiates it from sibling DCA tools like dca_create, dca_pause, dca_resume, and dca_stop. An agent can discern this tool's role 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 context is clear: use this when you need to modify an existing DCA plan, identified by plan_id. It does not explicitly state when not to use it or name alternatives, but the purpose and sibling names make the appropriate invocation obvious. Lacks explicit exclusions or conditional guidance, so not a 5.

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

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

Annotations already signal destructiveHint and idempotentHint, so the description doesn't need to restate those. It adds valuable behavioral context by explaining the purge side effect: securities are removed from all other groups. It does not mention irreversibility or permissions, but the destructive annotation covers the main warning.

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, front-loaded sentences. The primary action and required parameter come first, followed by the optional behavior. 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 combined with schema and annotations covers what an agent needs: the action, the required id, and the purge behavior. No output schema exists, so return-value details are less critical. It could be slightly more explicit about the purge=false postcondition or alternatives, but it is complete for effective 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 100%, so the schema already explains id, purge, and _jq. The description adds only marginal restatement ('numeric', 'remove its securities from all other groups'), which is helpful but not a substantial semantic expansion 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 names the exact operation ('Delete a watchlist group'), specifies the identifier ('by id (numeric)'), and defines the conditional scope ('Set purge=true to also remove its securities from all other groups'). It is clearly distinct from sibling tools like create_watchlist_group and update_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 gives a clear context: use this when deleting a watchlist group by numeric id, and sets out the purge variant. It does not explicitly contrast with create/update alternatives, but the delete intent is unambiguous enough that an agent can select it correctly.

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 safety profile. The description adds the return structure (items with id, amount, currency, status, created_at, updated_at) and filter semantics (states and currencies), which are useful beyond the annotations. No contradictions.

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 sentence states purpose and return fields, the second explains the two filters. Front-loaded, no waste, and all content 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, idempotent tool with 0 required parameters and full schema coverage, the description covers all essential aspects: what it returns, how to filter, and the scope (current account). No missing information an agent would need 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 covers 100% of parameters with descriptions, so baseline is 3. The description adds specific allowed state values (Pending/Finished/Failed) not present in the schema, and clarifies currency codes are comma-separated. This enriches the parameter meaning beyond the schema.

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

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

The description states a specific verb (List) and resource (deposit history for the current account), which clearly distinguishes it from siblings like withdrawals. It also lists the return fields, making the purpose unambiguous and non-tautological.

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 deposits but does not explicitly state when to use it vs alternatives or provide exclusions. It mentions 'current account' but doesn't contrast with other tools like account_balance or withdrawals. No explicit guidance on selection criteria.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the 'Up to 10 price levels' limit, which is useful behavioral context beyond annotations, but does not describe response format or error behavior.

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

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

Two concise sentences with no wasted words. The purpose is front-loaded and the level limit is a valuable additional detail.

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

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

For a simple tool with one required parameter and no output schema, the description is minimal but covers the core purpose and a key limit. However, it omits any description of the response structure, which could be helpful given the absence of an output schema. Still, the schema covers parameter semantics and annotations cover safety, so it is adequate but not comprehensive.

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

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

Schema coverage is 100% with both parameters ('symbol' and '_jq') fully described in the schema. The description adds no extra meaning about parameters, so the baseline 3 applies.

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

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

States a specific verb 'Get' and resource 'order book depth' for a symbol, with an additional detail on level count. It is clear what the tool does, though it does not explicitly differentiate from sibling tools like 'quote' or 'candlesticks' which might also return market data, but the resource is specific enough.

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 any exclusions or conditions. It simply states what it does, leaving the agent to infer 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?

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable context: region-specific variant where dividend_yield_ttm is a percent value and that region is auto-detected. This goes beyond the structured annotations and helps interpret results correctly.

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 waste. The core purpose is front-loaded, and the region variant is a meaningful addition that earns its place. The structure is efficient and scannable.

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 required parameter and no output schema, the description covers the purpose and a key behavioral nuance. It omits output structure details, but the agent has enough to call it correctly. A slight additional note on typical response fields would push it to 5.

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

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

Schema description coverage is 100%, so both parameters are fully documented in the schema. The tool description adds nothing about parameter usage or format beyond what the schema provides. Baseline 3 applies because the schema carries the semantic load.

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 the specific action 'Get dividend history for the symbol' with a clear resource and scope. It does not explicitly differentiate from the sibling dividend_detail, but the core purpose is unambiguous and actionable.

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 like dividend_detail. The description mentions region detection but does not address selection criteria, exclusions, or complementary tools. An agent is left to infer when this tool is appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds no behavioral traits beyond 'detailed', but it also does not contradict the annotations, so the safety profile is adequately covered.

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

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

A single, front-loaded sentence with no filler. It communicates the core action efficiently and is appropriately sized for a simple read-only getter.

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 the response contains or how this tool differs from simpler dividend tools. Saying 'detailed dividend distribution scheme' is too vague to guide the agent on expected return data, and no usage context or alternatives are given.

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

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

Schema description coverage is 100%, and both parameters are thoroughly documented in the schema, including the canonical symbol format and the _jq filter semantics. The description adds no additional parameter meaning beyond what the schema already provides.

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

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

The description uses a specific verb ('Get') and a specific resource ('detailed dividend distribution scheme'). The word 'detailed' helps distinguish it from the sibling tool 'dividend', though the exact meaning of 'distribution scheme' remains somewhat vague.

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 related siblings like 'dividend' or 'capital_distribution'. It does not state any conditions, exclusions, or alternatives, leaving the agent to infer usage from the name alone.

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

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

Annotations already cover read-only, idempotent, non-destructive aspects. The description adds case-insensitivity and default values, which are useful. It does not disclose response format or edge cases, but annotations handle most transparency needs.

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

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

A single, focused sentence with no fluff. It front-loads the core purpose and then lists key defaults and optionality efficiently. It is appropriately brief and every word serves a 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 an estimation tool with full schema coverage and safe annotations, the description is complete. It provides necessary defaults and usage context, making it sufficient for an agent to call it correctly. No output schema means returns are not detailed, but that is not required 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?

Schema coverage is 100%, so parameters are already described. The description adds default values and case-insensitivity, which adds some value but is not highly informative beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool estimates max buy/sell quantity for a symbol, with a specific verb and resource. It distinguishes from siblings like submit_order and replace_order by focusing on estimation rather than execution, though it does not explicitly name alternatives.

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

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

The description gives clear context: only symbol is required, and it explains defaults and optionality for side, order_type, and price. It does not explicitly say when not to use it versus alternatives, but the purpose implies it is for pre-trade estimation.

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, and idempotent, so the description does not need to restate those. It adds valuable behavioral context by disclosing the regional restriction and the specific DcRegionRestricted error for AP accounts, which goes beyond the structured 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 entire description is one tight sentence that leads with the core action and then adds the critical regional constraint. There is no filler, and every clause contributes 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 simple read-only tool requiring only one parameter, the description is nearly complete: it names what is returned, the target market, and a key error condition. It does not describe the return shape, but no output schema exists and the response type is implied by 'documents'.

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

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

The input schema already provides full descriptions for all three parameters, including the required 'symbol' and optional 'limit' and '_jq'. The description adds no parameter-specific detail, but with 100% schema coverage, the baseline applies and the schema carries the explanatory burden.

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

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

The description uses a specific verb ('Get') and a precise resource ('regulatory/prospectus documents for a US ETF'), making the tool's function immediately clear. It also distinguishes itself from broader sibling tools like 'filings' by scoping to ETF-specific documents and US accounts.

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

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

The description clearly states the tool is for US ETFs and explicitly warns that AP accounts will receive a DcRegionRestricted error. It provides strong contextual usage guidance, though it does not explicitly name alternative tools for non-US or non-ETF document lookups.

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

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

Annotations already cover read-only/idempotent/non-destructive behavior, and the description adds value by declaring the response structure and currency coverage. It goes beyond the schema's one generic parameter. Minor extra context like base-currency semantics or list size would be helpful but is not essential given 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 filler. The verb and resource are front-loaded, and the return shape follows immediately. Every sentence contributes 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?

With no output schema, the description takes on the burden of explaining the response, and it does so by naming the fields and example currencies. Some ambiguity remains about how the rate is quoted (e.g., base currency) and whether the list is exhaustive, but the tool is simple and annotations cover the safety profile.

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, is fully described in the input schema with detailed semantics and examples, so the description need not repeat it. The tool description doesn't elaborate on parameters, but baseline 3 is appropriate since schema coverage is 100%.

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 exchange rates for all supported currencies') and includes the exact return shape (list of from_currency, to_currency, rate, timestamp). It does not explicitly name or differentiate from sibling tools, but the resource is unambiguous enough to distinguish it from the large sibling set.

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 such as quote, market_status, or now. The usage context is only implied ('for exchange rates'), with no mention of when not to use it or which sibling covers adjacent scenarios.

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, so the safety profile is covered. The description adds the data scope (executives and board members) but no further behavioral details such as response shape, pagination, or rate limits. This is 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, front-loaded sentence with no wasted words. It is appropriately sized for a simple read tool, though it lacks the additional routing value seen in higher-scoring definitions.

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 low complexity, complete parameter schema, and strong annotations, the description is minimally sufficient. Still, with no output schema and no usage guidance, the agent gets only a broad sense of what is returned and no help choosing this tool among many 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?

Schema description coverage is 100%, so the schema fully documents both 'symbol' and '_jq', including the canonical symbol caveat. The description itself adds no parameter detail, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get company executive and board member information.' It is not a tautology and clearly identifies what data the tool returns. However, it does not differentiate itself from sibling tools such as 'participants' or 'company', so it misses the top score.

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

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

There is no guidance on when to use this tool versus alternatives, and no mention of prerequisites or exclusions. The description only states what the tool does, leaving the agent to infer usage from the tool name and context.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering safety. The description adds context on return structure (items array with specific fields) and confirms it is per symbol. It does not contradict annotations, and it meaningfully supplements the safety profile with output expectations.

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 sentence that front-loads the core action and then specifies return fields. No redundant words or filler. The description is efficient and immediately usable.

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

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

For a two-parameter read tool with full schema coverage and annotations handling safety, the description is nearly complete. It specifies the return shape, which substitutes for an output schema. Minor omissions like pagination or rate limits are not critical given the simple list nature and the tool's safe profile.

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

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

Schema description coverage is 100%; both symbol and _jq are documented with syntax and canonical-form guidance. The description adds no new parameter semantics beyond reiterating that it returns items for the symbol. Baseline 3 is appropriate because the schema already carries the parameter meaning.

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

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

The description states a specific verb ('Get') and resource ('regulatory filings'), enumerates example types (8-K, 10-Q, 10-K) and returns a structured items array. It is unambiguous and clearly distinguishable from siblings like news or corp_action, which cover different data.

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

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

The description implies use when the agent needs regulatory filing data for a security, but provides no explicit guidance on when to use this tool versus alternatives (e.g., news for non-regulatory announcements, corp_action for corporate events). It does not mention exclusions or conditions, so usage is inferred from purpose rather than stated.

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

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

Annotations already mark the tool readOnly, openWorld, idempotent, and non-destructive; the description adds useful behavioral detail beyond that by disclosing the default date range and the truncation behavior for ranges over two weeks. This goes beyond what annotations or the schema 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?

Two sentences with no filler. The category list is front-loaded, the date defaults are stated compactly, and the truncation warning earns its place as an essential constraint.

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 filtered read-only calendar with a rich schema and annotations, the description covers required category selection, optional date behavior, and the truncation constraint. It does not describe the return shape, but no output schema exists and an agent can still invoke the tool correctly with the provided information.

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

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

Schema description coverage is 100%, so parameters are already well-documented, including category values, date formats, and the market filter. The description adds one extra semantic constraint not in the schema: ranges longer than two weeks truncate results, which clarifies start/end interplay.

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

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

The description identifies a specific resource (finance calendar) and enumerates its categories (report, dividend, split, ipo, macrodata, closed), which makes the tool's scope clear. It lacks an explicit verb like 'list' or 'get' and does not distinguish from sibling tools such as macrodata, dividend, or ipo_calendar, so it falls short of a 5.

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

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

The description gives clear context for when to use this tool: it covers a defined set of financial event categories and states the default date window. It also adds an operational constraint (keep ranges under two weeks or results truncate), though it does not explicitly name alternatives or say when not to use it.

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

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

Annotations already convey the safety profile (readOnlyHint, idempotentHint, openWorldHint, non-destructive), so the bar for added behavioral disclosure is lower. The description adds no behavioral traits beyond them — nothing about result size, the default kind when omitted, or any quirks of the data returned. It mostly restates the parameter options rather than disclosing runtime behavior.

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

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

Two compact sentences, with the core purpose front-loaded and the parameter reference following. The format is efficient and scannable, though the second sentence's parameter list partially duplicates schema content. Overall it earns its place as a tight, well-structured summary.

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 annotation coverage and full schema documentation, the core essentials are present. However, there is no output schema and the description does not say what shape the returned report takes, nor does it address the five-plus overlapping financial_report_* siblings. An agent choosing between financial_report, financial_report_latest, and financial_report_snapshot would still face 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?

Schema coverage is 100%, so the schema already documents all four parameters, which sets a baseline of 3. The description restates the kind and report_type value lists and expands the abbreviations (af=annual, saf=semi-annual), adding modest convenience. However, most of this is redundant with the schema's own parameter descriptions, so the description does not meaningfully surpass the baseline.

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

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

The description states a specific verb ('Get') and resource ('financial reports') and enumerates exactly which statements are covered (income statement, balance sheet, cash flow). It is clear in its own right but does not explicitly differentiate itself from the many financial_report_* siblings (financial_report_latest, financial_report_snapshot, financial_report_key_metrics, financial_statement), so an agent must rely on naming to pick it.

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 its alternatives. It never mentions financial_report_latest, financial_report_snapshot, financial_report_key_metrics, or financial_statement, nor any condition that would select one over another. With such a large sibling cluster, this omission leaves the agent without routing direction.

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, so the safety profile is covered. The description adds useful behavioral detail: the default report period, accepted report keys, and the specific regional error code.

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 action and then pack in the essential report modes, default, and regional error behavior. There is no filler or redundant prose.

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 fully documented parameters and strong annotations, the description covers scope, report selection, defaults, and a known failure mode. It does not describe the output shape, but 'key financial metrics' provides a reasonable expectation and no output schema is available.

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

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

Schema description coverage is 100%, so the baseline is 3. The description re-states the report options and default but adds no meaning beyond what the schema already provides for symbol, report, or _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 verb and resource: 'Get key financial metrics (fin-keyfactor) for a US symbol,' and it includes report variants and region restrictions. It is clear and actionable, though it does not explicitly differentiate itself from the similarly-named financial_report and financial_report_snapshot sibling tools.

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

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

It gives clear context on when to use: for US accounts only, and it even warns that AP accounts will trigger a DcRegionRestricted error. It does not name an alternative tool for non-US reports, so it stops short of fully routing the agent away.

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, and the description adds no behavioral context beyond a generic 'Get'. It does not clarify what 'latest' means, what the summary contains, or that a non-canonical symbol returns an empty record; that last detail lives only in the schema.

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

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

The description is a single, concise sentence with no filler and the action is front-loaded. It is efficient, though it slightly repeats the title rather than adding richer 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?

For a simple read-only tool with fully documented parameters and safe annotations, the minimal description is arguably sufficient. However, without an output schema and with sibling tools that overlap in purpose, the lack of additional context about return shape and tool selection leaves 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 100%, so the baseline is 3. The description itself adds no parameter meaning, but the schema already fully documents symbol's canonical-form behavior and the generic _jq filter, so no significant gap exists.

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 concrete resource ('latest financial report summary'), and the scope ('for a security'). However, it does not distinguish this tool from siblings like financial_report, financial_report_snapshot, or financial_report_key_metrics, so the clarity is good but not excellent.

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 when-to-use guidance, no mention of alternatives, and no exclusions. Given the large sibling set containing several closely related financial-report tools, an agent receives no help selecting this tool over those 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by listing return field groups, but does not discuss auth requirements, rate limits, or response shape (no output schema). With annotations covering most behavioral expectations, a 3 is appropriate for the modest extra context.

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

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

The description is a compact single sentence that front-loads the main action and then lists the key field groups and report types. It avoids redundancy and every clause contributes meaning, though it might be slightly dense for an agent to parse quickly.

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 snapshot tool with rich annotations (safe, idempotent, read-only), the description covers the core return fields and report types. No output schema exists, but the listed fields give sufficient context for an agent to decide whether this tool provides the needed data. Minor gaps like pagination or filter behavior are not critical for a snapshot.

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

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

Schema description coverage is 100%, so all five parameters (symbol, report, fiscal_year, fiscal_period, _jq) are documented in the schema. The description's mention of report types ('qf/saf/af') and field groups adds only marginal semantic value beyond what the schema already provides; baseline 3 is correct.

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 ('financial report snapshot'), enumerates the exact field groups returned (report_desc, fo_revenue/fo_ebit/fo_eps, fr_* ratios), and clarifies report types (qf/saf/af). This distinguishes it from siblings like financial_report, financial_report_key_metrics, and financial_statement by the snapshot's condensed nature and the specific 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 implies usage by naming the report types and field categories, but it does not explicitly state when to prefer this tool over alternatives (e.g., financial_report_latest for the most recent data, financial_report_key_metrics for ratios only). No when-not or alternative-selection guidance is provided beyond the tool's inherent scope.

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

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

Annotations already disclose that this is read-only, idempotent, and non-destructive. The description adds the supported statement kinds and report periods, which is useful scoping context. It does not describe response shape, pagination, rate limits, or the behavior of the ALL option, 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?

The description is two compact sentences with the purpose front-loaded and no filler. The parameter quick-reference is dense but immediately useful. It earns its place despite some overlap with the 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?

The core invocation details are present: required symbol, kind values, report values, and defaults. However, with no output schema, the description does not clarify the shape of the response or what ALL returns. It also lacks disambiguation from closely related sibling tools, making the context adequate but not complete.

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

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

Schema coverage is 100%, so the schema already documents kind, report, symbol, and _jq. The description largely restates the kind/report enums and adds that 'af' is the default report, which is a minor increment. This is a baseline-3 situation where the schema carries the parameter-documentation burden.

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

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

The description says 'Get financial statements (income statement, balance sheet, or cash flow) for a security,' which is a specific verb and resource. It clearly identifies what the tool returns. However, it does not differentiate this tool from nearby siblings such as financial_report, cash_flow, or statement_export.

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

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

There is no guidance about when to use financial_statement versus related alternatives like financial_report, financial_report_snapshot, cash_flow, or statement_export. The only implicit guidance is that it is relevant when financial statements are requested. No exclusions, prerequisites, or alternative-selection conditions are stated.

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

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

The annotations already provide a strong safety profile: readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds only the output scope and no behavioral details such as pagination, empty responses, or return shape. It does not contradict the annotations, but it also does not enrich 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 concise sentence with no filler: 'Get EPS forecast and analyst estimate history.' The core resource and action are front-loaded, 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 read-only two-parameter query, the annotations and schema cover safety and inputs well. However, there is no output schema, and the description only vaguely mentions return categories without specifying fields, forecast period, or how estimates are structured. It is adequate but leaves meaningful 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 100%, with detailed parameter explanations including the canonical-symbol caveat for `symbol` and a full `_jq` description. The tool description itself contributes no additional parameter-level meaning, so the 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 uses a clear verb and resource: 'Get EPS forecast and analyst estimate history.' It is unambiguous and distinct in topic, but it does not explicitly contrast sibling tools like consensus or institution_rating, so it stops short of full 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 gives no guidance on when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. With many related estimation/rating siblings present, selection would rely on the agent's prior knowledge rather than the description.

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