APICK

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it is limited to Korean bank accounts, requires either bank_code or bank_name, and costs 60 points per call. It does not describe failure behavior, but for a read-only lookup with clear annotations this is acceptable.

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 action and purpose, followed by the key input constraint and cost. The Korean sentence duplicates the English sentence, which is somewhat redundant, but the bilingual structure is purposeful for the target domain and does not add excessive length.

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

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

The tool has 3 parameters, all fully documented in the schema, and read-only annotations. The description adds the remaining essential context: Korean bank scope, remittance-check use case, the bank_code/bank_name precondition, and point cost. No output schema exists, but the expected result is clear from the stated purpose. Error-case details are not critical for this read-only lookup.

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 meaningful semantics beyond the schema by clarifying that bank_code or bank_name is required even though both are optional in the JSON schema. It also reinforces the account_num format requirement indirectly by mentioning the Korean bank account context.

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 specific action and resource: 'Look up the account holder name of a Korean bank account.' It also adds the practical context of verifying the account holder before remittance, which distinguishes it from nearby identity/name tools like name_rrn_auth.

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 an explicit use case: '송금 전 예금주 확인 등에 사용합니다' (used for verifying account holder before remittance). It also states a necessary precondition: 'bank_code 또는 bank_name 중 하나는 입력해야 합니다' (either bank_code or bank_name must be entered). It does not explicitly mention alternatives or when not to use the tool, so a small gap remains.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the non-obvious cost signal '[호출당 20포인트]' (20 points per call), which is real behavioral context an agent needs and cannot get from structured fields. It still does not describe rate limits or error behavior.

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?

Content is front-loaded with the retrieval scope before the field list, and each element earns its place. The main inefficiency is full duplication across English and Korean, which pads length without 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's enumeration of returned fields (title, price, rating, reviews, availability, seller, features, images) usefully compensates by telling the agent what a call yields. Combined with annotations covering the open-world read profile and the stated per-call cost, it is largely complete for a simple two-parameter lookup.

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 one of url or asin is required (including the /dp/ASIN format and ASIN length). The description merely restates 'URL or ASIN' without adding syntax or precedence 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?

States a specific verb (조회/retrieve) and a specific resource (Amazon product), and it enumerates the exact fields returned (title, price, rating, reviews, availability, seller, features, images). The Amazon/URL-or-ASIN scoping distinguishes it from generic search siblings like google_shopping_search, though it never names an alternative explicitly.

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 'by URL or ASIN' phrasing implies the input condition under which the tool is used, but there is no explicit guidance on when to prefer it over google_search, google_shopping_search, or how it relates to amazon_reviews_create. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely non-structured information: a per-call cost of 30 points and the 10-page review cap, both of which affect invocation decisions. It does not say how many reviews per page or whether results are paginated/sorted, keeping it below 5.

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?

Short and front-loaded: what it does, what it returns, defaults, and cost in that order. Minor waste from the English and Korean sentences largely restating each other, though the Korean version does add field detail (rating, price, genre).

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, and the description does cover both halves of the return (app metadata fields and customer reviews), the cost, and the pagination limit. Missing only secondary details like reviews per page or ordering, which is acceptable for a simple 3-parameter read 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%, so page, appId and country are already documented with defaults and bounds in the schema. The description restates the same defaults (country kr, page max 10) without adding format, semantics or edge-case guidance, 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 and resource ('Get iOS app metadata and customer reviews'), plus the keying mechanism ('by numeric app id'). The 'iOS' scope and 'reviews' payload clearly separate it from the many product/metadata siblings (amazon_product, coupang_product, youtube_metadata) without needing those names.

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: it describes defaults (country=kr, page up to 10) and cost, so an agent can infer this is a read call on a known App Store id, but there is no explicit when-to-use or when-not-to-use statement and no named 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 already establish the read-only, open-world nature, so the description needs only add extra behavioral context. It adds that the tool is free and that it returns the complete bank list for use as an input reference. It doesn't describe response structure or update behavior, but these are minor for a zero-argument list tool.

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

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

The main purpose is front-loaded and clear, and the use case is useful. However, the same information is repeated in English and Korean, and '무료입니다. [무료]' duplicates the free notice, adding minor noise.

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 tool, the description is functionally complete: an agent knows what it returns, why it exists, and that it costs nothing. Without an output schema, a sample return shape would be a nice addition, but the stated purpose 'bank codes and names' adequately implies the output.

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 takes no parameters, so there are no parameter semantics for the description to illuminate. The baseline for zero-parameter tools is 4, and the description correctly focuses on the output data instead.

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 concrete verb and resource: 'List Korean bank codes and names,' and further clarifies it returns the full list ('전체 목록을 반환합니다'). This clearly distinguishes bank_code from the many sibling tools and states exactly what data is returned.

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 the intended use case: finding the bank_code input value for transfer_1won and account_realname. It stops short of giving exclusions or comparing to alternatives, but no sibling provides a comparable bank-code lookup, so this is sufficient direction.

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 useful behavioral details beyond the annotations: it accepts strings with a 'data:image/type;base64,' prefix and mentions a per-call point cost. The readOnlyHint annotation is consistent with a decoding operation. It does not mention error behavior or output delivery, but the core behavior is transparent.

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-loads the core action, then adds the prefix allowance and cost note. The English and Korean sentences repeat the same meaning, which is slightly redundant, but the overall size is still appropriate and every distinct piece of information is useful.

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 utility with annotations, the description provides enough context: what the tool does, input tolerances, and cost. It lacks explicit output format or failure behavior, but since the return is described as an image file, this is reasonably complete for the tool's complexity.

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

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

The schema already covers 100% of the single parameter's meaning, including the accepted data-prefix format. The description repeats essentially the same information without adding new semantic detail, so the baseline score of 3 is appropriate.

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

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

The description states a precise transformation: 'Decode a base64-encoded image string back into an image file.' The verb is specific, the resource is clear, and no sibling tool performs base64 decoding, so the purpose is unambiguous and well differentiated.

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 intended use is implied—decode a base64 image string when you need the original image file—but there is no explicit when-to-use or when-not-to-use guidance, nor any named alternatives. It is enough for a simple, unique utility but does not actively guide selection.

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 and openWorldHint; the description adds real behavioral context beyond them: the exact response sections (summary, distribution, competitors, low_rate, insights), the explicit exclusion of raw listings, and the cost of 50 points per call, which matters for a metered API.

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 analysis scope, then the return shape, then the cost caveat. The English and Korean text largely mirror each other, but the Korean portion carries unique details (median rate, HHI, response keys, no raw list, pricing), so it is not pure duplication.

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

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

With no output schema, the description compensates by naming all five response sections and stating what is excluded. The remaining gap is pagination: pageNo/numOfRows are offered but it is unclear whether they paginate aggregates or are ignored, which is genuinely ambiguous for a statistics endpoint.

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 carries parameter meaning (bizType enum with default, date formats, pageNo/numOfRows defaults). The description adds nothing about how date ranges or bizType scope the analysis, 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 and resource ('Analyze Korean public-sector award results') and enumerates the concrete analyses: success-rate distribution/averages, winner concentration (HHI), and low-rate notices. The note that it returns no raw listings functionally separates it from a raw notice lookup, though the sibling bid_notice is never named.

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 implied by the 'no raw list provided' caveat, which tells the agent this is for aggregate statistics rather than enumerating postings, but there is no explicit when-to-use/when-not or a named alternative (e.g., bid_notice) for retrieving the underlying records.

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 establish readOnlyHint and openWorldHint, but the description adds genuinely non-structured context: the exact response sections (summary·distribution·deadlines·largest·insights), an explicit negative behavior (no raw notice list is returned), the implicit default filter, and a per-call cost of 50 points. That is substantive disclosure beyond the annotations, though permission/rate-limit or pagination interaction details are absent.

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 scope statement and the exclusion of raw listing are front-loaded, and the cost note is a tidy trailing marker. The full English-to-Korean duplication of the opening sentences repeats information without adding any, which slightly inflates length.

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 7 optional parameters and no output schema, the description compensates by naming the return sections and the no-raw-list constraint, which is the most important thing an agent needs. The remaining gap is that it never says what date window applies when startDate/endDate are omitted.

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 baseline is 3. The description restates the bizType default already documented in the schema and otherwise says nothing about how bidNtceNo, date ranges, or indstrytyCd interact with the aggregate analysis. It adds no meaning 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 ('Analyze Korean public-sector bid notices') and enumerates the analytic dimensions: budget bands, agencies, industries, closing urgency, largest opportunities. It also explicitly distinguishes itself from a listing tool by stating '공고 원문 목록은 제공하지 않습니다'. It does not name the sibling tool (e.g., bid_award), which keeps it just 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?

