Skip to main content
Glama

외국인등록증 텍스트 추출(OCR)

ocr_identi5
Read-only

Extract key fields from a Korean alien registration card (residence card) image via OCR. 외국인등록증 사진에서 이름, 외국인등록번호, 발급일자 등 주요 정보를 추출해 구조화된 결과와 원문 텍스트(raw_text)를 반환합니다. 정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오. [호출당 12포인트]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
image_urlYes다운로드 가능한 https URL (허용 형식: image/png, image/jpeg) (최대 50MB)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / image_url / description
      Previous value: -"다운로드 가능한 https URL (허용 형식: image/png, image/jpeg) (최대 25MB)"New value: +"다운로드 가능한 https URL (허용 형식: image/png, image/jpeg) (최대 50MB)"
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already mark the tool read-only, and the description adds useful behavior beyond that: it returns structured fields plus raw_text, and it discloses a per-call point cost. No contradiction exists. It does not cover error behavior or image failures, but the additional context is meaningful.

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

Conciseness5/5

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

The description is compact: an English summary, a Korean sentence that adds fields/output/legal condition/cost, and no filler. It is front-loaded with the action and resource, and every clause contributes information.

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

Completeness4/5

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

For a one-parameter OCR tool with annotations, the description is nearly complete: it names inputs, example fields, output types, legal precondition, and cost. With no output schema, the raw_text/structured-result mention helps, though a fuller field list would make it complete.

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

Parameters3/5

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

Schema coverage is 100% and the only parameter image_url is fully described with URL type, allowed MIME types, and size limit. The description adds no new parameter semantics and is not required to, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('extract') and resource ('Korean alien registration card image') and names example fields, clearly identifying the tool's function. It does not explicitly differentiate from sibling OCR/identity tools like ocr_identi1-4 or identity_document_residence_card, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the clear context: use when a Korean ARC image needs key-field extraction via OCR. It also gives a concrete prerequisite (secure legal basis/consent before processing). It does not spell out when-not-to-use or name alternatives, which would have made the guidance stronger.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.