Korea Business Verify (KBV)

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

Annotations already cover the read-only, idempotent, open-world safety profile, and the description adds substantial non-redundant context: unmet approvals cause goods to be held or returned, multiple approving agencies may exist with any one sufficient, conditions are quoted in authoritative Korean, tariff rates are included, and data provenance is named. This is exactly the beyond-schema context the dimension rewards.

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?

Front-loads what it returns and what happens when approvals are unmet, then layers caveats and provenance. Dense but nearly every clause carries information; the final free-test-code sentence is a slight tack-on but still useful for trial invocation.

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

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

With no output schema, the description carries the return-value burden and does so well, enumerating statutes, agencies, certificates, quoted conditions, and tariff rates. It also sets expectations about Korean-language output and the fact-lookup limitation, leaving no significant gap for a two-parameter read-only tool.

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

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

Schema coverage is 100%, so both parameters are already documented, including the 6-digit truncation behavior and the import/export enum. The description only echoes the 10-digit HS code usage and says nothing about the direction parameter, so baseline 3 is appropriate.

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

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

States a specific verb (check requirements) and resource (Korean customs clearance requirements) scoped by 10-digit HS code. Distinguishes itself from the batch sibling by being a single-code fact lookup, and the 'not a legal customs determination' line clarifies what the tool does not do.

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?