Provides useful default-behavior guidance ('bizType 을 생략하면 용역 공고를 분석합니다'), which tells the agent what happens when a key filter is omitted. However, it never states when to choose this tool over alternatives or which situations it is unsuitable for; the agent must infer the boundary with bid_award and other bid-related tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and external data access. The description adds important behavioral context beyond annotations: a cost of '[호출당 50포인트]' per call and that financial_info=Y returns corporate financial data at no extra charge. 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 purpose is front-loaded in the first sentence and the cost is placed last. The Korean sentence largely duplicates the English purpose, which adds length without new information for non-Korean readers, but the structure is otherwise 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?

With no output schema, the description usefully enumerates returned fields (대표자, 주소, 직원수, etc.) and covers cost and the optional financial_info behavior. It omits error-handling details beyond the financial_info case, but is otherwise complete for a simple read-only lookup.

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 biz_no format and financial_info behavior are fully documented in the schema. The description repeats financial_info=Y but adds no syntax or format details beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb ('Look up') and resource ('general status information of a Korean business'), keyed by the '10-digit business registration number', and lists returned fields. It does not explicitly differentiate itself from potential siblings such as venture_biz_info, so it falls 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?

The description explains what the tool retrieves and what financial_info=Y does, but gives no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. Like the calibration example for update_drive, usage is only implicitly inferable from the purpose.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds two things annotations cannot: a per-call cost of 30 points and the precedence rule that supplying PNU causes bunji fields to be ignored. Those are material behavioral facts for planning a call.

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 the purpose and then the input requirement and cost. No filler or repetition, though the enumeration of ten register types is dense and could arguably be left to the enum.

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 14-parameter lookup with no output schema and read-only annotations, the description covers purpose, required inputs, type-scoping, and cost. It stops short of describing the shape of the returned register records, but the type enumeration and annotations make it usable as-is.

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 14 parameters including type-specific fields. The description restates the PNU (19-digit) vs sigunguCd·bjdongCd requirement but adds no format or syntax detail beyond what the schema provides, 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 (look up) and resource (Korean building register) and enumerates the ten register types matching the `type` enum, so the agent knows exactly what is returned. It does not name any sibling to contrast with, but the resource is distinct enough from tools like registry_realestate_search or land_rt_price to avoid confusion.

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 the required input combination (PNU or sigunguCd·bjdongCd) and the address-based path, which is genuine usage context. However, it never says when to prefer this over alternatives such as registry_realestate_search or land_rt_price, so selection guidance is only implied.

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 declare readOnlyHint and openWorldHint, and the description adds genuinely new behavior: it returns a formatted/normalized number plus carrier and line-type analysis, and it discloses a per-call cost of 40 points. Missing is what happens on an invalid number (error vs. negative result), which would complete the picture.

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 and short, with the useful cost tag at the end. The Korean sentence largely restates the English one, which is redundant for an agent, though it may be an intentional localization choice.

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 only names three of the outputs without structure or error behavior. Adequate for a single-parameter lookup, but the return semantics remain underspecified.

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's format (domestic 010..., overseas +country code) is already documented in the schema. The description adds no syntax or constraint 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?

States specific verbs (validate, format) plus the resource (phone number) and the extra outputs (carrier, line type), so the agent knows exactly what it gets. It is implicitly distinct from check_email_valid and check_spam_number by resource, but it never names a sibling to sharpen the boundary.

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 says what the tool does but never states when to choose it over alternatives or any prerequisites. No guidance on when-not to use it, or how it relates to check_spam_number, which also concerns phone numbers.

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 declare readOnlyHint and openWorldHint, so the safety profile is free. The description earns credit by disclosing the cost model ('[호출당 50포인트]') and by enumerating the derived metrics returned, which annotations do not cover. It stops short of stating data freshness, failure behavior, or return shape, so 4 rather than 5.

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

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

Two sentences: the first front-loads the verb, resource and identifying inputs; the second enumerates output content and cost. Nothing is padded, though the bilingual duplication (English action line + Korean detail line) costs a little compactness. The cost tag is well placed at the end.

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 read-only 4-parameter tool with 100% schema coverage and no output schema, the description covers inputs, returned statement set, derived ratios and per-call cost — enough to call it correctly. Gaps are minor: no guidance on missing-data behavior or on what 'all' produces versus a single statement section.

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 crno format, the type/scope enums and the bizYear default are all documented in the schema. The description only restates the crno+year pairing at a high level and adds no format, edge-case, or defaulting information beyond it. 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 verb and resource ('Get a company financial package') and enumerates exactly what is included: 요약재무제표, 재무상태표, 손익계산서, plus computed 부채비율·영업이익률·ROA·ROE and growth rates. This clearly separates it from generic business-lookup siblings, though it never names a sibling it should not be used in place of.

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 implied: call it with a 법인등록번호 and optional year to obtain statements and ratios. There is no explicit when-to-use/when-not, no mention of alternatives such as biz_detail or venture_biz_info, and no prerequisite guidance, so the agent must infer the boundary itself.

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 genuinely new behavioral context not present in structured fields: the per-call cost (30 points) and a full enumeration of returned fields in the absence of an output schema. It does not cover failure modes for bad URLs/IDs, which keeps it from a 5.

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 field list is front-loaded and informative, but the entire description is duplicated verbatim in English and Korean, roughly doubling its length without adding information. Placement of the cost note at the end is reasonable, but the redundancy is a real efficiency cost.

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 correctly compensates by enumerating the returned fields, and it adds cost information the annotations lack. Combined with annotations covering the read-only/open-world profile, an agent has nearly everything needed; only error behavior and invalid-input handling are unaddressed.

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 url and product_id, including the 'one of these is required' constraint in Korean. The description only restates the two input modes ('by URL or product id') without adding syntax, format, or precedence rules, 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 resource (Coupang product) and enumerates the exact data returned (title, prices, discount, rating, reviews, stock, seller, options, categories, images), so the agent knows exactly what it retrieves. The vendor name implicitly separates it from amazon_product and naver_shopping_product siblings, but it never explicitly contrasts them, 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?

