get_car_scrapCheck whether a Korean vehicle has a scrap/total-loss accident record, by VIN or license plate number. 차대번호(VIN) 또는 차량번호로 폐차사고처리 여부를 조회합니다. 중고차 구매 전 확인 등에 사용합니다. [호출당 10포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | 조회 종류. 1: 차대번호(VIN), 2: 차량번호 | |
| value | Yes | 차대번호(type=1, 17자리) 또는 차량번호(type=2) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already in annotations, the description adds valuable context: the tool is a read-only lookup, charges 10 points per call, and returns a status about scrap/total-loss handling. It does not detail output format but covers cost and scope, which is useful beyond 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 bilingual (English and Korean) with the Korean sentence essentially repeating the English content. While informative, the redundancy wastes space. Cost and use case are useful additions, but the duplication makes it less concise than ideal.
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 lookup tool with no output schema, the description sufficiently covers purpose, input method, use case, and cost. It does not need to explain return values since the description implies a yes/no status. It is nearly 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 covers 100% of parameters with detailed descriptions (type values 1/2, value format with length constraint for VIN). The description reiterates the 'VIN or vehicle number' from schema without adding new semantic details, so it meets the baseline 3 but does not exceed 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 clearly states the tool checks whether a Korean vehicle has a scrap/total-loss accident record, using VIN or license plate. This specific verb+resource distinguishes it from sibling tools like get_car_flooding (flooding records). The inclusion of the use case (pre-purchase used car check) reinforces clarity.
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 clear context: it is used for checking scrap/total-loss records, especially before buying a used car. It does not explicitly name alternatives or state when not to use it, but the purpose is distinct enough that the usage context is clear. Missing explicit exclusions prevents a 5.
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 target distinct resources and actions, but there is potential overlap between biz_detail and venture_biz_info, and the PCCC tools (req_pccc, get_pccc, check_pccc) require careful reading. Descriptions are clear enough to avoid major misselection.
Tool names mix verb-led patterns (check_*, get_*, req_*, search_*) with noun-phrase patterns (biz_detail, holiday_info, land_rt_price, parcel_tracking). This inconsistency makes it less predictable than a uniform verb_noun scheme, though names remain readable.
With 16 tools, the set is slightly above the typical 3-15 range, but the broad scope of the API—spanning business info, personal validation, car history, parcel tracking, and address search—justifies the count. No tool feels redundant.
The API covers its core verification workflows, but notable gaps exist: no tool for listing parcel carriers despite being referenced in parcel_tracking, no business search by name, and car history only covers flooding and scrap, missing general accident records. These gaps could limit agent workflows.