APICK

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it is limited to Korean bank accounts, requires either bank_code or bank_name, and costs 60 points per call. It does not describe failure behavior, but for a read-only lookup with clear annotations this is acceptable.

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

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

The description is compact and front-loaded with the action and purpose, followed by the key input constraint and cost. The Korean sentence duplicates the English sentence, which is somewhat redundant, but the bilingual structure is purposeful for the target domain and does not add excessive 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 tool has 3 parameters, all fully documented in the schema, and read-only annotations. The description adds the remaining essential context: Korean bank scope, remittance-check use case, the bank_code/bank_name precondition, and point cost. No output schema exists, but the expected result is clear from the stated purpose. Error-case details are not critical for this read-only lookup.

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 baseline is 3. The description adds meaningful semantics beyond the schema by clarifying that bank_code or bank_name is required even though both are optional in the JSON schema. It also reinforces the account_num format requirement indirectly by mentioning the Korean bank account context.

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 action and resource: 'Look up the account holder name of a Korean bank account.' It also adds the practical context of verifying the account holder before remittance, which distinguishes it from nearby identity/name tools like name_rrn_auth.

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 an explicit use case: '송금 전 예금주 확인 등에 사용합니다' (used for verifying account holder before remittance). It also states a necessary precondition: 'bank_code 또는 bank_name 중 하나는 입력해야 합니다' (either bank_code or bank_name must be entered). It does not explicitly mention alternatives or when not to use the tool, so a small gap 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 already establish the read-only, open-world nature, so the description needs only add extra behavioral context. It adds that the tool is free and that it returns the complete bank list for use as an input reference. It doesn't describe response structure or update behavior, but these are minor for a zero-argument list tool.

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 purpose is front-loaded and clear, and the use case is useful. However, the same information is repeated in English and Korean, and '무료입니다. [무료]' duplicates the free notice, adding minor noise.

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 zero-parameter tool, the description is functionally complete: an agent knows what it returns, why it exists, and that it costs nothing. Without an output schema, a sample return shape would be a nice addition, but the stated purpose 'bank codes and names' adequately implies the output.

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 tool takes no parameters, so there are no parameter semantics for the description to illuminate. The baseline for zero-parameter tools is 4, and the description correctly focuses on the output data instead.

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 concrete verb and resource: 'List Korean bank codes and names,' and further clarifies it returns the full list ('전체 목록을 반환합니다'). This clearly distinguishes bank_code from the many sibling tools and states exactly what data is returned.

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 explicitly states the intended use case: finding the bank_code input value for transfer_1won and account_realname. It stops short of giving exclusions or comparing to alternatives, but no sibling provides a comparable bank-code lookup, so this is sufficient direction.

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 description discloses useful behavioral details beyond the annotations: it accepts strings with a 'data:image/type;base64,' prefix and mentions a per-call point cost. The readOnlyHint annotation is consistent with a decoding operation. It does not mention error behavior or output delivery, but the core behavior is transparent.

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-loads the core action, then adds the prefix allowance and cost note. The English and Korean sentences repeat the same meaning, which is slightly redundant, but the overall size is still appropriate and every distinct piece of information is useful.

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

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

For a simple one-parameter utility with annotations, the description provides enough context: what the tool does, input tolerances, and cost. It lacks explicit output format or failure behavior, but since the return is described as an image file, this is reasonably complete for the tool's complexity.

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

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

The schema already covers 100% of the single parameter's meaning, including the accepted data-prefix format. The description repeats essentially the same information without adding new semantic detail, 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 states a precise transformation: 'Decode a base64-encoded image string back into an image file.' The verb is specific, the resource is clear, and no sibling tool performs base64 decoding, so the purpose is unambiguous and well differentiated.

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 intended use is implied—decode a base64 image string when you need the original image file—but there is no explicit when-to-use or when-not-to-use guidance, nor any named alternatives. It is enough for a simple, unique utility but does not actively 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 it read-only and open-world, and the description is consistent with that (조회/lookup). It adds value by listing the returned data (representative, address, employee count, establishment date, industry, etc.) and noting the 50-point cost per call, which is useful because there is no output schema.

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 compact and front-loads the purpose and input constraint before listing return fields and cost. The bilingual repetition is somewhat redundant, but the field list and point cost justify each section.

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

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

For a simple one-parameter lookup with no output schema, the description provides enough to invoke correctly: input format, scope, and expected result fields. It lacks explicit routing guidance among siblings, but that affects selection more than 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 single parameter biz_no is already fully documented in the schema with 100% coverage: string, 10 digits, no hyphen, example. The description adds only the Korean-business scope and repeats '10-digit business registration number,' so it does not materially exceed 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 and resource: look up general status information of a Korean business using its 10-digit business registration number, and enumerates the fields returned. It is clear and distinct in function, but it does not explicitly differentiate itself from sibling venture_biz_info, so it misses the top score.

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?

No guidance is given on when to prefer this tool over alternatives such as venture_biz_info or other business/ID lookup tools, and no exclusions or prerequisites are mentioned. The qualifier 'general status information' hints at scope but does not tell an agent when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral context: it explains that the tool performs MX lookups and disposable-domain detection, and it discloses the per-call point cost. This goes beyond the schema and 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 compact, front-loaded with the action and purpose, and includes a cost note. The bilingual repetition is justified given the Korean title and likely user base, and no filler or unnecessary detail is present.

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

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

For a one-parameter tool with readOnlyHint and openWorldHint annotations, the description provides enough information to select and invoke it correctly. The only minor gap is that the return value format is not described, but this is mitigated by the clarity of the validation checks listed.

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 documents the single 'email' parameter with an example. The tool description adds general context about what is validated but does not add new parameter-level detail 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 names a specific verb ('Validate') and a precise resource (email), and enumerates the exact checks performed: syntax, MX availability, and free/disposable domain status. This clearly distinguishes it from sibling tools like check_phone_valid or check_spam_number.

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 makes the tool's context clear: use it when email deliverability/validity checks are needed. However, it does not explicitly mention when not to use it or name alternative tools, so the usage guidance is implied rather than explicit.

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 the description carries a lower burden. It adds useful context about the matching inputs and the per-call cost of 20 points, but it does not disclose response behavior such as what exact result is returned on match or mismatch. This is adequate but not rich.

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 English definition, followed by a Korean restatement and a cost note. The bilingual repetition is slightly redundant but purposeful for the target audience, and the cost information earns its place.

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 with four fully documented parameters and read-only annotations, the description is mostly complete. It covers the purpose, inputs, use case, and cost. The only notable gap is that no output format is described, though for a boolean-style check this is a minor omission.

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

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

Schema description coverage is 100%, and each parameter already has a clear description and example. The description adds no additional parameter semantics beyond what the schema provides, 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 clearly states a specific verb and resource: verify that a Korean Personal Customs Clearance Code matches the provided name, zip code, and phone number. It also gives a concrete use case (해외직구 주문 정보 검증), which distinguishes it from sibling tools like get_pccc or req_pccc that likely issue or retrieve codes rather than verify 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?

