APICK

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 baseline is met. The description adds valuable behavioral context: the cost per call ('[호출당 60포인트]') and the required presence of either bank_code or bank_name. It does not detail the return format or error handling, but for a simple lookup this is sufficient.

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

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

The description is bilingual and includes purpose, usage, a mandatory-input note, and cost in just four sentences. The Korean repetition slightly lengthens it, but every clause carries meaningful information. It is efficient without being terse.

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

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

Given the tool's simplicity (3 params, no output schema), the description covers the essential aspects: purpose, usage context, the required bank_code/bank_name relationship, and cost. It omits return value details, but the tool's function is straightforward enough that this does not create a significant 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%, so the baseline is 3. The description adds value by explaining that bank_code and bank_name are alternatives and at least one is required, a constraint not present in the schema's required list (which only lists account_num). It also references the bank_code tool for obtaining bank codes, enriching the 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 clearly states the tool's function: 'Look up the account holder name of a Korean bank account.' It uses a specific verb ('look up') and resource ('account holder name'), and includes a usage context ('송금 전 예금주 확인 등에 사용') that distinguishes it from related tools like bank_code or transfer_1won.

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 when to use it ('before remittance to verify the account holder') and makes a critical input requirement clear: 'bank_code 또는 bank_name 중 하나는 입력해야 합니다' (either bank_code or bank_name must be entered). It does not provide explicit alternatives or when-not-to-use scenarios, so it stops short of a 5.

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

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

Annotations declare readOnlyHint=true, but the description states '포인트는 모델별 정액으로 1장 단위 차감됩니다' (points are deducted per image), implying a side effect. This directly contradicts the readOnlyHint annotation, violating the requirement to disclose behavioral traits consistently.

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 information-dense and covers essential aspects, but the first two sentences repeat the same information in English and Korean, creating slight redundancy. Overall, every sentence contributes 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?

Given no output schema, the description effectively explains the return format (images[].b64_json), model selection, pricing, and that points are deducted. It lacks error handling or rate-limit details, but is largely complete for a generation 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%, but the description adds valuable semantics: 'model' should come from the specified endpoint, and the prompt length (max 3000) is reinforced. It also clarifies output dimensions and pricing, enriching the meaning of both 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 clearly identifies the action ('Generate'), the resource ('1024x1024 image'), and the output format ('base64'). It is specific and distinct from siblings like base64_to_image or draw_watermark_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 explains what the tool does and how to obtain model IDs, but does not explicitly state when to use this tool versus alternatives or provide exclusions. It gives useful context but lacks explicit usage 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?

With annotations already providing readOnlyHint and openWorldHint, the description adds '전체 목록을 반환합니다' (returns the full list), indicating no pagination or filtering, and states it is free ('무료입니다'). This goes beyond the annotations, though it doesn't elaborate on output format or potential response sizes.

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 relatively short and front-loaded with the primary action. However, it contains redundancy: the Korean phrase repeats the English statement, and '무료입니다' appears twice (plain text and as '[무료]'). This is somewhat wasteful but not overly verbose.

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

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

For a zero-parameter, no-output-schema tool, the description covers purpose, usage context, and a key behavioral trait (full list). It also names dependent tools, which helps the agent understand when to invoke it. Minor gaps: no mention of response format or update frequency, but given the simplicity, it is largely complete.

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

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

The tool has zero parameters, and schema coverage is 100% vacuously. Per the baseline for 0 params, the description need not explain any parameter semantics. It could have further described output structure, but that's beyond 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 clearly states the tool lists Korean bank codes and names ('List Korean bank codes and names'), using a specific verb and resource. It also provides the Korean equivalent, ensuring unambiguous purpose. The mention of usage with transfer_1won and account_realname further distinguishes its role among sibling 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?

Explicitly states when to use this tool: 'transfer_1won, account_realname Tool의 bank_code 입력값을 찾을 때 사용합니다' (use when finding bank_code input values for transfer_1won and account_realname tools). This gives clear context and indirectly excludes other uses, though it doesn't name 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 provide readOnlyHint=true, and the description adds that strings with a data URI prefix are allowed and that it returns an image file. The prefix allowance is already present in the schema parameter description, so the added value is minimal. The pricing note ([2 points per call]) is cost information, not behavioral transparency. No contradictions 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 two sentences (in English and Korean) plus a brief cost note. It is front-loaded with the core action and includes necessary details without fluff. Each sentence earns its place, though the bilingual repetition is slightly redundant but acceptable.

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

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

The tool is simple (one input, no nested objects, no output schema), and the description adequately states the conversion and input flexibility. However, it does not explain the output format or how the image file will be returned, which could be useful for an agent. Given the low complexity, the description is mostly 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% for the single parameter, and the schema already documents that the string may include the data URI prefix. The description repeats this detail without adding extra meaning beyond the schema. 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 tool's function with a specific verb ('Decode') and resource ('base64-encoded image string'), and the result ('an image file'). This distinguishes it from sibling tools, which handle other image operations but none specifically decode base64 to an 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 intended use is implied by the description: use this tool when you have a base64-encoded image string and need the original image file. However, there is no explicit 'when to use' vs. alternatives, nor any exclusions or conditions. The uniqueness among siblings makes it fairly clear, but guidance is not 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 and openWorldHint, so the safety profile is covered. The description adds useful context beyond annotations, including the 40-point cost per call and the kind of status fields returned. 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 description is short and front-loaded with the English purpose statement. The Korean sentence repeats some information but adds a valuable field list and cost note, so it earns its place; minor redundancy prevents a 5.

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

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

With no output schema, the description must explain what the tool returns, and it does: representative, address, employee count, establishment date, industry, business type, contact, business status, and tax type. It also includes the cost and the required input format, making it complete for a simple lookup 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, biz_no, is fully documented in the schema (10 digits, hyphen excluded, example provided). The description adds minimal parameter meaning beyond restating the 10-digit registration number, so the baseline of 3 is appropriate given 100% 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 by its 10-digit business registration number.' It clearly identifies the tool's function and lists common output fields, but it does not explicitly distinguish itself from sibling tools like venture_biz_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 conveys when to use the tool: when you have a Korean business registration number and need general status information. It does not mention exclusions or alternatives, but the context is clear enough for a straightforward lookup 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?

Beyond the readOnlyHint annotation, the description discloses additional behavioral details: include_img=1 returns an image with recognition results displayed, and the call costs 3 points. These add operational context not present in annotations, though it doesn't detail bounding box format or confidence threshold behavior beyond the 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 concise, with a clear English sentence, a Korean equivalent, a note about include_img, and cost information. All sentences contribute value, and the most important information is front-loaded.

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

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

No output schema exists, so the description carries the burden of explaining return values. It mentions bounding boxes and the include_img behavior, covering the core functionality. Minor gaps like the exact format of bounding boxes or behavior when no vehicles are detected are not critical but 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 coverage is 100%, but the description adds meaning for the include_img parameter by explaining that setting it to 1 returns an image with recognition overlays, which is more specific than the schema's 'include result image' note. The other parameters are already well-described 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 tool's function: detect vehicles (cars, motorcycles, bicycles, trucks) in an image and return their bounding boxes. It uses a specific verb ('Detect') and describes the output, distinguishing it from sibling detection tools like face_detection and person_detection by focusing on vehicles.

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 vehicle detection but does not explicitly mention when to use this tool over alternatives, nor does it state exclusions. Sibling tools like face_detection and person_detection could create confusion, but the clear vehicle scope offers implied 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 indicate readOnlyHint=true and openWorldHint=true. The description adds value by stating the tool checks 'real and deliverable' (indicating deeper validation than syntax) and includes a cost note ('[호출당 10포인트]'). This goes beyond the annotations and discloses relevant behavioral traits, though it does not describe limitations or side effects.

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

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

The description is extremely concise, with three clear elements: purpose, use cases, and cost. It is front-loaded with the primary action and contains no filler or redundant content beyond the bilingual repetition, which is harmless.

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

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

Given the simple single-parameter schema and good annotations, the description is mostly complete. It covers behavior and use cases, but it does not explicitly state the return format (e.g., boolean or result object). Since there is no output schema, this is a minor gap that could be filled for full completeness.

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 covers the single 'email' parameter with a description and example. The tool description does not add additional parameter semantics, so the baseline of 3 is appropriate given 100% 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 action: 'Validate whether an email address is real and deliverable.' This uses a specific verb and resource, and distinguishes the tool from siblings like check_phone_valid by focusing on email. The mention of use cases ('회원가입 입력값 검증, 발송 전 리스트 정제 등') reinforces its purpose.

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

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

The description provides clear usage context by listing example scenarios: 'signup input validation, list cleansing before sending.' It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to decide when to use this tool.

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

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

Annotations include readOnlyHint=true, and the description's 'Verify' aligns with that, so no contradiction. The description adds a notable behavioral detail beyond annotations: '[호출당 20포인트]' (20 points per call), which is a cost/rate-limit disclosure. It also adds the specific use context, though no further side-effect details are needed for a read-only 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 front-loads the key information in the first sentence and includes a useful cost note. However, it repeats the same content in English and Korean, creating redundancy. The second sentence essentially restates the first, so it could be more concise. Structure is otherwise clear.

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

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

