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

Annotations already establish read-only/idempotent safety, and the description adds substantial context beyond them: the public data source, that records contain only 상호·업종·행정동 with no detailed address or phone, that ordering is alphabetical rather than rating-based, and that each result carries list_page and ready URLs. For a lookup tool this is unusually rich behavioral disclosure.

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?

Purpose and the region-required constraint are front-loaded, but the single dense paragraph is heavy with parenthetical asides, and the '[보임 — 한국 업체·입찰 공고 찾기]' prefix references 입찰 공고 (bid notices), which belongs to a sibling tool and mildly muddies the scope.

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?

With no output schema, the description correctly explains what each result returns (list_page, ready URLs) and what fields are absent (no address or phone), which is the key completeness burden. It leaves limit/pagination behavior and the default result count unstated, a modest remaining gap.

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 75% and the schema already documents region narrowing and category examples, which the description largely restates ('지역 필수', 동 단위 축소, 247 subcategories). The undocumented 'limit' parameter is never explained, so the description adds only marginal meaning over the schema.

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?

States a specific verb and resource ('전국 영업 중 업체를 ... 찾습니다') plus the full category scope (247 상권업종 소분류, region required), so an agent immediately knows this is a nationwide business-directory lookup, not a bid or vendor-search tool. It explicitly contrasts itself with search_vendors, making sibling disambiguation concrete.

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?

'지역 필수' tells the agent a region must be supplied, and the closing sentence routes to search_vendors when procurement records or owner-registered detail are needed. It does not address the other siblings (find_local_shops, get_vendor, list_categories), so exclusions are incomplete but the primary conditional is clear.

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