The description explicitly says it is used for verifying overseas direct-purchase order information, giving the agent a clear context for selecting it. It does not mention exclusions or explicitly name sibling alternatives, but the use case is concrete enough to guide invocation.

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 a read-only, open-world operation. The description adds meaningful behavior beyond that: HLR does a network-level lookup to check line activation, and using it increases the cost. This is useful context not present in the annotations. 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 reasonably short and front-loaded with the core action. English and Korean versions are both present, creating some redundancy, but the pricing note and optional HLR behavior add practical value. Minor duplication keeps it from a 5.

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

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

For a simple two-parameter, read-only tool with full schema coverage, the description covers purpose, optional behavior, and cost. It does not detail the return format, but the annotations and schema provide enough context for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents both number and search_hlr with examples and behavior. The description reinforces search_hlr=true's role but does not add new parameter meaning beyond what the schema provides. 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 a specific verb and resource: 'Validate and format a phone number.' It also introduces the optional HLR lookup, which sharpens the scope by explaining an additional mode. This distinguishes it from sibling tools like check_email_valid or check_spam_number.

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 for when the optional search_hlr=true is worthwhile: it checks whether a mobile line is active. It also communicates the cost tradeoff, 10P base versus 30P with HLR. It does not explicitly name alternatives or exclusion cases, so it falls 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 show readOnlyHint and openWorldHint, which cover safety and openness. The description adds useful behavioral context: the Korea-specific reported-data scope and a cost signal of 10 points per call. It does not contradict 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 key action is front-loaded and the cost note is clear. The Korean sentence restates the first English sentence, making it slightly redundant, but overall the description remains short and scannable.

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 lookup with no output schema, the description supplies enough context: purpose, domain, usage examples, and cost. It does not spell out the response shape, but 'Check whether' strongly implies a boolean-style report.

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 'number' parameter already documented and exemplified. The description itself adds no new parameter semantics, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Check whether a phone number has been reported for spam, advertising, or criminal use in Korea.' This clearly identifies the tool's purpose and semantically distinguishes it from nearby siblings such as check_phone_valid, which would address phone-number validity rather than report history.

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 explicit use context: '수신 전화 필터링, 이상 거래 탐지 등에 사용합니다' (incoming call filtering, abnormal transaction detection). It does not state exclusions or name an alternative tool, so it falls 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 provide readOnlyHint=true and openWorldHint=true, and the description aligns with them by describing a collect-and-return operation with no destructive effect. It adds an operational cost note ('[호출당 40포인트]') but does not disclose output limits, the number of latest videos returned, or any external data variability beyond what openWorldHint already implies.

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-loads the core behavior, and includes a useful cost note. The main inefficiency is that the Korean sentence restates the English sentence, but the overall size is still appropriate for a simple tool.

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, read-only tool with no output schema, the description adequately communicates what the tool returns: a channel profile and recent uploaded videos, plus the per-call cost. It could be more explicit about how many videos count as 'latest' or what the profile fields are, but those are minor gaps for this simple scope.

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 user_id parameter already has a clear description with an example ('CNN'). The tool description adds no additional parameter-level detail, such as accepted formats or validation rules, so the baseline of 3 applies.

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

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

The description clearly states a concrete action ('Collect') and resource ('YouTube channel profile and its latest uploaded videos'), which distinguishes it from siblings like download_youtube_video or video_to_mp3. The Korean sentence reinforces the same behavior without distorting it.

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

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

The description implies that this tool is for retrieving YouTube channel/account profile data, so an agent can infer when to use it. However, it provides no explicit guidance on when not to use it or which alternative tools to prefer, such as download_youtube_video for downloading actual videos.

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=false, and the description does not contradict them. It adds useful behavioral context beyond annotations: it converts and returns the PDF, accepts only DOCX input, and costs 80 points per call.

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 English action, but the Korean sentence largely repeats the same conversion statement. The cost note and format restriction are useful, but the bilingual redundancy makes the description less concise than it could be.

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 low-complexity tool with one fully documented parameter, no nested objects, and no output schema, the description plus schema is complete. The agent knows what input is required, what the tool returns, what restrictions apply, and what the call costs.

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 single docx_url parameter already documents the downloadable HTTPS URL, allowed MIME type, and 25MB limit. The description adds no meaningful parameter semantics beyond reaffirming the DOCX-only restriction.

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 (convert), a specific source resource (DOCX), and a specific target format (PDF). This makes it easy to distinguish from reverse operations like pdf_to_docx and other conversion tools such as html_to_pdf.

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 no explicit when-to-use or when-not-to-use guidance and does not name alternatives for reverse conversion. The only guidance is the input restriction that exactly DOCX files are allowed, which is a constraint rather than usage-direction 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 only provide readOnlyHint and openWorldHint. The description adds meaningful behavior: output is an MP4, non-public/blocked content returns failure, and each call costs 3 points. There is no contradiction with the readOnlyHint annotation since downloading is a fetch operation.

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

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

The description is short and front-loaded with the core purpose. The Korean sentence duplicates the English sentence, creating slight redundancy, but the overall length is appropriate and the failure/cost notes are valuable.

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 no output schema, it adequately covers the input, the output format, and a key failure mode. It does not mention size limits or asynchronous behavior, but those are not essential for a basic call.

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

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

The schema already describes the single url parameter with 100% coverage, including an example. The description reinforces that the URL should point to a publicly available YouTube video but adds no additional parameter-level details beyond that.

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 ('Download') and resource ('a publicly available YouTube video') and clearly specifies the return format ('as an MP4 file'). This makes it easy to distinguish from siblings like extract_video_thumbnail or video_to_mp3.

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 a clear scope by saying the video must be publicly available and that private/blocked posts will fail. However, it does not explicitly mention alternative tools or state when-not-to-use conditions beyond the public availability constraint.

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

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

Annotations include readOnlyHint=true, which is consistent with a tool that returns a transformed PNG rather than modifying the source. The description adds format support (PNG, JPEG), adjustable parameters, and a per-call point cost, which is useful context. It does not explain potential failure modes, image size limits beyond the schema, or whether the returned PNG is a download URL or base64 payload, so it stays at a moderate level.

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?

Two sentences plus a short cost note. It is compact and front-loads the core action. The cost note is extra but relevant for agent decision-making. Slightly redundant with schema field descriptions, but not bloated.

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 image transform tool with a 100% documented schema and readOnlyHint, the description covers the essential behavior, supported formats, and adjustable attributes. It does not describe return format details, but with no output schema and a simple visual transformation, the gaps are minor. Sibling differentiation is sufficient via the image/PDF distinction.

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 with type, range, and default. The tool description repeats the general concepts of size, color, opacity, density but adds no syntax or behavioral detail beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Draw') and a concrete resource ('a visible text watermark across an image'), and it states the output is a PNG image. It is clearly distinct from draw_watermark_pdf, which is a sibling, because it specifies image files. It could name the sibling explicitly, but the resource difference is already clear.

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

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

