APICK Business

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

Annotations already mark it read-only and open-world, and the description is consistent with that (조회/lookup). It adds value by listing the returned data (representative, address, employee count, establishment date, industry, etc.) and noting the 50-point cost per call, which is useful because there is no output schema.

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

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

The description is reasonably compact and front-loads the purpose and input constraint before listing return fields and cost. The bilingual repetition is somewhat redundant, but the field list and point cost justify each section.

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

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

For a simple one-parameter lookup with no output schema, the description provides enough to invoke correctly: input format, scope, and expected result fields. It lacks explicit routing guidance among siblings, but that affects selection more than invocation.

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

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

The single parameter biz_no is already fully documented in the schema with 100% coverage: string, 10 digits, no hyphen, example. The description adds only the Korean-business scope and repeats '10-digit business registration number,' so it does not materially exceed schema coverage.

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

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

The description states a specific verb and resource: look up general status information of a Korean business using its 10-digit business registration number, and enumerates the fields returned. It is clear and distinct in function, but it does not explicitly differentiate itself from sibling venture_biz_info, so it misses the top score.

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

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

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

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral context: it explains that the tool performs MX lookups and disposable-domain detection, and it discloses the per-call point cost. This goes beyond the schema and annotations without contradicting them.

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

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

The description is compact, front-loaded with the action and purpose, and includes a cost note. The bilingual repetition is justified given the Korean title and likely user base, and no filler or unnecessary detail is present.

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

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

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

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

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

Schema description coverage is 100%, and the schema already documents the single 'email' parameter with an example. The tool description adds general context about what is validated but does not add new parameter-level detail beyond the schema.

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

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

The description names a specific verb ('Validate') and a precise resource (email), and enumerates the exact checks performed: syntax, MX availability, and free/disposable domain status. This clearly distinguishes it from sibling tools like check_phone_valid or check_spam_number.

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

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

The description makes the tool's context clear: use it when email deliverability/validity checks are needed. However, it does not explicitly mention when not to use it or name alternative tools, so the usage guidance is implied rather than explicit.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, covering safety and external interaction. The description adds the per-call cost (40P), which is a meaningful behavioral detail. However, it does not disclose the return format or behavior on invalid inputs, leaving a gap beyond what annotations 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 brief and front-loaded with the core purpose, followed by cost. It is slightly redundant due to bilingual text (English and Korean) but remains efficient and 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?

With no output schema, the description fails to explain what the tool returns (e.g., validity boolean, formatted number, carrier, line type). An agent cannot predict the result structure, which is a significant gap for a tool that performs multiple checks. The cost note does not compensate for missing output 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?

The schema description for 'number' is complete with examples (01012341234, +country code format), so the parameter is well-documented. The description adds no extra semantics beyond the schema, matching the baseline for high 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 validates and formats a phone number, checks carrier and line type, using specific verbs and a concrete resource. It is distinct from siblings like check_email_valid (email) and check_spam_number (spam), 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 phone number validation but does not explicitly compare with alternatives or state when not to use it. Given the many sibling tools, explicit routing (e.g., 'use for phone validity, not email') would help, but the tool's name and function make the intended context inferable.

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

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

Annotations already show readOnlyHint and openWorldHint, which cover safety and openness. The description adds useful behavioral context: the Korea-specific reported-data scope and a cost signal of 10 points per call. It does not contradict the annotations.

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

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

The key action is front-loaded and the cost note is clear. The Korean sentence restates the first English sentence, making it slightly redundant, but overall the description remains short and scannable.

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

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

For a one-parameter, read-only lookup with no output schema, the description supplies enough context: purpose, domain, usage examples, and cost. It does not spell out the response shape, but 'Check whether' strongly implies a boolean-style report.

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

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

Schema description coverage is 100%, with the 'number' parameter already documented and exemplified. The description itself adds no new parameter semantics, so the baseline of 3 applies.

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

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

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

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

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

The description gives explicit use context: '수신 전화 필터링, 이상 거래 탐지 등에 사용합니다' (incoming call filtering, abnormal transaction detection). It does not state exclusions or name an alternative tool, so it falls short of a 5.

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

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

