APICK Business

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read-only nature is known. The description adds value by listing the specific data fields returned (대표자, 주소, 직원수, 설립일, etc.) and the point cost per call (40포인트), giving the agent a clearer behavioral expectation. 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 two sentences with key information front-loaded: function, input, fields, and cost. The bilingual repetition (English and Korean) is somewhat redundant, but both parts contribute useful details (English summary, Korean field list), so it remains efficient and 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?

For a simple single-parameter lookup tool with no output schema, the description is sufficiently complete. It states the input format, the returned fields, and the cost. It does not explain response format or error conditions, but for a tool of this complexity the description covers the essential operational context.

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

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

The schema already provides a full description of the single parameter biz_no, including format and example. The description's mention of '10-digit business registration number' is redundant with the schema coverage, so it adds no new semantic meaning beyond the structured 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 starts with 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. It does not explicitly differentiate from sibling tools like venture_biz_info, but 'general status' hints at a distinction, so it is clear but not fully distinguishing.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or situations where another sibling tool would be more appropriate. The context is purely about what the tool does, not when to choose 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?

Beyond the readOnlyHint annotation, the description discloses the tool checks deliverability (not just syntax) and includes a cost/rate-limit note ('[호출당 10포인트]'). This adds behavioral context that the annotations do not provide. It does not detail response format or network behavior, but with annotations present the bar is lower, and the added cost/deliverability info justifies 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 English purpose, followed by Korean context and cost. While the bilingual phrasing is redundant, the overall length is appropriate and every sentence contributes to operational understanding. Slight 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 should indicate what the tool returns, but it only states the validation purpose. It mentions usage and cost, but the return format (e.g., boolean, reason codes) is unknown. For a simple single-param tool this is a notable gap, so it earns a 3.

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

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

The schema covers the sole parameter 'email' with a description and example, making schema description coverage 100%. The description adds no extra meaning about the parameter beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Validate whether an email address is real and deliverable.' This is a specific verb + resource that distinguishes it from sibling tools like check_phone_valid. The Korean usage context further clarifies 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: '회원가입 입력값 검증, 발송 전 리스트 정제 등에 사용합니다' (used for signup input validation, pre-send list cleaning, etc.). It implies when to use the tool but does not explicitly name alternatives or exclusions relative to sibling tools, 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?

The description aligns with the readOnlyHint annotation and adds useful context: the cost of 20 points per call and the specific fields being verified. It does not contradict annotations and provides additional behavioral detail beyond what the schema or annotations already convey.

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 overview followed by a Korean translation and a cost note. The Korean sentence repeats the English but serves a bilingual audience; no extraneous information. It is slightly redundant but still efficient.

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

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

The tool is relatively simple with all parameters documented and read-only annotations. The description explains the purpose and cost, but does not specify the return format (e.g., boolean, success/error). Given no output schema, a bit more detail on return values would improve completeness, but current info is adequate for invocation.

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

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

The input schema already documents all four parameters with detailed descriptions and 100% coverage. The description only restates that name, zip, and phone are used and adds nothing beyond the schema; hence 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: verifying that a Korean PCCC matches the given name, zip code, and phone number. It specifies the resource (PCCC) and the action (verify), and distinguishes it from sibling tools like get_pccc or req_pccc which deal with retrieval/request rather than validation.

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: '해외직구 주문 정보 검증 등에 사용합니다' (used for overseas direct purchase order information verification). This gives context but does not explicitly exclude other scenarios or name alternatives; however, the intended context is clear enough for an agent to select this tool over others.

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 openWorldHint=true, which the description does not contradict. The description adds value beyond annotations by disclosing a per-call cost of 10 points and clarifying that validation checks 'in service' status, implying a live lookup. It does not detail error behavior or response format, but with annotations covering safety, this is solid.

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, followed by format details and cost. The English and Korean sentences are redundant (translation), but each element (purpose, format, cost) is useful. It is concise without being overly 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?

For a single-parameter, read-only tool with high schema coverage and no output schema, the description covers the essential aspects: purpose, input format, and cost. It lacks an explicit statement about return type or error cases, but given the low complexity and good annotations, this is adequate and not severely 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 schema already covers the parameter fully with examples (domestic and international), so baseline is 3. The description adds a meaningful rule: domestic numbers must start with 0 and should be entered 'as-is', reinforcing the schema example. While somewhat redundant, the explicit formatting guidance and 'as-is' instruction improve understanding 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 validates whether a phone number is in service, using a specific verb ('validate') and resource ('phone number') with a clear scope ('in service'). This distinguishes it from sibling tools like check_spam_number (which checks spam reputation) and check_email_valid (email validation), so the purpose 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 usage for validating phone numbers and provides format instructions for domestic and international numbers, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or related tools such as check_spam_number. Guidance is present but implicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds context about the cost per call, the Korean geographic scope, and the types of reports checked, which 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 appropriately short, front-loaded with the core purpose, and includes a bilingual translation and cost note. Every sentence adds value without unnecessary repetition, making it highly concise 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?