The tool is simple and read-only, with a clear purpose. However, no output schema is provided, and the description does not disclose what the tool returns beyond vague '일치 여부' (match or not). It also doesn't mention whether this tool is meant to be used in conjunction with PCCC issuance tools like get_pccc. More detail on the return value would improve completeness.

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 all four parameters (name, pccc, zip, phone) having detailed descriptions including formats and examples. The description restates the parameters' collective role ('matches the given name, zip code, and phone number') but adds no new semantic information beyond what the schema already provides. Baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Verify that a Korean Personal Customs Clearance Code (PCCC) matches the given name, zip code, and phone number.' The use case '해외직구 주문 정보 검증 등' (overseas direct purchase order verification) and the explicit '검증' (verification) verb distinguish it from sibling tools like get_pccc or req_pccc, which likely issue or request PCCC.

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

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

The description provides a clear context: '해외직구 주문 정보 검증 등에 사용합니다' (used for verifying overseas direct purchase order information). It does not explicitly exclude other uses or name alternatives, but the context is sufficient for an agent to understand when this tool is appropriate. No misleading 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 indicate readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context such as the cost of 10 points per call and input format requirements, which go beyond the annotations. 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 description is extremely concise: one line states the purpose, a second line demonstrates the input format, and a brief cost note. Every sentence earns its place without unnecessary verbosity.

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

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

For a simple validation tool with one parameter, readOnly annotations, and no output schema, the description covers purpose, input format, and cost. The return value is implied, and the provided context is sufficient for an agent to use 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 input schema already fully describes the 'number' parameter with examples (100% coverage). The description repeats the same format information and adds minor detail about domestic/overseas handling, but does not significantly extend 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 clearly states the tool's function: 'Validate whether a phone number is in service.' This is a specific verb+resource combination that distinguishes it from siblings 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 provides clear context on when to use the tool (to validate phone numbers) and gives specific input format instructions for domestic and overseas numbers. However, it does not explicitly mention alternatives or when not to use this 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 declare readOnlyHint=true and openWorldHint=true, so the read-only nature is already known. The description adds the cost note '[호출당 10포인트]' (10 points per call), which is an important operational constraint not found in annotations. It also mentions the tool checks a report database, giving some behavioral context. It doesn't describe output format, but with annotations covering safety, this is adequate.

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 extremely concise—three short sentences in English and Korean that cover purpose, use cases, and cost. It front-loads the core function and wastes no words. The bilingual repetition is unnecessary 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?

Given the tool's simplicity (1 parameter, no output schema), the description covers purpose, use cases, and cost. It does not mention what the output looks like (e.g., boolean or report details), but for a simple spam-check tool this is a minor gap. The annotations and schema cover safety and parameter format, so overall it is fairly 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%: the only parameter 'number' has description '전화번호 (예: 01012341234)' (phone number with example). The description adds no extra detail about the parameter beyond what the schema already provides. The baseline for high schema coverage is 3, and the description does not elevate it further.

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

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

The description clearly states the tool's function: 'Check whether a phone number has been reported for spam, advertising, or criminal use in Korea.' It uses a specific verb and resource, and is distinguishable from sibling tools like check_phone_valid (which likely validates number format). The Korean phrase repeats the same purpose, reinforcing clarity.

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 contexts for use: '수신 전화 필터링, 이상 거래 탐지 등에 사용합니다' (used for incoming call filtering, abnormal transaction detection, etc.). This gives practical guidance on when to invoke the tool, though it does not explicitly mention alternatives or exclusions. It does not name sibling tools, so it misses a clear 'when not to use' but still offers solid 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 and openWorldHint, so the read-only nature is covered. The description adds the cost (40 points per call) and confirms it returns profile and video info, but does not disclose behaviors like response limits, error handling, or whether it performs actual scraping. With annotations present, this is acceptable 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 concise, with a front-loaded English sentence followed by a Korean translation and a cost note. It is efficient but slightly redundant due to the bilingual repetition; still, all information is relevant and no fluff 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 low-complexity tool with one parameter and no output schema, the description adequately states what is returned (channel profile and latest videos). It could be more complete by specifying the number of videos or response format, but the cost note and annotation hints provide reasonable 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%, and the only parameter (user_id) is already clearly described in the schema with an example ('CNN'). The tool description does not add further parameter-level meaning, so the baseline of 3 applies.

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

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

The description clearly states the tool collects a YouTube channel profile and its latest uploaded videos. It uses a specific verb ('Collect') and resource, and naturally distinguishes itself from sibling tools like download_youtube_video, which focuses on downloading a video rather than gathering channel-level information.

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: use this tool when you need a YouTube channel's profile and recent uploads. However, it does not explicitly mention when not to use it or name alternatives, so 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 provide readOnlyHint=true, so safety is covered. The description adds the fact that the tool 'converts and returns' the PDF, and specifies a per-call point cost, which is useful behavioral context regarding return and pricing. 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?

Description is short and front-loaded with the main action. However, it repeats the same information in English and Korean ('DOCX파일을 PDF파일로 변환'), causing slight redundancy, and the allowed-format line echoes the schema.

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?

Tool is simple with one parameter and good schema coverage, but there is no output schema and the description does not specify the structure of the returned PDF (e.g., file URL, base64, etc.). It only says 'converts and returns,' leaving a gap for agents unsure about output format. Cost and format constraints are covered, but return semantics are incomplete.

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 docx_url is fully documented in the schema with URL type, allowed MIME, and max size (100% coverage). The description only restates that DOCX files are allowed, adding no new 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?

Description clearly specifies the conversion action: 'Convert a DOCX (Word) file to a PDF file.' This distinguishes it from sibling tools like pdf_to_docx and pdf_to_image by naming the exact source and target formats.

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

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

Gives clear context for when to use the tool (any DOCX to PDF conversion). States a constraint: 'Only DOCX format files are allowed,' which implies not to use for other formats. However, it does not explicitly name alternative tools for other use cases.

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 annotations (readOnlyHint, openWorldHint), the description adds important context: it returns MP4, fails on non-public/blocked posts, and charges 3 points per call. This helps the agent understand cost and failure behavior without contradicting 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 English action sentence. The Korean sentence adds the failure condition and cost, but it does repeat some of the same info. Still, it earns its place without being overly verbose.

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

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

For a simple one-parameter tool with no output schema, the description covers the core functionality, return format, and an important failure case. It does not specify how the MP4 is returned (e.g., binary vs path) or handle edge cases like size limits, but for this complexity it is fairly 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 url parameter already includes an example. The description does not add extra meaning beyond the schema, 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 action: downloading a publicly available YouTube video and returning it as an MP4 file. It distinguishes from siblings by specifying the MP4 output and the public-only constraint, making it unambiguous.

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

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

