APICK Identity

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

Annotations already declare readOnlyHint=true, so the tool is known to be non-mutating. The description adds value by specifying the cost (20 points per call), the legal requirement, and the fact that it returns a masked image. It does not contradict annotations, and it gives context not present in the schema, such as the legal basis constraint.

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 two sentences (one bilingual) and effectively packs the core function, parameters, legal requirement, and cost into a compact block. It is front-loaded with the main verb and outcome, followed by the type details and usage caveat. While it repeats some schema information, it does so succinctly and without fluff.

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 only two parameters and no output schema, the description covers the essential context: what it does, what the inputs mean, the legal prerequisite, and the cost. It does not describe the output format in detail, but it states it returns the masked image, which is sufficient. Given the schema handles input constraints (URL format, size), the description is complete enough for an agent to call it 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 coverage is 100% (both parameters have descriptions), so the baseline is 3. The description adds meaning by elaborating each type value (e.g., type 3 is 'mask except first digit of last part') and clarifies that both inputs are mandatory. This goes beyond the schema's terse '가림 처리 타입' and provides concrete interpretation for the agent.

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 ('mask'), a clear resource ('resident registration numbers found in an image'), and the outcome ('return the masked image'). It explicitly enumerates four masking types, and the tool is clearly distinct from sibling tools that focus on identity-document recognition or authentication. There is no ambiguity about the tool's function.

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 clearly states that both the image and the type parameter are required, and it lists the four allowed type values. It also provides a critical usage condition: only use with a legitimate processing basis such as data-subject consent. It does not explicitly contrast with alternatives, but the sibling tools are obviously different in purpose, so this is adequate.

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

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

Annotations already provide readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context: mandatory input fields, date format validation, legal authorization prerequisite, and cost per call. It does not disclose output structure or error handling, but given the annotations, the additional context is well above baseline.

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 compact, with the purpose front-loaded in the first sentence, followed by critical usage constraints and cost in a single follow-up. Every sentence earns its place, and the bilingual text is efficient without unnecessary detail.

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 read-only verification tool with four documented parameters and no output schema, the description covers purpose, input requirements, format constraints, legal basis, and cost. It does not mention what the tool returns (e.g., valid/invalid), which would be helpful, but the tool's simple nature and the provided annotations make the description largely complete.

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?

The schema already describes all four parameters with 100% coverage. The description only restates that all four are required and reinforces the numeric-only rule for date, which duplicates the schema's parameter descriptions. No meaningful new semantics are added, so the baseline score of 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 explicitly states 'Verify the authenticity of a Korean resident registration card (jumin-deungnokjeung) using text input.' This is a specific verb+resource combination and the 'text input' qualifier distinguishes it from image-based sibling tools like identi_card_image1. The Korean title confirms the same purpose.

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 clearly specifies that all four parameters must be entered and that date must be numeric, which guides usage. It also states the legal requirement ('정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만') and discloses the per-call cost. It does not explicitly name alternative tools, but the 'text input' wording implicitly differentiates from image-based siblings.

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

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

Annotations already declare readOnlyHint=true, and the description adds context such as required vs optional fields, a per-call cost, and the need for legitimate processing basis. These go beyond the 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 two succinct sentences plus a legal note and cost indicator. It is front-loaded with the purpose and avoids unnecessary detail.

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?

It provides essential context: tool purpose, required/optional parameters, legal usage constraint, and cost. It does not describe the return value/response format, which is a gap given there is no output schema, but overall it is sufficient for selection and invocation.

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?

The input schema has 100% description coverage for all 11 parameters. The tool description repeats the required/optional distinction and parameter groups but does not add new semantic meaning beyond the schema, so it stays at 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 'Verify the authenticity of a Korean driver license using text input,' with a specific verb, resource, and input mode. This distinguishes it from image-based sibling tools and other document types.

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?

It indicates 'using text input' as the context and lists required/optional fields, plus a legal prerequisite for consent. However, it does not explicitly name alternatives or state when not to use, leaving some ambiguity compared to siblings.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description's job is to add context. It discloses required input completeness (all five fields), numeric date constraints, the per-call point cost, and the legal compliance requirement, going beyond the 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 reasonably concise and front-loaded with the main purpose. However, it repeats the same information in English and Korean, creating slight redundancy, though the added legal and cost details justify the length.

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?

