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

With no annotations at all, the description carries the full burden and does add real behavioral context: the unit is daily average movement counts, and the response keys within/outside/total are defined. It still omits key operational traits such as data recency, handling of missing weeks, and whether a series can be empty, which matters for a time-series query tool.

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 core purpose is front-loaded in one sentence, then the constraints follow as scannable bullets with an example week string and a closing note on output fields. Every bullet carries actionable constraint information; the enum enumerations are lengthy but necessary given 0% schema coverage.

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 six-parameter, five-required time-series query with no annotations and no output schema, the description covers parameter domain rules, cross-parameter requirements, format, units, and return-field meaning. Only the direction parameter and data-lag/missing-data behavior remain undocumented, which is a modest gap rather than a blocking one.

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, and it largely does: it enumerates the valid item values per category, flags the cross-parameter dependency (시군구 requires sido), and specifies the exact week string format with an example. The one gap is the required enum parameter direction ('유입'/'유출'), which is never explained even though its values are self-describing.

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 first line gives a specific verb and resource: weekly population-movement volume (daily average counts) for a single target over a period. That is far more precise than the name alone. It stops short of 5 because it never distinguishes itself from plausible siblings such as get_breakdown or analyze_region_week, so an agent must infer the boundary itself.

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 bullet list gives strong conditional guidance on which category/item pair applies and states the hard availability limit ('성별·연령·입지유형은 전국 기준만 있다'), which effectively tells the agent when this tool can and cannot answer a question. However, there is no guidance about when to prefer this over sibling tools, and no prerequisites or exclusions relative to alternatives.

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