Given the tool's simplicity (one parameter, no output schema, and strong annotations), the description covers purpose, use cases, cost, and scope quite well. However, it does not explicitly state the return format, though it is implied by the verb 'check', so it falls just short of a 5.

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

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

The input schema has 100% coverage for the single 'number' parameter, including a format example. The description does not provide additional parameter details beyond what the schema already specifies, so it earns the baseline score of 3.

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

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

The description specifically states the tool checks phone numbers for spam, advertising, or criminal use in Korea, using a clear verb and resource. This clearly distinguishes it from siblings like check_phone_valid, which likely only validates number format.

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 use cases (incoming call filtering, anomaly detection) but does not mention exclusions or direct alternatives. While context is clear, it lacks explicit guidance on when not to use this tool, so it doesn't achieve a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by disclosing the per-call cost ('[호출당 10포인트]') and the query scope (Korean vehicles by VIN/plate). This goes beyond the annotation-provided safety profile, though it doesn't describe return format or error handling.

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

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

The description is front-loaded with the core purpose and includes both English and Korean versions, which is redundant but intentional for audience coverage. The sentence about used-car purchase and the cost note are useful. It's efficient without unnecessary fluff, only slightly padded by the bilingual 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?

For a simple 2-parameter read-only tool, the description covers purpose, usage, vehicle scope, and cost. No output schema exists, but the boolean nature ('whether...has a flood damage record') is implied. It doesn't mention limitations like database coverage, but the given information is sufficient for most agent invocation scenarios.

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

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

The schema description coverage is 100%—both 'type' and 'value' are documented with details (e.g., type 1 is VIN, type 2 is license plate). The description merely summarizes this ('by VIN or license plate number') without adding new semantics, 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's function: 'Check whether a Korean vehicle has a flood damage record, by VIN or license plate number.' This specific verb+resource+scope distinguishes it from sibling tools like get_car_scrap (scrap vehicle info) and check_pccc (accident history) by targeting flood damage specifically.

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: '중고차 구매 전 확인 등에 사용합니다' (used for checking before purchasing a used car). This gives context on when to use the tool, but it doesn't explicitly mention when not to use it or reference alternative 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?

With readOnlyHint and openWorldHint already in annotations, the description adds valuable context: the tool is a read-only lookup, charges 10 points per call, and returns a status about scrap/total-loss handling. It does not detail output format but covers cost and scope, which is useful 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 bilingual (English and Korean) with the Korean sentence essentially repeating the English content. While informative, the redundancy wastes space. Cost and use case are useful additions, but the duplication makes it less concise than ideal.

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 lookup tool with no output schema, the description sufficiently covers purpose, input method, use case, and cost. It does not need to explain return values since the description implies a yes/no status. It is nearly complete for the tool's complexity.

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

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

The schema covers 100% of parameters with detailed descriptions (type values 1/2, value format with length constraint for VIN). The description reiterates the 'VIN or vehicle number' from schema without adding new semantic details, so it meets the baseline 3 but does not exceed 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 checks whether a Korean vehicle has a scrap/total-loss accident record, using VIN or license plate. This specific verb+resource distinguishes it from sibling tools like get_car_flooding (flooding records). The inclusion of the use case (pre-purchase used car check) reinforces 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 context: it is used for checking scrap/total-loss records, especially before buying a used car. It does not explicitly name alternatives or state when not to use it, but the purpose is distinct enough that the usage context is clear. Missing explicit exclusions prevents 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 description discloses the cost (30 points per call), which is a behavioral trait beyond annotations. It also explains the prerequisite of req_pccc and SMS verification. Annotations are minimal (readOnlyHint=false, etc.), but there is no contradiction; the 'retrieve' action is consistent with a read operation that may still incur points or state changes.

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 sentence followed by a Korean translation of the same content. This is efficient but slightly redundant. The cost note is useful and compact. Overall, every sentence earns its place, though the bilingual repetition could be tightened.

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 covers purpose, prerequisites, and cost. It does not explain return values or failure behavior, but given the low complexity and parameter clarity, this is acceptable and reasonably complete.

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

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

