APICK Business

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful non-annotation context: the per-call cost (100 points), the default country, and the 10-page pagination ceiling, all of which shape whether and how an agent calls it.

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 short sentences, front-loaded with what the tool returns before defaults and cost. The English/Korean duplication is redundant but conventional for this toolset and does not obscure the key 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 no-output-schema read tool, the description covers purpose, keying parameter, defaults, pagination limit, and cost. It omits return shape beyond a parenthetical field list, but that is a minor gap given the tool's simplicity and the read-only annotation.

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 each schema field already states its default and bounds (page 기본 1/최대 10, country 기본 kr, appId numeric). The description restates the same defaults, adding no syntax or format detail beyond the schema, so 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+resource (get iOS app metadata and customer reviews) and the keying scope (numeric app id), even enumerating the metadata returned (rating, price, genre). Among ~100 siblings, none covers iOS app reviews, so an agent can unambiguously route here.

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 is only implied: the description says what the tool fetches, so the agent infers it should be called when iOS app info/reviews are wanted. There is no explicit when-to-use framing, no when-not guidance, and no alternative named (though no close sibling 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 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?

Annotation readOnlyHint=false could look surprising for a 'get_*' tool, but the description discloses why: it bills on first result return (60P base, 0.5× per extra incomeYear) and re-queries within the validity window are free, matching idempotentHint=true. It also enumerates the outcome state machine (AUTH_WAITING/COLLECTING/RESULT_EXPIRED) and the expiry trigger, so the side-effect profile is fully clear.

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

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

Front-loaded with purpose, then behavior, then the billing note in brackets. Every sentence carries operational meaning, though the pricing formula and status enumeration make it dense; nothing is clearly removable but it is heavier than strictly necessary.

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

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

With no output schema, the description compensates by naming the return fields (resultAvailable, status, errorCode, result.cashReceiptDeduction, resultExpiresAt), so an agent knows both what to check and where the payload lives. Nothing needed for a correct async-fetch call 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?

Only one parameter and schema coverage is 100%, so the format/pattern burden sits on the schema. The description confirms that transactionId must come from the req_cash_receipt_deduction response, but that origin is already stated in the schema description, so it adds little beyond the baseline.

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 (조회한다 – 조회 of approval status and deduction result) and explicitly anchors the tool to the req_cash_receipt_deduction transactionId, cleanly distinguishing it from the sibling that creates the request. An agent can tell this is the polling/result-fetch half of a two-step flow without opening the 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 status-driven calling protocol: AUTH_WAITING means wait for phone approval, COLLECTING means re-query with the same ID shortly after, RESULT_EXPIRED means a new authentication request is required. This is exactly the when/when-not guidance an agent needs to avoid mis-calling 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?

Goes well beyond the annotations by disclosing the billing model (charged on first result return, free re-query within the validity period), the state machine (AUTH_WAITING/COLLECTING/RESULT_EXPIRED), the fields to check (resultAvailable, status, errorCode), and where the payload lives (result.drivingLicense). This explains why readOnlyHint=false despite the 'get' framing, so there is no contradiction.

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

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

Front-loaded with purpose and then state handling, all in a compact block. The trailing bracketed clause restates the billing/re-query rule already stated earlier, a minor redundancy that keeps it just short of 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 carries the full burden and does so: it names the status states, the billing conditions, the response fields, the payload location, and the expiry behavior. Nothing an agent needs to poll and interpret this tool 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 description coverage is 100% and the schema already states that transactionId comes from the req_driving_license response. The description repeats that linkage but adds no format or syntax detail beyond it, 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?

States a specific verb and resource (retrieve approval status and driver's license result) and explicitly anchors it to the sibling req_driving_license as the source of the transactionId. An agent can tell this is the polling/result-retrieval counterpart to the request tool without opening 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?

Gives explicit state-dependent instructions: wait for mobile approval on AUTH_WAITING, re-query with the same ID shortly on COLLECTING, and start a new authentication request after RESULT_EXPIRED. The entry condition (obtain transactionId from req_driving_license) and the free re-query window are both named, leaving little 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?

Discloses behavior that annotations cannot convey: first result return triggers billing, re-query within the validity window is free, RESULT_EXPIRED is returned after resultExpiresAt, and which fields (resultAvailable, status, errorCode) should be inspected. This explains the otherwise puzzling readOnlyHint=false annotation for what looks like a read operation.

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

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

Dense and front-loaded: purpose, state machine, billing, and return fields in a tight sequence. The only waste is the bracketed billing sentence at the end, which restates the billing/refund rule already stated earlier in the description.

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

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

With no output schema, the description carries the full burden and does so: it names the result container (result.employment), the status fields, the error codes, and the expiry behavior. An agent has everything needed to poll correctly and interpret the response.

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 is fully documented in the schema, including its origin and the 32-hex-character format. The description restates that the transactionId comes from req_employment but adds no format or usage detail beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb+resource: it queries approval status and employment/insurance verification results using a transactionId. It also implicitly distinguishes itself from the sibling req_employment by naming that tool as the source of the required transactionId, so an agent knows this is the poll/result side rather than the initiation side.

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 concrete state-dependent guidance: on AUTH_WAITING wait for phone approval, on COLLECTING retry shortly with the same ID, and after resultExpiresAt a new authentication is required. It does not explicitly state that req_employment must be called first as a prerequisite step, but the dependency is clear from the parameter origin.

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?

Adds behavioral facts well beyond the annotations: billing is triggered by the first successful result return, re-query within the validity window is free, and expiry is signaled with RESULT_EXPIRED. This is exactly the kind of cost/side-effect context the readOnlyHint=false annotation alone cannot convey, and nothing contradicts 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?

Front-loads the purpose, then state handling, then billing and field guidance; every sentence carries actionable information. It is dense but not padded, though the bracketed billing restatement at the end is mildly redundant.

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

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

With no output schema, the description compensates by naming the fields to inspect (resultAvailable, status, errorCode) and where the payload lives (result.healthCheckup), plus the expiry field resultExpiresAt. An agent needs nothing more to call and interpret this 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% and the single transactionId parameter already documents its source and 32-char hex format, so the description adds little parameter-level meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Names a specific verb (조회) and resource (국가 건강검진 결과 조회 결과 / approval status) and scopes it by the req_health_checkup transactionId, which cleanly separates it from the sibling requisition tool req_health_checkup. An agent can tell exactly what this returns without opening the 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 explicit state-driven guidance: AUTH_WAITING means a phone approval is pending, COLLECTING means re-query with the same ID shortly, and RESULT_EXPIRED means a new authentication submission (req_health_checkup) is required. The polling/retry behavior is spelled out rather than 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 declare openWorldHint=true, idempotentHint=true, destructiveHint=false and readOnlyHint=false, and the description reinforces the read-but-billed nature with the 'billed on first result, free re-queries within validity' note. It also discloses polling states, error codes, and expiry behavior. However, the billing/readOnly nuance is the only place it goes clearly beyond the annotation layer, so this is a solid but not exceptional 3-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?

Front-loaded with the purpose, then walks through status handling, billing, result location, and expiry in a logical order. Slightly redundant: the billing point is restated in the bracketed closing note, which repeats the earlier sentence rather than adding 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?

With no output schema, the description must carry the return contract, and it does: it names resultAvailable, status, errorCode, the result.npsJoinHistory path, and resultExpiresAt with the RESULT_EXPIRED terminal state. An agent has everything needed to call and interpret this polling 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% and documents the transactionId format (16-byte lowercase hex, 32 chars). The description adds useful provenance — that the id comes from the req_nps_join_history response for the same product — which the schema does not state.

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 (retrieve approval status and NPS join history result) via the transactionId issued by req_nps_join_history. It explicitly distinguishes itself from the sibling req_nps_join_history by naming it as the source of the id, so an agent can separate the request step from the result-retrieval step.

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

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

Gives explicit conditional guidance: AUTH_WAITING means wait for mobile approval, COLLECTING means re-query shortly with the same ID, and RESULT_EXPIRED after resultExpiresAt means a fresh authentication request is needed. When-to-call and what-to-do-next are both spelled out.

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?

Discloses billing behavior (charged on first result return, free re-queries within validity), the expiry behavior (RESULT_EXPIRED after resultExpiresAt), the polling states, and where the payload lives (result.personalIncome). It also notes re-auth is required after expiry. This goes well beyond the annotations. The readOnlyHint=false vs. a pure read query is slightly at odds but explainable by billing side effects, so no contradiction.

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

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

Four dense Korean sentences, front-loaded with the core action, then state handling, then billing, then result location. The bracketed repetition of the billing rule is redundant with the earlier sentence but otherwise contains 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?

Covers everything an agent needs for a single-param polling/result tool: the producing sibling, the polling states and re-query cadence, the billing trigger, the expiry failure mode, and the result field location. No output schema exists, yet the description still points to the key result fields (resultAvailable, status, errorCode, result.personalIncome).

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 baseline is 3; the description adds real value by tying transactionId's provenance to req_personal_income's response and by clarifying that the same ID can be reused within the validity window, which the schema does not state.

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?

Specifies a clear verb (조회) and resource (금융소득 조회 결과), and explicitly distinguishes itself from its sibling req_personal_income by positioning itself as the result-retrieval tool that consumes the transactionId produced by req_personal_income. An agent can tell the pair apart without inspecting schemas.

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 explicit when-to-use routing: on AUTH_WAITING wait for mobile approval; on COLLECTING re-query later with the same ID; on RESULT_EXPIRED submit a new authentication (req_personal_income). This is a full state-machine guide, not just a hint.

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?

Adds substantial behavior beyond the annotations: a billing model (charged on first result, free re-queries inside the validity window), the set of fields to inspect (resultAvailable, status, errorCode), where the payload lives (result.taxReturnHistory), and the expiry/error behavior. The non-readOnlyHint is consistent with the described charging, so there is no contradiction.

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

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

Front-loads the core action and keeps every sentence functional, but the appended bracketed pricing formula is dense and slightly crammed onto the end rather than integrated. No true filler, though.

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 full burden and does so: it names the returned fields, the expiry field, the expiration error code, and the billing consequence. An agent has everything needed to poll, interpret, and re-drive the workflow.

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 pattern is documented, so the baseline is 3; the description still adds value by explaining provenance (the ID returned by the same-product req_tax_return_history call) and the retry-with-same-ID rule that the schema cannot express.

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 (retrieves the approval status and national-tax-filing lookup result for a transactionId) and explicitly ties it to the sibling req_tax_return_history that produces the ID. An agent can distinguish this polling/result tool from the request tool without opening 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?

Gives explicit when-to-use and state-machine routing: AUTH_WAITING means waiting on phone approval, COLLECTING means retry later with the same ID, and after resultExpiresAt a RESULT_EXPIRED forces a new auth request. It also states the alternative (re-request via req_tax_return_history) for the expired case.

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

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

Annotations already declare readOnlyHint=true 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?

Annotations only declare the safety profile (not read-only, not idempotent, open-world). The description adds high-value behavior beyond that: an approval-flow (returns transactionId/status, requires mobile approval), a non-idempotency warning (don't repeat the request), and a cost/notification disclosure (휴대폰 알림 발송, 20P billed on successful send regardless of lookup range).

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 purpose, then the cost/risk warning, then the async flow and its warnings. Every sentence carries distinct operational value with 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?

Even without an output schema, the description discloses the returned artifacts (transactionId and status), the required follow-up call, and the billing caveat, which is everything an agent needs to invoke and sequence this asynchronous authentication 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% and every parameter carries its own description, so the schema does the heavy lifting. The description adds no field-level syntax or constraints, making the baseline 3 correct.

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 the exact resource (현금영수증 소득공제 내역), and is clearly the authentication-request step of a two-stage flow. It is distinguishable from the sibling get_cash_receipt_deduction, which it explicitly names as the subsequent step.

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

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

Gives explicit when-to-use (call after user confirmation), when-not (do not repeat requests while approval is pending, do not auto-approve), and the alternative/next step (pass transactionId to get_cash_receipt_deduction after approval). Nothing is 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 declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true; the description adds mobile notification dispatch, 20-point per-call billing, async phone approval flow, and prohibition on auto-approval, providing rich side-effect context beyond structured fields.

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?

Compact structure front-loads purpose, then billing warning, approval flow, prohibition, and cost; every sentence earns its place.

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

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

No output schema exists, but the description explains return values (transactionId and status), the required handoff to get_driving_license, and operational constraints; complete for an async billable authentication 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 all four required parameters documented, so the schema carries parameter meaning; the description adds no syntax or format detail for name, birthDate, phone, or authProvider.

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 (request identity verification) and resource (driver's license lookup), and explicitly names get_driving_license as the downstream tool, distinguishing it from siblings.

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 says to call after user confirmation, not to repeat while approval is pending, not to auto-approve, and to pass transactionId to get_driving_license after approval.

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 mark it non-read-only and non-idempotent, and the description adds concrete behavioral facts beyond them: a phone push notification is sent, a per-call charge of 20 points applies, and transactionId plus status are returned. It does not cover edge cases like auth failure or expiry, so a small gap remains.

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 purpose, then the cost caveat, the return values, and the flow into get_employment, with no filler sentences. It is dense but every clause carries actionable information, so it stays readable despite the packing.

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 async, side-effecting authentication request with no output schema, the description supplies the return values (transactionId, status), the user-confirmation prerequisite, the cost, the anti-repeat rule, and the downstream tool, so an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so all five parameters (name, phone, birthDate, authProvider, insuranceYears) are already documented in the schema. The description adds no parameter-level meaning such as format or default behavior, 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?

States a specific verb (요청) and resource (재직·보험료 확인 본인 간편인증) and clearly distinguishes this initiation step from the sibling get_employment, which it names as the follow-up retrieval call. An agent can tell exactly what this tool does without opening the 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 explicit when-to-use (after user confirmation, since notification/cost occur), the required follow-up (pass transactionId to get_employment after phone approval), and explicit when-not-to (do not repeat requests while approval is pending, do not auto-approve). This is a full routing instruction with 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?

Despite annotations covering the safety hints, the description adds high-value behavioral context the annotations cannot: a phone notification is dispatched, per-call billing of 20 points applies, the call returns transactionId/status in an async approval flow, and retries/auto-approval are prohibited. This materially informs invocation decisions.

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 purpose and cost warning, then the workflow and prohibitions; every sentence carries operational value. Slightly dense with several clauses, but nothing is redundant.

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

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

With no output schema, the description compensates by naming the returned fields (transactionId, status) and explaining the next step, fully describing this half of a two-step asynchronous flow. Nothing an agent needs to call it 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 description coverage is 100% with four fully documented required params and an enum for authProvider, so the schema does the heavy lifting. The description adds no syntax or format detail beyond what the schema already provides, matching the baseline 3.

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

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

States a specific verb (request simple identity verification) and resource (national health checkup result lookup), and clearly distinguishes this prerequisite step from the get_health_checkup sibling it feeds into. An agent can tell the two apart without opening 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?

Explicit routing guidance: call only after user confirmation, do not repeat requests while approval is pending, do not auto-approve, and after approval pass transactionId to get_health_checkup. Covers when-to-use, when-not, and the named downstream alternative.

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

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

Annotations only tell it is not read-only and not idempotent. The description adds crucial beyond-schema behavior: SMS push notification is sent, billing is incurred (접수 과금, 호출당 20포인트), returns transactionId+status, and warns against duplicate auto-approval requests. This is exactly the extra context annotations cannot express.

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?

Tight, front-loaded sequence: purpose → caution → return value/next step → prohibition → cost. Every sentence earns its place with zero 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?

For a cost-incurring, async, user-confirmation-gated auth-initiation tool with no output schema, the description covers purpose, prerequisite (user confirmation), return values (transactionId, status), handoff to get_nps_join_history, anti-patterns, and cost. Nothing an agent needs to call it 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 description coverage is already 100% with all six params documented, so description adds no param-level detail. It does mention transactionId/status as outputs, which is helpful since no output schema exists, but does not explain the from/to query range parameters 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 (요청/인증 요청) and resource (국민연금 가입내역 조회). Clearly distinguishes itself from the sibling get_nps_join_history by naming it as the follow-up step, and from other req_* sibling tools.

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

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

Explicitly tells when to call (사용자 확인 후), how to proceed after (휴대폰 승인 안내 후 get_nps_join_history에 transactionId 전달), and what not to do (승인 대기 중 반복 요청, 자동 승인 금지). Alternative/sibling routing is named directly.

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?

Annotations declare non-read-only, non-idempotent, open-world, non-destructive, but the description adds what the structured fields cannot: per-call cost (호출당 20포인트), a real side effect (휴대폰 알림 발송 및 접수 과금), and the explicit warning not to retry while pending — which is the practical consequence of idempotentHint=false. No contradiction.

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

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

Five compact sentences ordered as purpose → cost warning → return/next-step → prohibition → price tag. No filler, and the cost caveat is placed early enough to gate the call.

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 5-param authentication-request tool with no output schema, the description supplies the return shape (transactionId, status), the follow-up tool, and the cost. There is no output schema to omit, and nothing an agent needs to invoke it 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 description coverage is 100%, so name, birthDate, phone, authProvider, and incomeYears are already documented, including patterns and enum values. The description adds no field-level syntax or defaults beyond what the schema provides, 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?

States a specific verb and resource (본인 간편인증 요청) scoped to 금융소득(이자·배당) 조회, which cleanly separates it from the sibling get_personal_income that performs the actual retrieval. An agent can tell from the first sentence that this is the authentication handshake, not the data fetch.

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?

Explicit preconditions ('사용자 확인 후 호출하세요'), the downstream flow (return transactionId/status → phone approval → pass transactionId to get_personal_income), and a negative rule ('승인 대기 중 인증 요청을 반복하거나 자동 승인하지 마세요'). When-to-use, what-follows, and when-not-to are all covered.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false. The description adds substantive behavior annotations do not carry: a phone notification is dispatched, a 20P fee is incurred on send success (independent of lookup scope), the call returns transactionId and status, and repeated or automated approval requests are prohibited.

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?

Purpose comes first, followed by the cost/precondition warning, the return-and-handoff flow, and the prohibition. Every sentence carries actionable content with no filler, and the bracketed cost note is compactly placed.

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

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

There is no output schema, but the description compensates by stating the return payload (transactionId and status) and the downstream step needed to finish the flow. For an asynchronous identity-auth request, the agent has everything required to invoke it correctly and safely.

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 each of the five parameters (name, phone, birthDate, authProvider, years) is documented in the schema itself, including the enum values and patterns. The description adds no per-parameter meaning beyond that, 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 names a specific action (request simple identity authentication) and a specific resource and scope (national tax return history lookup), so it is immediately distinguishable from the sibling get_tax_return_history, which consumes the result of this call rather than initiating it.

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 states explicit conditions: call only after user confirmation, do not repeat the request while approval is pending, do not auto-approve, and after approval pass transactionId to get_tax_return_history. Both the when-to-use and when-not-to-use cases, plus the handoff to the alternative tool, are spelled out.

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.