Explains the trigger condition (you have a product's HS code and need to know clearance requirements) and gives a free test code plus the disclaimer that conditions are not evaluated against your product. It does not explicitly name the batch sibling as the alternative for multiple codes, so 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 adds substantial behavior beyond the annotations: it explains the result ordering (restricted first, then unchecked, then clear), how invalid codes are handled via summary.invalid_hs and excluded from counts, and what details are returned for restricted codes. This is strong disclosure for a read-only, idempotent lookup tool.

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

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

The description is front-loaded with the core action and batch scope, then moves efficiently through output contents, ordering, invalid handling, usage timing, and limitations. Every sentence contributes useful information without repetition.

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

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

Although there is no output schema, the description explains the relevant return structure, ordering, and invalid-code reporting, which is exactly what an agent needs for this batch lookup. The annotations cover safety and idempotency, and the schema covers parameter details, so the definition is complete for its complexity.

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

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

Schema coverage is 100%, so the schema already documents hs_codes and direction fully. The description reinforces the 100-code limit and mentions invalid code handling, but it does not add meaning for the direction parameter or explain HS code formatting 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 states a specific verb and resource: screen a product catalog for Korean import restrictions. The batch scope is explicit through 'in one call' and 'up to 100 HS codes', which distinguishes it from the singular check_korea_import_requirements sibling.

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

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

It gives clear usage context: use before opening a Korea shipping lane or listing a catalog for Korean buyers, and adds the important limitation that this is fact lookup only, not a legal customs determination. It does not explicitly route single-code checks to the non-batch sibling, so it falls short of full when-to-use/when-not 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?

Goes well past the readOnly/idempotent annotations: discloses a 24-hour cache with a per-entry 'cache': true marker, the 100-item cap, preserved input ordering, and the non-obvious domain behavior that a company can be active yet still debarred. Source attribution (NTS, PPS) gives the agent grounds for trust and citation.

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?

Front-loaded with the action, scale and input format in the first clause, then layers output shape, the debarment caveat, the alternative-usage hint, and the cache caveat — each sentence adding distinct information. Dense but zero redundancy.

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

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

Even though an output schema exists, the description still characterizes the return shape (one entry per input, order preserved, fields plus a debarment count) and pre-empts the main interpretive trap of an active-but-debarred company. Nothing an agent needs to select and call this correctly is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds meaning beyond 'array of strings': it identifies the value as a Korean business registration number (사업자등록번호), which tells the agent what identifier the caller must supply. The hyphen/space tolerance detail merely restates 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?

States a specific verb (screen), resource (Korean businesses), input format (10-digit 사업자등록번호) and a hard limit of 100 in one call. The phrase 'instead of repeated single checks' distinguishes it from the sibling single-check tool check_korean_business_status without the agent needing to open either schema.

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

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

Explicitly scopes usage to 'supplier, vendor or customer list screening' and rules out the loop-of-single-checks pattern. It stops short of naming the alternative tool (check_korean_business_status) or stating the size threshold at which to switch back, which would have earned 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 readOnly, idempotent and openWorld, so safety is covered. The description adds genuinely useful context beyond them: the data source (Korea National Tax Service, real-time) and a free-tier exemption for the Samsung test number, which is exactly the kind of operational detail annotations cannot express. Return values are partly described but the output schema already covers 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?

Three tight sentences, front-loaded with what it does, then what it returns and where the data comes from, then the practical testing note. No sentence is filler and nothing is buried.

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 an output schema and full annotations, the description covers purpose, source, freshness and a useful live-test example. The only gap is sibling differentiation against verify_korean_business, which an agent may hesitate between.

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

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

Schema coverage is 100% and the single parameter already documents the 10-digit format with hyphens/spaces and an example. The description restates the 10-digit requirement and adds the Korean term 사업자등록번호, but contributes no new syntax or constraints beyond the schema. 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?

States a specific verb and resource: check the registration status of a Korean business by its 10-digit registration number, and names the returned status values and tax type. It is clearly a single-record lookup, distinguishing it from the batch sibling, but it does not articulate how it differs from verify_korean_business or find_korean_business.

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 input form (having a 10-digit registration number) is implied clearly enough that an agent knows when this tool applies. However, there is no explicit statement about when to prefer verify_korean_business or find_korean_business, and no exclusions or prerequisites beyond the number format.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: results are ranked with a confidence score, ambiguity is expected ('Samsung Electronics' matches four), and the data comes from two named registries (DART, Public Procurement Service) — which explains coverage limits an agent would otherwise not anticipate.

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?

Front-loads the core purpose, then the usage condition, then the return shape and sources. The Samsung example is the one apparent indulgence but it concretely demonstrates the ambiguity the tool exists to resolve, so it earns its place. No filler.

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

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

With no output schema, the description carries the burden of describing return values and does so (ranked candidates, confidence score, discriminating evidence such as registration status, tax type, region). It also discloses data provenance, which is the remaining thing an agent needs to judge result trustworthiness.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the English/Korean name forms that the description repeats. The description's note that a name can match several distinct companies implicitly justifies the `limit` parameter, but it never discusses `limit` or its default directly, so the added meaning is indirect.

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

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

States a specific verb+resource (find a Korean company by name) and immediately scopes it against the rest of the toolset by noting it applies when the 10-digit registration number is unknown — 'the number every other tool here needs.' An agent can distinguish it from verify_korean_business and check_korean_business_status without opening any schema.

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

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

Gives an explicit selection condition (you do not know the registration number) plus the implied inverse: the sibling tools are the ones that need the number. It also sets expectations for the ambiguous case and names the upstream sources, so the agent knows when this is the right entry point.

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 carry the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds that it returns a match result plus current status, but with an output schema present that is partly redundant, and it omits key behavior: whether a non-matching or unregistered number returns match=false versus an error, and what "current status" values mean.

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

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

Two compact sentences with zero waste: the verification semantics come first, the usage context second. Nothing is padded or repeated from annotations.

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 an output schema present, return values needn't be spelled out, and the annotations cover the read-only/idempotent profile. What's still missing is the mismatch/not-found behavior and the meaning of the status field, which an agent would want before relying on the result for a due-diligence decision.

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%, including format hints (YYYY-MM-DD, 10-digit with hyphens allowed) and the NTS b_adr mapping for address, so the schema does the heavy lifting. The description only implies the three required matching inputs and adds no syntax or semantics beyond the schema.

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

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

States a specific verb (verify), resource (Korean business registration number), and the matching criteria (representative name + opening date), which distinguishes it from find_korean_business (lookup) and check_korean_business_status (status only). It stops short of naming those siblings explicitly, so the differentiation is inferred rather than declared.

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?

"Use for KYB / due-diligence before transacting with a Korean company" gives a clear decision context for when to reach for this tool. No exclusions or explicit alternatives are named, e.g. it doesn't say to use check_korean_business_status when only status is needed or check_korean_business_batch for multiple numbers.

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