The description implies usage (when you need a YouTube video as MP4) and notes that private/blocked videos will fail, but it does not explicitly mention alternatives such as video_to_mp3 for audio or crawl_youtube for metadata. No clear when-not-to-use or alternative suggestions are 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 declare readOnlyHint=true, and the description adds useful context: it returns a PNG image, supports PNG/JPEG/etc., allows adjustments to size/color/opacity/density, and costs 10 points per call. This goes beyond the annotation by disclosing output format and operational details, though it does not explicitly state that the original image remains unchanged (which might be implied by 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 description is two sentences (plus a cost note), front-loaded with the primary action in English and Korean, then details. Every sentence contributes: statement of function, output format, adjustable properties, supported formats, and cost. No fluff or redundancy.

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

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

Given the tool has 6 parameters and no output schema, the description covers the essential context: what it does, what it returns (PNG), supported input formats, and adjustable attributes. It also notes the cost. It could be more complete by mentioning the https URL requirement or that image_url must be a downloadable link, but those are in 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 all six parameters. The description mentions font size, color, opacity, and density, which mirrors schema fields, but adds no extra semantic meaning beyond what the schema provides. 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 'Draw a visible text watermark across an image' and specifies that it returns a PNG image with the watermark inserted. This distinguishes it from the sibling tool draw_watermark_pdf by explicitly focusing on image files and listing supported image formats.

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 watermarking images but does not explicitly contrast with alternative tools like draw_watermark_pdf or provide when-to-use/not-use guidance. The supported formats and mention of 'image' give some context, but no direct exclusions or alternatives are stated.

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

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

Annotations provide readOnlyHint=true, and the description adds that it returns a new PDF ('PDF 를 반환합니다'), supports adjustable attributes (size, color, opacity, angle, density, area), restricts input to PDFs, and costs 10 points per call. These details are consistent with the annotations and provide additional behavioral context.

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

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

The description is short and front-loaded with the primary action. However, the English and Korean sentences are redundant (both state watermarking across every page of a PDF). The additional cost note is useful, but the duplication slightly detracts from conciseness.

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

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

For a 9-parameter tool with no output schema, the description covers the core behavior, return type (PDF), input restriction, adjustability, and cost. It does not elaborate on error cases or authentication, but the schema and annotations fill most gaps, making it complete enough for a PDF watermarking 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 descriptions cover all 9 parameters with ranges and defaults, so the baseline is 3. The description mentions adjustable attributes (글자 크기·색상·투명도·각도·밀집도·적용 영역) but does not add any syntax or format details beyond what the schema already provides.

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

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

The description clearly states the tool draws a visible text watermark across every page of a PDF file and returns the modified PDF. The action (draw) and resource (PDF) are specific, and the mention that only PDF format is allowed distinguishes it from image watermarking 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?

The description gives clear context: it is for PDF files, and explicitly states that only PDF format is allowed ('PDF 형식의 파일만 허용됩니다'). However, it does not mention alternative tools (e.g., draw_watermark_image) for non-PDF inputs, so explicit when-not/alternative guidance is absent.

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 aligns with that by describing a non-mutating operation. It adds behavioral context about regular interval extraction and ZIP return format, plus a point cost, but does not detail error handling or processing limits beyond the 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 concise, with two sentences (English and Korean mirroring) plus a point cost, all relevant to the tool's function. It front-loads the core action and earns its 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?

Given the schema covers parameters and the description explains the output as a ZIP file, the tool is adequately characterized. No output schema exists, but the description's mention of ZIP return covers the essential output. Minor gaps like processing time are not critical.

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 has rich descriptions for all three parameters (count range, width range, video_url constraints), so the description doesn't need to add parameter semantics. 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 clearly states a specific verb-resource pair: 'Extract preview thumbnail images from a video at regular intervals and return them as a ZIP file.' This distinguishes from siblings like video_to_mp3 or download_youtube_video by focusing on thumbnail extraction.

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

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

The description provides clear context for when to use the tool (extract preview thumbnails) but does not mention alternatives or exclusions, nor does it give guidance on choosing between this and similar video tools. The point cost is noted but not framed as usage 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, indicating this is a safe, non-destructive operation. The description adds valuable behavioral context by specifying the output format (JPEG), per-call cost (20 points), and supported image formats (PNG, JPEG, etc.), which are not covered by annotations. 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 short and front-loaded with the purpose, but it contains redundancy: the first sentence in English and the second sentence in Korean essentially say the same thing. The third sentence provides useful format and cost information. A leaner version could combine the purpose into one sentence without losing meaning, making the current structure slightly less 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?

Even without an output schema, the description explains that the tool returns a JPEG image with faces blurred, which is the core return value. It also mentions supported input formats and the cost per call. For a relatively simple transformation tool, this is adequate, though edge cases (e.g., no faces found, invalid URL) are not addressed.

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 provides detailed descriptions for both parameters (image_url with format and size limits; threshold with range, default, and sensitivity meaning). Schema coverage is 100%, so the description does not need to add parameter details. It does not add any parameter-specific information beyond what the schema already offers, 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 tool's function: 'Detect faces in an image and blur (mosaic) them.' It specifies the resource (image) and the action (detect and blur), and it distinguishes itself from similar sibling tools like face_detection by mentioning blurring/mosaicking. The return format (JPEG) is also mentioned.

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 functional context—use this tool when you need to blur or mosaic faces in an image. It does not explicitly name alternatives or exclusions, but the purpose is specific enough that an agent can infer when to use it versus face_detection or other image tools. The lack of explicit 'when not to use' guidance prevents a higher score.

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 agent knows it's a safe read operation. The description adds useful behavioral context: a cost of 3 points per call and that setting use_feature=1 returns additional face feature information. 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 concise, with the primary action front-loaded in English and cost noted at the end. The English and Korean sentences repeat the same content, creating minor redundancy, but overall it 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?

Despite no output schema, the description explains that coordinates are returned and that features are optionally included, but it lacks detail on response structure. It also omits image-format or size limitations, which are present in the schema, and does not mention error scenarios. Given tool complexity, this is adequate but leaves gaps.

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

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

The input schema has 100% coverage, documenting all three parameters with descriptions. The tool description repeats the use_feature behavior but does not add substantial new meaning beyond the schema. 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 starts with 'Detect faces in an image and return their coordinates,' which is a specific verb+resource statement that clearly distinguishes the tool from siblings like person_detection or face_blur. The additional mention of optional face feature info further clarifies its 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 implies usage for face detection in images but provides no explicit guidance on when to prefer this over siblings (e.g., person_detection, face_blur) or when not to use it. The use_feature flag is explained but not in the context of alternative 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?

With readOnlyHint=true and openWorldHint=true annotations already declaring the safety profile, the description adds the cost aspect ('[호출당 10포인트]' = 10 points per call) and the query scope (flood history by VIN/plate). This gives useful operational context beyond the annotations, though it does not detail response format or rate limits.

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 purpose, then the Korean equivalent, then the use case and cost. Slight redundancy exists from bilingual repetition, but every sentence serves a purpose and the cost note is placed at the end without 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 simple read-only lookup with robust annotations and full schema coverage, the description provides all essential context: what the tool does, how to invoke it (by type/value), and when to use it. The lack of an output schema is mitigated by '~여부' (whether or not) implying a yes/status response, which is adequate.

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 describes both parameters (type: 1=VIN, 2=plate; value: VIN or plate number). The description mentions 'by VIN or license plate' but adds no syntax, constraints, or default behavior beyond the schema. Baseline 3 is appropriate given the 100% 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 a specific action—'Check whether a Korean vehicle has a flood damage record'—with explicit input methods (VIN or license plate). This uniquely distinguishes it from sibling tools like get_car_scrap, which covers scrap history rather than flood records. The bilingual title and description reinforce 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?

The description includes a concrete use case—'중고차 구매 전 확인 등에 사용합니다' (used for checking before buying a used car)—which helps an agent know when to select this tool. It does not explicitly contrast with alternatives like get_car_scrap, but the context is clear enough for a straightforward lookup 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 mark readOnlyHint=true, so the description adds value by stating this is a lookup/조회 operation and disclosing the cost '호출당 10포인트' per call. It does not describe output format, but the read-only, inquiry nature is clear.

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

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

The description is compact, with an English sentence, a Korean equivalent, a use-case line, and a cost note. Minor redundancy exists with the bilingual repetition, but every part adds useful context and no filler 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 simple two-parameter lookup with readOnlyHint, the description is sufficiently complete: it states the purpose, input types, and cost. It does not explain the return format, but the word '여부' (whether or not) implies a boolean-like result, and no output schema exists to require further detail.

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

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

Schema coverage is 100%, so the schema already fully documents the type and value parameters. The description adds only a high-level mention of VIN or license plate, which does not materially surpass the schema's detailed Korean descriptions.

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 checks whether a Korean vehicle has a scrap/total-loss accident record by VIN or license plate. It uses a specific verb ('Check') and names the resource ('Korean vehicle scrap/total-loss record'), which distinguishes it from sibling tools like get_car_flooding.

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

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

Provides a clear use case: '중고차 구매 전 확인 등에 사용합니다' (used for checking before purchasing a used car). This gives helpful context, though it does not explicitly mention when not to use it or name alternative 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?

The description adds behavioral details beyond annotations by disclosing the cost ('[호출당 30포인트]') and the dependency on an SMS verification code from a prior step. This complements the annotations (readOnlyHint=false, openWorldHint=true) 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 concise, with an English lead sentence followed by Korean details and a cost note. It is slightly redundant due to bilingual repetition, but remains compact and front-loaded with the core purpose.

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

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

The tool is simple with two parameters and no output schema. The description covers the purpose, input prerequisites, and the retrieval flow, implying the result is the PCCC. It is complete enough for an agent to invoke correctly, though it does not describe the return format or error handling.

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% coverage with clear descriptions for both parameters (auth_key from req_pccc response, answer as the 6-digit SMS code). The description largely restates these semantics without adding new parameter-specific 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 clearly states the tool's function: 'Retrieve a Korean Personal Customs Clearance Code (PCCC)' with a specific verb and resource. It also references the req_pccc tool as the source of auth_key, distinguishing this retrieval step from the authentication request step.

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

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

It provides explicit prerequisite context: the auth_key is obtained from calling the req_pccc Tool, and the answer is the 6-digit SMS verification code. This indicates when to use the tool, though it does not explicitly state alternatives or exclusions (e.g., check_pccc).

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. The description adds valuable context beyond that: returns JSON, works despite partial image transformations, supports PNG/JPEG, and costs 10 points per call. 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 concise and front-loaded with the core purpose, followed by supporting details (return format, robustness, formats, cost). Every sentence adds value; bilingual duplication is acceptable for broader accessibility.

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 single-parameter read tool with no output schema, the description is thorough: it explains what it does, what it returns (JSON), supported formats, robustness characteristics, and cost. No critical information is missing for an agent to decide to use it.

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

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

Input schema fully describes image_url (https URL, allowed formats, max size). The description only repeats 'PNG, JPEG' which is a subset of the schema's allowed formats. No additional semantic meaning is provided 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 clearly states the tool reads invisible watermark codes from images, distinguishing it from sibling tools like set_watermark and draw_watermark_image. The verb 'Read' and resource 'invisible watermark code' are specific 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 provides clear context: it is for reading watermarks from images, supports common formats, and notes robustness. However, it does not explicitly mention alternatives or exclusions (e.g., 'use set_watermark to insert'), so it lacks explicit when-not-to-use 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 agent knows this is a safe read operation. The description adds value by specifying the exact return fields (image URL, source link, title) and the paging behavior, which is not fully covered by the schema. The cost note ('[호출당 5포인트]') also provides operational context. 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, with an English sentence followed by a Korean equivalent and a brief cost note. The bilingual repetition is slightly redundant for an English-centric agent but not excessive. Information is front-loaded and every component serves a clear purpose.

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

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

Given the lack of an output schema, the description adequately covers the return values (image URL, source link, title) and paging behavior. For a simple two-parameter search tool, this is sufficient contextual information. It does not mention edge cases (e.g., empty results, rate limits), but those are not critical for basic usage.

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 'keyword' and 'page' already described in the input schema. The description's mention of paging ('page 로 결과 페이지를 넘겨 가며 조회할 수 있습니다') adds slight emphasis but no new semantic information beyond what the schema provides. Baseline of 3 is appropriate when the schema handles 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 the tool's function: 'Google image search by keyword: return image results (image URL, source link, title).' It specifies the verb (search/return), the resource (Google image search), and the output fields. This distinguishes it from sibling tools like google_search (web search) and google_lens_search (image-based search), even without naming them 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 provides clear context for when to use the tool: to retrieve Google image search results for a specific keyword, with the ability to paginate via the 'page' parameter. It does not explicitly mention alternatives or exclusions, but the tool's purpose is so specific that an agent can easily infer when to select it over siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable context: it costs 40 points per call and only accepts image file formats (JPEG, PNG, WebP, GIF, BMP as per schema). This goes beyond the annotations without contradicting them, giving the agent useful operational details.

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: the first line states the core purpose ('Reverse image search'), followed by a Korean version. It includes the cost notice and format restriction in two short sentences. The bilingual repetition is slightly redundant but does not detract from 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?

For a low-complexity, read-only tool with a single parameter and no output schema, the description covers the essential context: what it does, what results to expect (matching web pages and labels), input format constraints, and cost. The annotation openWorldHint also signals external network usage, making this effectively complete.

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

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

The input schema covers the single parameter (image_url) with a full description of allowed formats and size limit (100% coverage). The description reiterates that an image is uploaded and only image files are allowed, but adds no new semantic information beyond what the schema already 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 opens with 'Reverse image search: upload an image and get visually matching web pages and labels.' This is a specific verb+resource combination that clearly states the tool's function. It distinguishes itself from typical text-based search tools, though it does not explicitly name siblings like google_image_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 when to use this tool: when you have an image file and want to find visually matching web content. It also notes that only image formats are allowed, but this is more of an input constraint than a tool-selection guideline. There is no explicit mention of 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 indicate readOnlyHint, and the description adds important context: cost per call (5 points) and pagination behavior. This goes beyond the structured metadata, though it does not cover potential rate limits or result caps.

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

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

The description is compact, with no wasted words. It states purpose, output fields, pagination, and cost in two short sentences, making it easy to scan.

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

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

For a simple tool with two parameters and no output schema, the description adequately covers what it returns (link, title, snippet), how to paginate, and cost. It does not elaborate on response structure, but that is not required given the simplicity and inherent web search 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?

The schema provides 100% coverage for both parameters. The description adds behavioral meaning to the 'page' parameter by explaining it allows paging through result pages, which is valuable beyond the schema's basic description.

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

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

The description explicitly states it performs a 'Google keyword search' and returns web search results (link, title, snippet). The verb 'search' and resource 'Google' are specific, and it distinguishes itself from sibling tools like google_image_search and google_lens_search by focusing on keyword-based web results.

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 usage for keyword-based web search, mentioning pagination via 'page'. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls slightly 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 include readOnlyHint=true, which already signals no side effects. The description adds behavioral details: it recognizes RRNs via image processing, requires both image and type, and notes a cost of 20 points per call. This goes beyond annotations but could mention failure cases or output format for a 5.

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 redundant, repeating the same sentence in English and Korean ('Mask resident registration numbers...' vs '이미지에서 주민등록번호를 인식해...'). This wastes space. The other details (type explanation, legal notice, cost) are useful, but the bilingual duplication hurts 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?

For a tool with no output schema, it adequately explains the return value (masked image), the required inputs, the cost, and legal prerequisites. It does not mention edge cases (e.g., no RRN found), but overall it is complete enough for the task.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the type options and mentions that both image and type are required, adding little beyond the schema. No new parameter semantics are provided.

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

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

The description clearly states the tool's function: 'Mask resident registration numbers found in an image and return the masked image.' It specifies the resource (resident registration numbers in images) and the action (masking), and is distinct from sibling tools like face_blur or watermark 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 provides a clear usage context (masking RRNs in images) and a strong legal condition ('Use only if you have secured a legitimate processing basis such as the data subject's consent'). However, it does not explicitly mention when not to use it or alternatives, 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?

The annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds a cost note ('[호출당 3포인트]' – 3 points per call) and implies a lightweight query. It does not contradict the annotations, and the additional cost info is useful beyond the structured metadata.

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 extremely concise, front-loaded with the core purpose, and each sentence provides value: the English summary, a Korean translation for accessibility, use-case context, and a cost hint. No redundancy or fluff.

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

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

This is a simple two-parameter read-only tool with no output schema. The description adequately conveys the tool's purpose and scope, and with the schema and annotations, an agent has enough context to invoke it correctly. It could be improved by stating the return format (e.g., list of holiday names and dates), but given the low complexity, the current level 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 schema provides 100% coverage for both parameters (year and month), including ranges and examples, so the description has little to add. The description only rephrases 'given year and month' without offering additional format or behavior insights. This is at the baseline 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 clearly states the tool's function: 'Look up Korean public holidays for a given year and month.' This is a specific verb (look up) + resource (Korean public holidays) with a defined scope (year/month). It also mentions intended use cases (business day calculation, schedule management), which helps differentiate it from sibling lookup tools like bank_code or land_rt_price.

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

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

The description provides clear context for when to use the tool: '영업일 계산, 일정 관리 등에 사용합니다' (used for business day calculation, schedule management, etc.), implying the tool is appropriate for scheduling and business-day-related tasks. However, it does not explicitly mention alternative tools or conditions for when not to use it, so it lacks explicit exclusions.

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 beyond annotations: it specifies the output is a PDF file and notes a per-call cost ('호출당 30포인트'), which is a rate-limit style detail. 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, but it repeats the same English and Korean content in nearly identical sentences. The cost note is valuable and compact, though the redundancy prevents 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?

With only 2 params, full schema coverage, and no output schema, the description adequately covers purpose and return type ('변환된 PDF 파일을 반환'). It does not mention pagination, but the schema handles that. Overall complete for a simple conversion 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 description coverage is 100%, as both html and pagination parameters have descriptions. The tool description does not add meaning beyond the schema beyond restating that HTML is a string, 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 'Render HTML code into a PDF file', specifying both the verb and the resource. It distinguishes this tool from siblings like docx_to_pdf or pdf_merge by focusing on HTML input, making its purpose unambiguous.

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

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

The description implies usage for raw HTML strings via 'HTML 문자열을 입력하면' but does not explicitly state when to use this tool versus alternatives like url_screenshot or url_html. No exclusions or alternative tool mentions are provided, so guidance is only 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 declare readOnlyHint=true, but the description adds meaningful behavioral context: legal basis requirement, cost (40 points per call), and field requirements. This goes beyond what annotations convey 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 and front-loaded with the main purpose. Some redundancy exists due to bilingual repetition and restating schema-required fields, but it remains efficient and well-structured.

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?

Includes important legal and cost context, but with no output schema, it does not describe the return value or result format. Given the tool's simple verification purpose, this is a moderate 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%, with each parameter already described (name, rrn1, rrn2, date). The description repeats the all-required and date-format constraints but adds minimal new semantic value 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 clearly states a specific action ("Verify the authenticity of a Korean resident registration card") and specifies the input mode ("using text input"), distinguishing it from image-based sibling tools. Both English and Korean reinforce the same purpose.

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

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

Provides explicit preconditions: all four fields must be entered, date must be numeric, and it requires legal processing grounds (consent). However, it does not explicitly contrast with alternatives like identi_card_image1 or identi_card2, though the 'text input' phrase implies a text-only use case.

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, but the description adds significant context beyond that: it mandates legal consent/processing grounds and notes a per-call point cost. It does not describe the response format or error behavior, but the added legal and cost information goes beyond annotation coverage.

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 and compact, but the English and Korean opening sentences are redundant restatements of the same idea. The detailed field enumeration also duplicates schema information. Some trimming would make it more concise and 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?

No output schema is provided, so the description should explain what the verification response contains (e.g., a boolean or detailed result), but it only says '진위 여부를 확인합니다' without clarifying the return structure. Input requirements are well covered, but the missing output semantics make the description incomplete for an agent to interpret results 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 baseline is 3. The description groups required fields (birth_y/m/d, name, licen_no0-3) and optional fields (ghost_num, rrn1, rrn2) and explains the license number sections, but this largely mirrors the schema's own descriptions. It adds little new semantic meaning beyond what the structured schema already provides.

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

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

The description uses a specific verb 'verify' and explicitly names the resource: 'authenticity of a Korean driver license using text input.' This distinguishes it from image-based sibling tools like identity_document_driver_license and identi_card_image* tools by emphasizing textual input.

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

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