Annotations already mark the tool as read-only and open-world, and the description adds a billing note about points per call. However, it does not disclose what the response looks like or caveats about record availability, which is more noticeable because there is no output schema.

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

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

The description is compact and front-loaded with the core behavior. The English and Korean sentences are somewhat redundant, but this bilingual structure is reasonable for the target market and adds a use case and cost note without becoming bloated.

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

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

For a simple two-parameter lookup tool, the description covers purpose, identifiers, use case, cost, and safety via annotations. It is adequate for an agent to select and invoke the tool, though a brief note on the return format would make it fully complete.

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

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

Schema description coverage is 100%, with type and value already explained in the schema. The main description restates the two lookup modes but does not add meaningful new parameter semantics beyond what the schema provides.

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

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

The description states a specific verb (check) and a specific resource (Korean vehicle flood damage record), scoped by VIN or license plate. This makes the tool's function unambiguous and inherently distinct from siblings like get_car_scrap, which covers a different vehicle record type.

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

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

The description explicitly provides a concrete use case: checking flood history before purchasing a used car. It does not mention exclusions or alternatives, but the stated context is clear enough for an agent to understand when this tool is appropriate.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds beyond them by disclosing the per-call point cost and the Korean-vehicle scope. It does not describe response details, but this is a simple read-only lookup and no contradiction exists.

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

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

The English and Korean sentences are compact and front-loaded with the core purpose before cost and use case. The Korean sentence largely repeats the English sentence, causing slight redundancy, but the overall entry remains efficient.

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

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

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

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

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

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

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

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

The description states a clear verb and resource: checking whether a Korean vehicle has a scrap/total-loss accident record, keyed by VIN or license plate. It does not explicitly differentiate itself from sibling tools such as get_car_flooding or get_pccc, so it stops short of 5.

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

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

It gives an explicit intended use case: used before buying a used car. It does not, however, mention when to prefer an alternative or when not to use this tool, so it lacks the exclusions needed for a 5.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses critical side effects: per-call charging, re-query charges, DB storage, and state-dependent messages such as '인증 대기중입니다.' and '조회된 개인통관고유부호가 없습니다.' It also states the exact cost of 30 points per call, fully compensating for limited annotation detail.

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 core purpose in English and then details statuses, charging, and re-query behavior in Korean. Each sentence adds distinct operational information, though the mixed-language structure and level of detail make it slightly dense. It remains logically organized 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?

With no output schema, the description provides essential response semantics: status field values, example messages, checked_at, and the returned PCCC/address. It covers pending, success, and no-code scenarios along with cost implications. It omits edge cases like invalid tx_id or expired requests, but the core agent-relevant behavior is fully specified.

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

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

The schema already fully documents tx_id as the transaction ID from the req_pccc response (100% coverage). The description restates this and adds that it is used to check processing status, but does not provide additional format, length, or constraint details. 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 states a specific verb-resource pair: 'Retrieve a Korean Personal Customs Clearance Code (PCCC) by transaction ID.' It clearly positions itself as the counterpart to req_pccc by referencing the tx_id source, distinguishing 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?

It explicitly ties usage to a prior req_pccc call ('req_pccc 로 받은 tx_id') and explains the relevant states (pending, approved, no code) and the 24-hour re-query window. It does not explicitly name alternative tools, but the relationship to req_pccc makes the usage context unambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description's 'Look up/조회' aligns with that read-only behavior. The description adds a per-call cost note ('[호출당 3포인트]') and downstream use cases, which is useful context. It does not disclose output shape or edge-case behavior, but for a safe read-only lookup the annotations carry most of the burden.

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

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

The description is three short sentences, with the primary lookup action and scope front-loaded. The Korean sentence repeats the English statement, which is mildly redundant, but the overall size is compact and the extra cost/use-case information is earned.

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

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

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

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

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

Schema description coverage is 100%: both year and month are documented with type, range, and example values. The description only restates 'given year and month' and does not need to add further parameter detail. The baseline of 3 applies because the schema fully handles parameter semantics.

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

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

