APICK Identity

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

The description discloses the point cost per call ([호출당 20포인트]) and the legal/consent requirement, which are not in annotations. It also implies OCR-based recognition ('인식해'). It doesn't mention failure modes, but readOnlyHint=true already indicates no side effects.

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, with English and Korean duplicating the same message, making it longer than necessary. It is reasonably structured with distinct clauses for action, inputs, legal basis, and cost, but the redundancy reduces conciseness.

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 tool with two parameters and no output schema, the description covers the core behavior, input requirements, legal constraint, and cost. It does not specify the return format (e.g., URL vs binary), but the phrase 'return the masked image' is sufficient for an agent to know what to expect.

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 provides full descriptions for both parameters (100% coverage). The description repeats the type mapping and required inputs but adds no new parameter-specific meaning beyond what the schema offers.

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 tool's function: masking resident registration numbers in images and returning the masked image. The verb 'mask' is specific and the resource (RRNs in images) is unambiguous, distinguishing it from sibling tools that handle identity documents for other purposes.

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 explains that both image file and type must be provided, and adds a legal condition for use ('information subject's consent or other legitimate basis'). While it doesn't explicitly discuss alternatives, no sibling tool offers similar masking functionality, so the context is clear.

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?

While annotations already declare readOnlyHint and openWorldHint, the description adds valuable behavioral context: it costs 60 points per call ('[호출당 60포인트]'), requires legal basis for use, and processes a single file without text input. These details go beyond the structured annotations, though the return format is not described. No contradiction exists.

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 main purpose. It comprises a short English sentence followed by Korean explanations, including input expectations, legal note, and cost. No fluff, though the bilingual repetition is redundant. It earns a 4 rather than 5 due to slight 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?

Given the tool's simplicity (one parameter, read-only, no output schema), the description covers purpose, input type, legal usage, and cost. It does not explicitly state the return value, but '진위 여부를 확인합니다' strongly implies a verification result. This is adequate for an agent to select and invoke the tool correctly, though a bit more detail on the response would push it to 5.

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% coverage: 'image_url' has a detailed description specifying HTTPS, formats (jpeg/png/pdf), and size limit (25MB). The parameter description adds no further meaning beyond what the schema already provides, so the baseline of 3 is appropriate per the rubric.

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 tool's function: 'Verify the authenticity of a Korean resident registration card from an image or PDF file.' The verb 'verify' plus the specific resource and input format make the purpose unambiguous. It distinguishes from siblings by emphasizing image/PDF input and noting '텍스트 입력 없이 파일 하나만 전달하면 됩니다,' which sets it apart from text-based alternatives like identi_card1.

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 clear context for when to use this tool: upload an image or PDF file for authenticity verification, with no text input. It also includes a legal prerequisite: '정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오.' However, it does not explicitly mention alternative tools or exclusion scenarios, such as 'use identi_card1 for text-based input,' so it stops short of a full 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, so no safety cautions needed. The description adds valuable behavioral context: automatic recognition of information, no text input needed, legal basis requirement, and per-call cost of 60 points. It also clarifies file format and size limits via schema. 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.

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

The description is compact and front-loaded with the core action in English, followed by a Korean summary, a usage note, and a cost indicator. Every sentence serves a purpose; no filler. The bilingual format is slightly redundant but acceptable for the target audience.

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 strong annotations, the description covers the essential selection and invocation information: what it does, input type, legal condition, and cost. It does not specify the output format, but as a verification tool the return value is implicit. The absence of an output schema makes a brief output note desirable, but overall completeness is high.

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 a detailed description of image_url (format, size, HTTPS). The description merely restates that an image/PDF file is needed, adding no new syntax or format details. Baseline 3 is appropriate since the schema fully documents the parameter.

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 verifiable action: 'Verify the authenticity of a Korean driver license from an image or PDF file.' It names the exact resource (Korean driver license) and input type (image/PDF), distinguishing it from sibling tools that likely handle other document types or 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 clear usage context: upload a single file without text input, and requires legal processing basis (consent). It does not explicitly name alternative tools or exclusion conditions, but for a one-parameter tool this is acceptable guidance. The note about consent is an important prerequisite.

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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds that it uses automatic recognition, requires legal basis, and costs 60 points per call. It also discloses the file upload behavior. It does not detail processing steps or failure modes, but the added legal and cost context is valuable.

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 front-loaded with the main purpose in English, followed by redundant Korean repetition. It includes legal and cost notices, which are useful, but the bilingual repetition adds a few extra words. Overall it is still compact and structured, not verbose.

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 no output schema, the description should clarify what the tool returns. It says '확인합니다' (verifies), implying a result, but does not specify whether it returns a boolean, detailed report, or something else. For a verification tool, the output format is important. The input and legal context are covered, but the missing output expectation lowers the score.

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 fully describes image_url (https URL, allowed MIME types, 25MB limit). The description restates that it accepts an image or PDF and says 'no text input,' which is redundant. No new semantic detail is added beyond the schema, so the 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 clearly states 'Verify the authenticity of a Korean passport from an image or PDF file' and notes the input type. This is a specific verb (verify) and resource (Korean passport), distinguishing it from sibling identity tools like driver's license or ID card verification.

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 clear usage context: upload a passport image/PDF, no text input, single file. It also gives an explicit when-not-to-use condition: only when legitimate legal basis (e.g., consent) is secured. However, it does not name alternative tools or explicitly exclude other document types, so it stops short of a 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 indicate read-only and open-world hints. The description adds useful behavioral details: it recognizes the document confirmation number, requires only one file, imposes a legal consent prerequisite, and notes a cost of 60 points per call. It does not disclose the response format or error behavior, but the annotations lower the 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 concise but contains a mild redundancy: the first sentence in English and the second in Korean convey nearly the same core idea. Still, each sentence contributes: purpose, method, input requirements, legal caveat, and cost. It is structured and front-loaded.

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 tool is simple with one parameter and good annotations, but the description does not specify what the verification response looks like (e.g., a boolean or detailed result). Given many sibling tools, it adequately identifies the document type and input source, but the lack of output behavior leaves some ambiguity for an agent.

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 fully documents the single parameter (image_url) with format and size constraints. The description adds only that no text input is needed and a single file suffices, which is mild extra context. With 100% schema coverage, a baseline 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 opens with a specific action and resource: 'Verify the authenticity of a Korean resident registration certificate from an image or PDF file.' It also mentions automatic recognition of document confirmation numbers, distinguishing it from sibling tools that may handle other document types or text inputs.

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 indicates the tool is for image/PDF inputs and explicitly notes 'without text input,' implying text-based alternatives exist. It also provides a legal usage condition (consent basis). It does not explicitly name sibling tools or say 'use this instead of X,' so it misses full alternative differentiation.

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 this as read-only, and the description adds useful operational details: card_sn's conditional requirement, the need for a legitimate processing basis, and the 60-point cost per call. It does not contradict the annotations, and no further behavioral details are critical.

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 the core purpose in the first clause and only necessary additional details (eligibility, legal condition, cost). Every sentence adds value, and the bilingual repetition is acceptable.

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 verification tool, the description covers the input requirements, a critical condition (card_sn), a legal prerequisite, and cost. The lack of an output schema is partially mitigated by the phrase '진위 여부를 확인합니다', though a more explicit statement of the return format would make it fully 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?

Schema coverage is 100% for both parameters, and the description supplements this by clarifying that card_sn is optional but mandatory for cards issued after 2011-01-01. This adds meaningful semantics beyond the schema, though image_url is not elaborated 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 the tool verifies the authenticity of a Korean alien registration card from an image or PDF, using 'Verify' as the verb and specifying the card type. However, it does not differentiate this tool from sibling tools like identi_card_image1-4 or identi_card5, so it falls 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.

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

The description provides clear usage context: upload an image/PDF of the card, with card_sn required for cards issued after 2011-01-01. It also warns to use only with legal grounds, but it does not 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?

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable context by detailing exactly what gets masked (last 6 digits of RRN), the response format (base64 masked_image), and the legal requirement, going beyond the annotation 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 front-loaded with the main purpose and includes necessary operational details in a few sentences. It is somewhat verbose with bilingual repetition, but every sentence contributes meaning, so it earns a 4.

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 parameter and no output schema, the description covers input requirements, the key output field (masked_image as base64), and usage prerequisites. It does not list all extracted key fields, but the phrase 'key fields' is acceptable for this 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?

The input schema fully describes the single image_url parameter (100% coverage), but the description adds that only one PNG/JPEG file is needed and mentions the 20MB limit, complementing schema semantics.

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 tool extracts key fields from a Korean driver license image and masks the last 6 digits of the RRN. This specific verb-resource-action pair distinguishes it from sibling tools for ID cards, passports, and residence cards.

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 that a single PNG or JPEG image is sufficient and emphasizes using the tool only with proper legal grounds such as consent. While it does not explicitly name alternative tools, the Korean driver license focus implies when to use it over 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 does not contradict this; instead, it adds behavioral details: the tool returns a masked image as base64 in the masked_image field, expects exactly one PNG/JPEG, and requires authorization. This goes beyond the annotation by clarifying the response format and input constraints.

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 front-loaded with the core purpose, then adds necessary details about input, output, legal basis, and cost. The bilingual phrasing is somewhat redundant, but each sentence contains useful operational information and there is minimal filler.

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 no output schema, the description partially compensates by mentioning the masked_image field but does not specify what 'key fields' are extracted or how errors are handled. While the input parameter is fully described, the absence of a field list for the extracted data is a notable gap for an agent deciding whether this tool meets a need.

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%, with the image_url property described as a downloadable HTTPS URL with allowed MIME types and size limit. The description repeats the PNG/JPEG and single-file requirement but adds no new parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.

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 tool's function: 'Extract key fields from a Korean resident registration card image and mask the last 6 digits of the RRN.' This is a specific verb-resource-outcome statement that distinguishes it from sibling tools for driver licenses, passports, and residence cards by explicitly naming the document type (주민등록증).

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 clear context by specifying that the tool is for Korean resident registration card images and mentions a legal precondition ('Use only when you have secured legal processing grounds'). However, it does not explicitly discuss alternatives or when not to use this tool, though the sibling names suggest document-type-specific tools.

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 the description adds useful behavioral context: the tool returns a masked image as base64 in the masked_image field, requires a legitimate processing basis, and costs 20 points. It also discloses input format constraints (PNG/JPEG, MRZ included). These details go beyond the annotation.

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 but repeats information in English and Korean. It is front-loaded with the main action and provides additional details (output field, legal basis, cost) in an organized manner. Some redundancy exists but not enough to impede understanding.

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?

No output schema, so the description must explain return values. It does: masked_image field as base64. It also covers input requirements, legal use conditions, and point cost. Given the tool's complexity, this is a complete description.

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 baseline is 3. The description adds meaningful semantics for the single parameter (image_url) by specifying that the image should contain the 2 MRZ lines and that only one image should be provided. This enriches the schema's bare URL description.

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 tool extracts key fields from a passport image and masks the passport number and MRZ area. The verb+resource is specific ('extract... mask... passport') and distinguishes it from sibling tools for 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?

The description provides clear context: should be used with a passport image, specifically one PNG/JPEG image including the MRZ lines. It also gives a critical usage condition (must have legitimate basis such as consent). It doesn't explicitly name alternatives but the sibling names and passport specificity imply when 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?

Annotations provide readOnlyHint=true, and the description adds meaningful behavioral context beyond that: masking the last 6 digits, returning the masked image as base64 in the masked_image field, and requiring legal consent for processing. This is substantial additional disclosure with no 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 well-structured with an English statement followed by Korean translation and operational details. The bilingual repetition adds length but is appropriate for the target context. It is reasonably concise, though the point-cost note and legal reminder could be considered extra.

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 strong annotations, the description covers input format, output format (masked_image field), and legal usage. However, it does not enumerate the specific 'key fields' being extracted, which is a notable gap given there is no output schema to fill in that detail.

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 description covers 100% of the single parameter (image_url), so this is a baseline 3. The description repeats the PNG/JPEG and single-image constraints but does not add new parameter semantics beyond what the schema already 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 uses a specific verb and resource: 'Extract key fields from a Korean alien registration card (residence card) image and mask the last 6 digits of the registration number.' This clearly distinguishes the tool from siblings such as identity_document_passport and identity_document_driver_license.

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 identifies the target document type (Korean alien registration card) and states a legal prerequisite: only use with proper consent or legal basis. However, it does not explicitly mention when not to use the tool or name alternative tools, so usage guidance is clear but not fully exclusionary.

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. The description adds practical context: all three fields must be entered, legal authorization is required, and there is a per-call cost of 40 points. It does not describe return format or mismatch behavior, but annotations cover safety.

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 purpose. It includes a redundant Korean translation of the English sentence, but the cost note in brackets is useful and compact.

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 verification tool, it covers purpose, required inputs, legal condition, and cost. However, with no output schema, it does not describe the return value (e.g., boolean, object) or error handling, which is a notable gap for a tool likely used in decision-making.

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 each parameter already described (한글 성명, 앞 6자리, 뒤 7자리). The description repeats these requirements and adds '모두 입력해야 합니다,' which is already captured by the required array. No new parameter semantics beyond 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 opens with 'Verify that a Korean name and resident registration number (RRN) match a real registered person,' a specific verb and resource. It clearly distinguishes from sibling tools by focusing on name/RRN existence rather than identity document images or masking.

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 provides a clear usage condition: '정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오' (use only with legal basis), which is a when-not guideline. However, it does not mention alternatives or explicitly compare with document-based verification tools.

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