Clear context is provided: this tool is for text-based verification of Korean driver licenses, and it requires a legal processing basis such as consent. It does not explicitly exclude other tools or name alternatives, but the text-input scope and legal requirement sufficiently clarify when 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 declare readOnlyHint=true, and the description adds context about mandatory fields, date format restrictions, legal consent requirements, and a per-call cost. It does not describe output behavior, but the read-only nature is already annotated and the description provides sufficient safety and processing context.

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

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

The description is reasonably concise, with bilingual text that reiterates the same core message, a clear example, and a cost note. It is front-loaded with the verb and resource, and each sentence serves a purpose, though the bilingual duplication 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?

The tool has a simple input schema and no output schema, so the description should ideally explain the return value/confirmation format. It does not, and it also omits details about what happens on failure or how the authenticity result is presented. The legal and cost context is valuable, but the lack of output information leaves a gap for agent 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?

All five parameters are fully documented in the schema with descriptions and format examples. The description recaps the requirement that all fields must be entered and dates are numeric, but this is redundant with the schema's required array and property descriptions. Thus parameter semantics are adequately covered by the schema, and the description adds minimal new 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 clearly states the tool verifies the authenticity of a Korean passport using text input, distinguishing it from image-based or other document verification tools. The title and description align, making the purpose 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?

It specifies that all five fields must be provided and gives a clear legal prerequisite (consent/legitimate basis). However, it does not explicitly name alternative tools for other document types or mention when not to use it, so it is clear but lacks exclusions.

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 adds useful context beyond the readOnlyHint: it mentions a cost of 40 points per call and a legal compliance requirement. This is extra behavioral information without contradicting the annotations. It does not describe the return format or failure behavior, but annotations already cover the read-only nature.

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 primary purpose, followed by parameter and legal details. There is some English/Korean redundancy, but it remains scannable and each sentence adds 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 simple verification tool with no output schema, the description covers purpose, required parameters, legal basis, and cost. However, it does not explain what the tool returns (e.g., whether it returns a boolean or detailed result) or how errors are handled, which is a notable gap given the lack of an output schema.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description reiterates the schema's information (required fields, type meanings, optional name) without adding new semantic detail, so no score above baseline is earned.

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 resource 'Korean resident registration certificate', and specifies the input method 'text input'. This distinguishes it from image-based sibling tools like identi_card_image1, making its purpose 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 a clear legal usage condition ('only when there is a lawful basis such as consent') and lists required/optional parameters, which are helpful. However, it does not explicitly compare with alternative tools (e.g., identi_card_image1 or identity_document_*), providing only implied differentiation via 'text input'.

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 adds value by disclosing the cost per call (40 points) and the need for legitimate processing grounds. No contradiction with annotations.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description provides specific usage context: required fields, digit constraints, conditional requirement for card_sn, and the legal basis for use. However, it does not explicitly compare with alternative tools or state when not to use it.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the bar is lower. The description adds useful behavioral context by requiring legal consent, mentioning the per-call cost, and emphasizing that only one file is needed. It does not contradict the annotations, and it provides more than a bare read-only claim, justifying a 4.

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

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

The description is concise and front-loaded with the core purpose. Some redundancy exists between the English and Korean sentences, but each sentence contributes practical information (input, legal condition, cost). It is not overly long, and the structure is acceptable.

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

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

The tool is simple with only one parameter and no output schema. The description covers the input type, purpose, legal restriction, and cost. It does not specify the return format, but for a single-purpose verification tool, this is a minor gap. Overall, it is complete enough for an agent to invoke 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 provides full coverage of the single parameter (image_url) with format and size constraints. The description reinforces that only a single file is needed, but does not add significant new meaning beyond the schema. Baseline 3 applies because schema coverage is 100%.

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 'Verify the authenticity of a Korean resident registration card from an image or PDF file.' The verb 'Verify' and resource 'Korean resident registration card' are specific, and the focus on image/PDF distinguishes it from sibling tools like identi_card1 (likely text-based) and other identity document verifiers.

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

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

The description provides clear usage context: for checking authenticity via uploaded image/PDF files, with no text input required. It also gives an important exclusion: 'Use only when you have secured a legitimate processing basis such as the data subject's consent.' However, it does not explicitly compare to alternatives or state when not to use it relative to other identity verification tools, 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, so the agent knows this is a safe, read-only operation. The description adds useful behavioral context beyond annotations: it automatically recognizes inscribed information, requires a legal basis, and notes a per-call cost of 60 points. This enhances transparency without contradicting the read-only hint.

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

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

The description is concise, with the main purpose in the first sentence and additional legal/cost details in a few short sentences. The bilingual repetition is somewhat redundant, but it remains compact and easy to parse. No filler or irrelevant information.

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 readOnlyHint and openWorldHint annotations, the description covers the essential aspects: purpose, input type, legal requirement, and cost. It does not describe return format, but that is not expected given the simple nature and lack of an output schema. No significant gaps.

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

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

The input schema fully describes the single parameter image_url, including allowed formats and size limit (100% schema coverage). The description adds little beyond the schema, merely repeating that the input is an image/PDF file. Since the schema handles semantics, a 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 its purpose: 'Verify the authenticity of a Korean driver license from an image or PDF file.' This uses a specific verb ('verify'), names the resource ('Korean driver license'), and distinguishes it from sibling tools like identi_card_image1 or identity_document_id_card, which handle other documents.

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: it accepts a single image/PDF file, no text input, and requires a legal basis such as consent. It does not explicitly mention alternatives or when not to use, but the document-type specification provides sufficient guidance for most cases.

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 agent knows it is a read-only operation. The description adds useful behavioral context: it requires legal processing grounds, incurs 60 points per call, and accepts a single file (image/PDF) without text input. It does not detail return format or error behavior, but this is not required given the simple nature of the 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 three sentences, bilingual, with each sentence providing distinct, essential information: purpose, input requirements, and legal/cost constraints. It is front-loaded with the primary purpose and avoids repetition of schema details.

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 with no output schema, the description covers the essential aspects: the exact function, input format, legal prerequisite, and cost. The only minor gap is not explicitly describing the output format (e.g., boolean vs detailed result), but the purpose implies a verification outcome, making the description complete enough for the tool's simplicity.

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

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

The input schema has 100% coverage for the single parameter image_url, so the baseline is 3. The description adds semantic value by specifying the expected content (passport personal details page) and clarifying that only one file is needed, which helps the agent understand what URL to provide. It also matches the schema's accepted formats (jpeg, png, pdf).

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

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

The description clearly states the tool verifies the authenticity of a Korean passport from an image or PDF file using the verb 'verify' and resource 'Korean passport'. It distinguishes from sibling tools by specifying the input type (image/PDF) and the specific document (passport), which aligns with the title 여권 진위 확인.

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: use when you have an image/PDF of a Korean passport and need authenticity verification, with no text input required. It also includes a legal prerequisite (obtaining consent), which is a when-to-use condition. However, it does not explicitly mention when not to use this tool compared to similar sibling tools like identity_document_passport.

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 useful behavioral context: it automatically recognizes the document verification number and other details to check authenticity, notes a per-call cost, and imposes a legal-use condition. It does not, however, mention the format of the returned verification result.

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 stays compact. The English and Korean sentences are partly redundant, but each adds useful info (file-only, legal basis, cost), so it is concise without being wasteful.

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 tool, the description covers the main usage, legal requirement, and cost. However, with no output schema, it fails to specify the exact return value or structure (e.g., boolean vs. detailed result), leaving a notable gap for an authenticity-check 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 input schema fully documents the single image_url parameter with allowed formats and size limit (100% coverage). The description only indirectly references the parameter (image/PDF file, no text input), adding no new parameter-specific 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 clearly states the tool verifies the authenticity of a Korean resident registration certificate (주민등록등본) from an image or PDF, with a specific verb and resource. The title and description together distinguish it from sibling identity-document tools, which handle other document types.

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

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

It provides clear usage context: a single file without text input is sufficient, and it should only be used when legal grounds such as consent are secured. However, it does not explicitly contrast with sibling tools or exclude cases, so it stops short of a 5.

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

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

With readOnlyHint=true, the bar is lower. The description adds valuable context: the conditional card_sn requirement, the legal processing basis, and a per-call cost of 60 points. It does not describe failure modes or detailed response format, but the added context goes beyond 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, followed by Korean translation and key instructions. The bilingual repetition adds length but is useful for a Korean-focused tool. Each sentence conveys necessary information, with no wasteful 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?

The tool has no output schema and the description does not explain what the verification result looks like or potential error cases. It also does not differentiate among several similarly named sibling tools, leaving some ambiguity in selection. The essentials are covered, but gaps remain.

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 repeats the card_sn condition already present in the schema and adds no additional parameter meaning beyond it. There is no supplementary guidance for image_url or card_sn formats beyond what the schema 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 clearly states the tool verifies the authenticity of a Korean alien registration card from an image or PDF, with a specific verb and resource. It does not explicitly differentiate from sibling tools like identi_card_image1-4 or identity_document_residence_card, but the input scope is well-defined.

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: use when you have an image/PDF of an alien registration card, with a note that card_sn is required for cards issued after 2011-01-01 and that legal consent is needed. However, it does not mention alternatives or explicitly state when not to use this tool.

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

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