The description uses a specific verb ('Look up') with a clearly bounded resource: Korean public holidays for a given year and month. The bilingual text and the stated use cases ('영업일 계산, 일정 관리') make the tool's role unambiguous. It is easily distinguished from the sibling tools, none of which target holiday data.

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

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

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

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

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

Annotations already declare readOnlyHint=true, and the description complements this by adding that the operation is free ('무료입니다') and scoped to the currently authenticated API key. It does not detail rate limits or exact response structure, but for a zero-parameter read-only tool this is reasonable.

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

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

The description is short and front-loaded, but it repeats the same content in English and Korean and redundantly states '무료입니다' and '[무료]'. The core message is clear, but the duplicate free-note is unnecessary and slightly bloats the definition.

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

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

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

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

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

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

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

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

The description uses a specific verb ('Check'/'조회') and a specific resource ('APICK account balance and status'/'잔여 포인트와 계정 상태 정보'). It clearly identifies what the tool does and is easily distinguished from the broad sibling list, none of which target account info.

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

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

The description clearly implies when to use the tool: whenever the agent needs the current APICK account balance or status. It does not explicitly mention alternatives or exclusion criteria, but with zero similar siblings and a simple purpose, the context is sufficient.

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

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

Annotations already mark this as read-only and open-world, and the description adds meaningful behavioral detail: invalid addr1 triggers an options field listing selectable regions, and each call costs 100 points. This goes beyond the structured annotations.

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

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

The description is compact and front-loaded with the core purpose. The bilingual Korean sentence is somewhat redundant with the English opening, but it improves accessibility for the likely Korean-speaking user, so the structure remains efficient.

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

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

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

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

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

Schema description coverage is 100%, so the schema already fully documents all four parameters, including type codes, year range, and address format examples. The description adds no additional parameter-level meaning beyond schema coverage.

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

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

The description states a specific verb and resource: 'Look up real estate transaction price records in Korea by region, property type, and year.' This clearly distinguishes the tool from all siblings, none of which target real estate transaction prices.

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

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

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

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description states results are not stored ('결과는 저장하지 않고') and each call queries in real time, plus the per-call 5-point cost. These details affect caching, cost, and re-use decisions and are not present in the annotations.

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

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

The description is front-loaded with purpose, then behavioral notes, carrier examples, alternative routing, and cost. The bilingual text causes some duplication, but every sentence carries useful information and nothing is wasted.

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

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

For a two-parameter real-time lookup with no output schema, the description is complete: carrier identification, tracking number, alternative tool, cost, and no-persistence behavior are all covered. The lack of a detailed return format is acceptable because the purpose statement clearly indicates the result is delivery status.

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 both parameters with examples, so the basic semantics are covered. The description adds value by giving concrete carrier code examples with Korean names and directing users to a free endpoint for the full list, though it does not specify tracking-number format details.

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,' naming a specific action, object, and required method. It also distinguishes itself from parcel_tracking_auto by requiring a known carrier code, so its role among siblings is clear.

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

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

It explicitly tells the agent to use parcel_tracking_auto when the carrier is unknown, and points to /rest/parcel_tracking_carriers for the full carrier list. This is concrete when-to-use and alternative guidance that is not left to inference.

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

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

Annotations already cover readOnlyHint and openWorldHint, so the safety profile is established. The description adds non-obvious behavioral details: automatic carrier detection from the tracking number format, real-time status lookup, and a per-call point cost. There is no contradiction with the annotations.

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

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

The description is compact: an English sentence, a Korean mirror sentence, and a third sentence naming the alternative and cost. The bilingual duplication is a minor redundancy, but the purpose is front-loaded and every sentence carries useful 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 one-parameter, read-only tool with full schema coverage and openWorldHint, the description covers the core decision factors: function, usage condition, alternative, and cost. Return format is not specified, but no output schema exists and openWorldHint signals variable results, so nothing essential is missing.

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

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

The schema already describes trackingNumber with 100% coverage ('운송장번호 (택배사 지정 없이 형식만으로 자동 판별)'). The description reinforces the same idea with 'from the tracking number alone' but adds little parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Track a Korean parcel in real time with automatic carrier detection from the tracking number alone.' It clearly distinguishes itself from the sibling parcel_tracking by emphasizing auto-detection versus a known carrier, so an agent can tell them apart without opening the sibling 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?