The description implies usage for adding visible text watermarks to images and lists supported image formats and adjustable attributes. It does not explicitly state when to use this tool over draw_watermark_pdf or set_watermark, but the image-vs-PDF distinction is clear from the description and sibling name. No explicit exclusions or alternative routing, but enough context for a typical agent.

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 is consistent with it by stating a new artifact is returned ('삽입한 PDF 를 반환합니다') rather than implying mutation of the source. Beyond the annotation, the description adds useful behavioral facts: adjustable properties, PDF-only restriction, and a 10-point-per-call cost. No contradiction exists between the write-looking action ('draw') and the read-only hint because the tool returns a processed copy.

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 output behavior, customization options, format constraint, and cost. The only waste is that the Korean sentences largely restate the English ones, creating minor bilingual redundancy, but every substantive fact earns its place.

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 9 parameters, 2 required, full schema coverage, and an annotation covering the safety profile, the description covers the essentials: purpose, output (returns watermarked PDF), customization, and input restriction. Gaps are minor — no explicit mention of failure modes for invalid URLs or guidance on which sibling to use for non-PDF files — but these are partially mitigated by the schema and tool-name context.

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 every parameter already carrying ranges, defaults, and units (e.g., angle 0~360 default 35, density 100~200 default 150). The description's summary of '글자 크기·색상·투명도·각도·밀집도·적용 영역' (font size, color, opacity, angle, density, application area) provides a helpful conceptual grouping but adds no factual meaning beyond the schema, so the high-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 opens with a specific verb+resource: 'Draw a visible text watermark across every page of a PDF file.' It names the resource (PDF), the action (draw visible text watermark), and scope (every page). This clearly differentiates the tool from siblings like draw_watermark_image, which applies watermarks to images instead.

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

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

The description implies usage by stating the operation ('insert a text watermark across all pages of a PDF') and adds constraints ('PDF 형식의 파일만 허용됩니다' — only PDF files allowed) and cost ('[호출당 10포인트]'). However, it never explicitly routes to alternatives such as draw_watermark_image for non-PDF inputs, so an agent must infer the boundary from tool names rather than from this description.

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. The description adds behavioral context beyond annotations by stating that thumbnails are extracted at regular intervals, the result is a ZIP file, and each call costs 10 points. This does not contradict 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 core behavior is front-loaded and the cost note is compact. The bilingual repetition of the same sentence is slightly redundant for an AI agent, but it remains acceptably concise for a mixed-language tool listing.

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 required parameter, fully documented optional parameters, a clearly stated ZIP output, and read-only annotations, the description is largely complete. It lacks only explicit usage-alternative guidance, but that does not prevent an agent from invoking the tool correctly.

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

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

Schema description coverage is 100%, so count, width, and video_url are already fully documented with ranges and defaults. The description adds no parameter-level detail beyond what the schema provides, so the 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 clearly states the operation (extract thumbnail images), the resource (a video), and the return type (a ZIP file). It is unambiguous, but it does not explicitly distinguish this tool from sibling media tools such as video_to_mp3 or download_youtube_video, so it stops short of full 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 intended use is implied: use this tool when you need preview thumbnails extracted at regular intervals from a video. However, there are no explicit when-to-use or when-not-to-use instructions, and no alternative tools are named, leaving the agent to infer the appropriate selection 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 declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: supported input formats, JPEG output, and per-call cost. It does not mention edge cases such as when no face is found, but that is a minor gap for a read-only transformation.

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 action, and the Korean sentences add non-redundant details such as JPEG return format, supported image formats, and cost. There is no filler or unnecessary repetition.

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 two-parameter read-only tool, the description covers the essential operation, input formats, and return format. Minor omissions are an explicit alternative to face_detection and behavior when no face is detected, but with full schema coverage this is nearly 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%, and the schema already documents image_url requirements, allowed MIME types, size limit, threshold range, default, and semantics. The description adds no parameter-specific meaning beyond the schema, so the baseline 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 names the exact operation ('detect faces') and result ('blur/mosaic them') plus the JPEG output format, which clearly distinguishes it from sibling face_detection and other image tools. The Korean sentence reinforces the resource and output without ambiguity.

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

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

No guidance is given about when to choose this tool over alternatives such as face_detection or image_edit. The privacy-blurring use case is implied but never stated as a selection criterion or contrasted with sibling 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: it returns coordinates, optionally includes facial feature information when use_feature=1, and notes a 3-point charge per call. No contradiction with annotations exists, though error behavior and edge cases are not disclosed.

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

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

The description is short and front-loaded with the core action, but the Korean sentence largely duplicates the English one. The cost note is useful and placed at the end, yet the redundancy 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?

With no output schema, the description should explain the return value shape, and it only says 'coordinates' without describing the format or coordinate system. It also does not mention behavior when no face is found, which leaves meaningful gaps for an agent that must consume 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?

Schema coverage is 100%, so the schema fully documents all three parameters. The description only repeats the use_feature=1 behavior and adds no meaning beyond the schema for threshold or image_url, 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 uses a specific verb ('Detect'), names the resource (faces in an image), and states the output ('return their coordinates'). This clearly identifies what the tool does and distinguishes it from sibling tools like face_blur, which edit images rather than return detection coordinates.

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?

No when-to-use or when-not-to-use guidance is provided, and no alternative tools are mentioned. The agent must infer applicability from the schema and sibling list instead of being told how to choose between face_detection and related tools such as face_blur or nsfw_detection.

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 a billing note about points per call. However, it does not disclose what the response looks like or caveats about record availability, which is more noticeable because there is no output schema.

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 behavior. The English and Korean sentences are somewhat redundant, but this bilingual structure is reasonable for the target market and adds a use case and cost note without becoming bloated.

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 two-parameter lookup tool, the description covers purpose, identifiers, use case, cost, and safety via annotations. It is adequate for an agent to select and invoke the tool, though a brief note on 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 description coverage is 100%, with type and value already explained in the schema. The main description restates the two lookup modes but does not add meaningful new parameter semantics 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 states a specific verb (check) and a specific resource (Korean vehicle flood damage record), scoped by VIN or license plate. This makes the tool's function unambiguous and inherently distinct from siblings like get_car_scrap, which covers a different vehicle record 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 explicitly provides a concrete use case: checking flood history before purchasing a used car. It does not mention exclusions or alternatives, but the stated context is clear enough for an agent to understand 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 declare readOnlyHint and openWorldHint, and the description adds beyond them by disclosing the per-call point cost and the Korean-vehicle scope. It does not describe response details, but this is a simple read-only lookup and 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 English and Korean sentences are compact and front-loaded with the core purpose before cost and use case. The Korean sentence largely repeats the English sentence, causing slight redundancy, but the overall entry remains efficient.

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

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