Beyond the readOnlyHint annotation, the description discloses the output format (masked_image field as base64), input constraints (PNG/JPEG, single image), and the need for legal consent. It does not cover error or timeout behavior, but the annotations already establish the read-only nature.

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 English purpose statement, but the Korean translation repeats the same content verbatim, creating redundancy. The cost note adds utility but increases length, making 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 single-input document processor with no output schema, the description explains the return of a masked image and the extraction of fields, though it does not enumerate the specific fields extracted. This is reasonably complete given the tool's simplicity and the presence of related sibling tools.

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

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

The schema provides 100% coverage for the single image_url parameter, describing it as an https URL with format and size restrictions. The description echoes this input constraint but adds minimal additional meaning beyond what the schema already documents.

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

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

The description clearly states the tool's function: 'Extract key fields from a Korean driver license image and mask the last 6 digits of the RRN.' This specific verb+resource+action distinguishes it from sibling tools like identity_document_id_card and identity_document_passport, which target different document types.

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

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

Provides clear context for use: accepts a single PNG or JPEG image and requires legal grounds for processing. However, it does not explicitly mention when to use this tool over alternatives, though the specific focus on driver licenses implicitly delineates its scope.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds valuable behavioral details: the output format (masked_image field with base64) and the legal consent requirement. This helps the agent understand the tool's side effects and constraints beyond the structured annotations, with no contradiction.

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

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

The description is bilingual, with Korean repeating the English content, causing redundancy. It is front-loaded with the primary purpose, but the repeated information in two languages makes it longer than necessary without adding substance.

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

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

The description covers the input, output location, and legal consent requirement, but it does not enumerate the 'key fields' being extracted or discuss error handling. Given the absence of an output schema, these details would improve completeness, though the tool is simple enough that 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?

The input schema already covers the parameter semantics fully (image_url with allowed formats and max size), achieving 100% schema description coverage. The description's mention of PNG/JPEG and a single image is redundant with the schema, so it adds no new parameter-level 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 clearly states a specific action: extracts key fields from a Korean resident registration card and masks the last 6 digits of the RRN. It distinguishes from sibling tools by naming the exact document type (주민등록증) and the masking operation, making it easy for an agent to select the correct tool.

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

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

The description provides clear usage context: it specifies that a single PNG or JPEG image should be passed, the masked image is returned in the masked_image field, and it includes a strong when-not condition by requiring legal processing basis (e.g., consent). However, it does not explicitly name alternative tools for other ID types, so it stops short of a 5.

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

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

Annotations already indicate readOnlyHint=true, and the description adds valuable context beyond that: input format requirements, the need for MRZ lines, output location (masked_image field with base64), and legal/consent requirements. This substantially elevates behavioral understanding without contradicting 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 two sentences plus a legal note, with the English summary front-loaded and Korean details following. Every sentence adds useful info (input, output, legal basis, cost), with no filler or 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?

Covers input requirements, output, and legal constraints well for a single-parameter tool. However, it does not enumerate the specific 'key fields' extracted from the passport, leaving ambiguity about the JSON response content beyond masked_image. Without an output schema, the description should specify these fields for full completeness.

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 documents image_url with type, format, and size limits. The description adds crucial constraints beyond the schema: the image must be a single PNG/JPEG and must contain two MRZ lines. Since schema coverage is 100%, the added semantic detail earns a 4.

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

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

