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.