It explicitly states when to use this tool: when no carrier is specified and only the waybill number is available. It also names the alternative: '택배사를 이미 아는 경우에는 parcel_tracking Tool이 더 정확합니다' (if you already know the carrier, parcel_tracking is more accurate), providing direct when-to-use/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?

The description discloses key behaviors beyond annotations: asynchronous nature (returns tx_id without waiting), billing at receipt, and idempotent handling of duplicate pending requests (returns existing tx_id without re-billing). This is valuable context that annotations do not cover.

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

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

The description is a single dense paragraph that front-loads the purpose and then provides critical operational details. It is efficient, with no filler, though the billing and idempotency details add length but are necessary for correct use.

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

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

For an action that returns a tx_id and requires a follow-up, the description covers the full call flow: what to send, what is returned, how billing works, and how to get the final result. With no output schema, this is complete and self-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 the schema already documents all four parameters. The description references the parameters (name, birthday, phone, provider) but does not add semantic details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific action ('Request simple authentication') with a clear resource ('retrieve a Korean Personal Customs Clearance Code (PCCC)') and distinguishes itself from the sibling get_pccc by explaining the follow-up step. It is unambiguous and context-specific.

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

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

The description gives clear usage instructions: inputs, immediate tx_id return, the need to wait for user approval, and how to retrieve the result via get_pccc. It also mentions billing conditions. It does not explicitly state when NOT to use it or compare with alternatives like name_rrn_auth, but the flow is well-defined.

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 provided by annotations, the description goes beyond them by disclosing pagination (10 per page), the total_count response field, and the 2-point cost per call. It does not contradict the annotations and adds useful operational detail.

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 action in the first sentence and supporting details (keyword types, pagination, cost) following. It is concise, though the English and Korean opening lines repeat the core concept.

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 search tool, the description covers invocation essentials: keyword, pagination, total count, and cost. However, without an output schema, it does not describe the structure of returned address items or handle no-result or edge-case behavior, leaving a noticeable gap.

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

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

Schema description coverage is 100%, so the schema already defines juso and page, including the default page value and 10-per-page behavior. The description adds total_count context but does not materially expand parameter semantics beyond the schema, so the baseline 3 applies.

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

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

The description states a specific action—'Search Korean road-name addresses by keyword'—and clearly identifies the resource as road-name addresses, which helps distinguish it from generic address or land-price tools in the sibling list. It does not explicitly name sibling alternatives, 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?

Usage context is implied: the tool is for looking up Korean road-name addresses by keyword, and pagination behavior is described. However, there is no explicit when-to-use, when-not-to-use, or guidance for choosing among related siblings such as location or land_rt_price.

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 covered. The description adds useful behavioral detail beyond annotations by enumerating the content areas: business info, balance sheet, income statement, investment data, and venture confirmation info. It also discloses the per-call point cost, which helps the agent understand operational impact.

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

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

The description is short, front-loaded with an English summary, and the Korean sentence adds specific data categories beyond the English text. The cost note is brief and useful. Minor redundancy exists because the Korean wording repeats the English lookup intent, but 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?

With only one simple parameter, no output schema, and read-only annotations, the description provides enough context for an agent to understand what the tool returns by enumerating the information categories. It does not specify the exact response shape or field names, but for a simple business lookup this is a reasonable level of 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%, and the biz_no parameter is already documented with format requirements: business registration number, 10 digits, no hyphen. The tool description adds little to parameter understanding beyond confirming the tool is about Korean businesses. Since the schema carries the full load, 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 a specific action ('Look up') and a specific resource ('venture company information of a Korean business'), and lists the data categories returned. It does not explicitly name a sibling tool to differentiate from, but the venture-company scope is distinctive enough to separate it from broader business-info 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 phrase '벤처기업을 대상으로' implies this tool is intended for venture company information, giving some usage context. However, it does not explicitly say when to prefer this over sibling alternatives such as biz_detail, nor does it state exclusions or conditions. Usage guidance is present only by implication.

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