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

No annotations are provided, so the description carries the transparency burden. It discloses that the operation fetches (a read action) and executes in parallel, adding useful behavioral context beyond a bare schema. It does not detail error handling, pagination, or permissions, but for a simple read-only fetch this is adequate.

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

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

The description is a single, front-loaded sentence that conveys the verb, object, scope, and execution style with no wasted words. It is highly concise and well structured.

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

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

For a zero-parameter read tool with an output schema, the description is complete. It specifies the full scope (all holding types), and the output schema handles return structure. No additional context is necessary.

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

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

The tool has zero parameters, so the baseline for parameter semantics is 4. The description correctly avoids inventing parameters and instead focuses on the scope of the returned data, which 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 the specific verb 'Fetch' and clearly identifies the resource as 'all portfolio holdings' with enumerated asset types (cash, equities, mutual funds, bonds, other). This distinguishes it from sibling tools like get_cash_balances or get_equity_balances, which target individual asset types.

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 a complete view across all asset classes is needed, especially with the 'in parallel' execution hint. It does not explicitly state alternatives or when-not-to-use, but the sibling tool names and the 'all' scope make the intended usage 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description does not explicitly state safety, return format, or any limitations. For a tool with zero annotations and no output schema, this is a significant 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 a single, efficient sentence that avoids redundancy and front-loads the action. 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?

With no output schema, the description should clarify what the response contains or how it interacts with other portfolio tools. The absence of any mention of return structure, scope, or relationship to get_all_portfolios leaves the agent with incomplete information for a complete request.

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

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

The tool has zero parameters, so the description does not need to document parameter semantics. The baseline of 4 is appropriate because there are no parameter-related ambiguities to resolve.

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 bond and government securities holdings, using the explicit verb 'Get' with a specific resource. It distinguishes itself from sibling tools like get_cash_balances and get_equity_balances by asset class, and the parenthetical 'Obligasi / SBN' adds clarity for Indonesian government securities.

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

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

Usage context is implied by the asset class and sibling structure—users would select this for bond holdings rather than equities or cash. However, there is no explicit when-to-use guidance or indication of how this differs from get_all_portfolios, which may also include bond positions.

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

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

With no annotations provided, the description carries the full burden. 'Get' implies a read-only operation, and 'detailed' hints at comprehensive output, but it does not explicitly disclose non-mutating behavior, nor does it mention any requirements, rate limits, or exact output contents. The description adds contextual value with the RDN terminology but lacks detailed behavioral disclosure.

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

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

The description is a single, concise sentence that efficiently communicates the tool's purpose. It includes the helpful local term 'Rekening Dana Nasabah (RDN)' without wasted words. Every phrase contributes to understanding the tool's function.

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

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

The tool has no output schema and no annotations, so the description alone must explain return behavior. It states 'detailed cash balances' but does not specify the structure, aggregation level, or whether all accounts are included. While the tool is simple, the absence of output details leaves room for ambiguity about what 'detailed' entails, making the description minimally 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?

The tool has zero parameters, so the schema is complete. Per the rubric, 0 params yields a baseline of 4. The description appropriately does not attempt to describe parameters, as there are none, and adds no unnecessary syntax information.

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

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

The description clearly states the tool gets detailed cash balances (Rekening Dana Nasabah / RDN) across securities accounts, using a specific verb 'Get' and a well-defined resource. The mention of 'cash balances' and the term 'RDN' differentiates it from sibling tools like get_equity_balances and get_bond_balances.

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 fetching cash balances, and the sibling tool names suggest when to use this over alternatives, but it does not explicitly state exclusions or when to use this vs. another tool. The scope 'across securities accounts' provides context but no direct comparison to get_portfolio_summary or other asset-specific balance 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?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only mentions the content of the response (shares, market value, prices) but does not disclose whether the operation is read-only, required permissions, potential side effects, or pagination behavior. The implication of a 'get' is not enough to satisfy this dimension.

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

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

The description is a single, concise sentence that front-loads the core purpose and key return fields. There is no wasted phrasing or redundancy.

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

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

There is no output schema, so the description must explain return values. It lists shares, market value, and prices but uses 'including' to imply non-exhaustive coverage. It does not specify whether the result is a list or single object, or whether there are additional fields. Given the tool's simplicity, 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 has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics since there are none. It adds value by indicating the kind of data returned, but this is not parameter-related.

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 detailed Indonesian stock holdings (Saham) with shares, market value, and prices. It uses a specific verb ('Get') and resource ('equity balances'), and the qualifier 'Indonesian' distinguishes it from sibling balance tools.

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

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

