transfer_1wonSend a 1 KRW verification deposit to a Korean bank account and return the 4-character verification code printed on the transaction. 대한민국 은행 계좌로 1원을 입금해 적요에 표시되는 인증코드를 반환합니다. 계좌 실소유 확인(1원 인증) 절차에 사용합니다. bank_code 또는 bank_name 중 하나는 입력해야 합니다. [호출당 60포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| bank_code | No | 은행 코드 (bank_code Tool로 조회 가능, 예: 004) | |
| bank_name | No | 은행명 (예: 국민). bank_code 대신 입력 가능 | |
| account_num | Yes | 계좌번호 (숫자만, 하이픈 제외) |
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.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: listing bank codes, looking up account holder names, and sending a 1-won verification deposit. No overlap or ambiguity between them.
All names are lowercase snake_case, but the pattern is not uniform: 'bank_code' and 'account_realname' are noun phrases while 'transfer_1won' is a verb phrase. Still readable and predictable within this small set.
With exactly 3 tools, the set is well-scoped for the server's purpose of Korean bank account verification. Each tool is necessary and earns its place.
The tool surface covers the full verification workflow: lookup bank codes, check account holder, and perform the 1-won verification transfer. No obvious gaps for the stated domain.