get_building_atch_jibun_info

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read-only operation ('조회합니다' - retrieves/reads) and describes the paginated nature of results through the page_no and num_of_rows parameters. However, it doesn't mention rate limits, authentication requirements, error conditions, or whether all parameters are required for successful queries. The description adds some behavioral context but leaves significant gaps.

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, what information is provided, parameter documentation, and return format. Each sentence earns its place by adding value. While comprehensive, it could be slightly more concise by combining some of the parameter explanations or using a table format, but the current structure is logical and efficient.

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 complexity (8 parameters, no annotations, but has output schema), the description provides substantial context. The output schema exists, so the description appropriately focuses on explaining the return structure rather than duplicating it. The parameter documentation is thorough, and the purpose is clear. The main gap is the lack of usage guidelines and some behavioral aspects like error handling or authentication requirements.

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 description provides excellent parameter semantics that fully compensate for the 0% schema description coverage. It explains each of the 8 parameters with Korean names, English translations, format examples, and default values. The schema only shows parameter names and types, while the description adds crucial context about what each parameter represents (e.g., '시군구코드' = city/county/district code, '5자리' = 5 digits) and how to format them.

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: '건축물대장 부속지번을 조회합니다' (retrieves building register attached lot numbers). It specifies the exact resource (building register attached lot numbers) and provides details about the information returned (lot address, new address, register classification). This distinguishes it from siblings like get_building_title_info or get_building_floor_ouln_info which target different building register aspects.

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 no guidance on when to use this tool versus alternatives. While it mentions what information is provided, it doesn't indicate scenarios where this specific attached lot number data is needed versus other building information tools. There's no mention of prerequisites, dependencies, or typical use cases for this particular data subset.

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