For a simple two-parameter, read-only lookup with no output schema, the description covers what, how, why, and cost. It could improve by naming related car-lookup siblings or describing the response format, but nothing essential is missing for invoking correctly.

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

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

Schema description coverage is 100% and both type and value are already documented in the schema. The description only restates the type-to-VIN/plate mapping without adding new format or validation details, so it earns the baseline score.

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 clear verb and resource: checking whether a Korean vehicle has a scrap/total-loss accident record, keyed by VIN or license plate. It does not explicitly differentiate itself from sibling tools such as get_car_flooding or get_pccc, so it stops short of 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?

It gives an explicit intended use case: used before buying a used car. It does not, however, mention when to prefer an alternative or when not to use this tool, so it lacks the exclusions needed for 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 provide read/idempotent/destructive hints, and the description adds the practical fact that each call costs 30 points and that a prior req_pccc step is required. It does not address failure behavior, expiration of the auth key, or what the returned PCCC response looks like, so the added behavioral context is useful but limited.

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

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

The English opening sentence is front-loaded and clear, but the Korean sentence largely restates the same information. Both sentences earn some keep because the Korean specifies the req_pccc relationship explicitly, yet the redundancy makes it less tight than it could be.

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 gives the prerequisite flow, both required inputs, and the cost. It is sufficient to invoke correctly, though an agent would still benefit from knowing what happens on invalid/expired auth keys or how the PCCC appears in the response.

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 the schema already describes auth_key as coming from req_pccc and answer as the 6-digit SMS code. The description repeats this information without adding format details beyond what the schema provides, so it adds no material semantic value over 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 names a concrete operation ('Retrieve a Korean Personal Customs Clearance Code') and the exact inputs (auth_key, 6-digit SMS code), so an agent knows immediately what resource and verb are involved. It also references the sibling req_pccc as the source of auth_key, which distinguishes this from the surrounding PCCC-related tools.

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 states the usage context: call after req_pccc and use the auth_key from that response plus the SMS code. It does not explicitly contrast with check_pccc or state when not to use this tool, so it stops short of full exclusionary 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, so the read-only nature is covered. The description adds meaningful behavioral context beyond the annotations: the tool returns a JSON result, is robust to partial image modification ('높은 확률로 워터마크를 확인'), supports common formats, and carries a per-call cost of 10 points — a practical operational detail agents benefit from. No contradiction with annotations 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 tight and purpose-front-loaded: one clear directive sentence followed by three high-value specifications (JSON return, robustness, format support) and a cost note. Every sentence earns its place. Minor redundancy exists from stating the same idea in both English and Korean, but the whole remains compact and scannable.

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 low-complexity, single-parameter read tool with readOnlyHint=true and full schema coverage, the description is nearly complete: it covers return format (JSON), supported formats, robustness characteristics, and cost. With no output schema present, it would benefit from a brief note on the JSON response structure, but that gap is minor for a tool returning a watermark code.

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 single image_url parameter is already fully documented (downloadable https URL, allowed MIME types, 50MB cap). The description's mention of PNG/JPEG support is consistent with but less specific than the schema, adding minimal new meaning. Baseline 3 is appropriate 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?

The description opens with a specific verb+resource pair: 'Read the invisible watermark code embedded in an image.' It clearly states the tool's function (read/query, return as JSON) and is naturally distinguished from closely related siblings like set_watermark (write operation), draw_watermark_image, and draw_watermark_pdf (visible watermark drawing). The bilingual phrasing reinforces rather than obscures the 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?

Usage context is implied rather than explicit: the read-vs-set/draw contrast with sibling names signals when to pick this tool, and the description adds practical conditions (works on partially modified images, supports PNG/JPEG, costs 10 points per call). However, there is no explicit 'when to use' statement, no named alternative, and no exclusion guidance such as 'use draw/set_watermark to embed watermarks instead.'

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 useful context: per-call cost of 20 points, pagination behavior via page, and the result structure. No contradiction with annotations is present.

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 and return fields. The bilingual English/Korean restatement is slightly redundant, but the pagination and cost details earn their place.

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 two-parameter read-only tool with no output schema, the description sufficiently covers return values, pagination, and cost. Minor omissions such as result count or limits prevent a perfect 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?

Schema description coverage is 100%, so the schema already documents both keyword and page. The description only restates the search behavior and pagination without adding constraints, formats, or default-value clarification 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 operation: Google image search by keyword, and lists the exact returned fields (image URL, source link, title). This clearly distinguishes it from general google_search and image-based google_lens_search.

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 indicates the intended use case: retrieving Google image results for a specific keyword, with page for pagination. It does not explicitly name alternatives or state when not to use the tool, so it falls 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 declare readOnlyHint=true and openWorldHint=true, covering safety and non-determinism. The description adds allowed formats and a cost note ('60 points per call'), but it does not disclose much beyond that; the 'upload an image' wording also conflicts slightly with the URL-based input in the 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, then adds format/cost constraints. The Korean sentence largely restates the English part with a slightly expanded output list, introducing minor redundancy, but overall it remains appropriately sized.

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 purpose, a broad output description, and constraints. However, because there is no output schema, it should do more to describe what the returned labels or pages look like, and it never clarifies that the 'upload' is actually a URL reference rather than a file upload.

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 documents the downloadable https URL, allowed MIME types, and 50MB limit. The description only reiterates the image-format restriction and does not add meaning beyond schema, so it meets the baseline for a fully covered 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 'Reverse image search' and clearly states the action: provide an image and get visually matching web pages and labels. It is specific about verb and resource, but it does not distinguish itself from the sibling google_image_search, which appears to serve a very similar 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 use case is implied by 'reverse image search' and the Korean phrase '이미지로 검색', and the only exclusion is that only image-format files are allowed. There is no explicit guidance on when to prefer this over google_image_search, google_search, or image_similarity, so an agent must infer the appropriate 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 and openWorldHint, so the safety profile is covered. The description adds concrete behavior: returned fields are limited to link/title/snippet, pagination is possible via page, and each call costs 5 points. 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 short and front-loaded with the core function and output shape. The bilingual repetition (English and Korean) adds minor redundancy, but it is compact and includes only useful operational notes like pagination and cost.

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

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

For a simple read-only lookup with full parameter documentation, the description covers the required keyword, optional page paging, and result fields. It does not detail edge cases like empty results or error formats, but those are not necessary for correct 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?

Schema description coverage is 100%, so both keyword and page are already documented in the schema. The description adds only a small amount of extra context about using page to navigate result pages, which is helpful but not essential.

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 names a specific verb ('return'), a clear resource ('Google web search results'), and the exact output fields (link, title, snippet). The 'keyword' qualifier distinguishes it from sibling image/lens search tools like google_image_search and google_lens_search.

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

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