There is no statement of when to use this tool versus amazon_product or naver_shopping_product, and no prerequisites or exclusions are given. The only usage-adjacent information ('by URL or product id') is really input format, not selection guidance, so an agent must infer the Coupang-only scope from the name.

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 genuinely useful behavior beyond the readOnlyHint/openWorldHint annotations: a missing case returns result 0·count 0 rather than an error, and the call is not billed in that case. It also discloses cost ([호출당 60포인트]). However, it says nothing about auth requirements, rate limits, or response shape, so the addition is solid but partial.

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 purpose sentence is front-loaded and the field list is compact. The Korean sentence largely re-states the English with the field enumeration, so there is some bilingual redundancy, but nothing is padded or 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 2-parameter read-only lookup with no output schema, the description covers purpose, returned data fields, empty-result semantics, and per-call cost — enough to call it correctly. The main residual gap is not saying what the caller needs (auth/key) or how court names are matched.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema (court as name-or-code, case_no with year/부호/number format). The description only restates '사건번호와 법원(이름·코드)' without adding syntax, format, or validation detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource (look up a Korean court auction case) plus the identifying keys (case number, court) and enumerates the returned fields (기본정보·매각기일·감정평가액·최저매각가격·진행상태). It is clearly distinguishable from the bid_award/bid_notice siblings by domain, but it never names or contrasts those siblings explicitly.

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: an agent infers it should call this when it has a 사건번호 and a 법원. There is no explicit when-to-use, no prerequisites (e.g., which court codes are valid), and no routing away from related tools like bid_award or bid_notice.

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 annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-fetch behavior are covered. The description usefully adds the per-call cost ('[호출당 40포인트]'), which annotations cannot express, but says nothing about how many 'latest' videos are returned or any fetch/rate constraints.

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

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

Two sentences plus a bracketed cost marker, front-loaded with the purpose before the cost. The English and Korean sentences are semantically duplicates, which is mild redundancy but justified for a bilingual audience.

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

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

With no output schema, the description should say more about what comes back – profile fields, number of videos, ordering, or truncation. It covers the input and the cost adequately but leaves the return contract underspecified for an agent that must consume the result.

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 a single required user_id whose description already enumerates accepted forms (handle, channel ID, URL, e.g. CNN). The description adds no parameter meaning 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?

States a specific verb ('look up') and resource ('YouTube channel profile and its latest uploaded videos'), and adds scope beyond a plain channel-info lookup by including recent videos. However, it never distinguishes itself from the sibling youtube_channel (or youtube_search), so an agent must guess which one to pick for basic channel 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives despite several obvious siblings (youtube_channel, youtube_search, youtube_metadata). The only routing-adjacent information is the cost note, which tells the agent nothing about when this tool is the right choice.

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 annotations already declare readOnlyHint=true and openWorldHint=false, and the description does not contradict them. It adds useful behavioral context beyond annotations: it converts and returns the PDF, accepts only DOCX input, and costs 80 points per call.

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 English action, but the Korean sentence largely repeats the same conversion statement. The cost note and format restriction are useful, but the bilingual redundancy makes the description less concise than it could be.

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

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

For a low-complexity tool with one fully documented parameter, no nested objects, and no output schema, the description plus schema is complete. The agent knows what input is required, what the tool returns, what restrictions apply, and what the call costs.

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 docx_url parameter already documents the downloadable HTTPS URL, allowed MIME type, and 25MB limit. The description adds no meaningful parameter semantics beyond reaffirming the DOCX-only restriction.

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 (convert), a specific source resource (DOCX), and a specific target format (PDF). This makes it easy to distinguish from reverse operations like pdf_to_docx and other conversion tools such as html_to_pdf.

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

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

The description provides no explicit when-to-use or when-not-to-use guidance and does not name alternatives for reverse conversion. The only guidance is the input restriction that exactly DOCX files are allowed, which is a constraint rather than usage-direction 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 include readOnlyHint=true, which is consistent with a tool that returns a transformed PNG rather than modifying the source. The description adds format support (PNG, JPEG), adjustable parameters, and a per-call point cost, which is useful context. It does not explain potential failure modes, image size limits beyond the schema, or whether the returned PNG is a download URL or base64 payload, so it stays at a moderate level.

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

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

Two sentences plus a short cost note. It is compact and front-loads the core action. The cost note is extra but relevant for agent decision-making. Slightly redundant with schema field descriptions, but not 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 an image transform tool with a 100% documented schema and readOnlyHint, the description covers the essential behavior, supported formats, and adjustable attributes. It does not describe return format details, but with no output schema and a simple visual transformation, the gaps are minor. Sibling differentiation is sufficient via the image/PDF distinction.

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 every parameter is already documented with type, range, and default. The tool description repeats the general concepts of size, color, opacity, density but adds no syntax or behavioral detail beyond the schema. 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 uses a specific verb ('Draw') and a concrete resource ('a visible text watermark across an image'), and it states the output is a PNG image. It is clearly distinct from draw_watermark_pdf, which is a sibling, because it specifies image files. It could name the sibling explicitly, but the resource difference is already 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?

The description implies usage for adding visible text watermarks to images and lists supported image formats and adjustable attributes. It does not explicitly state when to use this tool over draw_watermark_pdf or set_watermark, but the image-vs-PDF distinction is clear from the description and sibling name. No explicit exclusions or alternative routing, but enough context for a typical agent.

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

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

Annotations provide readOnlyHint=true, and the description is consistent with it by stating a new artifact is returned ('삽입한 PDF 를 반환합니다') rather than implying mutation of the source. Beyond the annotation, the description adds useful behavioral facts: adjustable properties, PDF-only restriction, and a 10-point-per-call cost. No contradiction exists between the write-looking action ('draw') and the read-only hint because the tool returns a processed copy.

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: purpose first, then output behavior, customization options, format constraint, and cost. The only waste is that the Korean sentences largely restate the English ones, creating minor bilingual redundancy, but every substantive fact 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?

For a tool with 9 parameters, 2 required, full schema coverage, and an annotation covering the safety profile, the description covers the essentials: purpose, output (returns watermarked PDF), customization, and input restriction. Gaps are minor — no explicit mention of failure modes for invalid URLs or guidance on which sibling to use for non-PDF files — but these are partially mitigated by the schema and tool-name 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 coverage is 100%, with every parameter already carrying ranges, defaults, and units (e.g., angle 0~360 default 35, density 100~200 default 150). The description's summary of '글자 크기·색상·투명도·각도·밀집도·적용 영역' (font size, color, opacity, angle, density, application area) provides a helpful conceptual grouping but adds no factual meaning beyond the schema, so the high-coverage 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+resource: 'Draw a visible text watermark across every page of a PDF file.' It names the resource (PDF), the action (draw visible text watermark), and scope (every page). This clearly differentiates the tool from siblings like draw_watermark_image, which applies watermarks to images instead.

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 by stating the operation ('insert a text watermark across all pages of a PDF') and adds constraints ('PDF 형식의 파일만 허용됩니다' — only PDF files allowed) and cost ('[호출당 10포인트]'). However, it never explicitly routes to alternatives such as draw_watermark_image for non-PDF inputs, so an agent must infer the boundary from tool names rather than from this description.

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. The description adds behavioral context beyond annotations by stating that thumbnails are extracted at regular intervals, the result is a ZIP file, and each call costs 10 points. This 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 core behavior is front-loaded and the cost note is compact. The bilingual repetition of the same sentence is slightly redundant for an AI agent, but it remains acceptably concise for a mixed-language tool listing.

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

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

For a tool with one required parameter, fully documented optional parameters, a clearly stated ZIP output, and read-only annotations, the description is largely complete. It lacks only explicit usage-alternative guidance, but that does not prevent an agent from invoking the tool correctly.

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

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

Schema description coverage is 100%, so count, width, and video_url are already fully documented with ranges and defaults. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the operation (extract thumbnail images), the resource (a video), and the return type (a ZIP file). It is unambiguous, but it does not explicitly distinguish this tool from sibling media tools such as video_to_mp3 or download_youtube_video, so it stops short of full differentiation.

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

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

The intended use is implied: use this tool when you need preview thumbnails extracted at regular intervals from a video. However, there are no explicit when-to-use or when-not-to-use instructions, and no alternative tools are named, leaving the agent to infer the appropriate selection context.

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=true, so the safety profile is covered. The description adds useful behavioral context beyond that: supported input formats, JPEG output, and per-call cost. It does not mention edge cases such as when no face is found, but that is a minor gap for a read-only transformation.

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

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

