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=false, idempotentHint=true and openWorldHint=true, but the description adds substantive behavior the annotations cannot convey: immediate job_id return, the polling handoff, and the point-billing model (base 10P per job, 5P per result, reserve-then-charge-actual semantics). Auth requirements and rate limits are not covered, so a 4 rather than 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 async contract and cost are front-loaded in the first sentences, and every sentence carries information. The English/Korean duplication of the same two facts is mildly redundant, though defensible 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 correctly compensates by naming the return value (job_id) and the follow-up tool for results, and it discloses the cost model. It stops short of covering failure/retry behavior beyond what idempotency_key implies.

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/asin exclusivity, the 1-100 range for max_results, and the idempotency key format. The description only restates the max_results reservation behavior already present in the schema, adding no new parameter-level meaning; 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 ('Collect Amazon product reviews') with explicit scope ('up to 100') and enumerates the returned fields (rating, title, text, date, verified purchase, helpful count). This clearly separates it from the sibling amazon_product, which fetches product data rather than reviews.

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

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

Explicitly tells the agent the tool is asynchronous and routes it to the sibling scrape_jobs_status for retrieving results, which is the key decision an agent must make here. It lacks a when-not condition (e.g., when to prefer a synchronous alternative), so it falls just 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 covered. The description adds genuinely useful non-annotation context: the per-call cost (100 points), the default country, and the 10-page pagination ceiling, all of which shape whether and how an agent calls it.

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

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

Three short sentences, front-loaded with what the tool returns before defaults and cost. The English/Korean duplication is redundant but conventional for this toolset and does not obscure the key information.

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

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

For a no-output-schema read tool, the description covers purpose, keying parameter, defaults, pagination limit, and cost. It omits return shape beyond a parenthetical field list, but that is a minor gap given the tool's simplicity and the read-only annotation.

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

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

Schema description coverage is 100% and each schema field already states its default and bounds (page 기본 1/최대 10, country 기본 kr, appId numeric). The description restates the same defaults, adding no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource (get iOS app metadata and customer reviews) and the keying scope (numeric app id), even enumerating the metadata returned (rating, price, genre). Among ~100 siblings, none covers iOS app reviews, so an agent can unambiguously route here.

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

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

Usage is only implied: the description says what the tool fetches, so the agent infers it should be called when iOS app info/reviews are wanted. There is no explicit when-to-use framing, no when-not guidance, and no alternative named (though no close sibling exists).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, covering safety and external interaction. The description adds the per-call cost (40P), which is a meaningful behavioral detail. However, it does not disclose the return format or behavior on invalid inputs, leaving a gap beyond what annotations convey.

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

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

The description is brief and front-loaded with the core purpose, followed by cost. It is slightly redundant due to bilingual text (English and Korean) but remains efficient and easy to scan.

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

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

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

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

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

The schema description for 'number' is complete with examples (01012341234, +country code format), so the parameter is well-documented. The description adds no extra semantics beyond the schema, matching the baseline for high schema coverage.

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

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

The description clearly states the tool validates and formats a phone number, checks carrier and line type, using specific verbs and a concrete resource. It is distinct from siblings like check_email_valid (email) and check_spam_number (spam), making its purpose unambiguous.

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

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

The description implies usage for phone number validation but does not explicitly compare with alternatives or state when not to use it. Given the many sibling tools, explicit routing (e.g., 'use for phone validity, not email') would help, but the tool's name and function make the intended context inferable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-network behavior are covered. The description usefully adds the per-call cost (40 points) and the fact that both profile and recent video data are returned, but it omits how many videos, whether results are paginated, or any rate limits.

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 bilingual sentences plus a bracketed cost note, with the core purpose front-loaded in the first sentence. Every sentence carries content, though the full Korean restatement is somewhat redundant with the English.

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 shape, and it does name the two data sets (profile + recent videos). However it leaves the volume/format of returned videos unspecified, and gives no guidance for choosing it over sibling youtube tools.

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

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

Schema coverage is 100% and the single parameter's schema description already enumerates the accepted forms (channel ID, handle, channel ID UC…, or URL). The description adds nothing 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 (collect) and resource (YouTube channel profile + latest uploaded videos), naming both artifacts returned. It does not, however, differentiate itself from siblings like youtube_channel or youtube_metadata, which the agent would have to disambiguate on its own.

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 when-to-use guidance and no mention of alternatives among the many youtube_* siblings (youtube_channel, youtube_metadata, youtube_search). The only usage signal is the point cost, which is a pricing hint rather than a selection rule.

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 only declare readOnlyHint and openWorldHint, so the description carries real added weight: it discloses the 1-hour link expiry, the base-fee-plus-per-10MB billing model, the 30-point per-call charge, and the public-video restriction. It omits failure behavior (geo-blocked, private, age-gated videos) and any rate limits, which keeps it 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?

Front-loaded with the core action and scope in the first clause, then billing and the youtube_formats pointer, which is a sensible priority order. The full Korean restatement duplicates every fact already given in English, which is defensible for the audience but adds bulk.

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 describing the return value (a download link valid for 1 hour) and the cost model, so the agent knows what it gets and what it pays. The only remaining gap is error/failure semantics for unavailable videos, which is minor for a 5-parameter, mostly self-documenting 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 the schema already documents url, quality, start, end, and codec with examples and defaults. The description only restates 'chosen quality (up to 4K)' and 'optionally only a time range' at a high level, adding no syntax or edge-case detail beyond the schema (e.g., what happens if start exceeds end). 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 (download a public YouTube video) plus the output format (MP4), the quality ceiling (up to 4K), the optional time-range trimming, and the returned artifact (1-hour download link). An agent can distinguish this from youtube_audio_download, video_to_mp3, and youtube_formats without opening any schema.

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

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

