APICK Identity

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

Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds meaningful behavioral context: it recognizes RRNs, applies one of four masking modes, returns the masked image, and discloses a 20-point cost per call plus a legal-use requirement. 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 main action is front-loaded and the description is reasonably compact. The bilingual repetition is slightly redundant, but the required-input note, type enumeration, legal caveat, and cost disclosure are all meaningful and add value without excessive clutter.

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 tool with no output schema, the description covers the essential operational details: what it does, required inputs, masking modes, legal conditions, and cost. It does not specify the output representation beyond "masked image," but that is likely sufficient for 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 already provides 100% parameter coverage, including descriptions for both type and image_url. The description repeats the type mapping and emphasizes that both inputs are required, adding little semantic value beyond what the schema already states.

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 begins with a specific verb and resource: "Mask resident registration numbers found in an image and return the masked image." This clearly distinguishes the tool from sibling image tools like face_blur, draw_watermark_image, and general image_edit.

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 the required inputs (image file and type) and adds an important condition: use only when there is a lawful basis such as consent. It does not explicitly compare against alternatives like face_blur, but the RRN-specific scope provides clear context for when this tool is appropriate.

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 open-world, so the bar is lower. The description adds meaningful behavioral context beyond annotations: it requires all four fields, restricts the date format, mandates a lawful basis for use, and discloses the per-call cost of 40 points. This gives the agent a genuine sense of the operational constraints and authorization requirements.

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, front-loaded with the core purpose, and every sentence adds useful information: input mode, required fields, date constraint, legal condition, and cost. It is slightly bilingual/repetitive but still efficient for the range of details it conveys.

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 has no output schema, so a description of expected return values would be valuable. The description covers inputs, legal prerequisites, and cost, but never explains how the verification result is returned (e.g., simple pass/fail, reason codes, possible error conditions). This is a notable gap even though annotations and input documentation are solid.

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 schema already documents all parameters and their formats. The description reinforces that all four items are required and gives a date example, but it does not add significant new meaning beyond what the schema already provides. This aligns with the baseline 3 for full schema coverage.

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') and a specific resource ('authenticity of a Korean resident registration card'), and the title's '[Text]' tag clearly distinguishes it from image-based sibling tools like identi_card_image1. The bilingual text backs this up with 'using text input'. An agent can confidently understand what this tool does at a glance.

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: use when you have text-based card fields, all four items must be provided, and date must be numeric. It also adds a legal prerequisite ('only use when legitimate processing grounds such as consent are secured'). It does not explicitly name alternatives for image or OCR cases, but the '[Text]' distinction combined with the strong input conditions provides adequate routing guidance.

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 goes beyond them by disclosing the per-call cost, the legal-basis requirement, and importantly the scope limits (it does not verify the serial number itself or the physical license's tampering). Those negative-capability and cost statements are exactly the kind of context annotations cannot carry. It still omits how the result is returned or any throttling behavior.

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 purpose is front-loaded, but the content is delivered twice, once in English and once in Korean, with the ghost_num caveat repeated almost verbatim. That bilingual duplication costs space without adding information, though each individual sentence is otherwise clean.

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 an 11-parameter, 8-required verification tool with no output schema, the description covers required vs optional inputs, the ignored field, the cost, the legal precondition, and the limits of what is verified. The one real gap is the absence of any statement about the response shape (pass/fail, matched fields), since no output schema exists to cover 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 every parameter is already documented, and the description largely restates it: required birth_y/m/d, name, licen_no0-3, and optional ghost_num/rrn1/rrn2. It adds slight value by stressing that ghost_num accepts arbitrary strings and is ignored in the decision, but that is also in the schema. Baseline 3 applies when 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?

States a specific verb+resource: checking a Korean driver's license number and personal details, and explicitly disclaims what it does not do (serial-number validation, physical forgery detection). That said, it never distinguishes itself from the sibling identity_document_driver_license or from identi_card1/3/4/5, so an agent cannot tell which of the near-identical tools to pick from the text 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?

Provides a real precondition (only use with a lawful basis such as the data subject's consent) and a cost signal (40 points per call), which implies when it is appropriate to invoke. However, it gives no explicit routing guidance versus the driver-license-adjacent siblings, so the agent must infer the choice from tool names.

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 and openWorldHint, and the description is consistent with them. It adds useful context about the legal basis requirement and per-call cost, but it does not describe the verification result structure or any edge-case behavior.

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 a clear purpose sentence, but the Korean sentence largely repeats the English opening. The legal notice and cost information are useful, though the cost note is tangential to tool invocation.

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?

Input requirements are well covered: all fields, formats, and legal preconditions are stated. However, there is no output schema and no description of what the verification result looks like, which is a meaningful gap because an agent needs to interpret the outcome to decide its next action.

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 schema already documents each parameter with a short label. The description adds value by reinforcing that all five parameters are mandatory and clarifying the numeric date format with an example, which is not fully explicit 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 the verb 'Verify' and the specific resource 'Korean passport', and it distinguishes the method with 'using text input'. This sets it apart from image-based sibling tools, though it doesn't name an alternative explicitly.

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 explicitly lists all five required fields, states the date format requirement ('숫자만, 예: 20230101'), and gives a legal precondition ('적법한 처리 근거를 확보한 경우에만'). It gives clear usage conditions but does not explicitly discuss alternatives or 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 and openWorldHint=true, so this is a non-destructive lookup. The description adds meaningful behavioral context: it is a text-based verification requiring a 16-digit document confirmation number split into four 4-digit parts, a issuance type, and an explicit legal-consent warning. It also discloses the per-call cost ([호출당 40포인트]), which is useful operational transparency.

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 main purpose in the first sentence, followed by key input rules, legal notice, and pricing. The Korean and English lines partially duplicate each other, but the repetition reinforces the core message without excessive bloat.

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 no output schema, the description provides what an agent needs: required fields, optional fields, format constraints (4-digit segments), issuance type meaning, a legal-use warning, and cost. The only minor omission is the exact response shape, but read-only verification tools without output schemas are often judged by success/failure status and this is acceptable.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds the composite meaning that doc_num1~doc_num4 together form the 16-digit document confirmation number, and clarifies that type refers to issuance channel (정부24 vs 기타). This is helpful but not extensive; baseline 3 is appropriate given full schema coverage.

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 the authenticity') and the resource ('Korean resident registration certificate' / 주민등록등본), and the title also specifies the document type. This distinguishes it from sibling tools like identi_card1-5 or identity_document_* by focusing on text-based verification of the 주민등록등본.

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 required inputs (doc_num1~4, type) and notes name is optional, plus a legal-consent condition for use. It doesn't explicitly contrast with sibling alternatives (e.g., identi_card_image1 for image-based verification), but the text-input scope and the legal proviso give reasonable usage context.

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 contradiction exists. The description adds meaningful behavioral context: it is a verification operation, requires legitimate processing grounds, and consumes 40 points per call. These details go beyond what annotations and schema provide, even though output format and error behavior are 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 compact and front-loaded with the tool's purpose, followed by parameter guidance, legal conditions, and cost. It contains some redundancy with the schema, but each sentence carries practical information for invocation and compliance. It is appropriately sized for the tool's complexity.

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 verification tool with no output schema, the description sufficiently covers input requirements, conditional fields, legal prerequisites, and cost. It does not describe the exact result format, but the purpose is straightforward enough that an agent can reasonably infer a boolean or verification result. The main gap is not explaining differences among identi_card1-5 siblings explicitly.

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 each parameter already described in terms of format and length. The description repeats these constraints rather than adding new semantic meaning beyond the schema. It does usefully summarize requiredness and the card_sn condition, but does not materially expand parameter understanding.

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 specific resource ('Korean alien registration card'), and a specific input mode ('using text input'), which distinguishes it from image-based siblings like identi_card_image1-5 and OCR variants. The title's [Text] marker reinforces the text-based 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?

The description clearly specifies required fields, format constraints, and the conditional requirement for card_sn on cards issued after 2011-01-01. It also provides a legal-usage condition (consent or lawful basis). It does not explicitly name alternative tools or when-not-to-use, but the context is clear enough for an agent to decide when this tool fits.

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 annotations already declare readOnlyHint=true and openWorldHint=true, which cover the safety profile. The description adds useful behavioral context: the card data is automatically recognized, the operation requires a lawful processing basis, and each call consumes 60 points. It does not disclose whether the file is stored or what happens on failure, but this is acceptable given the read-only 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 compact and front-loaded with the main action, then adds the input requirement, legal condition, and cost in short sentences. The bilingual phrasing repeats some content, but the Korean sentence adds the detail that the card's written information is automatically recognized, so the redundancy is mild and purposeful.

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 one-parameter tool, the description covers what input to provide and when use is lawful. With no output schema present, it would benefit from stating the response format (e.g., whether it returns true/false or a result object). The absence of a sibling differentiation also leaves a small contextual gap, but the core call is understandable.

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 image_url as a downloadable https URL with allowed formats (jpeg/png/pdf) and a 50MB limit, so the baseline is 3. The description reinforces 'image or PDF' and 'one file' but adds no new technical details about the URL parameter 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 opens with a specific verb and object: 'Verify the authenticity of a Korean resident registration card from an image or PDF file.' It clearly scopes the tool to image/PDF input and explicitly says no text input is needed. However, it does not differentiate itself from the nearly identical sibling names identi_card_image2 through identi_card_image5.

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 a clear precondition for use ('정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오') and states that only a single file is required. It does not, however, mention when to prefer this tool over alternatives such as identi_card1 or the OCR variants, leaving the choice to inference.

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 adds valuable behavioral context: it auto-recognizes the printed information, performs authenticity verification, requires a lawful processing basis, and notes the per-call point cost. It does not describe the output format, but for a read-only verification tool this is a minor gap.

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, front-loaded with the core purpose, and every sentence adds useful information: what it does, input expectations, legal constraints, and cost. There is no redundant 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?

For a one-parameter read-only tool, the description covers the essential context: input type, operation, legal prerequisite, and cost. It does not explicitly state the return value shape, but '진위 여부를 확인합니다' implies a pass/fail or verification result, which is adequate for this simplicity level.

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 baseline is 3. The description adds that only one file is needed and that no text input is required, but it uses 'upload' rather than echoing the URL-based parameter. Most parameter meaning is already fully covered by 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 a specific verb and resource: verifying the authenticity of a Korean driver license from an image or PDF. It is distinct from general OCR and other document types, but it does not explicitly differentiate itself from similarly named sibling tools such as identi_card_image1 or 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 gives useful context: use it when you have a driver license image or PDF and no text input is needed, and only when you have a lawful basis. However, it does not mention alternatives or explain when not to use this tool, especially given the large number of similar identity-verification 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 provide readOnlyHint=true and openWorldHint=true. The description adds that the tool auto-recognizes passport information and verifies authenticity, and it discloses the legal-consent requirement and per-call point cost. It does not explain the output/return behavior, failure cases, or what exactly 'verified' means, so it provides only moderate behavioral context 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 front-loaded with the core purpose and includes useful legal and cost information. However, the English and Korean sentences duplicate the same core message, creating redundancy. It is not overly long, but the duplication prevents a higher score.

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 single-parameter tool, the description covers the essential input requirement, legal authorization, and cost. However, with no output schema present, it does not describe what the agent should expect in response, how to interpret the verification result, or why this tool differs from the many sibling identity/OCR 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?

Schema description coverage is 100% and the schema already fully describes the single parameter: a downloadable HTTPS URL with allowed types (image/jpeg, image/png, application/pdf) and a 50MB limit. The description adds 'one file, no text input,' but this does not materially extend the schema's 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 clearly states a specific action and resource: 'Verify the authenticity of a Korean passport from an image or PDF file.' The title reinforces the scope with '[Image/PDF] 여권 진위 확인'. However, it does not explicitly distinguish this tool from sibling variants like identi_card_image1/2/4/5 or identity_document_passport, so it stops short of full sibling 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 gives clear usage conditions: supply one file without text input ('텍스트 입력 없이 파일 하나만 전달하면 됩니다') and only use when a legal basis such as consent exists. This is helpful context, but it does not explicitly state when to prefer this tool over alternatives or 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 mark the tool as read-only and open-world. The description adds useful behavioral context: automatic recognition of the document confirmation number, cost of 60 points per call, and a legal/consent prerequisite. There is no contradiction with 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 the core purpose. The bilingual redundancy is acceptable for a Korean-focused tool, and the additional operational details (file-only input, consent requirement, cost) each add practical value.

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 no output schema and read-only annotations, the description covers the input, expected behavior, legal condition, and cost. It does not describe the exact response format, but '진위 여부를 확인합니다' sufficiently signals the result is an authenticity verdict. Explicit sibling differentiation is the main missing piece.

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 documents image_url with 100% coverage, including HTTPS requirement, accepted MIME types, and max size. The description adds that only a file is needed and that images/PDFs are acceptable, but it does not add meaningful parameter semantics 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 uses a specific verb and resource: 'Verify the authenticity of a Korean resident registration certificate from an image or PDF file.' This clearly distinguishes it from OCR tools and other identity document tools, even though the image4 suffix carries no semantic meaning by itself.

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 gives clear usage context: upload only a file, no text input required, and use only when a lawful basis such as consent exists. It does not explicitly name sibling alternatives or state when not to use this tool over identi_card_image1/2/3/5 or ocr_identi variants, but the input conditions are 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 supply readOnlyHint and openWorldHint, and the description adds useful behavior: automatic recognition of printed information, conditional requirement for card_sn, a legal-consent prerequisite, and a per-call point cost. There is no contradiction with 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 first English and Korean sentences both state the same verify-from-image/PDF purpose, creating redundancy. The legal-use warning and cost note are valuable, but the duplicated purpose could be trimmed.

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 covers input requirements, the conditional card_sn, and legal prerequisites, which is enough to attempt a call. However, there is no output schema and the description does not explain the result format or failure behavior of the verification 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?

Schema description coverage is 100%, so the schema already documents image_url and card_sn. The description repeats the card_sn condition but adds no parameter meaning 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 states a specific action (verify authenticity) on a specific resource (Korean alien registration card) from image/PDF, so an agent can identify the core purpose. However, the sibling tools identi_card_image1-4 appear nearly identical, and the description offers no explicit differentiation among them.

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 clearly communicates context: ARC authenticity verification, image/PDF input, card_sn requirement for post-2011 cards, and lawful basis. It does not state when to prefer this tool over the many sibling identity and OCR tools, or what cases should use an alternative.

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=false, and the description adds useful operational context: the accepted MIME types (image/jpeg, image/png), the maximum size (50MB), the base64 response format, the cost, and a legal-use warning. It could further disclose error behaviors (e.g., invalid image handling), but the description clearly exceeds the annotations' minimal signal.

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 key purpose, then the operational details, legal note, and cost. Every sentence contributes: input type, output location, legal condition, and pricing. No 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?

For a one-parameter tool with a 100%-covered schema and read-only annotation, the description conveys the purpose, input constraints, output location, legal usage condition, and cost. It lacks explicit notes on failure/error cases or what '지정 정보' (specified fields) means exactly, but the core call flow is sufficiently documented.

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 value by clarifying that only one image file is needed, that the URL must be downloadable via HTTPS, the allowed formats, and the size limit. It does not repeat the schema's property name but confirms the expected usage flow.

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 key fields from a Korean driver license image') and a concrete resource (Korean driver license), plus the distinctive masking behavior. It is clearly distinguishable from sibling tools like identity_document_id_card / passport / residence_card because it names the document type and its masking target (RRN last 6 digits).

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 explicitly states the input requirement ('PNG 또는 JPEG 이미지 파일 하나만 전달'), the output location ('masked_image 필드에 base64로 포함'), the legal precondition ('정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용'), and the cost ('호출당 30포인트'). It distinguishes this tool from generic OCR or other identity document tools by the masking behavior and document type.

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 annotation, the description explains the output format (masked_image field with base64), input limits (PNG/JPEG, single file), legal processing requirements, and per-call cost. There is no contradiction with 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: purpose first, then input requirements, output behavior, and legal caveat. The bilingual repetition is mild but does not hurt clarity.

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 covers invocation well, but there is no output schema and the description does not enumerate which key fields are extracted or how they appear in the JSON response beyond masked_image. For a document-extraction tool, that is a meaningful gap, though enough information is present for basic use.

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 image_url with allowed MIME types and the 50MB size limit. The description restates PNG/JPEG and single-file requirements but adds no genuinely new parameter semantics, so the schema-coverage 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 uses a specific verb ('Extract') and a clear resource: Korean resident registration card images. It also states the exact masking behavior (last 6 digits of the RRN), which distinguishes it from sibling tools like identity_document_passport or 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?

It clearly communicates when to use the tool: when a user has a single PNG/JPEG image of a Korean resident registration card and needs key fields plus a masked RRN image. It also includes important legal-consent guidance and input format constraints, though it does not explicitly name alternative tools or when not to use this one.

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 annotation, the description discloses meaningful behavior: the masked image is returned in the masked_image field as base64, the input must include both MRZ lines, and a legal basis such as consent is required. It also notes the per-call point cost. There is no contradiction with 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 the core purpose. The bilingual Korean sentence partially restates the English opener, creating minor redundancy, but every major item (input, output, legal basis, cost) is included without padding.

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 no output schema, the description covers the input requirement, the output location (masked_image base64), and the legal prerequisite. It does not enumerate the 'key fields' that are extracted, which is a minor gap, but overall the agent has enough context to invoke 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?

The schema already covers image_url type, allowed MIME types, and size limit with 100% coverage. The description adds useful semantic guidance beyond the schema by specifying that exactly one image file should be passed and that it must include the two MRZ lines.

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 verb and resource: 'Extract key fields from a passport image and mask the passport number and MRZ area.' It is passport-specific and therefore distinguishable from sibling tools like identity_document_driver_license, identity_document_id_card, and identity_document_residence_card.

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 usage context: pass a single PNG/JPEG image that includes two MRZ lines, and use only when lawful processing grounds exist. It does not explicitly mention alternatives or exclusion cases, but the context is sufficient for an agent to know when this tool is applicable.

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 is consistent with that. It goes beyond annotations by specifying exactly what is masked, that the masked image is returned as base64 in the masked_image field, and the input constraints. 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 front-loaded with the core purpose and then packs in essential constraints: output field, single-document requirement, legal basis, and cost. The bilingual phrasing adds specificity rather than pure filler, and every clause carries information relevant to invoking the tool correctly.

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, the description is quite complete: it names accepted document types, input format, output field, and legal requirements. The main omission is that it does not enumerate which 'key fields' are extracted, which would be more relevant given there is no 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 schema already covers image_url format and size with 100% coverage, so the baseline is 3. The description adds content-level constraints: the image must contain exactly one ID document, and lawful processing grounds are required. This is useful but does not deeply expand the parameter 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 uses a specific verb ('Extract') and names the exact resource types: Korean residence card, permanent resident card, and overseas Korean resident card. It also specifies the masking behavior of the last 6 digits, which clearly differentiates it from sibling tools like identity_document_driver_license, identity_document_id_card, and identity_document_passport.

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 invocation context: only one ID per image, PNG/JPEG images, and a lawful processing basis such as consent. It does not explicitly name sibling alternatives or state when not to use this tool, but the accepted document types are precise enough to guide selection.

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 the tool as read-only and open-world, and the description adds meaningful context: the per-call 50-point cost and the requirement for a legal basis. It does not detail the exact return format, but the read-only annotation lowers the burden and the added constraints are useful.

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 purpose. The English and Korean sentences largely duplicate each other, which is slightly redundant, but each part still adds clarity for the intended audience and includes cost and legal-use information in few 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?

For a simple three-parameter read-only verification tool, the description covers the purpose, mandatory inputs, legal constraint, and cost. It does not specify the exact success/failure return shape, but this is partially mitigated by the read-only/open-world annotations and the straightforward nature of the operation.

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 name, rrn1, and rrn2. The description reinforces that all three are required and restates the rrn1/rrn2 digit meanings, but it adds 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 clearly states the tool verifies whether a Korean name and RRN match a real registered person, using a specific verb and resource. It is not explicitly differentiated from siblings like account_realname or hide_rrn, but the name/RRN scope is specific enough to avoid serious 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 a clear usage condition: use it only when a lawful basis such as the data subject's consent has been secured. It does not discuss alternatives or explicit exclusions relative to sibling tools, but the legal precondition is actionable and important.

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