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

With no annotations, the description relies on the verb '조회' (lookup) to imply a read-only operation and states the batch limit of up to 100. It does not disclose return format, error behavior, or operational requirements, leaving some gaps for a no-annotation 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 a single, front-loaded sentence that conveys the core function and use case without unnecessary detail. It is appropriately concise for a simple lookup tool.

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

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

Given the single required parameter and absence of an output schema, the description provides sufficient context: it states the batch limit and purpose. It does not elaborate on response content, but for a straightforward lookup tool this is acceptable.

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

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

The schema description covers the parameter fully ('사업자번호 목록 (최대 100)'), so baseline is 3. The tool description adds minimal parameter-specific meaning beyond confirming the batch use case, matching the array structure.

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 specifies '사업자 상태 일괄 조회' (batch lookup of business status) with a max of 100, clearly stating the verb, resource, and batch scope. It distinguishes from siblings like 'check_business_status' by emphasizing batch capability.

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 indicates the intended use case ('경비처리·정산 자동화용' – for expense processing and settlement automation), providing context. However, it does not explicitly mention alternatives or when not to use it, though the batch nature implies it's for bulk queries.

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 no annotations, the description carries the full behavioral disclosure burden. It does state that the operation is a read-only '조회' and lists the returned fields (status, tax type, closure date). However, it omits permission requirements, rate limits, and behavior for active or not-found businesses, leaving notable gaps.

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 short, front-loaded sentences. The first conveys the core function and outputs, and the second offers a lightweight usage-frequency signal. No filler or redundancy exists.

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

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

For a low-complexity tool with one well-documented parameter and no output schema, the description covers the essential purpose and expected return fields. It falls short only in not explicitly addressing sibling-tool selection or edge-case behavior, but the tool is simple enough that the description is largely complete.

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

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

Schema description coverage is 100% and the single parameter business_no is already described as '사업자등록번호'. The description adds no additional format, validation, or usage detail beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('조회' / query) and clearly names the resource and scope: business closure status, tax type, and closure date. This distinguishes it from siblings like batch_check_status and check_invoice_eligibility by specifying exactly what it returns.

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 only usage-related hint is '호출 빈도가 가장 높은 도구' (most frequently called tool), which is not actionable guidance. It does not explain when to use this tool versus batch_check_status, check_invoice_eligibility, or verify_business, and no exclusions are given.

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 no annotations, the description is the sole source of behavioral disclosure. It conveys that the tool synthesizes multiple factors (tax type, closure status) and outputs a determination with reasoning, but it does not address permissions, error behavior, or whether the operation is read-only, leaving gaps.

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

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

The description is concise and front-loaded, with the core function in the first sentence. The second sentence about being a differentiation tool is somewhat unnecessary but not verbose, so the overall structure is 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 simple with one parameter and no output schema. The description explains the core logic and mentions providing a rationale, which is helpful, but it does not specify the exact return structure or errors. Given the absence of annotations and output schema, this is moderately complete but not fully.

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

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

The input schema fully documents the single parameter business_no as '사업자등록번호' (business registration number), so schema coverage is 100%. The description adds no extra parameter nuance, matching the baseline score for fully covered schemas.

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 evaluates tax type and business closure status to determine eligibility for receiving tax invoices, and provides the rationale. It distinguishes itself by noting it is '순수 래퍼 대비 차별화 도구', implying a more integrated analysis than a simple wrapper, which sets it apart from sibling tools.

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

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

No explicit guidance is given on when to use this tool versus the sibling tools. The phrase about being a 'differentiation tool' relative to a pure wrapper is vague and does not mention alternatives, scenarios, or exclusions.

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

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

With no annotations, the description carries the full burden. It discloses that no API call is made, signaling a side-effect-free, static explanation. It also specifies the scope of tax types covered, which adds useful context beyond what the schema provides.

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 efficient sentences, opening with the core purpose and immediately adding the key behavioral note about no API calls. There is no redundant or filler content.

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

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

For a simple informational tool with one optional parameter and no output schema, the description is largely adequate. It covers the purpose and a key behavioral trait, but it does not indicate the output format or explicitly mention that omitting the parameter returns the full list (though the schema does). Given the low complexity, this is a minor gap.

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

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

The schema describes the parameter simply as '과세유형 문자열', but the description enriches it by enumerating the valid tax type values (일반/간이/면세/비과세). This additional context helps the agent understand what values to pass, exceeding 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's function: explaining the practical meaning of Korean tax types, listing the specific categories (일반/간이/면세/비과세). It uses a specific verb ('explain') and resource, and it is distinctly different from sibling tools that perform checks and verifications.

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 'API 호출 없음' (no API call) provides clear context that this is an informational reference tool rather than a data-fetching operation, implying it should be used for conceptual understanding. However, it does not explicitly name alternatives or state when not to use it, so it misses the top score.

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

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

No annotations are provided, so the description carries full burden. It discloses that the representative name is immediately discarded and not stored, which is a meaningful privacy behavior. However, it does not explicitly state whether the operation is read-only, if it triggers external calls, or if there are any side effects, leaving gaps in behavioral transparency.

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

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

The description is two concise sentences, front-loaded with the core purpose. Every sentence adds value: the first defines the function, the second provides a key privacy detail. No wasted words.

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

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

For a tool with three required parameters and no output schema, the description explains the verification logic and data handling but does not describe the return value or result format. It mentions '일치 여부' (match status) implicitly but does not specify whether the result is a boolean, status object, or something else, leaving a completeness 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%, providing full details for all three parameters (business_no, opening_date, representative_name). The description lists the same fields without adding new format or semantic details beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool verifies Korean business registration info by checking if input (business number, representative name, opening date) matches National Tax Service records. It distinctly identifies the resource and action, and the mention of matching against tax data differentiates it from sibling tools like check_business_status or batch_check_status.

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

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

The description implies usage for authenticating business registration details but does not explicitly state when to prefer this over siblings or any exclusions. It lacks guidance on when not to use it or alternatives.

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