search_jusoSearch Korean road-name addresses by keyword. 지번 또는 도로명 키워드로 도로명 주소를 검색합니다. 페이지당 10건씩 반환되며 total_count 필드로 전체 검색결과 개수를 확인할 수 있습니다. [호출당 2포인트]
| Name | Required | Description | Default |
|---|---|---|---|
| juso | Yes | 검색할 주소 키워드 (지번, 도로명. 예: 디지털로) | |
| page | No | 검색 결과 조회 페이지 (기본값 1, 페이지당 10건) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering safety. The description adds behavioral details beyond annotations: '페이지당 10건씩 반환되며 total_count 필드로 전체 검색결과 개수를 확인할 수 있습니다' (returns 10 per page, total_count shows total results) and '[호출당 2포인트]' (cost per call). This gives useful context about pagination and cost.
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 concise and front-loaded: two sentences cover purpose and key behavioral details, with the cost in brackets. There is no fluff, and every sentence adds 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?
Given the tool's moderate complexity (2 parameters, no output schema), the description sufficiently covers pagination, total_count, and cost. It does not detail the exact fields of returned address results, but annotations and the simple schema make this adequate for an agent to select and invoke 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 coverage is 100% for both parameters, providing baseline semantic clarity. The description adds value by clarifying that the 'juso' keyword can be '지번 또는 도로명' (land-lot or road-name) and giving an example '디지털로'. This reduces ambiguity beyond the schema 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?
The description clearly states the tool's function: 'Search Korean road-name addresses by keyword.' This uses a specific verb and resource, and the Korean phrase '지번 또는 도로명 키워드로' clarifies the search input. No sibling tool appears related to address search, so it is well-distinguished.
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 when to use the tool: when needing to search Korean road-name addresses. It also provides usage context such as pagination (10 per page) and total count. However, it does not explicitly mention exclusions or alternatives, though no sibling tool is a direct alternative, making the implied usage sufficient.
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.