The description is front-loaded with the core action, and the Korean sentences add non-redundant details such as JPEG return format, supported image formats, and cost. There is no filler or unnecessary repetition.

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

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

For a simple two-parameter read-only tool, the description covers the essential operation, input formats, and return format. Minor omissions are an explicit alternative to face_detection and behavior when no face is detected, but with full schema coverage this is nearly 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 coverage is 100%, and the schema already documents image_url requirements, allowed MIME types, size limit, threshold range, default, and semantics. The description adds no parameter-specific meaning 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 names the exact operation ('detect faces') and result ('blur/mosaic them') plus the JPEG output format, which clearly distinguishes it from sibling face_detection and other image tools. The Korean sentence reinforces the resource and output without ambiguity.

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 about when to choose this tool over alternatives such as face_detection or image_edit. The privacy-blurring use case is implied but never stated as a selection criterion or contrasted with sibling tools.

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=true, and the description adds useful behavioral context: it returns coordinates, optionally includes facial feature information when use_feature=1, and notes a 3-point charge per call. No contradiction with annotations exists, though error behavior and edge cases are not disclosed.

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

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

The description is short and front-loaded with the core action, but the Korean sentence largely duplicates the English one. The cost note is useful and placed at the end, yet the redundancy prevents a higher score.

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

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

With no output schema, the description should explain the return value shape, and it only says 'coordinates' without describing the format or coordinate system. It also does not mention behavior when no face is found, which leaves meaningful gaps for an agent that must consume the result.

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

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

Schema coverage is 100%, so the schema fully documents all three parameters. The description only repeats the use_feature=1 behavior and adds no meaning beyond the schema for threshold or image_url, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Detect'), names the resource (faces in an image), and states the output ('return their coordinates'). This clearly identifies what the tool does and distinguishes it from sibling tools like face_blur, which edit images rather than return detection coordinates.

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 when-to-use or when-not-to-use guidance is provided, and no alternative tools are mentioned. The agent must infer applicability from the schema and sibling list instead of being told how to choose between face_detection and related tools such as face_blur or nsfw_detection.

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=false, so the safety profile is covered. The description adds context annotations cannot express: that it can be called without an auth key and is free ('인증키 없이 호출할 수 있습니다. [무료]'), plus the relevance-label output. It stops short of describing ranking behavior or result limits on the search itself.

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 and the 'use before choosing' rule are front-loaded, and the sentences are short. The cost is full bilingual duplication of every sentence, which doubles length for a single audience of one agent, though it is defensible for a Korean/English service.

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 naming the returned fields (name, title, description, relevance) and the top-K behavior, and it discloses the auth-free access constraint. Nothing critical is missing for correct 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?

Schema description coverage is 100%, so both parameters are already documented with examples, making 3 the baseline. The description adds value by clarifying that the task string may be Korean or English, which meaningfully widens how the agent can phrase the input.

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 ('Find the APICK tools that best fit a task') and specifies the return shape (top matches with a high/medium/low relevance label). It is instantly distinguishable from every sibling, since those are concrete capability tools while this is the discovery layer over them.

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 states the sequencing rule: 'Use it before choosing among the many tools on this server.' That tells the agent both when to use it and why (navigating a large sibling set), which is exactly the routing guidance a meta-tool needs.

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 genuine behavioral context beyond that: it merges road-name and jibun result sets and ranks by match score, and discloses a per-call cost ('호출당 10포인트'), which is valuable for call planning.

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 core behavior, then usage context, then cost tag. Each sentence carries distinct information with no filler, though the English and Korean sentences partially duplicate the same core statement.

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 does the work of conveying what comes back (ranked, merged road/jibun candidates) and the usage context. Combined with read-only/open-world annotations and a fully documented schema, an agent has enough to call it correctly; only minor gaps like result shape specifics remain.

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 three parameters (query, size with default/max, category enum) are already documented in the schema. The description's mention of merging road and jibun results loosely maps to the category enum but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (return ranked candidates), resource (Korean address candidates), and scope (partial input, merging road-name and jibun results). The 'partial input' and 'merging' framing distinguishes it from a plain full-query address lookup, though it never names a sibling like geo_address_search explicitly.

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 Korean line '주소 입력 화면의 자동완성에 씁니다' gives a concrete usage context (autocomplete in address input screens), which implies when to use it. However, it offers no explicit when-not or alternative routing (e.g. use geo_address_search for complete queries), leaving the agent to infer.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds information the annotations do not carry: the output is an aggregation report (duplicate rate, district distribution) and each call costs 40 points. That billing disclosure is genuinely useful for agent planning; the lack of any note on batching or limits beyond the schema's 50 caps it at 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?

Two short sentences plus a bracketed cost tag, with the core action front-loaded and no filler. The language mixes English and Korean, which is efficient for a bilingual audience but slightly reduces scanability.

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, so the description carries the burden of explaining what comes back, and it does list the main report contents (duplicate rate, district distribution, unmatched addresses). Combined with 100% schema coverage and read-only annotations, an agent has enough to call it correctly; only the response shape (e.g. per-site grouping structure) remains implicit.

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 all three parameters, including the enum for addrType, are documented in the schema. The description mentions 'unmatched addresses with alternatives', which loosely maps to includeSuggestions but adds no syntax or format guidance beyond what the schema already states. 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 verb and resource: group an address list into real sites and report duplicate rate, district distribution, and unmatched addresses. This is concrete and distinguishable in substance from geo_standardize or geo_address_search. It does not name or exclude any sibling, so it falls 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?

The Korean sentence '여러 표기의 주소록을 지점 단위로 정리할 때 씁니다' gives implied usage: mixed-notation address books that need branch-level consolidation. However, it never names alternatives such as geo_address_quality or geo_standardize, nor any exclusions, so the agent must guess when this tool beats its neighbours.

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 value beyond them: alternatives are only produced for addresses that fail, capped at a maximum of 3 candidates, and each call is billed at 30 points. These behavioral details (failure handling, result cap, cost) are exactly the kind of context annotations cannot carry.

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 core purpose and kept short, with the cost note bracketed at the end. The English and Korean sentences largely restate each other, which is mild redundancy, but no sentence 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?

There is no output schema, so the description must convey the return shape, and it does: per-address scores, grades, and up to 3 alternative candidates for failures. For a 2-parameter read-only tool this is reasonably complete, though addrType's behavioral effect (auto/parcel/road) is left to the schema.

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

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

Schema description coverage is 100%, so both parameters (addrType enum and the addresses array) are already documented in the schema. The description adds only the notion of a "list" of Korean addresses and does not elaborate on addrType, 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?

Uses specific verbs (score, grade, suggest alternatives) against a specific resource (Korean addresses) with an explicit scope (validity and completeness). It is clearly an address-diagnosis tool, though it never explicitly contrasts itself with siblings like geo_standardize or geo_address_search, so it falls short of full sibling differentiation.

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

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

"고객 주소 데이터 정제에 씁니다" (used for cleaning customer address data) gives an implied usage context but no explicit when-to-use/when-not-to-use guidance and no naming of alternative tools such as geo_standardize or geo_address_autocomplete.

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 hints (readOnlyHint, openWorldHint) set a low bar, and the description clears it by disclosing that road-name and jibun results are merged with duplicate removal, plus an explicit cost of 20 points per call — a rate limit/cost trait not captured by 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?

Purpose is front-loaded and the cost disclosure is well-placed, but the entire content is duplicated verbatim in Korean and English, doubling length without adding information. The bilingual repetition is a structural inefficiency.

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

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