The description implies usage through the keyword-search framing and gives pagination guidance with page, but it never explicitly says when to choose this tool over alternatives or when not to use it. Sibling differentiation is left to the reader.

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 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 declare readOnlyHint=true and openWorldHint=true, and the description's 'Look up/조회' aligns with that read-only behavior. The description adds a per-call cost note ('[호출당 3포인트]') and downstream use cases, which is useful context. It does not disclose output shape or edge-case behavior, but for a safe read-only lookup the annotations carry most of 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 three short sentences, with the primary lookup action and scope front-loaded. The Korean sentence repeats the English statement, which is mildly redundant, but the overall size is compact and the extra cost/use-case information is earned.

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 two-parameter read-only holiday lookup, the description plus schema covers what an agent needs to call it correctly. There is no output schema, so the description could have described the returned holiday information, but this is a minor gap for a straightforward query tool. The cost note and read-only annotations round out the operational context.

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%: both year and month are documented with type, range, and example values. The description only restates 'given year and month' and does not need to add further parameter detail. The baseline of 3 applies because the schema fully handles 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 ('Look up') with a clearly bounded resource: Korean public holidays for a given year and month. The bilingual text and the stated use cases ('영업일 계산, 일정 관리') make the tool's role unambiguous. It is easily distinguished from the sibling tools, none of which target holiday data.

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

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

The description gives clear usage context by stating the tool is for business-day calculations and schedule management. It does not explicitly name alternatives or when-not-to-use conditions, but the sibling list contains no competing holiday tool, so the guidance is sufficient.

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 operation read-only, and the description adds the per-call point cost and confirms the output is a PDF file. It does not mention rendering limitations, CSS support, or how the file is returned, but for a simple conversion tool the key behavioral context is present.

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 action, and includes a useful cost note. The Korean sentence largely duplicates the English opening, which is minor redundancy in an otherwise tightly worded definition.

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 two-parameter conversion tool, the description plus schema is sufficient: input shape, optional pagination, and output type are covered. It could be more complete by describing the response format, but the absence of an output schema makes that a modest gap.

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 html and pagination parameters are already documented. The description only restates that an HTML string is the input and adds no new semantic detail about parameters.

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: 'Render HTML code into a PDF file,' and further clarifies the input is an HTML string returning a PDF. This clearly separates it from sibling converters like docx_to_pdf and pdf_to_image.

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 makes the primary use case explicit: provide HTML code as a string to receive a PDF, which implies it is not for URL-based conversion or other document formats. It does not explicitly name when-not-to-use or alternatives, so it stops short of full 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 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 provide readOnlyHint=true, so the read-only nature is covered structurally. The description adds meaningful behavioral context beyond annotations: a legal consent requirement, the cost of 40 points per call, and the mandatory/optional field grouping. It does not contradict any 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 core purpose is front-loaded in the first sentence, followed by essential field requirements and legal/cost caveats. It is reasonably compact for the amount of information conveyed, though the bilingual wording and field enumeration make it slightly longer than strictly necessary.

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 input requirements are fully specified with all required fields, formats, and legal caveats, which is enough to invoke the tool correctly. However, there is no output schema and the description does not describe the return value or error behavior of the authenticity check. An agent must infer what 'verify authenticity' returns, which is a notable gap for a verification tool with this parameter complexity.

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

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

Schema description coverage is 100% — every parameter has a Korean/English description and format examples. The description adds little beyond summarizing which parameters are required and explaining ghost_num and the four license-number sections. Since the schema already carries full parameter meaning, 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 verb and resource: 'Verify the authenticity of a Korean driver license using text input.' It clearly distinguishes from image-based sibling tools by explicitly stating the method (text input), and the title '[Text]' reinforces this. This is a precise, non-tautological purpose statement.

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: this is for text-based Korean driver's license authenticity verification. It explicitly states which fields are required versus optional and includes a legal prerequisite ('Use only when you have a lawful processing basis such as the data subject's consent'). It does not explicitly name alternatives or when-not-to-use other identi_card tools, so it loses a point, but the '[Text]' marker and 'using text input' strongly imply the boundary with image-based 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 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 indicate a mutating, idempotent, non-destructive op, but the description adds significant behavioral context: immediate point deduction (count×25), refunds for failed images, non-cancellation after acceptance, and per-image pricing. 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?

Three short Korean sentences each carry distinct operational information: scope, cost/refund behavior, and cancellation policy. The core task is front-loaded and there is no 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 an async tool with no output schema, the description covers submission, pricing, refunds, and cancellation well. It does not state what the response contains (e.g., a job ID) or how to retrieve results, though sibling tools image_batch_result and image_batch_status strongly imply the intended flow.

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 all 9 parameters. The description only adds cost semantics related to image_count, which is useful but does not compensate or expand 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 verb (접수합니다) and a clear resource: asynchronous generation or editing jobs for 1–50 images. The batch size and async nature distinguish it from single-image siblings like image_generate and 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 implies batch use through '1~50장' and '비동기' but does not explicitly say when to choose this over single-image alternatives. No direct comparison or exclusion of image_edit/image_generate is provided.

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 read-only behavior is covered. The description adds useful context: only one image is returned, only from completed jobs, and the operation is free. It does not describe error behavior for invalid job IDs or out-of-range indices, but the schema and annotations cover much of the safety profile.

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?

One short sentence contains the operation, the object, the condition (completed), and the return type (image content), with '[free]' appended. There is no filler or repetition of schema fields.

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 two-parameter read-only tool with full schema coverage and no output schema, the description is nearly complete: it identifies the return content and the required job state. It could be more explicit about using image_batch_status first, but this is a minor gap.

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 job_id and index already documented including zero-based indexing and the 0-49 range. The description adds no parameter-level information beyond saying 'specified one image', so it stays at the schema-covered 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 uses a specific verb and resource: it returns one specified image from a completed batch job as image content. It does not explicitly name sibling tools, but the contrast with image_batch_create and image_batch_status is clear from the wording (completed result vs creating/status).

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 word 'completed' implies the tool should be used after a batch job finishes, and the 'result' phrasing distinguishes it from status-checking or creation. However, it does not explicitly state when-not-to-use it or point to image_batch_status as a prerequisite/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?

The annotations already mark the tool as read-only, and the description adds useful context by specifying what is read: progress, pre-deduction, refund, and current deducted points, plus the '[무료]' cost signal. It does not explain status values or polling behavior, but that is a minor gap for a simple read-only status query.

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 a single Korean sentence that front-loads the resource and action, then briefly lists the queried fields, with '[무료]' as a compact cost tag. There is 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?

For a single-required-parameter read-only status tool, the description covers what will be returned (progress and point adjustments) and clearly identifies the domain of the input. Although there is no output schema, naming the principal return fields is sufficient for an agent to invoke the tool correctly.

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

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

The schema already fully documents job_id with a format pattern and the label '작업 ID', so schema coverage is 100%. The description adds only the domain context that this is a bulk image job; it provides no additional semantic detail 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 ('조회합니다') and resource ('대량 이미지 작업'), and enumerates the exact data returned: progress status, pre-deduction, refunds, and current deducted points. However, it does not explicitly contrast itself with sibling tools like image_batch_result, so differentiation depends on the tool name and the listed status-related fields.

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

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

