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

Annotations already declare the operation read-only and open-world, so the description does not need to restate safety. It adds useful operational context beyond the schema: credit cost per call, cache-hit behavior, dependency on search_address output, and the integer-KRW semantics of deal_amount_krw. Response pagination details are not disclosed, but this is a minor gap given the annotations.

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 front-loaded: cost appears first, followed by the core resource and required dimensions, then the one non-obvious input source. The example is embedded efficiently in parentheses. Every clause earns its place with no filler.

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?

Required inputs and their source are well covered, and the mention of deal_amount_krw hints at the response contents despite the lack of an output schema. Still, since there is no output schema, the description should clarify the overall return shape, pagination behavior, and result-list semantics; these are only implied by page/per_page parameters.

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?

The description enriches lawd_code by telling the agent to reuse search_address's lawd_code and provides a concrete example, which the schema itself does not convey. However, page and per_page receive no semantic enrichment beyond their names and default values, and schema coverage is only 50%. This is adequate but leaves clear gaps for the optional 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 ('국토교통부 아파트 매매 실거래가'), a concrete query dimension (시군구 + 계약월), and the exact code format. This goes well beyond restating the tool name and makes it easy to distinguish from sibling tools such as search_address or get_pricing.

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 gives actionable guidance: use the lawd_code returned by search_address, with an explicit Gangnam-gu example. It clearly implies this is a follow-up lookup after address resolution. It does not explicitly state when not to use it, but the context is strong enough for an agent to choose correctly.

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