The schema already covers both parameters with descriptions, but the description adds critical semantic context: auth_key comes from req_pccc's response, and answer is the 6-digit SMS code. This goes beyond the schema's generic descriptions and clarifies the exact source and format.

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 retrieves a Korean Personal Customs Clearance Code (PCCC) using an auth key and SMS verification code. It distinguishes itself from sibling tools like req_pccc (which requests the auth key) and check_pccc (which likely validates a 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 clear context on when to use the tool: after obtaining auth_key from req_pccc and receiving the 6-digit SMS code. It does not explicitly exclude alternatives or mention check_pccc, but the prerequisite flow is clearly implied, so the usage scenario is well understood.

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 the cost per call (3 points), which is a rate-related disclosure, and confirms it is a read operation. 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 short and front-loaded with the core purpose. It includes bilingual repetition (English and Korean) which is slightly redundant, but the extra information about use cases and cost is valuable. Overall, it is concise and structured effectively.

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 low complexity, complete parameter schema, and read-only annotations, the description provides sufficient context. It explains when to use the tool and notes the per-call cost, which is practically important. Without an output schema, a richer return format description would be useful, but it is not essential for this 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?

Schema description coverage is 100% with both year and month parameters fully described. The description does not add additional semantic detail beyond what the schema already provides, such as formats or ranges, so it meets the baseline but does not exceed 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's function: looking up Korean public holidays for a given year and month. It uses a specific verb ('Look up') and a specific resource ('Korean public holidays'), and it is distinct from all sibling tools, none of which deal with holidays.

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 mentions use cases such as 'business day calculation' and 'schedule management' (영업일 계산, 일정 관리). It does not explicitly state when not to use it or name alternatives, but there are no similar sibling tools, so the context is clear.

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

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

Annotations declare readOnlyHint and openWorldHint. The description adds that the operation is free and tied to the current authentication key, and it states the return content (remaining points and account status). 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 short and front-loaded with the main purpose. However, it contains redundancy: the English and Korean sentences overlap, and '무료입니다' and '[무료]' both state that it is free, preventing 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 simple, parameterless read-only tool, the description is complete: it specifies the auth context, the free nature, and the key output fields (balance and status). No output schema exists, so the description appropriately covers return values.

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. The description adds meaning by explaining what data the tool returns for the authenticated account, which is not represented in the empty schema.

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

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

The description states a specific verb ('Check') and resource ('APICK account balance and status'), and adds that it uses the current authentication key. This clearly distinguishes it from all sibling tools, which focus on email/phone/car/parcel checks.

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

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

Clear context is provided: use this tool when the user needs their APICK account balance or status. It does not explicitly mention alternatives or exclusions, but none of the sibling tools serve this purpose, so the implied usage is sufficient.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the specific error response behavior (options field with selectable regions when addr1 is invalid) and cost per call, which are 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 includes both English and Korean versions of the same content, which is redundant. It's short but not optimally concise; could omit 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?

The tool has no output schema, and the description does not describe the success response structure beyond the error case. It covers purpose, parameters, error handling, and cost but lacks return format details.

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

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

Schema covers all 4 parameters with descriptions (100%), so baseline 3. The description mentions region/property type/year but doesn't add new semantic details. The error behavior for addr1 is helpful but not parameter definition.

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 looks up real estate transaction prices in Korea by region, property type, and year, with a specific verb and resource. It also distinguishes from sibling tools which are unrelated.

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 (when needing transaction price records), but does not explicitly state when not to use or mention alternatives. The error-handling note about addr1 adds practical guidance.

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

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

Annotations already mark the tool as readOnlyHint=true and openWorldHint=true. The description adds that results are not saved and are fetched fresh on every call ('결과는 저장하지 않고 매 호출마다 즉시 조회합니다'), plus a per-call cost of 5 points. This extra information goes beyond the structured annotations.

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

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

The description is bilingual, which adds length, but it is front-loaded with the purpose in the first sentence. Every subsequent sentence adds value: behavior, examples, alternatives, and cost. It stays within a reasonable length given the need for examples and alias guidance.

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 two parameters and no output schema, the description covers the core usage, examples, alternatives, real-time behavior, and cost. It could mention what the returned status looks like, but for a simple read-only lookup the current level of detail 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 already provides 100% coverage for both parameters, but the description enhances it with concrete carrier code examples (e.g., cj, hanjin) and points to the full list at /rest/parcel_tracking_carriers, and clarifies that parcel_tracking_auto handles unknown carriers. This adds meaningful guidance on valid parameter values.

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 'Track a Korean parcel in real time by carrier code and tracking number,' clearly stating the verb, resource, and required inputs. It also distinguishes from sister tool parcel_tracking_auto by noting that this tool requires a known carrier code.

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

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

It explicitly instructs: 'if you don't know the carrier, use the parcel_tracking_auto Tool for automatic identification.' It also points to a free endpoint for the full carrier list, giving clear direction on when to use this tool vs alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds practical context including real-time behavior, automatic carrier detection, per-call cost (10 points), and an accuracy trade-off, without contradicting annotations. It does not detail return format, but the additions go 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 compact and front-loaded with the primary purpose, followed by usage guidance and cost. It includes a bilingual repetition (English and Korean) which is slightly redundant for a bilingual audience but still efficient overall, earning a 4 rather than 5.

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

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

For a simple tool with one parameter, annotations, and no output schema, the description covers purpose, usage context, real-time retrieval, and cost. It also mentions delivery status output, which compensates for the lack of output schema. Minor gaps like failure behavior are not critical here.

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

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

Schema coverage is 100%, so the schema fully documents the trackingNumber parameter. The description reinforces that only the tracking number is needed and that carrier detection is automatic, but it does not add format or syntax details 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 tracks Korean parcels in real time with automatic carrier detection, using a specific verb and resource. It explicitly distinguishes itself from the sibling parcel_tracking tool by emphasizing automatic detection, satisfying sibling differentiation.

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

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

The description provides explicit guidance: use this tool when the carrier is unknown, and use parcel_tracking if the carrier is already known. This directly addresses when-to-use vs. alternatives, exceeding minimal requirements.

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

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

The description discloses that a 6-digit verification code is sent via SMS, that points are charged per call, and that the response provides an auth_key. This adds behavioral context beyond the annotations (e.g., openWorldHint=true), such as the external SMS side effect and the workflow dependency on get_pccc.

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

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

The description is compact, front-loaded with purpose, and includes the critical workflow and cost. Every sentence earns its place, with no redundant or extraneous 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?

The description provides a complete picture of the two-step PCCC retrieval process, referencing get_pccc and the need for auth_key and SMS code. While it doesn't cover error scenarios or auth_key expiry, these are not essential for basic tool invocation and are not expected without an output schema.

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

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

Input schema covers all 4 parameters with descriptions (100% coverage), so the description adds little extra semantic value. It does confirm the parameters are used for identity verification, but does not elaborate beyond what the schema already states.

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

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

The description clearly states the tool's function: requesting SMS verification to retrieve a PCCC. It distinguishes itself from get_pccc by explicitly describing the two-step flow (auth_key + received code -> get_pccc), 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?

The description explains the intended sequence: call this tool first, then use get_pccc with the auth_key and SMS code. It clearly defines when to use this tool within the larger PCCC retrieval process, though it doesn't explicitly list exclusions (e.g., when an auth_key already exists).

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, covering safety. The description adds behavioral details beyond annotations: '페이지당 10건씩 반환되며 total_count 필드로 전체 검색결과 개수를 확인할 수 있습니다' (returns 10 per page, total_count shows total results) and '[호출당 2포인트]' (cost per call). This gives useful context about pagination and cost.

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: two sentences cover purpose and key behavioral details, with the cost in brackets. There is no fluff, and every sentence adds 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?

Given the tool's moderate complexity (2 parameters, no output schema), the description sufficiently covers pagination, total_count, and cost. It does not detail the exact fields of returned address results, but annotations and the simple schema make this adequate for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% for both parameters, providing baseline semantic clarity. The description adds value by clarifying that the 'juso' keyword can be '지번 또는 도로명' (land-lot or road-name) and giving an example '디지털로'. This reduces ambiguity beyond the schema 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's function: 'Search Korean road-name addresses by keyword.' This uses a specific verb and resource, and the Korean phrase '지번 또는 도로명 키워드로' clarifies the search input. No sibling tool appears related to address search, so it is well-distinguished.

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 the tool: when needing to search Korean road-name addresses. It also provides usage context such as pagination (10 per page) and total count. However, it does not explicitly mention exclusions or alternatives, though no sibling tool is a direct alternative, making the implied usage sufficient.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description adds value by disclosing the specific data returned (financial statements, investment data, confirmation info) and the cost of 40 points per call. This goes 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 moderately concise but includes redundant bilingual repetition of the same information in English and Korean. The cost note at the end is useful, but the duplication reduces overall conciseness.

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

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

For a simple one-parameter read-only lookup, the description covers the core purpose, the returned data categories, and the cost. It doesn't describe output format or error conditions, but annotations and schema cover most essential context, making it 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?

The schema fully documents biz_no with a 10-digit, no-hyphen format, so schema coverage is 100%. The description adds no additional parameter syntax or examples; thus the baseline 3 is appropriate.

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

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

The description clearly states the verb 'look up' and the resource 'venture company information of a Korean business', listing financial statements and investment data. The 'venture' qualifier distinguishes it from generic sibling tools like 'biz_detail'.

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 venture-company inquiries via the qualifier 'venture company', but it lacks explicit when-not-to-use guidance or alternative tool references. There are no exclusions compared with siblings, leaving usage somewhat implied.

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