The description provides context (Indonesian stocks) but does not explicitly state when to use this tool versus alternatives like cash or bond balances. No exclusions or alternatives are mentioned, so the agent is left to infer usage based on the tool name and sibling listings.

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

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

Without annotations, the description carries the full burden. The verb 'Get' implies a read-only operation, but there is no mention of authentication, data sensitivity, or any side effects. This is minimal but not misleading, so it earns an average score.

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

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

The description is a single concise sentence, front-loaded with the verb and resource. Every word earns its place, with no redundancy.

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

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

Given the low complexity (no parameters, no output schema), the description is mostly complete. It names the key data returned (identity, SID, investor profile), but could provide slightly more detail on what 'SID' stands for or what 'investor profile details' includes. Still, for a simple getter, it suffices.

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

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

The tool has zero parameters, earning a baseline of 4. The description adds no parameter details because none exist, which 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 'Get' with a clear resource: KSEI account holder identity, SID, and investor profile details. This clearly distinguishes it from sibling tools that focus on balances and portfolio summaries.

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: this tool retrieves identity/profile data, which is distinct from the balance and portfolio tools. However, it does not explicitly state when to use it versus alternatives or provide exclusion criteria, so it lacks the explicit guidance of a score 5.

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

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

No annotations are present, so the description carries the burden. It conveys this is a read-only operation ('Get') and discloses the returned data elements: unit counts and NAV values. It does not clarify scope (e.g., current portfolio vs all portfolios), but the operation is non-destructive and simple.

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

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

The description is a single, front-loaded sentence with no filler. It quickly states the action, resource, and key return contents in under 15 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 parameterless read tool, the description is mostly complete: it names the asset class and explicitly states what the returned holdings include. The only notable gap is whether the data is scoped to a specific portfolio, but given no parameters and the sibling tool structure, this is a minor ambiguity.

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

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

The tool has zero parameters, so the baseline is 4. The schema has no fields to document, and the description adds useful semantics by naming the returned data points (unit counts and NAV values).

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 gets mutual fund holdings, explicitly names the Indonesian term 'Reksadana,' and specifies the key return components (unit counts and NAV values). This distinguishes it from sibling balance tools for other asset classes.

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. It doesn't mention sibling tools like get_equity_balances or get_portfolio_summary, nor does it state exclusions or preferred contexts. Usage is only implied by the tool's name.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. The verb 'Get' signals a read-only operation, which is helpful. However, it does not disclose the return structure, authentication needs, or what specific instruments are included under 'other,' leaving some behavioral ambiguity for such a simple tool.

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

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

The description is a single sentence of seven words with no filler. It front-loads the action and the scope, and every word contributes to the meaning. This is appropriately concise for a tool with no parameters.

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

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

The tool has no output schema and no annotations, so the description must define both scope and expected return. It does state that the tool returns 'balances,' but it leaves 'other' undefined and does not specify whether the response is a list, map, or aggregate. Sibling names help partially, but the lack of examples of 'other instruments' creates ambiguity.

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

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

The input schema has zero properties, so there are no parameter names or types to describe. Per the rubric, 0 parameters gives a baseline of 4. The description adds no parameter details, but none are needed.

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

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

The description uses the verb 'Get' with a specific resource: 'other financial instruments and investment balances.' This indicates the tool is for balances outside the dedicated cash/equity/mutual fund/bond balance tools. However, the word 'other' is relative and relies on sibling names for full differentiation, so it stops short of a 5.

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

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

The description does not explicitly state when to use this tool versus alternatives, but the word 'other' implies it is a catch-all for balances not covered by sibling tools like get_equity_balances or get_cash_balances. This is implied usage guidance, not an explicit when-to-use/when-not-to-use recommendation.

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

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

No annotations are present, so the description must carry behavioral context. It only states the high-level nature of the summary without disclosing return format, aggregation level, or any access restrictions, leaving significant gaps.

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, clear sentence that wastes no words and provides the essential information upfront.

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

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

Despite being concise, the description lacks any detail about the summary output structure or potential limitations, making it barely adequate for an agent to understand the full scope of the tool, especially with no output schema.

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

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

The tool has zero parameters, and the schema confirms this. The description does not need to explain parameters; the baseline for zero-param tools is 4, and the description adds no unnecessary parameter details.

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

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

Description clearly states the tool retrieves a high-level summary of all portfolio holdings and balances, using a specific verb and resource. It distinguishes itself from sibling tools that focus on specific asset types (e.g., get_cash_balances) or full portfolios.

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 a high-level overview is needed, but it does not explicitly contrast with alternatives like get_all_portfolios or provide when-to-use/when-not-to-use guidance. It offers a clear context but no exclusions.

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