get_rh_rent

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

The verb '조회' indicates a read/query operation, providing some transparency that this is a data retrieval tool with no mutation side effects. However, with no annotations, the description carries the full burden and does not disclose pagination behavior, response format, or any rate limits, leaving significant behavioral details undocumented.

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 a single, compact sentence that immediately states the purpose and key parameters. There is no redundant wording or filler, making it extremely efficient.

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?

Given that there is no output schema and no annotations, the description needs to explain what the tool returns, how pagination works, and any limitations. It does none of this, providing only the basic query intent. For a tool with 4 parameters and a potentially complex response, this is a significant 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 description coverage is 50%, and the description reiterates the two required parameters (regionCode, dealYearMonth) but adds no new semantic details beyond what the schema already provides. It does not mention pageNo and numOfRows at all, so the 50% gap for these parameters remains uncompensated, though the core filtering params are highlighted.

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 the specific verb '조회' (query) and the resource '연립다세대 전월세 실거래가' (row house/multi-family rent transaction prices), which clearly distinguishes it from siblings like get_apt_rent, get_offi_rent, and get_rh_trade. It also specifies the key identifiers (지역코드+계약년월) in the description, making the purpose unambiguous.

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 implied usage is clear from the resource type: this tool is for row house/multi-family rent data, differentiating it from siblings. However, there is no explicit statement of when to use it over alternatives, no exclusions, and no mention of conditions or prerequisites.

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