The description implies the tool is used to check the progress and point accounting of an earlier bulk image job, which gives a clear context. It does not state when to prefer it over image_batch_result or image_batch_create, nor does it mention any exclusions or alternatives.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, etc.), the description adds the behavioral detail that the result is returned as image content and that each use costs 25 points. This pricing disclosure is useful context that annotations do not provide.

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 sentence is efficient and front-loaded, but the pricing information is duplicated: '장당 25포인트입니다' followed by '[이미지당 25포인트]' is redundant and does not earn its place.

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 6 parameters and no output schema, the description covers the core behavior, required inputs, return type, and cost. Optional parameters are documented in the schema, so nothing critical is missing for calling the tool correctly.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no parameter-level meaning beyond what is already in the schema, so the baseline of 3 applies.

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

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

The description clearly identifies the action ('이미지 한 장을 편집' - edit one image), the required input (original image + edit instruction), and the return type (image content). The phrase '한 장' (one image) distinguishes it from batch siblings like image_batch_create, and '편집' (edit) distinguishes it from image_generate.

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 the clear usage context: use when you have an original image and an editing instruction. It does not explicitly name alternatives or exclusions, but the input requirement is specific enough to guide tool 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 signal non-read-only, non-destructive, and idempotent behavior. The description adds useful context: reference images are not modified, the result is always a new image, and each image costs 25 points. It does not contradict any 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 short and front-loaded with the core function and key caveats. The only minor redundancy is the cost being stated twice: '장당 25포인트입니다' followed by '[이미지당 25포인트]'.

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 6-parameter tool with no output schema, the description covers generation modes, reference semantics, and cost, while the schema covers input details. The main gaps are the lack of explicit sibling differentiation from batch/editing tools and no indication of what the response contains.

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

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

The schema covers all 6 parameters with 100% description coverage, so the baseline is 3. The description adds no parameter-level detail beyond the schema; the reference-image semantics ('제품·인물·색감·구도') are already present in the schema property description. Cost is additional context but not 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 states a specific action and resource: '이미지 한 장을 생성합니다' — generate one image. It distinguishes itself from siblings by emphasizing '한 장' (single image, vs image_batch_create) and '결과는 새 이미지' (new image, vs edit-like operations).

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 for the two input modes: text-only or reference image plus text, and explains the reference image is only a guide. However, it does not explicitly state when to choose this tool over image_batch_create or image_edit, nor does it list exclusions, so the routing decision is mostly implicit.

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, so the safety profile is covered. The description adds useful context about per-call cost and typical application areas, but it does not disclose the similarity score scale, failure behavior, or limitations beyond the schema-provided 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 compact and front-loaded with the core action. The English and Korean portions repeat the same information, which is mildly redundant, but the use-case and cost notes earn their place and the overall length is appropriate.

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 two-parameter read-only tool with a richly documented schema, the description provides enough to invoke it correctly: what it does, what it returns, when to use it, and its cost. The lack of an output schema leaves the exact score range ambiguous, but this does not block correct 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?

Schema description coverage is 100%, with both parameters fully documented for URL format, MIME types, and size limits. The description only restates the conceptual roles of the two images ('base image' and 'comparison image') without adding 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 uses a specific verb and resource: 'Compare a base image with another image and return a similarity score.' It also names concrete use cases—original verification and duplicate detection—which clearly distinguishes it from image editing, generation, and detection siblings.

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 by stating the tool is for '원본 검증, 중복 이미지 탐지 등' (original verification, duplicate image detection, etc.). It does not explicitly name alternatives or when-not-to-use conditions, but the use cases provide enough guidance for 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 declare readOnlyHint=true, and the description complements this by adding that the operation is free ('무료입니다') and scoped to the currently authenticated API key. It does not detail rate limits or exact response structure, but for a zero-parameter read-only tool this is reasonable.

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, but it repeats the same content in English and Korean and redundantly states '무료입니다' and '[무료]'. The core message is clear, but the duplicate free-note is unnecessary and slightly bloats the definition.

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 zero-parameter, read-only account info tool, the description covers what the tool returns (remaining points and account status), the auth scope, and the cost. No output schema exists, so the description's explicit mention of return semantics is sufficient.

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 tool has zero parameters, and schema description coverage is trivially 100%. The description does not need to document parameters; the baseline for zero-parameter tools is a 4, and there are no gaps here.

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 ('Check'/'조회') and a specific resource ('APICK account balance and status'/'잔여 포인트와 계정 상태 정보'). It clearly identifies what the tool does and is easily distinguished from the broad sibling list, none of which target account info.

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 implies when to use the tool: whenever the agent needs the current APICK account balance or status. It does not explicitly mention alternatives or exclusion criteria, but with zero similar siblings and a simple purpose, the context is sufficient.

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 readOnlyHint annotation already indicates a safe read operation, and the description adds beyond that: the scope constraint that subdomains are not tracked, and the cost signal of 100 points per call. It does not describe the exact return shape, but for a simple read-only lookup with annotations present, the added context is meaningful.

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

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

The description is short and front-loaded with the main purpose. The Korean sentence largely repeats the English sentence, which is mild redundancy, but the scope caveat and cost note are valuable additions. It is appropriately sized overall, with only one repetitive sentence keeping it from a top 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 simple one-parameter, read-only lookup with no output schema and no nested objects, the description covers the essential context: what the tool does, the domain scope, and the cost. It does not specify the output format in detail, but 'historical IP address changes' sufficiently conveys what the agent should 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 documents the single 'domain' parameter at 100% coverage with an example. The description adds important semantic nuance not in the schema: the query is based on the top-level domain and subdomains are not tracked, which tells the agent to provide an apex domain like 'apick.app' rather than a subdomain.

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 resource: 'Look up the historical IP address changes of a domain.' This clearly distinguishes the tool from siblings like nslookup (current DNS), reverse_ip (IP-to-domain), and whois (registration info), since it is specifically about historical IP changes. The Korean sentence reinforces the same purpose without ambiguity.

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

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

The intended use is clear: use it when you need historical IP changes for a domain. The description also gives an explicit exclusion: subdomains are not tracked and lookup is based on the top-level/apex domain. It does not explicitly name alternative tools for other lookups, but the historical vs. current distinction is implied well enough.

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 mark the operation as read-only, and the description adds useful context by stating that a converted Excel file is returned and that each call costs 1 point. It does not document limits or error behavior, but these are minor for a simple conversion tool with readOnlyHint set.

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

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

