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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds crucial behavioral context beyond annotations: series freshness varies per series and must be checked via meta.series_as_of; stale series (Korea base rate, KOSPI) are not 'current' and should not be cited as such; invalid indicator names are rejected rather than silently dropped. This explains what the tool does beyond simple reads and is important for accurate interpretation of results.

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 compact and well-paced: two sentences of purpose, one hint about usage, one caveat paragraph about freshness. The most important practical caveat (series_as_of) appears at the end, but the warning is short and not buried. Every sentence earns its place, no redundancy.

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?

The key gap is the series_as_of metadata being important and not part of a structured output schema (no output schema present). The description does a good job giving the specific context of what to inspect (meta.series_as_of, examples of which series are lagging), which covers the major gap. Not perfect because there is no explicit statement of what the tool does if months is out of range (but schema enforces), and no mention of the openWorldHint meaning (allowed to make best-effort). Overall, description is complete for practical use.

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 100%; the schema fully documents the parameters (months range 1-240 default 24; indicators list with all names and formats). The description adds the caveat about series freshness related to months, but doesn't add significant new meaning beyond the schema. Baseline of 3 is appropriate given the schema's thorough documentation.

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 uses a specific verb ('조회한다' - retrieves), clearly names the resource (Korean base rate, KOSPI, M2, US Fed rate, S&P500 monthly time series), and explicitly states its use case ('금리가 집값에 어떤 영향?' background analysis). It distinguishes itself from the many sibling tools by focusing on macroeconomic monthly time series, not property-specific data.

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 explicitly states when to use this tool (for background analysis related to macro indicators and their effect on housing prices), and the caution about series freshness provides clear guidance: don't cite stale series as current, and always report the series-specific as-of date. While it doesn't explicitly name alternatives, the specific use case and the warning about currency sufficiently route the agent. The openWorldHint annotation and sibling names clarify what other tools are for individual areas.

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