APICK Finance

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it is limited to Korean bank accounts, requires either bank_code or bank_name, and costs 60 points per call. It does not describe failure behavior, but for a read-only lookup with clear annotations this is acceptable.

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

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

The description is compact and front-loaded with the action and purpose, followed by the key input constraint and cost. The Korean sentence duplicates the English sentence, which is somewhat redundant, but the bilingual structure is purposeful for the target domain and does not add excessive length.

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 3 parameters, all fully documented in the schema, and read-only annotations. The description adds the remaining essential context: Korean bank scope, remittance-check use case, the bank_code/bank_name precondition, and point cost. No output schema exists, but the expected result is clear from the stated purpose. Error-case details are not critical for this read-only lookup.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema by clarifying that bank_code or bank_name is required even though both are optional in the JSON schema. It also reinforces the account_num format requirement indirectly by mentioning the Korean bank account context.

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 and resource: 'Look up the account holder name of a Korean bank account.' It also adds the practical context of verifying the account holder before remittance, which distinguishes it from nearby identity/name tools like name_rrn_auth.

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 an explicit use case: '송금 전 예금주 확인 등에 사용합니다' (used for verifying account holder before remittance). It also states a necessary precondition: 'bank_code 또는 bank_name 중 하나는 입력해야 합니다' (either bank_code or bank_name must be entered). It does not explicitly mention alternatives or when not to use the tool, so a small gap remains.

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 the read-only, open-world nature, so the description needs only add extra behavioral context. It adds that the tool is free and that it returns the complete bank list for use as an input reference. It doesn't describe response structure or update behavior, but these are minor for a zero-argument list 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 main purpose is front-loaded and clear, and the use case is useful. However, the same information is repeated in English and Korean, and '무료입니다. [무료]' duplicates the free notice, adding minor noise.

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

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

For a zero-parameter tool, the description is functionally complete: an agent knows what it returns, why it exists, and that it costs nothing. Without an output schema, a sample return shape would be a nice addition, but the stated purpose 'bank codes and names' adequately implies the output.

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 takes no parameters, so there are no parameter semantics for the description to illuminate. The baseline for zero-parameter tools is 4, and the description correctly focuses on the output data instead.

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 concrete verb and resource: 'List Korean bank codes and names,' and further clarifies it returns the full list ('전체 목록을 반환합니다'). This clearly distinguishes bank_code from the many sibling tools and states exactly what data is returned.

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 intended use case: finding the bank_code input value for transfer_1won and account_realname. It stops short of giving exclusions or comparing to alternatives, but no sibling provides a comparable bank-code lookup, so this is sufficient 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?

The description adds meaningful behavioral context beyond annotations: it actually sends money, returns a transaction code, requires one of two bank identifiers, and costs 60 points per call. It could mention irreversibility or refund status, but the annotations already signal real-world side effects via openWorldHint=true and readOnlyHint=false.

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 main action is front-loaded and the text is fairly short, but the English and Korean sentences largely duplicate the same information. The bilingual format is helpful for human users, yet not every sentence adds new semantic value for 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?

With no output schema, the description compensates by identifying the return value: the 4-character verification code displayed in the transfer memo. It covers purpose, input requirements, and cost. It omits error scenarios, transfer timing, and what happens to the 1 KRW, but for a simple 3-parameter tool it is largely sufficient.

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

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

The schema already covers all three parameters, but the description adds a critical validation rule not present in the schema: one of bank_code or bank_name must be supplied. This clarifies the optional-looking schema fields and adds operational 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 operation: send a 1 KRW verification deposit to a Korean bank account and return the 4-character verification code from the transaction memo. This clearly distinguishes it from sibling tools like account_realname or 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?

It explicitly identifies the use case (account ownership verification / 1원 인증) and states that bank_code or bank_name must be provided. It does not name alternatives or give when-not-to-use guidance, so it falls short of a 5.

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