With no output schema, the description carries the return-value burden and does so by naming the returned fields (standardized address, parcel number, region code, coordinates), and it adds cost and dedup behavior. Pagination is covered by the schema, so remaining gaps are minor.

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 query, page, size, and the category enum (auto/road/parcel). The description adds no parameter-level detail such as query syntax or how category interacts with the merge behavior, 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 (Search) and resource (Korean road-name/jibun addresses) plus the return content (standardized text, parcel number, region code, coordinates). However, it never distinguishes itself from close siblings like geo_address_autocomplete, geo_standardize, geo_place_search, or search_juso, so an agent cannot tell them apart from the description alone.

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

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

The description explains what the tool returns but gives no when-to-use, when-not-to-use, or alternative routing. With so many near-identical geo_* and address-search siblings, the absence of any selection guidance is a real gap.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds the useful cost trait ([호출당 20포인트]) and enumerates return fields, but says nothing about rate limits, accuracy behavior for ambiguous addresses, or error cases when neither address nor coordinates resolve.

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 core English sentence is front-loaded and efficient, but the content is then repeated verbatim in Korean and followed by an annotation sentence, roughly doubling the length. The point-cost note is relevant, but the duplication costs space without adding distinct 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 usefully enumerates the returned fields (sido/sigungu/eupmyeondong/admin dong/lawdCd), which is exactly what an agent needs to interpret the response. It is less complete on input precedence (address vs. coordinates vs. point) and on how addrType affects results.

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 six parameters (x, y, point, address, addrType, includeZipcode) are already documented in the schema. The description only restates the address-or-coordinates duality and adds no syntax or precedence guidance beyond that.

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 (extract) plus the exact resource (administrative names and codes: sido, sigungu, eupmyeondong, admin dong, lawdCd) and the two input forms (address or coordinates). It is clear what the tool returns, though it never explicitly positions itself against close siblings like geo_reverse, geo_standardize, or geo_neighborhood.

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

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

The only usage signal is that lawdCd is the code used for 실거래가 (real transaction price) lookups, plus a per-call point cost. There is no statement of when to choose this tool over geo_reverse/geo_standardize/search_juso, nor any prerequisite or exclusion.

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 safety is covered. The description adds genuinely non-derived behavior: a per-call cost of 40 points, a hard 50-address batch cap, and default deduplication. These are operationally useful facts an agent cannot get from the schema or 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 core action, then context, then cost, with each sentence earning its place. The bilingual English/Korean pairing is somewhat redundant, but it serves the provider's audience and does not bury 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?

There is no output schema, but the description compensates by describing the return shape (coordinates, lot number, administrative code) plus a success/failure summary. Combined with full schema coverage and disclosed cost/limits, an agent has nearly 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 the schema already documents addresses, dedupe, and addrType. The description restates the 50-item limit and deduplication, which overlaps the schema's own text, and adds no syntax or format detail for addrType. Baseline 3 is appropriate when the schema carries the load.

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 (geocode a list of Korean addresses) and adds scope details: batch up to 50, deduplication, and a return of coordinates/lot numbers/admin codes with success-failure summary. The 'list at once' framing implicitly separates it from single-address geo siblings, but it never names an explicit counterpart tool, so it stops short of full differentiation.

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

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

The Korean clause '엑셀·DB에 쌓인 주소를 한 번에 정리할 때 씁니다' gives a clear use context (bulk cleanup of accumulated addresses). However, there are no exclusions or named alternatives to route an agent between this and single-address tools such as geo_address_search or geo_standardize.

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 genuinely new context: the per-call cost ([호출당 10포인트]), the internal mechanism (each address is geocoded to coordinates), and the shape of the result (same parcel/building verdict with distance and similarity).

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 decision in the first clause and adds only the use case and cost afterward. The English/Korean duplication is mild redundancy but serves a bilingual audience; no sentence 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?

With no output schema, the description compensates by stating the return content (same-parcel/same-building verdict, distance, similarity) and disclosing the point cost. A read-only tool with full schema coverage and annotations needs little more.

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 three parameters including the addrType enum are already documented in the schema; baseline 3 applies. The description mentions converting '두 주소' to coordinates but adds no format, syntax, or addrType guidance 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?

States a specific verb and resource: decides whether two Korean addresses refer to the same parcel or building, and returns distance plus text similarity. This is clearly distinguishable from siblings like geo_address_search or geo_standardize, which normalize or look up rather than compare a pair.

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 a use case ('고객·거래처 주소 중복 정리에 씁니다' – deduplicating customer/vendor addresses), which implies when to reach for it. However, it names no alternative tool (e.g., geo_standardize for normalization) and states no exclusions or prerequisites, so routing versus siblings 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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds two useful behavioral facts: auto-simplification when vertices exceed 3000 and a cost of 20 points per call. It does not describe error behavior or authentication requirements, but the added rate and auto-processing details are meaningful.

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 purpose is front-loaded, but the English sentence is immediately followed by a Korean translation that repeats the same information, wasting tokens. The cost note is useful and placed at the end, but the bilingual duplication weakens overall conciseness.

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

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

With no output schema, the description carries the burden of describing return values, and it does list the computed outputs (area, perimeter, centroid, bounding box) and the simplified GeoJSON. Annotations cover safety and openness, and the schema documents all parameters, so only minor details like output units or error handling are missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds operational meaning for the simplify parameter by explaining the automatic simplification threshold and framing includeGeometry as an optional simplified GeoJSON return. It also implicitly maps the Korean province/city/county/township terminology to the level enum.

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 an administrative district boundary and compute area, perimeter, centroid, and bounding box. It distinguishes itself from generic GeoJSON tools by naming the administrative-district domain, and from measurement tools by listing the exact geometry metrics it returns.

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

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

The purpose strongly implies when the tool is useful—when boundary geometry and derived metrics are needed—but it gives no explicit when-to-use, when-not-to-use, or alternative sibling guidance. An agent can infer usage from the specific resource, but there is no direct routing advice.

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 readOnlyHint and openWorldHint annotations already establish the safety profile, and the description adds useful behavioral context: area is returned in m², 평, and km², and each call costs 10 points. It does not contradict the annotations and does not overclaim destructive behavior.

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 sentence is front-loaded and informative, but the entire description is duplicated in Korean, which doubles the length without adding new agent-relevant information. The pricing note is useful but appended at the end rather than integrated.

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 does a good job naming the returned values: area, perimeter, centroid, bounding box, point-inclusion result, and simplified boundary. It remains slightly incomplete on how point versus x/y should be chosen, but the schema covers most invocation details.

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

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

Schema description coverage is 100%, so the schema already explains geojson, x, y, point, simplify, and includeGeometry. The description adds output-unit semantics for area but does not clarify parameter choices such as when to use point versus x/y.

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 resource (GeoJSON) and concrete operations: area, perimeter, centroid, bounding box, point-in-polygon, and boundary simplification. It is clear what the tool does, but it does not explicitly distinguish itself from nearby geo tools such as geo_measure.

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 implied by the stated operations: an agent can infer it should use this when it has GeoJSON and needs geometric analysis. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives like geo_measure.

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 establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a genuinely non-annotated behavioral fact: a per-call cost of 10 points ('[호출당 10포인트]'), which matters for agent budgeting. It still says nothing about error behavior or coordinate-system assumptions, keeping it below 5.

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 definition is short and front-loaded, leading with the computed outputs before the usage hint and cost note. The Korean line largely mirrors the English sentence, which is some duplication, but for a bilingual tool it is defensible 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?