The description is short and front-loaded with the core purpose, followed by input-format guidance and cost notice. The Korean sentence repeats the English statement, adding minor redundancy, but the overall structure remains efficient and scannable.

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 two-parameter conversion tool, the description covers purpose, input shapes, return behavior, and cost. There is no output schema, but the output type is explicit in the description. Minor details like default sheet_name or row-count validation are already partially covered by the 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?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds value by giving concrete examples of the two supported data_list formats and clarifying that the output is an XLSX file; sheet_name semantics are left to the schema, which is sufficient.

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 (convert) and resource (JSON to Excel/XLSX), and states that the result is returned. It also names the supported input shapes, which makes the tool's function unambiguous and distinguishes it from file-conversion siblings like docx_to_pdf or pdf_to_image.

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 conveys when to use the tool: whenever JSON data needs to be converted to Excel. It also gives concrete guidance on accepted data_list formats and mentions the per-call cost. It does not explicitly name alternative tools or state when not to use it, but no direct sibling performs this conversion.

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, and the description adds meaningful behavioral detail: invalid addr1 triggers an options field listing selectable regions, and each call costs 100 points. This goes beyond the structured 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 is somewhat redundant with the English opening, but it improves accessibility for the likely Korean-speaking user, so the structure remains efficient.

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

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

Despite having no output schema, the description conveys the essential invocation context: query dimensions, invalid-input behavior, and cost. It does not detail the transaction record fields returned, but for a simple lookup tool this is not a critical omission.

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

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

Schema description coverage is 100%, so the schema already fully documents all four parameters, including type codes, year range, and address format examples. The description adds no additional parameter-level meaning beyond 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 and resource: 'Look up real estate transaction price records in Korea by region, property type, and year.' This clearly distinguishes the tool from all siblings, none of which target real estate transaction prices.

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?

Clear context is provided: use this when the user needs Korean real estate transaction price history by region, type, and year. No exclusion or alternative is mentioned, but no sibling tool overlaps with this function, so ambiguity is minimal.

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?

Even though annotations already declare readOnlyHint=true, the description adds substantial behavioral context beyond them: the stateless server model, the compacted_messages continuation protocol, the default Korean system prompt, and token-based point deduction with a free tier. None of this is visible in the annotations, and the point deduction is a billing side-effect rather than a data mutation, so it does not contradict readOnlyHint.

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 core purpose is front-loaded in the first sentence, followed by high-value behavioral details (statelessness, history handoff), then cost and free-tier notes. Each sentence contributes a distinct fact, though the bilingual English/Korean restatement adds minor redundancy that 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?

For an 8-parameter chat tool with a nested compact object and no output schema, the description covers the essential invocation flow: model discovery, the stateless history handoff, and cost behavior. It names compacted_messages as a response element, but does not describe the overall response shape beyond that, and how the compact sliding_window strategy interacts with compacted_messages is left entirely to the 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?

Schema description coverage is 100%, so the schema already documents model, speed, system, compact, content, messages, max_tokens, and temperature thoroughly. The description adds only cross-referential value — tying messages to the compacted_messages lifecycle and routing model discovery to llm_models — rather than new per-parameter meaning. Baseline 3 is appropriate when the schema carries the parameter documentation burden.

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+resource statement — 'Send a chat request to a selected LLM model and receive the assistant reply' — that names the action, target, and outcome. It also differentiates from siblings by pointing to llm_models as the separate model-listing tool and by defining the stateless messaging contract, making it unmistakable against text_polish/text_summary and the other utilities.

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 procedural context: use llm_models to discover available models, send the full history on every call because the server is stateless, and reuse the response's compacted_messages as the next turn's messages. It also flags cost (points deducted by token usage) and a free tier. What it lacks is explicit when-not-to-use guidance or contrast with sibling text tools like text_polish and text_summary.

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 readOnlyHint annotation already signals a safe read operation, and the description adds meaningful behavioral detail: it lists exactly what the response contains (1M-token input/output prices in points, family, size, multimodal flag, tags, use_cases, max_context), states that everything is returned in one response, and notes that the tool is free. This goes well beyond the annotation without contradicting it.

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 structured but contains redundancy: the English opening is restated in Korean, and the free-of-charge point appears twice ('무료입니다' and '[무료]'). The key detail about llm_chat is placed late, though the response-content list is front-loaded. It is compact but not maximally efficient.

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

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

There is no output schema, so the description must carry the return-value explanation, and it does: it enumerates the exact fields returned, states the pricing basis (per 1M tokens, in points), says results come in one response, and explains the tool's relationship to llm_chat. Together with the fully documented input schema, an agent has enough to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, and each of the four optional parameters already has its own clear description and allowed values. The tool description does not add parameter-level meaning beyond that, so the baseline score of 3 is appropriate: 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 opens with a specific verb and resource: 'List available text-generation LLM models with per-token pricing and max context.' It also distinguishes itself from the sibling llm_chat by explicitly stating it is used to find the model input value for llm_chat. This makes the tool's role as a catalog clear and unambiguous.

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

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

The description gives an explicit usage condition: 'llm_chat Tool의 model 입력값을 찾을 때 사용합니다' ('Use when finding the model input value for the llm_chat Tool'). It names the relevant sibling tool directly, and since no other sibling provides model catalog data, this acts as complete 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, so the safety profile is covered. The description adds useful context by explaining that a domain is resolved to its IP before lookup and that each call costs 30 points; it does not detail output format or error 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?

It is short and front-loaded in English, but the Korean text largely duplicates the English sentence, creating redundancy. The cost note is useful but placed at the end; a single-language version would be tighter.

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 lookup tool with no output schema, the description provides enough to call it: input type, resolution behavior, cost, and result concept. It could be more explicit about the return structure, but the low complexity keeps this from being a serious gap.

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 the address property is already described as 'domain or IP' with an example. The description adds a small amount of process information (domain-to-IP resolution) but does not materially expand parameter meaning.

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 ('Look up') and resource ('geographic location of a domain or IP') and adds the domain-resolution behavior. It clearly states the tool's function but does not explicitly differentiate it from sibling lookup tools like nslookup or whois.

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?

No guidance about when to prefer this tool over nslookup, whois, or reverse_ip is provided. The closest signal is the phrase 'geographic location,' which implies a use case but never states exclusions or alternatives.

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

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

Annotations already 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.

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

Annotations already mark readOnlyHint=true, and the description adds that it returns an nsfw_score and can include detailed results when detail=1. It also discloses the per-call cost, but it does not explain the score scale, threshold, or what the detailed result contains.

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 first two sentences repeat the same statement in English and Korean, wasting tokens. The detail=1 and cost notes are useful but do not fully compensate for the 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?

