identi_card_image3Verify the authenticity of a Korean passport from an image or PDF file. 여권 인적사항면 이미지 또는 PDF 파일을 업로드하면 기재 정보를 자동 인식해 진위 여부를 확인합니다. 텍스트 입력 없이 파일 하나만 전달하면 됩니다. 정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오. [호출당 60포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | 다운로드 가능한 https URL (허용 형식: image/jpeg, image/png, application/pdf) (최대 50MB) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true, and the description does not contradict them. It adds valuable behavioral details: the tool costs 60 points per call, requires legal basis (consent), and outputs nothing about returns. This additional context goes beyond annotations, so a 4 is appropriate.
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 and front-loaded with the core purpose, followed by input requirements, point cost, and legal notice. It is not bloated, though the Korean and English versions repeat the same information, which could be slightly redundant but still efficient.
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 tool with a single well-documented parameter and no output schema, the description covers the essential context: what it does, input format, point cost, and legal requirement. It is complete enough for an agent to decide when to use it and how to invoke it, without missing critical details.
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% for the single parameter image_url, which already specifies the types (jpeg, png, pdf) and size limit (50MB). The description does not add extra semantic meaning beyond the schema, so the baseline of 3 applies.
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 verb 'Verify' and the resource 'Korean passport', and specifies the input type (image or PDF). It distinguishes itself from sibling tools by focusing on image/PDF-based passport verification, which is evident from the title and description.
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 about the input (no text, just file) and legal requirement (consent), but it does not explicitly mention when to prefer this tool over alternatives like identity_document_passport or other identi_card_image tools. It gives some guidance but lacks explicit exclusions or named alternatives.
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 distinct purpose: masking (hide_rrn), text-based verification (identi_cardN), image-based verification (identi_card_imageN), extraction with masking (identity_document_*), and name/RRN matching (name_rrn_auth). Within each group, the document type is clearly specified, so there is no ambiguity between tools.
Naming follows clear patterns: identi_card* for verification (with _image for image-based), identity_document_* for extraction, and descriptive names like hide_rrn and name_rrn_auth. While the prefixes differ across functional groups, each group is internally consistent and the names are readable and predictable.
16 tools is on the higher end but appropriate for the server's scope, covering five document types with two verification modes (text and image), four extraction/masking tools, a generic masking tool, and a name/RRN auth check. Each tool fills a needed role, though the number is slightly elevated due to the text/image split.
The server covers the core operations for identity document verification and extraction across all major Korean ID types. A minor gap is the lack of an extraction/masking tool for the resident registration certificate (identi_card4), but this is not a critical omission given the existing verification and masking capabilities.