APICK Finance

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

Annotations already declare readOnlyHint=true, and the description aligns with a read-only lookup. It adds value by disclosing the per-call cost ('[호출당 60포인트]') and the requirement to provide at least one of bank_code/bank_name. 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 concise but includes both English and Korean versions of the same information, which is slightly redundant. However, it is front-loaded with the core purpose, and the cost note is useful. Each 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 lookup with no output schema, the description provides sufficient context: purpose, usage scenario, input constraints, and cost. Given the sibling tools and annotations, the information is complete enough for an agent to select and invoke the 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 descriptions cover 100% of parameters, and the description supplements them by clarifying the XOR relationship between bank_code and bank_name, and references the bank_code Tool for obtaining codes. This adds 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 clearly states 'Look up the account holder name of a Korean bank account,' specifying the verb (look up) and resource (account holder name). It is distinct from sibling tools like bank_code (lookup bank codes) and transfer_1won (send 1 won for verification).

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 usage context with '송금 전 예금주 확인 등에 사용합니다' (used for confirming account holder before remittance) and a required condition: 'bank_code 또는 bank_name 중 하나는 입력해야 합니다' (either bank_code or bank_name must be entered). However, it doesn't explicitly contrast with transfer_1won, which might serve a similar verification purpose, so it lacks explicit exclusion.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, making the read-only nature clear. The description adds useful context beyond annotations: it returns the full list of bank codes and names and mentions it is free. For a simple read-only operation, this is sufficient 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 brief and front-loaded with the core purpose. However, the Korean sentence repeats the English content, and '무료' appears twice, adding minor redundancy. Still, it is concise overall.

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 list tool with no parameters and no output schema, the description fully covers what the tool returns and when to use it. The annotations (readOnlyHint, openWorldHint) provide safety context, so no further details are 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, and the description confirms it returns the entire list without any filters. Per the rubric, a zero-parameter tool receives a baseline score of 4, and the description aligns with the schema (empty object).

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

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

The description clearly states it lists Korean bank codes and names, using a specific verb ('List') and resource. It also distinguishes itself from sibling tools by explicitly noting that it provides bank_code input values for transfer_1won and account_realname.

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

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

The description explicitly states when to use the tool: 'transfer_1won, account_realname Tool의 bank_code 입력값을 찾을 때 사용합니다.' This gives clear usage context and a concrete use case, with no competing alternatives for this purpose.

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 non-read-only, non-idempotent operation. The description adds valuable context: the tool performs a real money transfer, costs 60 points per call, and returns a verification code. This goes beyond the structured 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?

The description is concise, front-loaded with the primary action, and includes essential details (return value, use case, input requirement, cost) with no fluff. The bilingual repetition is acceptable for the target audience and does not detract from clarity.

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 3-parameter tool with no output schema, the description covers the outcome (returns code), usage context, input constraints, and cost. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so parameter meanings are already documented. The description adds an important cross-parameter constraint: bank_code or bank_name must be provided, which the schema alone does not enforce. This extra guidance justifies a score above 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 clearly states the specific action: sending a 1 KRW verification deposit and returning the 4-character code from the transaction. It also identifies the use case (account ownership verification) and is distinguishable from sibling tools like account_realname and bank_code.

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

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

The description explicitly says this is for account real-owner verification (1원 인증) and requires bank_code or bank_name. However, it does not explicitly mention when not to use it or compare with sibling alternatives like account_realname.

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