The description clearly states the tool extracts key fields from a passport image and masks the passport number and MRZ area. This is a specific verb+resource+scope that distinguishes it from sibling identity document tools (driver's license, ID card, residence card) by explicitly targeting passports.

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

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

Provides clear context: use with a single PNG/JPEG image containing two MRZ lines, and only with legal basis (e.g., consent). However, it does not explicitly name alternative tools for other identity document types or state when not to use this 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?

Beyond the annotations (readOnlyHint=true, openWorldHint=false), the description discloses specific behavioral details: it masks the last 6 digits, returns the masked image in JSON as base64 in the masked_image field, and includes a legal prerequisite. This adds significant value over the annotations alone.

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 is well-organized. The bilingual repetition (English followed by Korean) adds length but is reasonable for the target audience. The cost note in brackets is extraneous but acceptable.

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

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

There is no output schema, so the description compensates by explaining the masked_image field in JSON and the base64 format. It does not enumerate all extracted fields, but the primary function (masking) and input requirements are sufficiently covered for a tool of this complexity.

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

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

The schema already provides full coverage for the single parameter image_url, including format and size constraints. The description only paraphrases the format requirement ('PNG or JPEG') and adds that a single image is passed, offering marginal additional semantic value.

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

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

The description clearly states the tool extracts key fields from a Korean alien registration card and masks the last 6 digits of the registration number. The resource is specific ('alien registration card') and the verb/action is precise, distinguishing it from siblings handling other document types (e.g., driver license, 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 provides clear usage context: input must be a single PNG or JPEG image, and it should only be used when legitimate data processing grounds are secured. It does not explicitly mention alternative tools, but the sibling set makes the document-type-specific usage obvious from the name and title.

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 agent knows the operation is safe. The description adds cost per call ([호출당 10포인트]) and mentions typical use cases, but it does not clarify the similarity score format (e.g., 0-1 or 0-100) or any potential limitations, leaving some behavioral ambiguity.

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 repeats the same core statement in English and Korean, making it somewhat redundant. It could be more concise by keeping only one language or merging the duplicate phrases, though it is not excessively long.

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 comparison tool with fully documented parameters, a readOnly annotation, and a stated output (similarity score), the description covers the essential context: purpose, use cases, and cost. It lacks output schema detail but is still sufficiently complete for its complexity.

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

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

The input schema already fully describes both parameters (image_url and compare_image_url) with format, size, and HTTPS requirements, giving high schema description coverage. The tool description adds no new parameter-level details beyond what is in the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool compares a base image with another image and returns a similarity score, with specific use cases (original verification, duplicate detection). It is easily distinguished from sibling tools like url_similarity, which compares URLs.

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

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

The description provides clear usage context by mentioning common use cases (e.g., original verification, duplicate image detection). It does not explicitly exclude alternatives or state when not to use the tool, but the context is sufficient for a simple comparison tool.

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

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

Annotations already declare readOnlyHint=true, so the description's read-only nature is pre-covered. The description adds valuable context beyond annotations: it is free ('무료입니다'), tied to the current authentication key, and returns balance and status information. This is useful for an agent deciding whether to call the 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 short and front-loaded with the English sentence, making the purpose immediately clear. However, '무료입니다' and '[무료]' are redundant (both say 'free'), which is a minor waste of tokens. Still concise overall.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description adequately covers the essential aspects: what it does (checks balance/status), the scope (current auth key), and the fact that it is free. It doesn't specify the exact output format, but for such a simple info tool, this 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, so the baseline is 4. There are no parameter details to explain, and the description adds no misleading information. The schema coverage is 100%, making parameter context unnecessary.

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

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

The description clearly states the tool's purpose: checking APICK account balance and status. It uses a specific verb ('Check') and resource ('APICK account'), and the Korean text adds detail about querying remaining points and account status. This uniquely distinguishes it from all sibling 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?

The description clearly implies when to use the tool (when checking account balance/status). However, it does not explicitly mention alternatives or exclusions. Since there are no similar sibling tools, this is sufficient 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 include readOnlyHint and openWorldHint, so the description adds useful context beyond those: the operational scope (top-level domain only, subdomains excluded) and the per-call point cost. This enhances transparency without contradicting 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 brief and front-loaded with the main purpose, followed by scope constraints and cost. It includes a bilingual repetition (English and Korean), which adds a bit of redundancy but each part is meaningful for the intended audience.

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

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

This is a simple read-only tool with one parameter, no output schema, and helpful annotations. The description covers the essential information: what it does, scope limitations, and cost. It doesn't detail the return structure, but for such a straightforward lookup, the description is sufficiently complete.

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

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

The input schema has 100% coverage for the single 'domain' parameter, including an example. The description does not add additional parameter details beyond what the schema provides, so a 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 tool's function: looking up historical IP address changes for a domain. It includes the specific constraint of top-level domain scope, which distinguishes it from sibling tools like nslookup (current IP lookup) and reverse_ip.

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

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

The description provides a clear use case and explicitly states that subdomains are not tracked, which serves as a when-not condition. It does not explicitly name alternative tools, but the context of siblings and the constraints given are adequate 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 the operation as safe (readOnlyHint=true, openWorldHint=false). The description adds behavioral context by noting that the tool returns the converted file and that each call costs 1 point. It does not contradict annotations and provides useful operational details.

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

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

The description is concise, front-loads the core purpose, and includes only essential details: the conversion operation, supported formats, and the per-call cost. The bilingual repetition serves user needs and does not pad the description with unnecessary 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 2-parameter tool with no output schema, the description sufficiently covers functionality, input formats, and the fact that the file is returned. It does not mention potential file-size limits or error handling, but these are minor for this use case.

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 both parameters. The description's mention of data_list formats mirrors the schema and adds a concrete example of the expected structure, but it does not significantly extend beyond the schema. Thus, 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 the tool's function: 'Convert JSON data into an Excel (XLSX) file.' This is a specific verb+resource pair, and no sibling tool overlaps with this functionality. The bilingual phrasing reinforces the 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 description provides clear context on when to use the tool (to convert JSON to Excel) and mentions the supported data formats (object array or 2D array). It does not explicitly mention when-not-to-use or alternatives, but the absence of competing sibling tools makes this acceptable.

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. The description adds useful behavioral context: if addr1 is invalid, the response includes an options field with a list of selectable regions, and each call costs 100 points. This goes beyond the annotations without contradicting them.

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

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

The description is relatively compact, with the English and Korean versions covering similar ground. It includes essential extras (error handling, cost) without excessive fluff. Minor duplication between languages prevents a perfect 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?

The tool has 4 required parameters and no output schema, but the description adequately explains the lookup purpose, the error-handling mechanism, and the cost. It does not detail normal response structure, but for a simple read-only lookup, this 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?

Schema description coverage is 100%, so parameters are already well-documented. The description adds a small but useful note about addr1 error behavior, but does not systematically elaborate on each parameter 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 a specific verb ('Look up') and resource ('real estate transaction price records in Korea') with the key dimensions (region, property type, year). It is distinct from all sibling tools, none of which deal with real estate 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?

The description provides clear context for when to use the tool (Korean real estate transaction lookups) and even includes an error-handling hint about addr1 guiding the user to valid regions. It does not explicitly mention alternatives, but there are no close sibling tools to distinguish from.

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 declare readOnlyHint=true, but the description discloses significant behavioral traits: stateless conversation handling, the need to reuse compacted_messages for subsequent turns, and cost implications (point deduction based on token usage). These details go well beyond the annotations and inform correct usage without contradiction.

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

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

The description is front-loaded with the core purpose, followed by distinct, non-redundant information about statelessness, model lookup, and cost. The Korean translation repeats the first sentence, which is acceptable for bilingual support but adds slight redundancy; still, every other sentence 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 8 parameters, nested objects, and no output schema, the description covers the essential context: purpose, stateless protocol, model discovery, cost, and how to handle multi-turn history. It does not detail the full return structure, but for a chat tool the response type (assistant reply) is clear; the compacted_messages mention bridges the 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?

Input schema covers all 8 parameters with descriptions, so the baseline is 3. The description adds operational meaning by explaining the messages lifecycle (compacted_messages reuse), the distinction between content and messages, and model selection. This enriches 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 opens with a specific verb+object: 'Send a chat request to a selected LLM model and receive the assistant reply.' This unambiguously identifies the tool's function and differentiates it from sibling tools like llm_models (which lists models) and text processing 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 operational guidance: emphasizes the stateless server, instructs to send full history via messages, and directs users to llm_models for model discovery. It lacks explicit exclusions or 'when not to use' but provides strong context for proper 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 readOnlyHint=true, and the description adds valuable context about response contents (pricing per 1M tokens, family, size, multimodality, tags, use_cases, max_context) and notes the tool is free. This goes beyond the structured annotations, though it does not discuss potential response size or pagination.

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 mostly concise and front-loaded with the main purpose. However, it contains redundancy: the same information is repeated in English and Korean, and '무료입니다' appears alongside '[무료]', which slightly wastes space. Still, it remains an efficient single-paragraph description.

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 takes responsibility for explaining return values, which it does by listing the included fields. It also provides the integration context with llm_chat and the free status. For a 4-parameter filter tool, this is sufficiently complete, though it could mention that all filters are optional.

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?

All 4 parameters have complete descriptions in the schema (100% coverage), so baseline is 3. The description does not repeat parameter details but does contextualize the tool's purpose for model selection. No additional parameter-level meaning is added 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 clearly states the tool lists available text-generation LLM models, specifying key attributes like pricing and context length. It also explicitly ties the tool to finding model input values for llm_chat, distinguishing it from sibling 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?

Provides explicit guidance on when to use (finding model input values for llm_chat), but does not mention alternatives or exclusions. The context is clear, so it earns a 4 rather than 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?

Although annotations already declare readOnlyHint and openWorldHint, the description adds valuable behavioral context: it explains that a domain input will first be resolved to an IP before returning location, and it notes a cost of 30 points per call. This goes beyond the structured annotations and helps the agent understand resolution behavior and resource usage.

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 primary English statement, but it redundantly repeats the same information in Korean ('도메인 또는 IP의 위치(지리 정보)를 조회합니다'). The cost note is useful, but the bilingual duplication slightly reduces efficiency. Overall it is compact and readable.

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 a single parameter, no output schema, and a simple read-only operation, the description covers the main behavior and cost. However, it does not specify the format or detail of the returned geographic information (e.g., country, city, coordinates), which is relevant given there is no output schema to fill that 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?

The schema already has 100% coverage for the single 'address' parameter, including its description and example ('apick.app'). The description repeats that the input can be a domain or IP and adds the resolution behavior, but it does not meaningfully enhance the parameter semantics beyond what the schema already provides. The baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Look up the geographic location of a domain or IP address.' It includes a specific verb (look up), resource (domain/IP), and scope (geographic location). This distinguishes it from sibling tools like nslookup or whois, which serve different DNS/registration lookups.

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 what inputs are accepted ('domain or IP address') but provides no guidance on when to choose this tool over alternatives such as reverse_ip, nslookup, or whois. It does not mention exclusions, prerequisites, or scenarios where a different tool would be more 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 the description adds meaningful behavioral context: the need for all three RRN components, the legal processing basis requirement, and the cost of 40 points per call. It does not contradict 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 primary purpose and includes necessary operational details (input requirements, legal condition, cost). The bilingual repetition is justified for a Korean audience, and there is no wasted 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?

Given the tool's complexity (3 required params, no output schema), the description covers all essential aspects: purpose, required inputs, legal prerequisites, and cost. The annotations cover safety (read-only), so no further behavioral detail is needed.

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 (name, rrn1, rrn2) already described. The description reiterates the requirement to input all three but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Verify that a Korean name and resident registration number (RRN) match a real registered person.' It uses a specific verb ('Verify') and identifies the exact resource (Korean name and RRN), distinguishing it from sibling tools like hide_rrn or identity_document_*.

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 explicit usage conditions: all three inputs (name, rrn1, rrn2) must be provided, and it must only be used when there is a legal basis such as data subject consent. It does not explicitly name alternatives, but the context is clear and actionable.

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 the description adds the cost per call (10 points) and clarifies the scope of NSFW. It does not elaborate on error behavior or output format, but the safety profile is covered by 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 but repeats the same content in English and Korean, making it slightly redundant. It front-loads the purpose and includes cost information, but the duplication prevents a perfect 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 tool with complete schema coverage and simple parameters, the description provides the main purpose, scope, detail flag, and cost. It does not define the nsfw_score range or output structure, but given no output schema, 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?

The input schema fully documents both parameters (image_url and detail) with descriptions. The description adds no significant extra semantic meaning beyond restating the detail parameter's effect and the image URL's existence. High schema coverage warrants a baseline 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 the tool detects NSFW (violent or sexually explicit) content in an image and returns an nsfw_score. This specific scope distinguishes it from sibling detection tools like car_detection, face_detection, and person_detection.

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 NSFW detection but does not explicitly state when to prefer this tool over alternatives or mention any exclusions. The only conditional guidance is about the detail parameter, not 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds extra behavior: error on non-domain input and the cost of 1 point per call, which is useful 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 short and front-loaded with the key action in English. The Korean sentence is a translation and somewhat redundant, but the clean structure with error behavior and cost keeps it 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 one-parameter tool with good annotations and no output schema, the description covers purpose, input format constraint, and cost. Return format is not detailed, but for a simple DNS lookup it's reasonably understandable. The sibling list includes related tools like whois and reverse_ip, which helps 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 a helpful description for 'domain' (e.g., apick.app). The tool description adds validation semantics ('non-domain values return an error'), going slightly 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: 'Resolve a domain name to its currently registered IP addresses (DNS lookup)'. This clearly distinguishes it from sibling tools like whois or reverse_ip, and the verb 'resolve' plus resource 'domain name to IP' is unambiguous.

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

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

The description implies when to use it (DNS lookup of a domain) and explicitly states that non-domain values return an error. It does not explicitly mention alternatives or exclusions, but the simple purpose and error condition provide clear 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 provide readOnlyHint=true, so the read-only nature is known. The description adds that it returns the full text (full_text) and mentions the cost ([8 points per call]), which is useful behavioral context beyond the annotations. No contradicting information 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 extremely concise, with two short sentences covering purpose, output, use cases, and cost. It is front-loaded with the English purpose statement, making it easy to scan. Every sentence earns its place with no waste.

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 OCR tool, the description covers the essential elements: what it does, the return value, when to use it, and cost. There is no output schema, so explaining full_text as the return is valuable. It does not discuss error handling or unsupported formats, but those are partially covered by the schema and are not critical for a basic 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 input schema provides 100% coverage for the single parameter image_url, specifying HTTPS URL, allowed formats (PNG/JPEG), and max size (25MB). 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 clearly states the verb ('Extract text from an image file'), the resource (image file), and the output (full_text). It also distinguishes itself from specialized OCR siblings (ocr_identi*) by explicitly framing itself as a general-purpose OCR tool for document photos, scans, and screenshots.

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

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

The description provides clear usage context: 'use for general-purpose images such as document photos, scanned images, and screenshots.' This implies that specialized identity-card OCR tools are not the target, but it does not explicitly name alternatives or exclude specific cases. Still, the guidance is sufficient for an agent to choose this tool for general OCR needs.

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 description adds value by specifying the output format (structured results + raw_text), the fields extracted, and the per-call cost (8 points). No contradiction with annotations; the additional behavioral details are useful beyond what annotations 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 description is compact and front-loaded with the core function, but it repeats the same information in English and Korean, adding minor redundancy. The legal caveat and cost note are useful, but the duplication prevents a perfect 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 a single parameter, full schema coverage, and readOnly annotations, the description adequately covers the tool's purpose, return types, and legal constraint. No output schema exists, but the described return (structured + raw_text) is sufficient for a low-complexity OCR tool. Minor gap: no error or edge-case behavior is mentioned.

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 parameter image_url, which already includes format (PNG/JPEG) and size (max 25MB) constraints. The description adds no further parameter-specific meaning, 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 tool extracts key fields from a Korean resident registration card via OCR, listing specific fields (name, RRN, address, issue date). This specificity distinguishes it from sibling OCR/identity tools by pinpointing the exact document type.

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

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

The description provides a clear condition for use: only when legal processing grounds are secured ('정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만'). However, it does not mention alternative tools for other document types, so while context is clear, explicit alternatives/exclusions are absent.

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 adds value beyond the readOnlyHint annotation by disclosing the return format (structured results + raw_text) and requiring a lawful basis such as consent. No contradictions with annotations are 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 and front-loaded with the core action, but the Korean sentence largely repeats the English content, introducing minor redundancy. It remains efficient overall.

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, the description covers the purpose, output, legal caveat, and cost. With no output schema, the explicit mention of structured results and raw_text adequately signals the expected return for this 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 input schema already provides 100% coverage of the single parameter (image_url) with format and size constraints. The description does not add additional parameter-specific details beyond what the schema 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 clearly states the verb 'Extract' and the specific resource 'key fields from a Korean driver license image via OCR', while also mentioning the return of structured results and raw_text. This distinguishes it from sibling tools that handle other document types.

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

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

The usage is implied (whenever Korean driver license OCR is needed), but the description does not mention alternative tools like ocr_identi1 or identity_document_driver_license, nor provide explicit exclusions. It only adds a legal compliance condition, not tool-selection 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?

The annotations already establish the tool as read-only (readOnlyHint=true). The description adds valuable context by stating that it returns structured results plus raw_text and by emphasizing the need for a legal basis (consent), which is not encoded in annotations. There is no contradiction with the read-only hint.

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

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

The description is reasonably concise and front-loaded with the English purpose, followed by a Korean elaboration that adds field examples and output details. The legal disclaimer and per-call cost are useful additions, though the bilingual repetition creates slight redundancy.

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

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

Given there is no output schema, the description adequately covers the output structure (structured fields plus raw_text) and the input is fully described in the schema. It does not detail error cases or behavior when no passport is found, but for a simple one-parameter OCR tool, this 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 input schema's description of image_url is comprehensive, covering the https requirement, allowed MIME types, and maximum size (100% coverage of the only parameter). The tool description adds no extra parameter-level detail, so the baseline score of 3 applies.

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

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

The description clearly states the tool's purpose: extracting key passport fields via OCR, naming the resource (passport image) and specific fields. It distinguishes itself from generic OCR tools by focusing on passports, but it does not explicitly differentiate from the sibling tool 'identity_document_passport' or other ocr_identi* tools, 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 passport-specific scope implies when to use the tool, and the consent/legal prerequisite is a useful condition. However, there is no explicit guidance about when to choose this over alternatives like identity_document_passport or other OCR variants, so the usage guidance is only partially informative.

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 valuable context such as the return of structured results and raw_text, the legal requirement, and the per-call point cost. It does not contradict annotations and provides additional behavioral context beyond the 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 relatively concise and front-loaded with the core purpose, but it duplicates the same information in English and Korean, which is somewhat redundant for an AI agent. Still, every sentence carries meaningful content (function, output, legal note, 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?

Given the simple single-parameter schema and no output schema, the description adequately explains the tool's function and output format. It could enumerate the specific 'key fields' extracted, but the document type is precise enough and the legal guidance is a valuable addition.

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

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

Schema description coverage is 100% for the single parameter image_url, detailing allowed formats and size. The description itself repeats 'image' and 'photo' but does not add new parameter semantics, 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 clearly identifies the tool's verb ('Extract'), resource ('Korean certified copy of resident registration'), and method ('via OCR'), distinguishing it from sibling identity-document OCR tools by specifying the exact document type (deungbon/주민등록등본).

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

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

It provides clear usage context by stating the legal prerequisite (consent or lawful basis) and implies use for deungbon images, but it does not explicitly mention when not to use it or name alternative sibling tools, 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?

Beyond the readOnlyHint annotation, the description adds that it returns structured results plus raw_text and emphasizes a legal precondition (consent). It does not discuss failure modes or exact output fields, but the read-only status plus return summary is sufficient for likely use.

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, but slightly redundant with English and Korean phrasing. It includes necessary usage caveats in a few lines, though the bracket cost note is a minor extra.

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

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

With no output schema, the description compensates by naming output components (structured result, raw_text) and providing legal context. For a single-parameter OCR tool, this covers essential usage and return expectations, though it could add a few more field examples.

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 already documents image_url with format and size constraints at 100% coverage, so the description adds no parameter-level semantics beyond restating the image input. 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 states a specific action—extract key fields from a Korean alien registration card via OCR—and names example fields (name, registration number, issue date). This clearly distinguishes it from generic OCR or other document types, though it does not explicitly contrast with sibling 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?

It implies use when you have an alien registration card image and explicitly requires legal basis/consent. However, it does not mention when to prefer this over sibling tools like ocr_identi1-4 or identity_document_residence_card, so 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 and openWorldHint, and the description adds valuable behavioral context: '결과는 저장하지 않고 매 호출마다 즉시 조회합니다' (Results are not stored and are queried immediately each call), plus the per-call point cost. These details go beyond the annotations and help the agent understand the tool's stateless, real-time nature, though response format is not described.

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

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

The description is concise, beginning with the core purpose in the first sentence, followed by useful details in a structured order: examples, alternative tool, free endpoint, and cost. The bilingual repetition adds some redundancy, but the overall message remains tight and each clause carries substantive information, making it an efficient description.

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 tracking tool with robust annotations, the description covers essential context: real-time query, no persistence, carrier list discovery, and the alternative tool for unknown carriers. It does not describe the response structure or error handling, but given the tool's straightforward nature and the support from annotations, this is only a minor gap and the description is largely complete.

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

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

The schema covers both parameters with 100% description coverage, so the baseline is 3. The description adds extra value by listing concrete carrier code examples (cj, hanjin, lotte, etc.) and pointing to a free endpoint for the full list, which assists the agent in selecting valid values. It does not significantly enhance trackingNumber semantics but enriches carrier semantics enough for a score of 4.

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

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

The description clearly states the tool's function: 'Track a Korean parcel in real time by carrier code and tracking number.' It further distinguishes from the sibling tool 'parcel_tracking_auto' by explicitly noting that it should be used when the courier is unknown, eliminating ambiguity about the tool's 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 provides explicit guidance on when to use this tool and when to use an alternative: '택배사를 모르면 parcel_tracking_auto Tool로 자동판별 조회하세요' (If you don't know the courier, use the parcel_tracking_auto tool for automatic detection). It also suggests a free endpoint for the full carrier list, giving the agent a clear path to obtain valid carrier codes.

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. The description adds behavioral context such as the cost of 10 points per call and the real-time nature of the tracking data. It does not contradict the annotations and provides useful non-obvious details beyond the structured metadata.

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 function and includes essential usage guidance and cost. However, it repeats the same sentence in English and Korean, creating redundancy that slightly reduces conciseness. Overall it remains brief and structured but loses a point for duplication.

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?

This is a simple single-parameter tool with no output schema. The description mentions the output type (real-time delivery status), the cost, and the alternative tool when the carrier is known. It does not explain error handling or edge cases, but given the low complexity, the coverage is adequate for an agent to select and 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 has 100% coverage for the single trackingNumber parameter, and the schema description already explains automatic format-based carrier detection. The tool description reiterates this but does not add new parameter-specific information, so it meets the baseline without exceeding it.

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 tracks Korean parcels in real time with automatic carrier detection from the tracking number alone. It distinguishes itself from the sibling parcel_tracking tool by noting that parcel_tracking is more accurate when the carrier is already known, which clarifies its specific scope.

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

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

Explicitly states when to use this tool (when the carrier is unknown) and when not to (if the carrier is known, use parcel_tracking instead). This provides clear contextual guidance and names the alternative, making the usage decision straightforward.

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