The description covers input requirements, legal basis, and cost, but does not describe the expected output format or behavior on invalid vs. valid passports. With no output schema, this leaves some operational uncertainty, though the readOnly and openWorld annotations mitigate safety concerns.

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 coverage is 100% and each parameter already includes a description with format examples (e.g., '숫자만, 예: 20230101'). The description mainly restates the requirement that all five fields must be entered, adding little beyond what the schema provides.

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 opens with 'Verify the authenticity of a Korean passport using text input,' clearly stating the tool's specific function and resource. The phrase 'text input' distinguishes it from image-based sibling tools like identi_card_image1, and the title '[Text] 여권 진위 확인' reinforces this differentiation.

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 specifies a text-input use case, which implies when to use this over image variants, and explicitly warns to use only when legal basis such as consent is secured. However, it does not name alternative tools directly or state exclusions, so some implicit guidance remains.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds useful behavioral context: legal processing basis is required and each call costs 40 points, which is beyond the annotations.

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 compact and front-loaded with an English summary, followed by a Korean explanation. It includes the cost note and legal requirement in just a few sentences, with no redundant or filler content.

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?

There is no output schema, so the description should explain the return format or success/failure behavior, but it does not. It adequately covers input parameters and usage conditions, but the missing output information leaves a gap for an AI agent invoking the tool.

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 coverage is 100% with descriptions for all parameters, so the baseline is 3. The description reiterates the same parameter meanings (e.g., doc_num1-4 are 4-digit segments, type meanings) without adding new semantic details beyond the schema.

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 explicitly states 'Verify the authenticity of a Korean resident registration certificate' and specifies the input method (text input), clearly distinguishing it from image-based siblings like identi_card_image1. It also mentions the specific document confirmation number and issuance type, making the purpose highly specific.

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 states required parameters (doc_num1-4, type) and that name is optional, plus the legal basis requirement for usage. It implies text input rather than image input, but does not explicitly name alternative tools or state when not to use this tool.

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

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

The annotation readOnlyHint: true already indicates it's a safe read operation. The description adds behavioral context such as the legal compliance requirement and the per-call cost of 40 points, plus parameter constraints. These go beyond the annotations and provide useful operational guidance, though the return format is not described.

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 moderately concise, with the redundant Korean sentence repeating the first English sentence being the main inefficiency. However, the rest of the sentences each add unique value (parameter details, legal note, cost), so it remains well-structured and informative.

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?

At 3 parameters with no output schema, the description provides enough context to understand the tool's purpose and constraints, but it does not describe the return value or error behavior. Given the tool is for verification, this omission leaves some ambiguity for the agent regarding how to interpret the result.

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?

