ocr_identi5Extract key fields from a Korean alien registration card (residence card) image via OCR. 외국인등록증 사진에서 이름, 외국인등록번호, 발급일자 등 주요 정보를 추출해 구조화된 결과와 원문 텍스트(raw_text)를 반환합니다. 정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오. [호출당 12포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | 다운로드 가능한 https URL (허용 형식: image/png, image/jpeg) (최대 50MB) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which is consistent with the extract operation. The description adds useful behavioral context beyond the annotation: the per-call cost (12 points), the legal consent requirement, and the return of raw_text in addition to structured fields. This goes beyond what the annotation states.
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 reasonably concise, with the core purpose front-loaded in English and additional detail in Korean. There is some redundancy between the English and Korean sentences, but it remains efficient and no sentence is wasted.
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 single-parameter OCR tool with no output schema, the description covers the essential: what it extracts, the return format (structured + raw_text), and legal/usage constraints. It is nearly complete, though it could be more explicit about the exact structure of the returned object, but given the simplicity, this is acceptable.
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% — the image_url parameter already includes allowed formats (image/png, image/jpeg) and size limit (50MB). The description adds no extra parameter-specific details, so it adds no value beyond the schema; baseline 3 is appropriate.
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 verb ('Extract'), a specific resource ('Korean alien registration card image'), and lists the key fields extracted (name, foreigner registration number, issue date). It also mentions returning structured results and raw_text, and the document type clearly distinguishes it from sibling OCR tools for other documents.
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 a clear usage condition: only use when lawful processing grounds (e.g., consent) are secured. However, it does not explicitly mention when to use this tool versus the sibling tools (ocr_identi1-4), though the document type is specified, making the selection inferable.
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: the generic `ocr` handles any image, while `ocr_identi1` through `ocr_identi5` are each tied to a specific document type (resident card, driver license, passport, certified copy, alien card). There is no ambiguity about which tool to use for a given input.
All tools follow a consistent `ocr` prefix with snake_case, and the specific ones use `ocr_identi` + numeric suffix. While the pattern is predictable, the numeric suffixes are not descriptive of the document type, which reduces self-documentation slightly.
Six tools is well-scoped for an OCR server. The generic tool handles broad use cases, and the five specific tools cover common identity documents without redundancy or bloat.
The server provides both a general OCR tool and structured extraction for the most common Korean ID documents. There are no obvious dead ends; the domain is fully covered for typical OCR and identity-document needs.