Explicitly routes the agent through youtube_formats first to inspect sizes and estimated costs, which is a concrete usage prerequisite rather than a vague hint. It also implies the scope limit (public videos only) and that billing scales with file size, but it never states when-not to use it (e.g., versus the audio-only or subtitle 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 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 mark the tool as read-only and open-world, and the description adds a billing note about points per call. However, it does not disclose what the response looks like or caveats about record availability, which is more noticeable because there is no output schema.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

States a specific verb and resource (조회한다 – 조회 of approval status and deduction result) and explicitly anchors the tool to the req_cash_receipt_deduction transactionId, cleanly distinguishing it from the sibling that creates the request. An agent can tell this is the polling/result-fetch half of a two-step flow without opening the schema.

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

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

Gives an explicit status-driven calling protocol: AUTH_WAITING means wait for phone approval, COLLECTING means re-query with the same ID shortly after, RESULT_EXPIRED means a new authentication request is required. This is exactly the when/when-not guidance an agent needs to avoid mis-calling it.

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

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

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

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

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

Front-loaded with purpose and then state handling, all in a compact block. The trailing bracketed clause restates the billing/re-query rule already stated earlier, a minor redundancy that keeps it just short of a 5.

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

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

With no output schema, the description carries the full burden and does so: it names the status states, the billing conditions, the response fields, the payload location, and the expiry behavior. Nothing an agent needs to poll and interpret this tool correctly is missing.

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

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

Schema description coverage is 100% and the schema already states that transactionId comes from the req_driving_license response. The description repeats that linkage but adds no format or syntax detail beyond it, so the baseline 3 applies.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema, including its origin and the 32-hex-character format. The description restates that the transactionId comes from req_employment but adds no format or usage detail beyond the schema, so the baseline of 3 is appropriate.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no output schema, the description compensates by naming the fields to inspect (resultAvailable, status, errorCode) and where the payload lives (result.healthCheckup), plus the expiry field resultExpiresAt. An agent needs nothing more to call and interpret this tool.

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

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

Schema coverage is 100% and the single transactionId parameter already documents its source and 32-char hex format, so the description adds little parameter-level meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

Names a specific verb (조회) and resource (국가 건강검진 결과 조회 결과 / approval status) and scopes it by the req_health_checkup transactionId, which cleanly separates it from the sibling requisition tool req_health_checkup. An agent can tell exactly what this returns without opening the schema.

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

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

Gives explicit state-driven guidance: AUTH_WAITING means a phone approval is pending, COLLECTING means re-query with the same ID shortly, and RESULT_EXPIRED means a new authentication submission (req_health_checkup) is required. The polling/retry behavior is spelled out rather than left to inference.

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

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

Annotations already declare openWorldHint=true, idempotentHint=true, destructiveHint=false and readOnlyHint=false, and the description reinforces the read-but-billed nature with the 'billed on first result, free re-queries within validity' note. It also discloses polling states, error codes, and expiry behavior. However, the billing/readOnly nuance is the only place it goes clearly beyond the annotation layer, so this is a solid but not exceptional 3-4.

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

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

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

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

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

With no output schema, the description must carry the return contract, and it does: it names resultAvailable, status, errorCode, the result.npsJoinHistory path, and resultExpiresAt with the RESULT_EXPIRED terminal state. An agent has everything needed to call and interpret this polling tool.

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

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

Schema coverage is 100% and documents the transactionId format (16-byte lowercase hex, 32 chars). The description adds useful provenance — that the id comes from the req_nps_join_history response for the same product — which the schema does not state.

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

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

States a specific verb and resource (retrieve approval status and NPS join history result) via the transactionId issued by req_nps_join_history. It explicitly distinguishes itself from the sibling req_nps_join_history by naming it as the source of the id, so an agent can separate the request step from the result-retrieval step.

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

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

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

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

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

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

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

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

The description front-loads the core purpose in English and then details statuses, charging, and re-query behavior in Korean. Each sentence adds distinct operational information, though the mixed-language structure and level of detail make it slightly dense. It remains logically organized and scannable.

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

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

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

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

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

The schema already fully documents tx_id as the transaction ID from the req_pccc response (100% coverage). The description restates this and adds that it is used to check processing status, but does not provide additional format, length, or constraint details. Baseline 3 is appropriate.

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

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

The description states a specific verb-resource pair: 'Retrieve a Korean Personal Customs Clearance Code (PCCC) by transaction ID.' It clearly positions itself as the counterpart to req_pccc by referencing the tx_id source, distinguishing it from all sibling tools.

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

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

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

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

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

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

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

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

Four dense Korean sentences, front-loaded with the core action, then state handling, then billing, then result location. The bracketed repetition of the billing rule is redundant with the earlier sentence but otherwise contains no filler.

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

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

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

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

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

Schema coverage is 100%, so baseline is 3; the description adds real value by tying transactionId's provenance to req_personal_income's response and by clarifying that the same ID can be reused within the validity window, which the schema does not state.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

With no output schema, the description carries the full burden and does so: it names the returned fields, the expiry field, the expiration error code, and the billing consequence. An agent has everything needed to poll, interpret, and re-drive the workflow.

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

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

Schema coverage is 100% and the pattern is documented, so the baseline is 3; the description still adds value by explaining provenance (the ID returned by the same-product req_tax_return_history call) and the retry-with-same-ID rule that the schema cannot express.

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

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

States a specific verb and resource (retrieves the approval status and national-tax-filing lookup result for a transactionId) and explicitly ties it to the sibling req_tax_return_history that produces the ID. An agent can distinguish this polling/result tool from the request tool without opening either schema.

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

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

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

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

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

Annotations already declare readOnlyHint=true, 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 the safety profile is covered. The description adds genuinely new behavioral context: a per-call cost of 20 points and the 20-results-per-page pagination limit, which are not derivable from structured fields. It omits any note on rate limits or failures, but the added cost signal is valuable.

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 facts (keyword search, returned fields, pagination, cost) are front-loaded and useful, but the same content is restated in both English and Korean, which doubles length without adding information. Structure is acceptable but not tight.

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 readOnly/openWorld annotations, a fully documented 2-param schema, and no output schema, the description covers purpose, return fields, pagination range, and cost. Only the routing to sibling search tools is missing, which is a minor gap for a callable search 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 both keyword and page are already documented in the schema. The description only adds that page ranges allow iterating through results, which the schema already implies (1~5, 20/page). Baseline 3 is appropriate when the schema carries the meaning.

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 ('Google image search by keyword') and enumerates the returned fields (image URL, source link, title), which distinguishes it from google_search and google_news_search by the 'image' resource. However, it never explicitly names those siblings or clarifies the boundary with google_lens_search, so differentiation is implicit.

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 pagination mechanics ('page 로 결과 페이지를 넘겨 가며 조회') but gives no when-to-use guidance, no exclusions, and does not route the agent to or away from alternative search tools. An agent must infer the choice purely from the resource noun.

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?

Goes well beyond the annotations by disclosing the asynchronous job pattern (returns job_id immediately, results via scrape_jobs_status), the output language (English), and the billing behavior ('Charged 20 points only when the place is found', full refund on failure). Annotations confirm idempotentHint=true while the schema supplies idempotency_key, and readOnlyHint=false (a job is created) is consistent with the description rather than contradicted.

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 portion is dense and front-loaded: capabilities first, then inputs, then the async contract, then cost. It is somewhat inflated by a near-full Korean restatement of the same facts, which is redundant for a single-language reader, though it does not obscure the critical leads.

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 fully covers the call contract: where inputs come from, the immediate job_id return, the required polling tool, the result language, and the cost/refund rule. Nothing an agent needs to invoke and then retrieve results 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%: url, place_id (with pattern) and idempotency_key (with pattern) are all documented in the schema itself. The description only restates the source of place_id/url ('from google_maps_search, or a Google Maps place URL'), adding no new syntax or format guidance beyond what the schema already gives. Baseline 3 applies when the schema carries the parameter burden.

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 precise verb+resource ('Google Maps place details') and enumerates the exact payload it retrieves: rating, reviews count, star distribution, top reviews, opening hours, busy hours, similar places, photos. It is clearly distinguishable from sibling google_maps_search, which supplies the input rather than the details. An agent can select it without opening a 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 clear operational context: obtain place_id from google_maps_search, or pass a Google Maps place URL, then poll scrape_jobs_status for the result. This routes the agent to both the upstream and downstream sibling. It stops short of an explicit when-not condition (e.g. use search instead of this tool when you only need the place_id), but the sourcing guidance is unambiguous.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower; the description still adds material context beyond them: a hard 20-place cap, an expected 30-60 second latency, and a cost of 10 points per call. Only the return format/pagination is left unspecified.

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 front-loaded and the field list is useful, but the same content is restated verbatim in Korean and English. The repeat is not pure waste (latency and point cost appear only in the Korean sentence) yet it inflates the description noticeably for a one-parameter 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?

For a one-parameter, no-output-schema lookup with annotations carrying the safety profile, the description supplies return fields, result limits, latency, and cost — everything needed to call it correctly and budget for it. It is complete for its complexity level.

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?

With a single parameter and 100% schema description coverage, the schema already documents 'keyword' including its length bound and example. The description adds no syntax or format detail beyond restating that a keyword drives the search, 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+resource ('Google Maps place search') and enumerates the returned fields (name, address, phone, rating, reviews, hours, coordinates) plus the 20-result cap for a keyword. The 'Maps' qualifier implicitly separates it from siblings like google_search, google_news_search, and 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 description says what the tool returns but gives no guidance on when to choose it over google_search, search_juso, or location, and no exclusion conditions. Usage is only inferable from the word 'place 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 the safe, external-fetch nature is covered structurally. The description adds one genuinely useful behavioral datum — the 5-point cost per call — but says nothing about result caps, pagination limits, or what happens when a keyword returns no news.

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 tool's function and return shape, then the Korean mirror and cost. The bilingual duplication is a deliberate pattern but does slightly inflate length; the English sentence alone carries the full payload.

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 listing the returned fields, and it discloses the cost. It falls short only on pagination/result-volume expectations and any failure behavior for a keyword with no 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 both parameters (keyword 1~200 chars, page 1~10) are already documented in the schema. The description only says results are returned 'for a keyword' and adds nothing about the keyword length limit or the page parameter, 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?

The description states a specific verb+resource ('Google News search') and enumerates the returned fields (title, publisher, published time, link), which is more than a bare restatement of the name. It implicitly distinguishes itself from the other search siblings by scope ('news'), but it never explicitly names or contrasts with google_search, google_image_search, or google_shopping_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?

There is no when-to-use guidance, no when-not-to-use, and no alternatives named among the many sibling search tools. The only supplemental guidance is the per-call cost, which is a pricing fact rather than a usage rule.

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, covering the safety profile. The description adds valuable behavioral context beyond annotations: rank range 1-100, failure if all needed segments cannot be checked, no charge on failure, and 50-point cost per call. Output shape and rate limits are still unspecified.

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, but the Korean sentence largely duplicates the English meaning, and the pricing/failure notes are separate. Every sentence is relevant, yet the bilingual redundancy reduces 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?

No output schema exists, but the description covers success intent (rank 1-100), failure behavior, and billing. It could specify the exact return shape (e.g., rank number or not-found result), but for a two-parameter read-only tool it is mostly 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%, so the schema already documents keyword (1-200 chars) and domain (including subdomains). The description adds no syntax or constraints beyond what the schema provides; 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 (find where a domain ranks) and resource (Google results for a keyword) with scope (1-100). It implicitly distinguishes itself from general google_search by rank-tracking intent, even though it does not name a sibling tool.

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

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

No explicit when-to-use or when-not-to-use guidance, and no alternative sibling such as google_search is referenced. The implied use case is clear from the purpose, but the agent receives no routing instructions.

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 concrete behavior: returned fields are limited to link/title/snippet, pagination is possible via page, and each call costs 5 points. 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 short and front-loaded with the core function and output shape. The bilingual repetition (English and Korean) adds minor redundancy, but it is compact and includes only useful operational notes like pagination and 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?

For a simple read-only lookup with full parameter documentation, the description covers the required keyword, optional page paging, and result fields. It does not detail edge cases like empty results or error formats, but those are not necessary for correct selection and 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 keyword and page are already documented in the schema. The description adds only a small amount of extra context about using page to navigate result pages, which is helpful but not essential.

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 ('return'), a clear resource ('Google web search results'), and the exact output fields (link, title, snippet). The 'keyword' qualifier distinguishes it from sibling image/lens search tools like google_image_search and google_lens_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?

The description implies usage through the keyword-search framing and gives pagination guidance with page, but it never explicitly says when to choose this tool over alternatives or when not to use it. Sibling differentiation is left to the reader.

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 two useful pieces beyond that: the exact result fields (compensating for the absent output schema) and a per-call cost note '[호출당 5포인트]', which is real behavioral context an agent should weigh. It omits pagination behavior despite the page parameter, keeping it 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?

Core purpose is front-loaded in the first sentence, with output fields and cost trailing efficiently. The bilingual Korean duplication repeats identical content, which is justified for a Korean-language service but is redundancy nonetheless, 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?

For a simple two-parameter search tool this is largely complete: it states the return fields (important since no output schema exists), the cost, and the parameter intent, while annotations cover the read-only/open-world nature. Pagination semantics and any result-count limits remain 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%, with both keyword and page already documented (including the 1~10 page range), so the schema does the heavy lifting. The description only echoes 'for a keyword' and adds no format or constraint 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 gives a specific verb and resource ('Google Shopping search: return product results ... for a keyword') and even enumerates the returned fields, so the tool's function is unmistakable. It does not, however, distinguish itself from the many sibling search tools (google_search, google_image_search, google_news_search, google_lens_search), leaving that separation to the tool name 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?

There is no when-to-use guidance and no named alternative. An agent scanning the large sibling set of Google search tools gets no signal about when Shopping is preferred over general, image, or news search. The purpose statement implies a product-search use case but stops short of routing 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 already indicate readOnlyHint=true and openWorldHint=false. The description adds meaningful behavioral context: it recognizes RRNs, applies one of four masking modes, returns the masked image, and discloses a 20-point cost per call plus a legal-use requirement. 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 main action is front-loaded and the description is reasonably compact. The bilingual repetition is slightly redundant, but the required-input note, type enumeration, legal caveat, and cost disclosure are all meaningful and add value without excessive clutter.

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

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

For a two-parameter tool with no output schema, the description covers the essential operational details: what it does, required inputs, masking modes, legal conditions, and cost. It does not specify the output representation beyond "masked image," but that is likely sufficient for invocation.

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

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

The input schema already provides 100% parameter coverage, including descriptions for both type and image_url. The description repeats the type mapping and emphasizes that both inputs are required, adding little semantic value beyond what the schema already states.

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 begins with a specific verb and resource: "Mask resident registration numbers found in an image and return the masked image." This clearly distinguishes the tool from sibling image tools like face_blur, draw_watermark_image, and general image_edit.

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

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

The description clearly states the required inputs (image file and type) and adds an important condition: use only when there is a lawful basis such as consent. It does not explicitly compare against alternatives like face_blur, but the RRN-specific scope provides clear context for 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=true and openWorldHint=true, and the description's 'Look up/조회' aligns with that read-only behavior. The description adds a per-call cost note ('[호출당 3포인트]') and downstream use cases, which is useful context. It does not disclose output shape or edge-case behavior, but for a safe read-only lookup the annotations carry most of the burden.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already mark the operation read-only, and the description adds the per-call point cost and confirms the output is a PDF file. It does not mention rendering limitations, CSS support, or how the file is returned, but for a simple conversion tool the key behavioral context is present.

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

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

The description is short, front-loaded with the action, and includes a useful cost note. The Korean sentence largely duplicates the English opening, which is minor redundancy in an otherwise tightly worded definition.

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

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

For a simple two-parameter conversion tool, the description plus schema is sufficient: input shape, optional pagination, and output type are covered. It could be more complete by describing the response format, but the absence of an output schema makes that a modest gap.

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

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

Schema description coverage is 100%, so the html and pagination parameters are already documented. The description only restates that an HTML string is the input and adds no new semantic detail about parameters.

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 and resource: 'Render HTML code into a PDF file,' and further clarifies the input is an HTML string returning a PDF. This clearly separates it from sibling converters like docx_to_pdf and pdf_to_image.

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 primary use case explicit: provide HTML code as a string to receive a PDF, which implies it is not for URL-based conversion or other document formats. It does not explicitly name when-not-to-use or alternatives, so it stops short of full routing 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 already mark this as read-only and open-world, so the bar is lower. The description adds meaningful behavioral context beyond annotations: it requires all four fields, restricts the date format, mandates a lawful basis for use, and discloses the per-call cost of 40 points. This gives the agent a genuine sense of the operational constraints and authorization requirements.

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 core purpose, and every sentence adds useful information: input mode, required fields, date constraint, legal condition, and cost. It is slightly bilingual/repetitive but still efficient for the range of details it conveys.

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 no output schema, so a description of expected return values would be valuable. The description covers inputs, legal prerequisites, and cost, but never explains how the verification result is returned (e.g., simple pass/fail, reason codes, possible error conditions). This is a notable gap even though annotations and input documentation are solid.

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 parameters and their formats. The description reinforces that all four items are required and gives a date example, but it does not add significant new meaning beyond what the schema already provides. This aligns with the baseline 3 for full schema coverage.

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

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

The description states a specific verb ('Verify') and a specific resource ('authenticity of a Korean resident registration card'), and the title's '[Text]' tag clearly distinguishes it from image-based sibling tools like identi_card_image1. The bilingual text backs this up with 'using text input'. An agent can confidently understand what this tool does at a glance.

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

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

The description gives clear context: use when you have text-based card fields, all four items must be provided, and date must be numeric. It also adds a legal prerequisite ('only use when legitimate processing grounds such as consent are secured'). It does not explicitly name alternatives for image or OCR cases, but the '[Text]' distinction combined with the strong input conditions provides adequate routing 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 already declare readOnlyHint=true and openWorldHint=true, and the description goes beyond them by disclosing the per-call cost, the legal-basis requirement, and importantly the scope limits (it does not verify the serial number itself or the physical license's tampering). Those negative-capability and cost statements are exactly the kind of context annotations cannot carry. It still omits how the result is returned or any throttling 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 purpose is front-loaded, but the content is delivered twice, once in English and once in Korean, with the ghost_num caveat repeated almost verbatim. That bilingual duplication costs space without adding information, though each individual sentence is otherwise clean.

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 11-parameter, 8-required verification tool with no output schema, the description covers required vs optional inputs, the ignored field, the cost, the legal precondition, and the limits of what is verified. The one real gap is the absence of any statement about the response shape (pass/fail, matched fields), since no output schema exists to cover 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 description coverage is 100%, so every parameter is already documented, and the description largely restates it: required birth_y/m/d, name, licen_no0-3, and optional ghost_num/rrn1/rrn2. It adds slight value by stressing that ghost_num accepts arbitrary strings and is ignored in the decision, but that is also in the schema. Baseline 3 applies 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?

States a specific verb+resource: checking a Korean driver's license number and personal details, and explicitly disclaims what it does not do (serial-number validation, physical forgery detection). That said, it never distinguishes itself from the sibling identity_document_driver_license or from identi_card1/3/4/5, so an agent cannot tell which of the near-identical tools to pick from the text 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?

Provides a real precondition (only use with a lawful basis such as the data subject's consent) and a cost signal (40 points per call), which implies when it is appropriate to invoke. However, it gives no explicit routing guidance versus the driver-license-adjacent siblings, so the agent must infer the choice from tool names.

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

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

Annotations already provide readOnlyHint and openWorldHint, and the description is consistent with them. It adds useful context about the legal basis requirement and per-call cost, but it does not describe the verification result structure or any edge-case 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 description is front-loaded with a clear purpose sentence, but the Korean sentence largely repeats the English opening. The legal notice and cost information are useful, though the cost note is tangential to tool invocation.

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

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

Input requirements are well covered: all fields, formats, and legal preconditions are stated. However, there is no output schema and no description of what the verification result looks like, which is a meaningful gap because an agent needs to interpret the outcome to decide its next action.

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 each parameter with a short label. The description adds value by reinforcing that all five parameters are mandatory and clarifying the numeric date format with an example, which is not fully explicit in 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 clearly states the verb 'Verify' and the specific resource 'Korean passport', and it distinguishes the method with 'using text input'. This sets it apart from image-based sibling tools, though it doesn't name 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 description explicitly lists all five required fields, states the date format requirement ('숫자만, 예: 20230101'), and gives a legal precondition ('적법한 처리 근거를 확보한 경우에만'). It gives clear usage conditions but does not explicitly discuss alternatives or when not to use this tool.

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 this is a non-destructive lookup. The description adds meaningful behavioral context: it is a text-based verification requiring a 16-digit document confirmation number split into four 4-digit parts, a issuance type, and an explicit legal-consent warning. It also discloses the per-call cost ([호출당 40포인트]), which is useful operational transparency.

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

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

The description is compact and front-loaded with the main purpose in the first sentence, followed by key input rules, legal notice, and pricing. The Korean and English lines partially duplicate each other, but the repetition reinforces the core message without excessive bloat.

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 verification tool with no output schema, the description provides what an agent needs: required fields, optional fields, format constraints (4-digit segments), issuance type meaning, a legal-use warning, and cost. The only minor omission is the exact response shape, but read-only verification tools without output schemas are often judged by success/failure status and this is acceptable.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds the composite meaning that doc_num1~doc_num4 together form the 16-digit document confirmation number, and clarifies that type refers to issuance channel (정부24 vs 기타). This is helpful but not extensive; baseline 3 is appropriate given full schema coverage.

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

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

The description clearly states the specific verb ('Verify the authenticity') and the resource ('Korean resident registration certificate' / 주민등록등본), and the title also specifies the document type. This distinguishes it from sibling tools like identi_card1-5 or identity_document_* by focusing on text-based verification of the 주민등록등본.

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 required inputs (doc_num1~4, type) and notes name is optional, plus a legal-consent condition for use. It doesn't explicitly contrast with sibling alternatives (e.g., identi_card_image1 for image-based verification), but the text-input scope and the legal proviso give reasonable usage 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 already declare readOnlyHint=true, so no contradiction exists. The description adds meaningful behavioral context: it is a verification operation, requires legitimate processing grounds, and consumes 40 points per call. These details go beyond what annotations and schema provide, even though output format and error behavior are not described.

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 tool's purpose, followed by parameter guidance, legal conditions, and cost. It contains some redundancy with the schema, but each sentence carries practical information for invocation and compliance. It is appropriately sized for the tool's complexity.

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 verification tool with no output schema, the description sufficiently covers input requirements, conditional fields, legal prerequisites, and cost. It does not describe the exact result format, but the purpose is straightforward enough that an agent can reasonably infer a boolean or verification result. The main gap is not explaining differences among identi_card1-5 siblings explicitly.

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 each parameter already described in terms of format and length. The description repeats these constraints rather than adding new semantic meaning beyond the schema. It does usefully summarize requiredness and the card_sn condition, but does not materially expand parameter understanding.

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 ('verify'), a specific resource ('Korean alien registration card'), and a specific input mode ('using text input'), which distinguishes it from image-based siblings like identi_card_image1-5 and OCR variants. The title's [Text] marker reinforces the text-based scope.

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

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

The description clearly specifies required fields, format constraints, and the conditional requirement for card_sn on cards issued after 2011-01-01. It also provides a legal-usage condition (consent or lawful basis). It does not explicitly name alternative tools or when-not-to-use, but the context is clear enough for an agent to decide when this tool fits.

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, which cover the safety profile. The description adds useful behavioral context: the card data is automatically recognized, the operation requires a lawful processing basis, and each call consumes 60 points. It does not disclose whether the file is stored or what happens on failure, but this is acceptable given the read-only annotation.

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 main action, then adds the input requirement, legal condition, and cost in short sentences. The bilingual phrasing repeats some content, but the Korean sentence adds the detail that the card's written information is automatically recognized, so the redundancy is mild and purposeful.

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, the description covers what input to provide and when use is lawful. With no output schema present, it would benefit from stating the response format (e.g., whether it returns true/false or a result object). The absence of a sibling differentiation also leaves a small contextual gap, but the core call is understandable.

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

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

The input schema already fully documents image_url as a downloadable https URL with allowed formats (jpeg/png/pdf) and a 50MB limit, so the baseline is 3. The description reinforces 'image or PDF' and 'one file' but adds no new technical details about the URL parameter 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 opens with a specific verb and object: 'Verify the authenticity of a Korean resident registration card from an image or PDF file.' It clearly scopes the tool to image/PDF input and explicitly says no text input is needed. However, it does not differentiate itself from the nearly identical sibling names identi_card_image2 through identi_card_image5.

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 a clear precondition for use ('정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용하십시오') and states that only a single file is required. It does not, however, mention when to prefer this tool over alternatives such as identi_card1 or the OCR variants, leaving the choice to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds valuable behavioral context: it auto-recognizes the printed information, performs authenticity verification, requires a lawful processing basis, and notes the per-call point cost. It does not describe the output format, but for a read-only verification tool this is a minor gap.

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

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

The description is short, front-loaded with the core purpose, and every sentence adds useful information: what it does, input expectations, legal constraints, and cost. There is no redundant filler.

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

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

For a one-parameter read-only tool, the description covers the essential context: input type, operation, legal prerequisite, and cost. It does not explicitly state the return value shape, but '진위 여부를 확인합니다' implies a pass/fail or verification result, which is adequate for this simplicity level.

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. The description adds that only one file is needed and that no text input is required, but it uses 'upload' rather than echoing the URL-based parameter. Most parameter meaning is already fully covered by 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 clearly states a specific verb and resource: verifying the authenticity of a Korean driver license from an image or PDF. It is distinct from general OCR and other document types, but it does not explicitly differentiate itself from similarly named sibling tools such as identi_card_image1 or identity_document_driver_license.

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 useful context: use it when you have a driver license image or PDF and no text input is needed, and only when you have a lawful basis. However, it does not mention alternatives or explain when not to use this tool, especially given the large number of similar identity-verification 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 provide readOnlyHint=true and openWorldHint=true. The description adds that the tool auto-recognizes passport information and verifies authenticity, and it discloses the legal-consent requirement and per-call point cost. It does not explain the output/return behavior, failure cases, or what exactly 'verified' means, so it provides only moderate behavioral context beyond the annotations.

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

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

The description is front-loaded with the core purpose and includes useful legal and cost information. However, the English and Korean sentences duplicate the same core message, creating redundancy. It is not overly long, but the duplication 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?

For a read-only single-parameter tool, the description covers the essential input requirement, legal authorization, and cost. However, with no output schema present, it does not describe what the agent should expect in response, how to interpret the verification result, or why this tool differs from the many sibling identity/OCR tools.

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 fully describes the single parameter: a downloadable HTTPS URL with allowed types (image/jpeg, image/png, application/pdf) and a 50MB limit. The description adds 'one file, no text input,' but this does not materially extend the schema's parameter documentation.

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 and resource: 'Verify the authenticity of a Korean passport from an image or PDF file.' The title reinforces the scope with '[Image/PDF] 여권 진위 확인'. However, it does not explicitly distinguish this tool from sibling variants like identi_card_image1/2/4/5 or identity_document_passport, so it stops 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?

The description gives clear usage conditions: supply one file without text input ('텍스트 입력 없이 파일 하나만 전달하면 됩니다') and only use when a legal basis such as consent exists. This is helpful context, but it does not explicitly state when to prefer this tool over alternatives or when not to use it.

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

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

Annotations already mark the tool as read-only and open-world. The description adds useful behavioral context: automatic recognition of the document confirmation number, cost of 60 points per call, and a legal/consent prerequisite. There is no contradiction with the annotations.

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

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

The description is compact and front-loaded with the core purpose. The bilingual redundancy is acceptable for a Korean-focused tool, and the additional operational details (file-only input, consent requirement, cost) each add practical value.

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 single-parameter tool with no output schema and read-only annotations, the description covers the input, expected behavior, legal condition, and cost. It does not describe the exact response format, but '진위 여부를 확인합니다' sufficiently signals the result is an authenticity verdict. Explicit sibling differentiation is the main missing piece.

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

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

The input schema already documents image_url with 100% coverage, including HTTPS requirement, accepted MIME types, and max size. The description adds that only a file is needed and that images/PDFs are acceptable, but it does not add meaningful parameter semantics beyond the schema.

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

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

The description uses a specific verb and resource: 'Verify the authenticity of a Korean resident registration certificate from an image or PDF file.' This clearly distinguishes it from OCR tools and other identity document tools, even though the image4 suffix carries no semantic meaning by itself.

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

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

It gives clear usage context: upload only a file, no text input required, and use only when a lawful basis such as consent exists. It does not explicitly name sibling alternatives or state when not to use this tool over identi_card_image1/2/3/5 or ocr_identi variants, but the input conditions are 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?

Annotations supply readOnlyHint and openWorldHint, and the description adds useful behavior: automatic recognition of printed information, conditional requirement for card_sn, a legal-consent prerequisite, and a per-call point cost. There is no contradiction with the annotations.

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

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

The first English and Korean sentences both state the same verify-from-image/PDF purpose, creating redundancy. The legal-use warning and cost note are valuable, but the duplicated purpose could be trimmed.

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?

It covers input requirements, the conditional card_sn, and legal prerequisites, which is enough to attempt a call. However, there is no output schema and the description does not explain the result format or failure behavior of the verification 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%, so the schema already documents image_url and card_sn. The description repeats the card_sn condition but adds no parameter 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?

The description states a specific action (verify authenticity) on a specific resource (Korean alien registration card) from image/PDF, so an agent can identify the core purpose. However, the sibling tools identi_card_image1-4 appear nearly identical, and the description offers no explicit differentiation among 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?

It clearly communicates context: ARC authenticity verification, image/PDF input, card_sn requirement for post-2011 cards, and lawful basis. It does not state when to prefer this tool over the many sibling identity and OCR tools, or what cases should use an 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 declare readOnlyHint=true and openWorldHint=false, and the description adds useful operational context: the accepted MIME types (image/jpeg, image/png), the maximum size (50MB), the base64 response format, the cost, and a legal-use warning. It could further disclose error behaviors (e.g., invalid image handling), but the description clearly exceeds the annotations' minimal signal.

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 key purpose, then the operational details, legal note, and cost. Every sentence contributes: input type, output location, legal condition, and pricing. No redundancy.

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

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

For a one-parameter tool with a 100%-covered schema and read-only annotation, the description conveys the purpose, input constraints, output location, legal usage condition, and cost. It lacks explicit notes on failure/error cases or what '지정 정보' (specified fields) means exactly, but the core call flow is sufficiently documented.

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. The description adds value by clarifying that only one image file is needed, that the URL must be downloadable via HTTPS, the allowed formats, and the size limit. It does not repeat the schema's property name but confirms the expected usage flow.

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 ('Extract key fields from a Korean driver license image') and a concrete resource (Korean driver license), plus the distinctive masking behavior. It is clearly distinguishable from sibling tools like identity_document_id_card / passport / residence_card because it names the document type and its masking target (RRN last 6 digits).

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 states the input requirement ('PNG 또는 JPEG 이미지 파일 하나만 전달'), the output location ('masked_image 필드에 base64로 포함'), the legal precondition ('정보주체의 동의 등 적법한 처리 근거를 확보한 경우에만 사용'), and the cost ('호출당 30포인트'). It distinguishes this tool from generic OCR or other identity document tools by the masking behavior and document type.

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 annotation, the description explains the output format (masked_image field with base64), input limits (PNG/JPEG, single file), legal processing requirements, and per-call cost. There is no contradiction with the annotations.

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

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

The description is compact and front-loaded: purpose first, then input requirements, output behavior, and legal caveat. The bilingual repetition is mild but does not hurt clarity.

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?

It covers invocation well, but there is no output schema and the description does not enumerate which key fields are extracted or how they appear in the JSON response beyond masked_image. For a document-extraction tool, that is a meaningful gap, though enough information is present for basic use.

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

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

The input schema already fully documents image_url with allowed MIME types and the 50MB size limit. The description restates PNG/JPEG and single-file requirements but adds no genuinely new parameter semantics, so the schema-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 uses a specific verb ('Extract') and a clear resource: Korean resident registration card images. It also states the exact masking behavior (last 6 digits of the RRN), which distinguishes it from sibling tools like identity_document_passport or identity_document_driver_license.

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 clearly communicates when to use the tool: when a user has a single PNG/JPEG image of a Korean resident registration card and needs key fields plus a masked RRN image. It also includes important legal-consent guidance and input format constraints, though it does not explicitly name alternative tools or when not to use this one.

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 annotation, the description discloses meaningful behavior: the masked image is returned in the masked_image field as base64, the input must include both MRZ lines, and a legal basis such as consent is required. It also notes the per-call point cost. There is no contradiction with the annotations.

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

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

The description is compact and front-loaded with the core purpose. The bilingual Korean sentence partially restates the English opener, creating minor redundancy, but every major item (input, output, legal basis, cost) is included without padding.

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 single-parameter tool with no output schema, the description covers the input requirement, the output location (masked_image base64), and the legal prerequisite. It does not enumerate the 'key fields' that are extracted, which is a minor gap, but overall the agent has enough context 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?

The schema already covers image_url type, allowed MIME types, and size limit with 100% coverage. The description adds useful semantic guidance beyond the schema by specifying that exactly one image file should be passed and that it must include the two MRZ lines.

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 identifies the verb and resource: 'Extract key fields from a passport image and mask the passport number and MRZ area.' It is passport-specific and therefore distinguishable from sibling tools like identity_document_driver_license, identity_document_id_card, and identity_document_residence_card.

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

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

The description gives clear usage context: pass a single PNG/JPEG image that includes two MRZ lines, and use only when lawful processing grounds exist. It does not explicitly mention alternatives or exclusion cases, but the context is sufficient for an agent to know when this tool is applicable.

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 is consistent with that. It goes beyond annotations by specifying exactly what is masked, that the masked image is returned as base64 in the masked_image field, and the input constraints. 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 description is front-loaded with the core purpose and then packs in essential constraints: output field, single-document requirement, legal basis, and cost. The bilingual phrasing adds specificity rather than pure filler, and every clause carries information relevant to invoking the tool correctly.

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 single-parameter tool, the description is quite complete: it names accepted document types, input format, output field, and legal requirements. The main omission is that it does not enumerate which 'key fields' are extracted, which would be more relevant given there is no output 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?

The schema already covers image_url format and size with 100% coverage, so the baseline is 3. The description adds content-level constraints: the image must contain exactly one ID document, and lawful processing grounds are required. This is useful but does not deeply expand the parameter semantics.

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

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

The description uses a specific verb ('Extract') and names the exact resource types: Korean residence card, permanent resident card, and overseas Korean resident card. It also specifies the masking behavior of the last 6 digits, which clearly differentiates it from sibling tools like identity_document_driver_license, identity_document_id_card, and identity_document_passport.

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

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

The description gives clear invocation context: only one ID per image, PNG/JPEG images, and a lawful processing basis such as consent. It does not explicitly name sibling alternatives or state when not to use this tool, but the accepted document types are precise enough to 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?

Adds substantial behavior beyond the annotations: async submission, per-image pricing tiers with upfront deduction and refunds for failures, non-idempotency (same request re-creates a new job), and irreversibility ('접수 후에는 취소할 수 없습니다'). This reinforces idempotentHint=false with concrete detail the annotation can't convey.

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

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

Purpose is front-loaded and sentences are tight, but the pricing (basic 40P·advanced 350P·premium 1,400P) is stated twice — once in the body and again in the trailing bracket — which is pure redundancy.

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

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

For an async, non-cancelable, paid batch job the description covers cost, refunds, and irreversibility well. The main omission is any pointer to image_batch_status/image_batch_result, which the agent needs to retrieve results, though the async nature implies polling.

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 9 parameters are already documented, including the quality tiers and their prices. The description repeats the same price mapping in prose, adding essentially no new meaning over 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 (접수/accept) and resource (비동기 생성·편집 대량 작업 for 1-50 images), so the agent knows this submits bulk async image jobs. It never names the single-image siblings (image_generate, image_edit) it competes with, so differentiation is left to the '대량'/'1~50장' scope only.

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 1-50 image count and '대량' framing imply this is the bulk path versus single-image tools, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is inferable from scope 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 provide readOnlyHint=true; the description adds the key behavioral constraint that only completed jobs are valid and that the output is image content. It does not contradict annotations, though it remains silent on error behavior for invalid indexes or incomplete jobs.

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?

A single, front-loaded sentence that conveys the action and condition without unnecessary words. The '[무료]' note is extra but minimal and does not detract from clarity.

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

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

For a simple read-only tool with fully described parameters and a clearly stated return type (image content), the description is sufficiently complete. It does not detail edge cases like index-out-of-range, but that is already constrained by schema maximum/minimum and does not impede 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?

Both parameters have schema descriptions (job_id as '작업 ID' and index with 0-based semantics and min/max), giving 100% schema coverage. The description adds no parameter-specific detail beyond what the schema already documents, 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 uses a specific verb ('반환합니다') and a precise resource ('완료된 대량 작업 결과 중 지정한 한 장'), clearly indicating it retrieves one image from completed batch results. This differentiates it from creation or status siblings, making its purpose unmistakable.

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 when a batch job is completed ('완료된'), but it does not explicitly state when to use this tool over alternatives like image_batch_status or image_batch_create. No direct exclusions or alternative referrals are provided.

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

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

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context beyond that: it surfaces billing-related state (pre-deduction, refund, current deduction points) and marks the operation as [무료]. This helps the agent understand what kind of read operation it is and what domain information is involved, with no contradiction to the annotations.

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

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

The description is a single, front-loaded sentence that names the resource, the action, and the key returned information. The [무료] note is compact and informative, and there is no redundant wording.

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 one simple parameter, readOnly annotations, and no output schema, the description reasonably covers what the tool returns by listing progress status and point-related fields. It does not enumerate possible status values or error behavior, but for a 1-parameter status query this is a minor gap rather than a significant omission.

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

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

The schema has 100% coverage for the single required parameter job_id, including its format pattern and description, so the description does not need to compensate. The description adds no extra semantic detail about job_id itself, which is appropriate given the high schema coverage.

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

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

The description uses a specific verb (조회합니다, 'queries') and a precise resource: the status of batch image jobs, including progress and point-deduction details like 선차감, 환급, and current deducted points. This clearly differentiates it from sibling tools such as image_batch_create and image_batch_result, even without naming them 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?

There is no explicit when-to-use guidance or mention of alternatives. The intended use—checking the status of a batch image job by job_id—is implied by the description, but the description does not tell the agent when to prefer this over image_batch_result or when it is not 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 idempotentHint=false and openWorldHint=true, but the description adds real value by disclosing concrete per-image pricing by quality tier and confirming that resending the same request re-edits and re-charges. This cost/non-idempotency context is genuinely useful for a paid mutation tool, though it omits any note on output delivery or latency.

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 pricing information is stated twice – once in prose and again in a bracketed line – which is redundant rather than additive. The core edit action is front-loaded, but the duplicated cost block wastes 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 fully documented input schema, the description covers the key non-parameter concerns: cost, per-image billing, and non-idempotent re-charging. It is complete enough to call correctly, though it could note output format defaults or delivery behavior.

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 are already documented in the schema, including the quality-to-price mapping and size enum. The description restates the quality pricing 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 (이미지 한 장), and the '한 장' (single image) scoping distinguishes it from batch siblings like image_batch_create. It does not explicitly name an alternative such as image_generate, so it stops 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?

Usage is only implied: you have an original image plus an edit instruction. There is no explicit when-to-use guidance or routing to alternatives like image_generate for new images, though the input/output distinction is inferable from the required params.

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

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

Annotations already declare readOnly=false, idempotentHint=false and openWorld=true, yet the description adds the key consequence: the same request is regenerated and re-billed every time, plus per-quality cost figures. That billing/idempotency context is genuinely useful beyond the structured hints, though it says nothing about latency or how the resulting image is delivered.

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 cost are front-loaded, which is good, but the per-image pricing is stated twice – once inline and again in a bracketed duplicate – which is redundant bloat.

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 six mostly self-documented parameters, the description supplies the cost model, non-idempotent billing behavior and mode coverage that an agent needs before spending credits. It would be more complete if it noted whether generation is synchronous or how the image is returned.

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 (size, prompt, quality, background, output_format, reference_image_url) is already documented in the schema. The description only echoes the quality-to-price mapping already present in the quality field, adding no syntax or format detail beyond it.

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 (생성) and resource (이미지 한 장), and the explicit '한 장' (single image) scope implicitly separates it from the batch sibling image_batch_create. It stops short of naming any sibling outright, so it is clear but not maximally 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?

It describes the two supported modes (text-only vs. reference-image-plus-text), which implies how to invoke it, but gives no explicit when-to-use/when-not guidance and never points to image_edit or image_batch_create as alternatives.

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, so the safety profile is covered. The description adds useful context about per-call cost and typical application areas, but it does not disclose the similarity score scale, failure behavior, or limitations beyond the schema-provided 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?

The description is compact and front-loaded with the core action. The English and Korean portions repeat the same information, which is mildly redundant, but the use-case and cost notes earn their place and the overall length is appropriate.

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 with a richly documented schema, the description provides enough to invoke it correctly: what it does, what it returns, when to use it, and its cost. The lack of an output schema leaves the exact score range ambiguous, but this does not block correct invocation.

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