With no output schema, the description carries the return-value burden and does so by listing every computed quantity (distances, bearings, length, area, perimeter, centroid, bounding box). Combined with a fully documented 4-parameter schema and read-only annotations, an agent has what it needs; only error handling and coordinate-system expectations are unstated.

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 baseline is 3: mode, unit, matrix and coordinates are all documented in the schema with enum values and the 200-coordinate cap. The description's enumeration of outputs loosely maps to the path/polygon modes but adds no syntax, default, or format 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 first sentence gives a precise verb (measure) plus the exact resource set (segment distances, bearings, total length, polygon area, perimeter, centroid, bounding box) from a coordinate list. An agent can immediately tell this is a geometric measurement tool rather than a geocoder or address tool. It stops short of naming a sibling such as geo_geojson_analyze to draw the boundary explicitly.

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 Korean sentence '지도에서 그린 경로나 필지 좌표를 바로 측량할 때 씁니다' gives concrete scenarios (a path drawn on a map, parcel coordinates) that select this tool. It is clear context but offers no explicit exclusions or named alternatives, so it does not reach the top tier.

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 genuinely useful context beyond the schema and annotations: a per-call cost of 40 points and the nature of the response (nearest lists plus average distance). It does not, however, disclose pagination or exact response shape.

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 is front-loaded and the sentences are dense with useful specifics. The English and Korean versions largely duplicate each other, which is reasonable for a bilingual audience but slightly inflates length.

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

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

With no output schema, the description carries the return-value burden and does so adequately by naming nearest lists and average distance. Combined with the 100% schema coverage and readOnly annotation, an agent has enough to invoke it correctly, though exclusions versus other geo tools remain unaddressed.

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 seven parameters (x, y, point, address, radius, limit, categories) are already documented in the schema. The description restates the category set and radius concept but adds no syntax or default detail 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?

The description states a specific verb and resource: analyzing daily-life facilities (convenience stores, subway stations, schools, hospitals, pharmacies) around an address or coordinate by category, returning nearest lists and average distance within a radius. This is far more specific than neighboring geo_* tools like geo_measure or geo_district_boundary, so an agent can distinguish it 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?

It offers one use context ('상권·입지 분석에 씁니다' / used for commercial-district and location analysis), which implies when it is appropriate. However, it names no alternatives and gives no when-not guidance, despite a crowded geo_* sibling family (geo_place_search, geo_measure, geo_reverse) where routing guidance would be valuable.

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 annotations already cover read-only and open-world behavior, but the description adds useful context: results are enriched with category hierarchy, addresses, distance and bearing, nearest-first sorting is used when an origin exists, radius excludes out-of-range results, and each call costs 20 points.

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

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

The description is front-loaded with the core purpose and then adds sorting/filtering behavior plus point cost. It is concise overall, though the English-Korean pairing repeats some information, and the Korean line adds details such as nearest-first sorting and radius exclusion.

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 read-only search tool with no output schema, the description explains what is searched, what each result contains, when distance/bearing are computed, how sorting works, and how radius filters results. Pagination details are left to the schema, which is reasonable given full schema coverage.

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

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

Schema coverage is 100%, so the schema already documents all eight parameters in detail. The description reinforces the origin-dependent distance sorting and radius filtering but does not significantly add 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 gives a specific verb and resource: search places by name and enrich each result with category, address, distance and bearing. It is clearer than a generic place search, though it does not explicitly contrast itself with nearby siblings such as geo_address_search or google_maps_search.

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

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

Use is implied by the search-by-name framing and the conditional note that distance/bearing are computed only when an origin exists. However, there is no explicit guidance on when to use this instead of geo_address_search, geo_address_autocomplete, or google_maps_search.

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 safety is covered. The description adds a genuinely useful behavioral fact beyond them: '[호출당 20포인트]', a per-call cost of 20 points, which an agent needs for budgeting. It does not cover failure modes for out-of-range coordinates, so it stops short of 5.

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 conversion and its outputs, then the use case and the cost tag; nothing is buried. The English and Korean sentences carry near-identical content, which is mild redundancy, but it is short and every element (outputs, use case, cost) 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?

With no output schema, the description compensates by enumerating the returned fields (jibun/road address, postal code, legal and administrative dong codes), plus cost and a usage scenario. For a single read-only conversion call with fully documented parameters, this is close to complete; only edge-case behavior for invalid coordinates is unaddressed.

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 x, y, and point are each documented with ranges and the mutual-exclusivity note ('point 를 쓰지 않을 때 필요합니다'). The description adds no coordinate syntax or precedence detail beyond that, so the baseline 3 is appropriate.

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

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

States a specific verb+resource pair (좌표→주소·행정구역) and enumerates the concrete outputs: jibun and road addresses, postal code, and legal/administrative dong codes. The coordinate-to-address direction is clear enough to separate it from address-input siblings like geo_address_search, though it never names an alternative explicitly.

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 Korean sentence '지도에서 고른 지점의 주소와 행정구역을 바로 확인할 때 씁니다' gives a real usage scenario (checking the address of a map-picked point), which is more than pure implication. However, it offers no when-not guidance and does not distinguish this single-point tool from geo_batch_geocode or geo_standardize, leaving the agent to infer the choice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's main added value is the cost disclosure '[호출당 50포인트]' (50 points per call), which is exactly the kind of operational context annotations cannot convey. It also sketches what the response contains (components and grade). It does not mention latency, batching, or whether calls are deterministic, keeping it just short of a 5.

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 in a deliberate order: what it produces, what feeds the score, when to use it, then cost. No filler, and the cost caveat is placed last without burying the core purpose.

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 still tells the agent the return is a 0-100 score plus components and grade, which is adequate. Seven parameters are fully covered by the schema, and the address/coordinate duality is stated. Minor gap: it does not say whether the score is comparable across calls or how grade thresholds work.

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 every parameter (x/y/point/address/radius/categories/limit) is already documented in Korean. The description only restates that you pass an address or coordinate and does not add defaults, interactions, or the address-vs-coordinate precedence rule beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource (score an address or coordinate for site selection) and enumerates the exact inputs to the formula (daily-infrastructure accessibility, category diversity, address confidence) plus the output shape (0-100 score with components and grade). No sibling in the geo_* family produces a composite score, so differentiation is implicit but 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 Korean sentence '후보지 여러 곳을 같은 기준으로 비교할 때 씁니다' gives a clear usage condition: comparing multiple candidate sites on a consistent basis. It stops short of naming alternatives (e.g. geo_place_search, geo_neighborhood) or stating when not to use it, so it is clear context without 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?

Annotations only cover readOnlyHint and openWorldHint, so the description usefully adds that the call costs 30 points (a cost/quota trait annotations do not expose) and that the PNU path deliberately skips coordinate resolution. It still omits failure behavior for unparseable or ambiguous addresses, but the added operational context is real value.

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

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

Front-loads the core purpose in the first sentence, then adds the PNU branch and cost tag compactly. The English/Korean bilingual restatement of the same content is mildly redundant for an agent, but overall the definition is tight and well ordered.

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 enumerating the returned fields (standard text, codes, coordinates, postal code). Combined with 100% schema coverage and read-only annotations, an agent has enough to call it correctly; only ambiguous-address and error semantics are 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 the schema already documents pnu, address, addrType and includeZipcode in detail — including the 'pnu or address, one required' rule. The description largely restates the PNU branch the schema already spells out, adding no syntax, defaults or interaction detail beyond it, which lands at 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 (normalize) and resource (Korean jibun/road address) and enumerates the exact outputs it produces — standard text, legal/administrative codes, coordinates and postal code — which separates it from single-purpose siblings like geo_admin_code or geo_reverse. It signals it is the bundled 'one response' tool, but never names which sibling to prefer, so differentiation is implicit rather than stated.

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?

