smart_building_lookup

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 thoroughly explains the tool's automatic processing flow: distinguishing between general and collective buildings, what data is returned for each type, and what is excluded (e.g., not retrieving '전유부' for collective buildings). It also details post-return AI actions, including user interaction steps and specific tool calls for follow-ups, providing comprehensive behavioral context beyond basic functionality.

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, usage guidelines, processing flow, post-return instructions, and parameters), making it easy to parse. It is appropriately detailed for a complex tool but could be slightly more concise in the post-return instructions, which include multiple sentences and warnings. Overall, most sentences earn their place by providing essential guidance.

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 (5 parameters, no annotations, but with an output schema), the description is highly complete. It covers purpose, prerequisites, detailed behavioral flow, post-return AI actions, and parameter semantics. The output schema likely handles return values, so the description appropriately focuses on usage context and workflow integration, making it sufficient for effective tool selection and invocation.

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 description coverage is 0%, so the description must compensate. It lists all 5 parameters in the Args section with brief explanations (e.g., '시군구코드 (5자리, search_bjdong_code로 조회)' - Sigungu code (5 digits, lookup with search_bjdong_code)), adding meaning beyond the schema's titles. However, it doesn't fully explain parameter interactions or provide examples for all parameters (e.g., detailed format for 'bun'), leaving some gaps in semantic clarity.

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: '건축물대장 스마트 조회 — 주소 하나로 건축물 전체 개요를 자동으로 파악합니다' (Smart building register lookup — automatically grasp the entire overview of a building with one address). It specifies the verb ('조회' - lookup), resource ('건축물대장' - building register), and scope ('전체 개요' - entire overview), distinguishing it from siblings that focus on specific parts like '전유부' or '층별 정보'.

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 explicit guidance on when to use this tool: '이 도구는 사용자가 건축물대장을 조회할 때 가장 먼저 호출해야 하는 핵심 도구입니다. search_bjdong_code로 코드를 얻은 뒤 이 도구를 호출하세요' (This tool is the core tool that should be called first when a user looks up a building register. Call this tool after obtaining codes with search_bjdong_code). It names the prerequisite tool (search_bjdong_code) and positions this as the initial step in a workflow, clearly differentiating it from sibling tools used later for specific details.

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