The input schema has 100% description coverage for all 3 parameters. The description adds extra semantic detail, particularly the 11-digit format for card_sn and the conditional requirement that it becomes mandatory for cards issued after 2011-01-01, which is not in the schema.

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 it verifies the authenticity of a Korean alien registration card using text input, which is a specific verb and resource. It distinguishes from image-based siblings by explicitly mentioning 'text input'.

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 for when the tool should be used, including legal basis ('정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오') and conditional requirement for card_sn for cards issued after 2011-01-01. However, it does not explicitly name alternatives 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value beyond these: the legal/consent processing requirement and the cost note ('[호출당 60포인트]'). It does not contradict annotations — verification is a read-only operation consistent with readOnlyHint. It stops short of richer disclosure (e.g., what the verification response contains), but adds meaningful context.

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 compact and front-loads the primary purpose, followed by usage guidance, legal note, and cost. It is mildly redundant — the English lead sentence and the Korean sentence express essentially the same purpose — but remains reasonably tight with no extraneous filler. Each sentence contributes, though two could be merged.

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 tool with 100% schema coverage and read-only annotations, the description is largely adequate. The main gap is the absence of any statement about the verification output format (boolean result, OCR'd fields, report) since no output schema exists. Given the sibling cluster and the sensitive personal-data nature, slightly more on expected behavior would strengthen it.

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 the schema already documents image_url (downloadable https URL, allowed formats jpeg/png/pdf, 50MB limit). The description marginally supplements this by stressing single-file, no-text input, but does not add format or syntax details beyond what the schema provides. Baseline 3 is appropriate when the schema carries the parameter documentation.

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 and resource: 'Verify the authenticity of a Korean resident registration card from an image or PDF file.' The title adds '[Image/PDF]' which distinguishes it from the text-input siblings (identi_card1-5). However, it provides no differentiation among the nearly identical image siblings (identi_card_image1-5), so it doesn't fully separate it from the closest alternatives.

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 gives clear context that this tool is for file-based input ('텍스트 입력 없이 파일 하나만 전달하면 됩니다' — pass a single file, no text input) and adds a legal prerequisite (consent of the data subject must be secured). It implies file-vs-text selection but does not explicitly name alternatives, and gives zero guidance on selecting among the five identical image endpoints, which is the agent's real selection problem.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds meaningful behavioral context: the operation requires a legal basis (consent), and there is a per-call cost (60 points). It also clarifies the input is a single file with no text input. No contradiction with annotations; it goes beyond the structured data.

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 compact and front-loaded: it states the core purpose in the first clause, then provides the practical requirement (file only), the legal condition, and the cost. Every sentence adds value with no redundancy. Well structured for quick parsing.

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 one-parameter tool with no output schema and read-only annotations, the description covers the key usage aspects: what it does, the input format, the legal prerequisite, and the cost. It does not specify the return format (e.g., true/false vs. detailed report), but that is not strictly necessary given the lack of an output schema and the simplicity of the task.

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 coverage is 100%, so the single parameter (image_url) is fully documented in the schema. The description adds the fact that only a file is needed ('no text input'), but that is largely implied by having just one parameter. No extra syntax or format details beyond the schema are provided, so 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 ('verify'), a clear resource ('Korean driver license authenticity'), and the input type ('image or PDF file'). This clearly distinguishes it from sibling tools like identi_card1 (likely text-based) and other identity document verifiers. The purpose is immediately clear and unambiguous.

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 implies usage via file upload without text input, which helps when the agent has an image/PDF rather than textual data. However, it does not explicitly name alternatives or state when not to use this tool versus the many sibling tools. The legal-consent requirement is a usage context, but no comparison or exclusion is given.

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

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description's 'Verify' action aligns with that. The description adds a compliance note about legal basis and a cost note (60 points per call), which are useful beyond the annotations. However, it does not disclose the return format or failure behavior, so the extra context is useful but limited.

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, with five short sentences in two languages. It is front-loaded with the purpose, then covers the input type, simplicity, legal condition, and cost. Each sentence contributes a distinct piece of information, though the cost note could arguably live in annotations. No wasted words.

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?

With only one parameter, no output schema, and read-only annotations, the description covers the core purpose, input, and usage conditions. However, it never describes what the verification response looks like, and it fails to clarify why this specific tool (identi_card_image4) differs from identi_card_image1/2/3/5. This leaves an important gap for an agent navigating a large family of similar tools.

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?

The schema covers the single parameter image_url 100%, including allowed formats and size limits. The description only repeats that input is an image or PDF, adding no new semantic detail about the parameter. With full schema coverage, the baseline of 3 is appropriate; the description does not compensate further.

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 a specific verb and resource: 'Verify the authenticity of a Korean resident registration certificate' and specifies the input type (image/PDF). However, it does not differentiate among the many sibling image tools (identi_card_image1..5), so an agent cannot tell which image variant to invoke based on the description alone.

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 mentions a legal condition ('only use with consent or other legitimate basis') and says 'no text input, just one file', but it gives no explicit guidance on when to choose this tool over alternatives like identi_card1..5 or identi_card_image1..5. It neither names alternatives nor states exclusion criteria, leaving tool selection ambiguous among the image variants.

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

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

Annotations already mark it as read-only, so the safety profile is covered. The description adds useful behavior around card_sn being required for 2011-01-01 or later cards, the lawful-processing requirement, allowed file types, and the per-call point cost. Return-value shape is not disclosed, but the read-only annotation lowers that burden.

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 and front-loads the core purpose before adding usage constraints, legal conditions, and cost. The in-language repetition adds length but is excusable for a Korean-domain tool. No filler or unrelated detail is present.

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 two-parameter read-only verification tool, the description covers input format, source, size, legal basis, and cost. The main gap is not describing the result/output shape, but the tool's purpose and schema already convey what an agent needs for straightforward invocation. Sibling differentiation would be the largest remaining omission.

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?

The input schema already has 100% parameter coverage and describes both image_url and card_sn well. The description mainly restates schema information, with only slight added value by explicitly saying card_sn is optional in general while mandatory after 2011-01-01. This is useful but minimal, so a 3 baseline 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 clearly states a specific action: verifying the authenticity of a Korean alien registration card from an image or PDF. It names the resource and the modality, so an agent can understand what the tool does. However, it does not explicitly distinguish itself from the many sibling identi_card_image1-4 or identi_card1-5 variants.

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 usable context: image/PDF input, optional card_sn with a mandatory condition for post-2011 cards, and the requirement to have a lawful basis. However, it gives no 'when to use this versus another identi_card tool' guidance, so an agent still cannot easily select among siblings.

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

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

Annotations indicate readOnlyHint=true, meaning the tool is non-destructive. The description adds valuable behavioral context: it returns a masked image in base64 within the masked_image field, notes a cost of 30 points per call, and requires legal processing basis. This goes beyond what the annotations provide, though it could be even more explicit about the return format or potential errors.

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 somewhat lengthy due to bilingual repetition (English and Korean) but the core purpose is front-loaded. It includes necessary details like cost and legal requirements, though some redundancy exists. Overall, it stays focused and structured, with no wasted sentences.

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?

Given the single parameter and no output schema, the description provides sufficient information to call the tool: it states the input format, the output field (masked_image as base64), the cost, and the legal prerequisite. It does not enumerate the extracted 'key fields' but that is acceptable since the tool's main purpose is masking and the response format is described. The absence of an output schema makes the description's mention of the return field particularly useful.

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?

The schema covers 100% of the parameter (image_url) with details on URL, format, and size. The description reinforces that only one PNG or JPEG image is needed and that it should be passed directly, which adds clarity. Since schema coverage is high, the baseline is 3, but the description's reinforcement and clarification earn a 4.

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 identifies the tool as extracting fields from a Korean driver's license and masking the last 6 digits of the RRN. It specifies the exact document type (운전면허증), distinguishing it from sibling tools like identity_document_passport or identity_document_id_card. The verb 'extract' and 'mask' are specific and action-oriented.

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 condition: use only when legal basis (consent) is secured, which is a valid usage guideline. It also states the input requirement (single PNG/JPEG image) but does not explicitly mention when to use this tool over alternatives (e.g., for other ID types). The context of Korean driver's license is implicit, but the exclusion of non-driver-license images is not stated.

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

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

Annotations already declare readOnlyHint=true, and the description aligns by describing extraction and masking without side effects. It adds valuable contextual details beyond annotations: output is a base64 image in masked_image field, input must be PNG/JPEG, a cost per call (30 points), and a legal compliance warning. This enriches the agent's understanding without contradiction.

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 efficiently structured, front-loaded with the core action and then giving input/output format and legal/cost notes. It is bilingual, which adds length but serves multilingual agents, and no sentence is superfluous. Minor redundancy between English and Korean prevents a 5.

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 one simple parameter and no output schema, the description covers the return format (base64 in masked_image), input constraints, legal usage, and cost. It does not cover error cases or multiple-image handling, but those are not essential for basic operation. Adequate for the tool's complexity.

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 coverage is 100%, so the parameter is fully documented in the schema (https URL, image/jpeg and image/png, max 50MB). The description redundantly mentions PNG/JPEG and 'one image' but does not add new semantic meaning 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') and resource ('Korean resident registration card') plus the masking action, and clarifies it returns both extracted fields and a masked image. The name and content clearly distinguish it from sibling tools for driver licenses, passports, and residence cards, so an agent can select it without ambiguity.

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 gives clear context: it is for ID cards, accepts one PNG/JPEG image, and requires lawful processing basis. It does not explicitly mention when not to use it or name alternatives, but the sibling names and descriptive resource make the applicable scenario evident. No exclusions are stated, which slightly lowers the score from 5.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: it returns a masked image in a base64 'masked_image' field, notes the point cost, and emphasizes legal compliance. No contradiction with annotations; the description enriches the operational understanding.

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 compact yet informative, using both English and Korean. It front-loads the core purpose, then covers input requirements, output format, legal notice, and cost. Every sentence contributes value without redundancy.

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?

Given a single parameter with complete schema coverage and no output schema, the description explains the input format, the specific output field (masked_image base64), and the legal/constraint context. It could mention which key fields are extracted, but this is not critical for invoking 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 covers 100% of the parameter (image_url with format and size limits). The description adds meaningful extra guidance: the image must be captured so that both MRZ lines are included, which is not in the schema. This helps the agent select an appropriate image URL.

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?

States a specific verb-resource pair ('Extract key fields from a passport image and mask the passport number and MRZ area') that precisely distinguishes this tool from siblings like driver's license or ID card tools. The bilingual description reinforces the passport-specific scope.

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?

Gives clear usage context: operates on the passport information page image, requires MRZ 2 lines to be included, and specifies PNG/JPEG format. It also states a legal precondition (consent basis). While it doesn't explicitly name alternative tools, the passport-specific wording makes the appropriate scenario obvious.

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

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

Annotations include readOnlyHint=true, which is consistent with the description's processing of an input image without external state changes. The description adds meaningful context beyond annotations: the output format (masked_image field with base64), a cost note (30 points per call), and a legal usage requirement. It could have mentioned any rate limits or auth needs, but these are not obviously relevant. The added context is valuable and not redundant.

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 bilingual (English and Korean) and includes legal and cost notes, making it slightly longer than necessary. However, it front-loads the main purpose and then provides operational details in a logical order. There is no fluff, and each sentence carries meaning, though the bilingual repetition could be seen as slightly redundant.

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?

With only one parameter and no output schema, the description covers key operational aspects: what the tool does, input format, output field (masked_image) and encoding (base64), plus usage constraints. It does not enumerate the 'key fields' that are extracted, which could be important for agents to decide if the response meets their needs. Still, the description is reasonably complete for a single-parameter tool.

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?

The schema already describes the only parameter (image_url) with 100% coverage, including allowed formats and size limit. The description restates the format ('PNG 또는 JPEG') but does not add new semantic meaning beyond what the schema provides. According to the calibration, a baseline of 3 is appropriate when schema coverage is high and the description adds minimal extra parameter detail.

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 verb 'extract' and the resource 'Korean alien registration card (residence card)', and specifies the action of masking the last 6 digits of the registration number. This distinguishes it from sibling tools like identity_document_id_card or identity_document_passport, which handle different document types. The purpose is unambiguous and specific.

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 indicates that a single PNG or JPEG image should be passed, and includes a legal prerequisite ('only use if you have a legitimate processing basis such as consent'). It does not explicitly name alternatives or state when NOT to use this tool, but the document type (alien registration card) and masking operation clearly differentiate it from siblings. The context is sufficient for an agent to decide when to invoke it.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context beyond that: the requirement for a legal processing basis, the mandatory presence of all three fields, and a per-call cost of 50 points. It does not describe failure/error behavior, but for a simple read-only verification this is acceptable.

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 short and front-loaded with the core purpose in English, followed by Korean equivalent and a few usage notes. The bilingual repetition makes it slightly longer than necessary, but every sentence conveys useful information (inputs, legal basis, cost) without excessive verbosity.

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 read-only verification tool with strong annotations and full schema coverage, the description is complete: it specifies the purpose, all required inputs, the legal precondition, and the cost. The Korean phrase '일치 여부' explicitly implies a boolean match result, setting adequate expectations even without an output schema.

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?

The input schema already describes all three parameters (name, rrn1, rrn2) with Korean explanations, and description coverage is 100%. The tool description only re-states the parameter names and their positional meaning, adding no new semantic detail beyond the schema, so the baseline score of 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?

Clearly states the tool verifies whether a Korean name and RRN belong to a real registered person, using the specific verb 'Verify' and naming the resource ('name and resident registration number'). The bilingual description reinforces the purpose and distinguishes it from sibling document-image verification tools by focusing on raw name/RRN data.

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?

Provides a clear usage context: it requires all three inputs and mandates a legal basis (consent) before calling, which is important for privacy-sensitive identity verification. It does not explicitly name alternative sibling tools, but the unique required parameters and the explicit legal condition make the intended use case well understood.

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