check_pcccVerify that a Korean Personal Customs Clearance Code (PCCC) matches the given name, zip code, and phone number. 이름, 개인통관고유부호, 우편번호, 전화번호를 입력하여 개인통관부호 일치 여부를 검증합니다. 해외직구 주문 정보 검증 등에 사용합니다. [호출당 20포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 우편번호 (5자리, 예: 12345) | |
| name | Yes | 이름 | |
| pccc | Yes | 개인통관고유부호 (P + 숫자 12자리, 예: P123456789012) | |
| phone | Yes | 전화번호 (숫자만, 예: 01012341234) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true and openWorldHint=true. The description adds cost information ('[호출당 20포인트]') which is a behavioral trait not covered by annotations. It also explains the purpose of the verification, going beyond the structural hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact, front-loads the core action, and includes only relevant detail: purpose, parameters, use case, and cost. The English and Korean versions are redundant but serve a multilingual audience, and the cost note is valuable. No wasted sentences.
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?
Tool has no output schema, so the description should explain what the verification returns. It does not mention return values or error behavior. However, it does cover purpose, parameters, usage context, and cost. For a simple verification tool, this is a moderate gap, making it barely adequate.
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 individual parameter descriptions. The description adds semantic value by explaining the relationship between parameters: the PCCC is verified against name, zip, and phone. This clarifies the functional role of each parameter beyond the schema's standalone descriptions.
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?
Description states a specific action: 'Verify that a Korean Personal Customs Clearance Code (PCCC) matches the given name, zip code, and phone number.' This clearly identifies the verb (verify), resource (PCCC), and scope (matching against name/zip/phone), distinguishing it from siblings like get_pccc and req_pccc which focus on issuance.
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 clear context for when to use: '해외직구 주문 정보 검증 등에 사용합니다' (used for verifying overseas direct purchase order info). It does not explicitly exclude alternatives, but the use case is clear and distinguishes from sibling tools that create/retrieve PCCCs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes; even within families like identi_card1-5 vs identi_card_image1-5, the text-input vs image-input distinction is clear. However, the sheer number of tools and some near-synonyms (e.g., ocr_identi1 vs identi_card_image1) could cause occasional misselection, but descriptions mitigate this.
Naming follows a loose verb-first pattern (check_, crawl_, download_, draw_, etc.) but includes significant deviations: bare nouns (bank_code, location, whois), numbered variants (identi_card1, identi_card_image1), and mixed prefixes (ocr_, identity_, etc.). The inconsistency is noticeable but still readable and predictable within functional clusters.
80 tools is far above the typical 3-15, but the server is a broad API aggregator covering many independent domains (banking, ID verification, media conversion, search, LLM, etc.), so the high count is somewhat justified. Still, the sheer number makes the toolkit feel unwieldy and hard to navigate, placing it at the high end of acceptable.
Within its stated purpose as a general-purpose utility API, the toolset covers a wide array of common task families: identity document verification (text and image), OCR field extraction, media conversion, web/search, domain/IP lookup, and LLM chat. Most operations have both get and act variants (e.g., set/get watermark, parcel_tracking/auto), with few obvious dead ends for typical use cases.