Offers one concrete usage branch: supply a 19-digit parcel number instead of an address and you get codes without a coordinate lookup. However, there is no when-to-use versus geo_address_search, geo_address_quality or geo_admin_code, and no statement of when this tool is the wrong choice. Usage is implied rather than guided.

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 cover only safety/idempotency hints, but the description adds substantial non-annotation behavior: billing of 126P on first result, free re-inquiry within the validity window, PARTIAL_SUCCESS still incurring the unit price, and RESULT_EXPIRED semantics. It also explains why readOnlyHint=false despite being a lookup (the charge), so no contradiction arises.

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 status handling, then billing, then result structure — a sensible order with no filler. Minor redundancy: the first-result charge and free re-inquiry are stated twice (mid-text and again in the bracketed pricing line).

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, so the description carries the return-value burden and does so: resultAvailable, status, errorCode, and the per-certificate result.businessRegistrationCert/vatTaxBaseCert/financialStatementCert fields, plus terminal statuses. An agent has everything needed to interpret and poll 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 the single transactionId parameter already documents its source, format, and 32-char hex pattern. The description restates the source but adds no syntax or meaning beyond the schema, 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?

States a specific verb (조회) and resource (승인 상태와 사업자 증빙서류 통합발급 결과), and explicitly ties itself to the upstream sibling req_business_cert_bundle as the source of the transactionId. 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 conditional routing: AUTH_WAITING means wait for phone approval, COLLECTING means re-poll with the same ID shortly, and RESULT_EXPIRED after resultExpiresAt means a new authentication submission is required. This is a complete when/when-not protocol, not implied usage.

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 only declare readOnlyHint=false, idempotentHint=true, destructiveHint=false; the description adds the crucial non-obvious traits — billing occurs on the first result return, re-queries within the validity window are free, and results expire at resultExpiresAt. It does not explain why the call is flagged non-read-only beyond pricing, but that is a minor gap given how much cost/expiry behavior is disclosed.

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

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

Front-loaded with the action and state handling, then cost and expiry, which is the right priority order. The 14-item enumeration of result.* sections is long but substitutes for a missing output schema, so it mostly earns its space.

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 and a single param, the description fully carries the burden: it names the returned result sections (conditional on the products chosen at request time), the status/error codes to check, expiry behavior, and cost model. An agent has everything needed to call and interpret it.

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 documents the single transactionId parameter at 100% coverage, but the description reinforces the provenance constraint (it must come from a req_hometax_biz_bundle response) and the reuse rule for polling, which matters for correct invocation.

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 (조회) plus the exact resource (사업자 국세 통합조회 결과) and pins the lookup key to the transactionId issued by req_hometax_biz_bundle, which cleanly separates it from the sibling request tool and from get_hometax_bundle (personal income tax).

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 state machine: AUTH_WAITING means wait for phone approval, COLLECTING means re-poll shortly with the same ID, RESULT_EXPIRED means a new authentication request is required. It also tells the agent which fields (resultAvailable, status, errorCode) to inspect before acting, leaving no ambiguity about when to poll vs. restart.

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, free re-queries within the validity window), the full status state machine, and the need to inspect resultAvailable/status/errorCode. The charge-on-first-call behavior actually explains why readOnlyHint is false despite this being a lookup, and nothing contradicts idempotentHint=true.

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, then status handling, then cost, then return contents, then expiry. Every sentence carries operational information; even the enumeration of result sections serves the point that only the products chosen at request time are returned.

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, so the description carries the full burden of explaining return values, and it does: it names the status/error fields to check, the possible result.* sections, and the expiry error. An agent has everything needed to poll correctly and to know when to re-request.

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 schema already documents the lowercase 32-hex transactionId and its origin in the same-product req_hometax_bundle response. The description restates that provenance but adds no new 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: retrieving approval status and personal national-tax integrated lookup results by transactionId. It explicitly ties itself to the sibling req_hometax_bundle as the source of the ID, making the request/result pair unambiguous against the many other req_* 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?

Gives concrete branch-by-branch guidance: AUTH_WAITING means wait for phone approval, COLLECTING means re-query with the same ID after a pause, and after resultExpiresAt the agent gets RESULT_EXPIRED and must file a new authentication request. It names the exact condition that routes the agent to the sibling req_hometax_bundle.

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 and idempotentHint=true; the description explains why by disclosing billing rules (84P on first result, free re-query within validity), PARTIAL_SUCCESS unit pricing, and expiry-to-RESULT_EXPIRED behavior. That is real behavioral context (cost, idempotent retry, temporal limits) beyond the annotation flags, and nothing contradicts 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 purpose is front-loaded in the first clause, followed by status-handling, billing, and result-path details; every sentence carries operational information. It is dense and the bracketed pricing footnote slightly duplicates the billing sentence, keeping it from 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 return contract: check resultAvailable, status, errorCode, and read per-certificate values at result.incomeAmountCert and result.pensionCreditCert. Combined with status enumeration, billing, and expiry handling, an agent has everything needed to call and interpret it.

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 schema already specifies the 32-char lowercase hex pattern, so the baseline is 3. The description adds retry semantics — reuse the transactionId from the req_income_cert_bundle response, and the same ID for polling — which is meaningful 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 (소득 증빙서류 통합발급 결과) tied to a specific key (req_income_cert_bundle의 transactionId). This clearly distinguishes it from the request-side sibling req_income_cert_bundle, so an agent can pick the right one without reading either schema.

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

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

Explicitly gives when-to-use branches: AUTH_WAITING means wait for phone approval, COLLECTING means retry shortly with the same ID, RESULT_EXPIRED means a new application is required. These state the condition and the required next action, including the alternative flow when the result is expired.

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

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

The description adds substantial behavior beyond the annotations: first-result billing, free re-query within validity, status checks including PARTIAL_SUCCESS, per-result paths, expiration behavior, and the need for a new authentication after expiry. These details are consistent with idempotentHint=true, destructiveHint=false, and readOnlyHint=false, since the tool can incur billing despite being a retrieval 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?

The definition is dense but front-loaded: the first sentence establishes the action and source ID, then status handling, billing, result paths, and expiry follow in a logical sequence. Every sentence carries operational meaning for invoking and interpreting the tool.

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

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

Although there is no output schema, the description explains the key result fields, status states, partial-success behavior, billing implications, and expiration handling. For a one-parameter retrieval tool with annotations covering safety and idempotence, this is complete enough for an agent to call and interpret 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 the single transactionId parameter is already fully documented. The description reinforces that the ID comes from req_nps_bundle and should be reused for polling, but it does not add format or syntax details 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 states a specific verb and resource: retrieve approval status and the integrated National Pension lookup result using a transactionId from req_nps_bundle. It clearly distinguishes this integrated bundle lookup from the individual get_nps_* sibling tools by naming the bundle result fields and the parent request 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 gives explicit state-based guidance: wait for phone approval when AUTH_WAITING, poll again with the same ID when COLLECTING, and submit a new request after RESULT_EXPIRED. It does not explicitly route the agent between this tool and the individual get_nps_join_history/get_nps_deduction_cert/get_nps_career_history siblings, but the transactionId context makes the intended workflow clear.

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

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

Discloses billing on first result return, free re-queries within validity, the RESULT_EXPIRED terminal state, and the key status fields to check — well beyond the annotations. The annotations (idempotentHint=true, readOnlyHint=false) are consistent with a re-runnable but billed call, and the description explains why.

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 retrieve action, then polling behavior, then billing and expiry. The billing point is repeated in the trailing bracketed sentence, which is mild redundancy but the content is otherwise dense and useful.

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 fully carries the return contract: resultAvailable, status, errorCode, result.npsCareerHistory, and resultExpiresAt/RESULT_EXPIRED. Nothing an agent needs to interpret a response is missing.

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

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

