Loading ToolBench
국토교통부 건축HUB(공공데이터포털) 건축물대장·건축인허가·주택인허가 조회 서버. 건축물대장·건축인허가·주택인허가 + 법정동코드 + 노후건축물/동단위 통계 분석.
Three tools with complete input schemas and descriptions, but descriptions are verbose (200-400+ chars) and lack LLM-optimized structure. All tools are READ_ONLY and well-scoped. Schemas are properly typed with defaults. However, descriptions bury key intent under implementation details (e.g., building_data explains internal ledger types rather than when to use it vs building_profile). No output schemas documented. Error handling is absent, no guidance on retryability, user-fixable errors, or recovery paths. Tool naming is clear (verb_noun pattern) but descriptions could be 50-150 chars with dependency hints instead of 200+ chars of API minutiae.
건축HUB 원천 데이터를 직접 조회한다 (건축물대장·건축인허가·주택인허가 통합, 고급용). 종합카드(building_profile)·연혁(parcel_history)·통계(district_stats) 등 가공 도구로 답이 안 되는 원본 행이 필요할 때만 쓴다. kind로 대장 종류를, type_name으로 세부 유형을 고른다.
한 필지(번지)의 건축물 핵심 스펙 + 용도지역을 종합 카드로 한 번에 조회한다. 표제부와 지역지구구역을 호출해 ① 용도지역·지구(법적 규제) ② 동별 주용도·구조·규모(층수/높이/연면적/대지면적) ③ 건폐율·용적률(미기재 시 면적으로 계산) ④ 세대/호수·주차·사용승인일·내진·에너지효율을 카드로 묶어준다.
주소 키워드로 시군구코드/법정동코드를 조회한다. 예: "광진구 자양동" → 해당 동의 sigungu_code(5자리)·bdong_code(5자리). 여기서 얻은 코드를 building_profile / parcel_history / building_data / old_buildings 등 다른 도구의 sigungu_code·bdong_code 인자로 사용한다. "자양동 680-63"처럼 번지가 섞여 있으면 자동으로 분리해 bun/ji 값을 함께 안내한다.
Descriptions are verbose (200-400+ chars) and implementation-focused rather than LLM-optimized. building_data spends 150+ chars explaining ledger types (kind/type_name enums) instead of answering 'when should I call this vs building_profile?' Rubric baseline: 10-1024 chars acceptable, but 50-200 is optimal for LLM selection.
No output schemas documented. LLMs cannot plan downstream calls or extract fields without knowing what building_data, building_profile, and find_region return. Rubric requires: 'Document the output schema. LLMs need to know what fields to expect.'
No error handling or recovery guidance. If find_region returns no matches, building_data fails with invalid codes, or API rate-limits, the LLM has no guidance on retry, user-fixable steps, or alternatives. Rubric: 'Error responses must tell the LLM what to do next.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=2025-11-25 | v2 |
building_data's kind and type_name parameters are enums but lack clear guidance on mutual dependencies. type_name valid values depend on kind (e.g., 'ledger' allows '기본개요' but 'permit' does not). Rubric: 'When one parameter's valid values depend on another, document this in both parameter descriptions.'
find_region description mixes example output ('광진구 자양동' → sigungu_code/bdong_code) with usage guidance. Rubric: 'Do not put example values in the description. LLMs tend to reuse example values literally.' Use parameter constraints and return-type documentation instead.