Skip to main content
Glama

APICK

by app.apick

[Text] 외국인등록증 진위 확인

identi_card5
Read-only

Verify the authenticity of a Korean alien registration card (residence card) using text input. 외국인등록증의 기재 정보를 입력해 진위 여부를 확인합니다. rrn(외국인등록번호 13자리)과 made_date(발급일자 10자리, 예: 2020-01-01)는 필수이며, card_sn(뒷면 일련번호)은 입력 시 11자리여야 하고 2011-01-01 이후 발급된 등록증은 필수입니다. 정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오. [호출당 40포인트]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rrnYes외국인등록번호 (숫자 13자리)
card_snNo뒷면 일련번호 (11자리). 2011-01-01 이후 발급분은 필수
made_dateYes발급일자 (10자리, 예: 2020-01-01)

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by disclosing the cost per call (40 points) and the need for legitimate processing grounds. No contradiction with annotations.

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

Conciseness4/5

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

The description is concise and front-loaded with the purpose. It includes some redundancy (English and Korean versions of the same statement) but remains efficient and information-dense.

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

Completeness3/5

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

Input requirements are well covered, but since there is no output schema, the description does not explain what the verification result looks like (e.g., a boolean, status message, or error). This is a notable gap for a verification tool.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds critical validation details: digit lengths (rrn 13, made_date 10, card_sn 11), a date format example, and the condition that card_sn is required for cards issued after 2011-01-01. This goes beyond the schema.

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

Purpose5/5

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

The description clearly states the action ('Verify the authenticity') and the resource ('Korean alien registration card'), and distinguishes itself from sibling image-based tools by specifying 'using text input'.

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 provides specific usage context: required fields, digit constraints, conditional requirement for card_sn, and the legal basis for use. However, it does not explicitly compare with alternative tools or state when not to use it.

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

All APICK toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation4/5

Most tools have clearly distinct purposes; even within families like identi_card1-5 vs identi_card_image1-5, the text-input vs image-input distinction is clear. However, the sheer number of tools and some near-synonyms (e.g., ocr_identi1 vs identi_card_image1) could cause occasional misselection, but descriptions mitigate this.

Naming Consistency3/5

Naming follows a loose verb-first pattern (check_, crawl_, download_, draw_, etc.) but includes significant deviations: bare nouns (bank_code, location, whois), numbered variants (identi_card1, identi_card_image1), and mixed prefixes (ocr_, identity_, etc.). The inconsistency is noticeable but still readable and predictable within functional clusters.

Tool Count3/5

80 tools is far above the typical 3-15, but the server is a broad API aggregator covering many independent domains (banking, ID verification, media conversion, search, LLM, etc.), so the high count is somewhat justified. Still, the sheer number makes the toolkit feel unwieldy and hard to navigate, placing it at the high end of acceptable.

Completeness4/5

Within its stated purpose as a general-purpose utility API, the toolset covers a wide array of common task families: identity document verification (text and image), OCR field extraction, media conversion, web/search, domain/IP lookup, and LLM chat. Most operations have both get and act variants (e.g., set/get watermark, parcel_tracking/auto), with few obvious dead ends for typical use cases.

Resources