Schema coverage is 100% and the schema itself already documents that transactionId comes from the req_nps_career_history response (with format). The description only restates this source relationship, adding little beyond the structured field.

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 (retrieves approval status and NPS career-history result) and explicitly ties itself to the sibling prerequisite req_nps_career_history via its transactionId. An agent can distinguish this result-fetch 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 polling rules: wait on AUTH_WAITING (phone approval), retry with the same ID on COLLECTING, and re-authorize after physical expiry. It also states the prerequisite relationship with req_nps_career_history and the free/billed conditions, 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?

Without the description the agent would have no idea this read-like call is metered. It discloses the billing model (first result 60P × (1 + 0.5 × (years-1)), free re-queries within the validity period), the async approval states, and the expiry behavior (RESULT_EXPIRED forces re-authentication). This adds substantial value beyond the annotations, which only cover the generic safety/idempotency hints.

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 is front-loaded in the first clause, followed by state handling, billing, and result location. The bracket at the end compactly restates the cost rule. It is dense but every sentence carries actionable information; mildly packed rather than wasteful.

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

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

With no output schema, the description carries the return-value burden and does so: it names resultAvailable, status, errorCode, result.npsDeductionCert, and resultExpiresAt, and explains the expiry error. For a polling-plus-billing tool this covers everything an agent needs to call and interpret 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?

There is only one parameter and schema description coverage is 100%, so the schema already documents the transactionId format (32 lowercase hex chars) and its source. The description restates the same origin (req_nps_deduction_cert) without adding format or usage detail, 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?

States a specific verb (조회/retrieve) and a precise resource (국민연금 소득공제용 납부확인서 결과), and explicitly ties itself to the sibling it depends on, req_nps_deduction_cert, whose transactionId it consumes. An agent can distinguish this from the request-side sibling 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 concrete when-to-use guidance tied to the req_nps_deduction_cert call that produces the transactionId, and tells the agent how to act in each state: wait on AUTH_WAITING, re-query the same ID on COLLECTING, and resubmit a new auth after RESULT_EXPIRED. It does not frame the paired request tool as an explicit alternative or spell out a when-not-to-use case, so it stops 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 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?

Goes well beyond the annotations: it discloses the billing model (20 points per call, charged only on successful retrieval, not on pending or empty results), the exact status/message values for each outcome, and the 24-hour re-query window with per-lookup charging. This explains why readOnlyHint=false and idempotentHint=false 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 core purpose and cost are front-loaded, and each subsequent sentence covers a distinct outcome (pending / approved / empty). Slight redundancy in restating '과금되지 않습니다' for two cases keeps it from a 5, but 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?

With no output schema, the description carries the full burden and does so: it enumerates returned fields (PCCC, address, checked_at), status values, and message strings for each branch. An agent can call this and interpret the response without further information.

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 schema already says tx_id is the req_pccc transaction ID, so the description largely repeats it. It does add the behavioral meaning of the parameter — that supplying it returns processing status and that results stay queryable for 24 hours — which is useful framing 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 ('Retrieve a Korean Personal Customs Clearance Code') and identifies the exact input that scopes it (the tx_id from req_pccc). The pairing with req_pccc makes the division of labor between the two siblings 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?

Clearly establishes the precondition that tx_id comes from a prior req_pccc call, and explains that this tool polls processing status. It stops short of an explicit 'call this only after req_pccc returns a tx_id' directive or stating what to do if the tx_id is unknown/expired beyond the 24h note.

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, so the read-only nature is covered. The description adds meaningful behavioral context beyond the annotations: the tool returns a JSON result, is robust to partial image modification ('높은 확률로 워터마크를 확인'), supports common formats, and carries a per-call cost of 10 points — a practical operational detail agents benefit from. No contradiction with annotations 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 description is tight and purpose-front-loaded: one clear directive sentence followed by three high-value specifications (JSON return, robustness, format support) and a cost note. Every sentence earns its place. Minor redundancy exists from stating the same idea in both English and Korean, but the whole 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?

For a low-complexity, single-parameter read tool with readOnlyHint=true and full schema coverage, the description is nearly complete: it covers return format (JSON), supported formats, robustness characteristics, and cost. With no output schema present, it would benefit from a brief note on the JSON response structure, but that gap is minor for a tool returning a watermark code.

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 single image_url parameter is already fully documented (downloadable https URL, allowed MIME types, 50MB cap). The description's mention of PNG/JPEG support is consistent with but less specific than the schema, adding minimal new 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?

The description opens with a specific verb+resource pair: 'Read the invisible watermark code embedded in an image.' It clearly states the tool's function (read/query, return as JSON) and is naturally distinguished from closely related siblings like set_watermark (write operation), draw_watermark_image, and draw_watermark_pdf (visible watermark drawing). The bilingual phrasing reinforces rather than obscures the purpose.

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

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

Usage context is implied rather than explicit: the read-vs-set/draw contrast with sibling names signals when to pick this tool, and the description adds practical conditions (works on partially modified images, supports PNG/JPEG, costs 10 points per call). However, there is no explicit 'when to use' statement, no named alternative, and no exclusion guidance such as 'use draw/set_watermark to embed watermarks instead.'

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 safety is covered. The description adds useful behavioral context beyond that: it discloses that pagination is supported via page and that each call costs 40 points ([호출당 40포인트]), which is a meaningful operational constraint not present in 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?

The core information is front-loaded in the first sentence, which is good. However, the Korean sentences mostly restate the English content (returned fields, pagination), creating duplication that wastes space without adding new meaning.

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, so the description must describe return values; it does so by naming image URL, source page link, and title. It also covers pagination and cost. For a simple two-parameter read-only search tool, this is largely complete, with only edge-case behavior (e.g., invalid page handling) left unspecified.

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 both keyword and page (including the 1–5 range and 20 results per page). The description's mention of pagination reinforces the page parameter's purpose but adds 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 and resource ('Google image search by keyword') and lists the returned fields (image URL, source link, title). It does not explicitly differentiate itself from other Google search siblings like google_search or google_lens_search, so it falls short of a 5, but the purpose is unambiguous.

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

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

No guidance on when to use this tool versus alternatives such as google_search, google_lens_search, or google_shopping_search. The pagination note describes how to use the page parameter, not when to choose this tool over siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and non-determinism. The description adds allowed formats and a cost note ('60 points per call'), but it does not disclose much beyond that; the 'upload an image' wording also conflicts slightly with the URL-based input in the schema. No contradiction with annotations.

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

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

The description is compact and front-loaded with the core action, then adds format/cost constraints. The Korean sentence largely restates the English part with a slightly expanded output list, introducing minor redundancy, but overall it remains appropriately sized.

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, the description covers the purpose, a broad output description, and constraints. However, because there is no output schema, it should do more to describe what the returned labels or pages look like, and it never clarifies that the 'upload' is actually a URL reference rather than a file upload.

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 downloadable https URL, allowed MIME types, and 50MB limit. The description only reiterates the image-format restriction and does not add meaning beyond schema, so it meets the baseline for a fully covered 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 opens with 'Reverse image search' and clearly states the action: provide an image and get visually matching web pages and labels. It is specific about verb and resource, but it does not distinguish itself from the sibling google_image_search, which appears to serve a very similar purpose.

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

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

The use case is implied by 'reverse image search' and the Korean phrase '이미지로 검색', and the only exclusion is that only image-format files are allowed. There is no explicit guidance on when to prefer this over google_image_search, google_search, or image_similarity, so an agent must infer the appropriate context.

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 annotations already establish that this is a read-only, open-world search, but the description adds valuable behavioral context beyond them: a maximum of 20 results, an expected processing time of 30–60 seconds, and a cost of 15 points per call. These are important for planning and cost awareness, though permission or failure behavior is not covered.

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-loads the core purpose, latency, and cost, which is good. However, the same content is repeated in Korean and English, making it less efficient than it could be, even if the bilingual format is intentional.

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