With no output schema, the description gives minimal return information (nsfw_score, optional detailed result) but omits the interpretation or range of the score and the shape of the detailed output. Still, for a simple single-URL detector, the core invocation requirements are present.

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 detail sufficiently. The description's mention of detail=1 effectively restates the schema's '세부 판정 결과 포함 여부' rather than adding new semantic meaning.

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 operation ('Detect whether an image contains NSFW content') and a specific output ('return an nsfw_score'), with an explicit definition of NSFW as violent or sexually explicit. This clearly distinguishes it from image-related siblings like face_detection or image_similarity.

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 intended use is implied by the operation itself, but there is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. An agent must infer when this tool is appropriate among many image-processing 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 indicate read-only and open-world behavior, and the description adds value beyond that by stating that invalid non-domain inputs return an error and that results reflect currently registered IPs. It does not mention empty-result handling or DNS resolver details, but those are minor for a simple read-only tool.

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 appropriately short and front-loaded, with the core action in the first sentence followed by validation behavior and cost. No unnecessary background or fluff is included.

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 DNS lookup with no output schema, the description provides enough context: what input is required, what output to expect (list of currently registered IP addresses), and what error to anticipate for invalid input. Nothing essential is missing.

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 only parameter, domain, already has 100% schema coverage with a clear description and example (apick.app). The tool description reinforces that the value must be a domain, but it does not add substantial 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 uses a specific verb and resource: 'Resolve a domain name to its currently registered IP addresses (DNS lookup).' This clearly distinguishes it from sibling tools such as reverse_ip (IP-to-domain lookup) and whois (domain registration metadata).

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 use case is explicitly clear: invoke it when given a domain and needing its current IP addresses. It also states that non-domain values produce an error, which is a useful when-not-to-use signal. However, it does not explicitly mention alternatives like reverse_ip or whois.

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

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

Annotations already mark it as read-only, but the description adds useful non-obvious behavior: it returns the complete extracted text as 'full_text' and discloses the per-call cost of 12 points. This goes beyond the structured annotations, though it does not discuss error cases or what happens with unsupported input.

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, followed by usage context and cost. There is slight redundancy between the English sentence 'Extract text from an image file (OCR)' and the Korean sentence that repeats the same idea, which prevents a perfect conciseness 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 simple one-parameter, read-only OCR tool with no output schema, the description covers what an agent needs: the action, the return shape (full_text), the intended image types, and the cost. The input parameter constraints are fully handled by the schema, so no critical information is missing.

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 only parameter, image_url, is already fully documented in the input schema with details about HTTPS URL, allowed MIME types, and the 50MB size limit. The description adds no additional parameter-level meaning, 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 uses a specific verb and resource: 'Extract text from an image file (OCR)' and further clarifies it returns 'full_text'. It also positions itself for '범용 이미지' (general-purpose images) such as document photos, scans, and screenshots, which implicitly separates it from sibling OCR tools like ocr_identi* and identity_document_*. This makes the tool's purpose unmistakable.

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 says to use it for '문서 사진, 스캔 이미지, 캡처 화면 등 범용 이미지', giving clear context for when this tool is appropriate. However, it does not explicitly state when not to use it or point to alternatives like the identity-document OCR siblings, so it falls 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 mark the tool as readOnly and not open-world, and the description adds useful behavioral context: it returns structured fields plus raw_text, mentions the per-call point cost, and warns about legal compliance. 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 short and front-loaded with the core purpose. The English and Korean sentences partly duplicate each other, but the additional legal and cost information is valuable and does not create meaningful 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?

With one parameter, a complete schema, and readOnly annotations, the description covers the input, extracted fields, output format, legal condition, and cost. It lacks explicit error/edge-case behavior and sibling differentiation, but it is sufficient for a simple OCR tool.

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

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

The only parameter, image_url, is fully documented in the schema with format and size constraints, so the schema carries the parameter semantics. The description adds little beyond restating that the image is a resident registration card photo, which is already implied by the tool's purpose.

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 names a specific action and resource: extracting key fields from a Korean resident registration card image via OCR, and it lists the fields extracted. It is clear, but it does not distinguish this tool from sibling tools like ocr_identi2–5 or identity_document_id_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 a clear legal precondition: use only when a lawful basis such as data subject consent has been secured. However, it does not explain when to choose this tool over the many alternative OCR/ID document tools, leaving variant selection 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 the description adds useful behavioral details beyond that: it returns structured results plus raw_text, extracts specific fields, and notes the cost per call. It does not mention failure modes or edge cases, but for a read-only OCR tool the added context is meaningful.

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

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

The description is short and front-loaded with the core purpose. The English/Korean duplication creates minor redundancy, but the legal-consent caveat and point cost are each valuable enough to justify their inclusion.

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 adequately covers expected outputs (structured result and raw_text) and examples of extracted fields. It could be more complete by distinguishing among the many sibling OCR tools, but nothing essential to invoking this tool correctly is missing.

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 the single image_url parameter, including allowed formats and max size, so the schema already fully documents the parameter. The description adds no additional parameter-level guidance, matching the baseline of 3.

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 ('Extract') and resource ('Korean driver license image via OCR'), and lists example fields (name, license number, birthdate). It does not explicitly distinguish this tool from siblings like ocr_identi1/3/4/5 or identity_document_driver_license, so it stops short of a 5.

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

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

The description gives a clear usage condition: use only when a legitimate processing basis such as data subject consent is secured. This acts as a when-not restriction and adds compliance context, though it does not explicitly compare against alternative OCR or identity-document 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 already declare readOnlyHint=true, and the description adds useful context: it returns both structured fields and raw_text, requires a legal basis due to sensitive personal data, and notes a per-call point cost. 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 main purpose. The English and Korean sentences are somewhat redundant, but the Korean sentence adds field names and raw_text detail, and the legal/cost notes earn their place.

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 compensates by naming the expected outputs: structured fields such as name, passport number, issue/expiry dates, birth date, plus raw_text. It could be more precise about exact output keys or failure behavior, but it is adequate for a one-parameter OCR 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 for the single parameter image_url is 100%, with the schema already specifying HTTPS, allowed MIME types, and the 50MB limit. The description adds nothing beyond referring to a passport image, 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 clearly states the action: extract key fields from a passport image via OCR, and lists examples of extracted fields. It does not explicitly differentiate itself from closely named siblings like identity_document_passport or ocr_identi1/2/4/5, so it stops short of a 5.

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

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

The description gives an important condition for use: only when a legal processing basis like consent has been secured. However, it provides no guidance on when to choose this tool over the many sibling passport/OCR tools, leaving tool selection largely implied.

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

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

Annotations already mark it read-only (readOnlyHint=true), so the description only needs to add context. It adds that output includes both structured results and raw_text, discloses the 12-point cost, and warns about legal processing grounds. No contradiction with annotations.

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

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

The core is front-loaded and the legal/cost notes are valuable, but the English and Korean sentences are largely redundant and could be merged without losing meaning.

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 carries the burden of explaining output. It mentions 'structured results and raw_text' but does not say which fields are extracted or in what structure, leaving an agent to discover this only by calling 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% and already specifies image_url format (https, png/jpeg, max 50MB). The description adds nothing about the parameter beyond saying it is an image of the deungbon, so baseline 3 is appropriate.

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

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

The description names a specific verb ('Extract key fields'), a specific resource ('Korean certified copy of resident registration (deungbon) image'), and the OCR method, which distinguishes it from sibling OCR/identity tools by document type. The Korean sentence reinforces the exact subject matter.

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