get_building_expos_pubuse_area_info

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

With no annotations provided, the description carries full burden of behavioral disclosure and does so comprehensively. It reveals important behavioral traits: parameter normalization behavior ('hoNm은 "401호" 또는 "401" 모두 가능합니다' - hoNm accepts both formats with internal normalization), pagination behavior with default values, and specific parameter requirements. It also describes the return structure in detail, going beyond what the output schema would provide alone.

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 well-structured with clear sections: purpose statement, important guidelines, parameter details, and return format. While comprehensive, it could be slightly more concise - some information in the Args section repeats what's in the guidelines. However, every sentence adds value, and the front-loaded important guidelines ensure critical information is seen first.

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 complex tool with 9 parameters, 0% schema description coverage, and no annotations, the description provides complete context. It covers purpose, usage constraints, parameter semantics with examples, behavioral details (normalization, pagination defaults), and return structure. Even with an output schema existing, the description adds valuable context about what '전유공용면적 정보' (exclusive/shared area information) contains in practical terms.

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 0% schema description coverage (titles only provide parameter names without meaning), the description fully compensates by providing extensive parameter semantics. Each parameter gets detailed explanations with examples: sigungu_cd is explained as '시군구코드 (5자리, 예: 11110 = 서울 종로구)' (municipality code, 5 digits, example). It clarifies parameter relationships (address components must be used together) and formatting rules for dong_nm and ho_nm.

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 purpose: '건축물대장 전유공용면적을 조회합니다' (Retrieve building register exclusive/shared area information). It specifies the resource (building register exclusive/shared area) and action (retrieve/query). However, it doesn't explicitly differentiate from sibling tools like 'get_building_expos_info' or 'get_building_floor_ouln_info' which might retrieve related building information.

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 excellent usage guidelines with explicit '중요/MCP 지침' (Important/MCP Guidelines) section. It clearly states when NOT to use certain parameters ('mgmBldrgstPk를 공식 파라미터로 지원하지 않습니다' - does not support mgmBldrgstPk as official parameter) and provides specific formatting rules for hoNm and dongNm parameters. It gives concrete examples for parameter values, making it very clear how to use this tool correctly.

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