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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and closed-domain behavior are covered structurally. The description's only added behavioral fact is the geographic scope ('in Korea'), which is genuinely useful context not present in the schema or annotations. It says nothing about auth requirements, rate limits, or how large/expensive the response is.

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?

A single dense Korean sentence plus a one-line English gloss; the scope ('around a point') and the Korean-market constraint are front-loaded. The mid-sentence output inventory is list-heavy but every item conveys what data is available, so little is wasted.

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 usefully enumerates the return contents, which is the right compensation. However, for a 4-parameter geo tool it omits the coordinate format, how to source lat/lon (the geocode sibling), and any sense of result size or pagination, leaving real gaps an agent must guess at.

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 only 50%: radius_m and category_code are documented in the schema (including the 500/1000/2000 enum values, which the description does not repeat), while lat/lon carry no description at all. The description's '좌표 둘레 반경' and '업종별' loosely map to radius and category but add no coordinate system, format, or unit information to compensate for the undocumented required parameters.

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 names a specific resource — commercial-district statistics within a radius of a coordinate in Korea — and enumerates the payload (business counts by industry, nearby businesses, district demographics/causes of death/ordinances, openings/closings trends). It is a noun-phrase inventory rather than a verb-led statement, but an agent can tell exactly what it returns. Sibling differentiation is moot since none of the listed siblings (geocode, get_law, search_bids...) overlap in domain.

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?

There is no when-to-use or when-not-to-use guidance and no named alternative. Critically, the tool requires lat/lon and a sibling tool (geocode) exists that presumably produces them, yet the description never says 'geocode an address first' or otherwise explains how to obtain the required inputs. Usage context is only implicit from the phrase 'around a point in Korea'.

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