Reevl — Korean Real Estate

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral detail beyond this: it returns distribution stats, provides per-province counts, and exposes unit conversion pitfalls. No contradiction with 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: it states what is returned, then gives a usage recommendation followed by a concrete example. Every sentence contributes and there is no fluff.

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 2-parameter, 0-required metadata tool with an output schema, this description is complete enough to invoke. It tells the agent what it returns, when to call it, why it matters, and what pitfalls to avoid.

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%, and both parameters are already meaningfully described in the schema. The description does not add significant semantics beyond what the input-schema provides, so the baseline of 3 is appropriate.

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 states a clear verb ('준다') and resource: all searchable axes, units, value distributions (min/median/max), and counts by province. It is clearly a metadata/guide tool rather than a search tool, but it does not explicitly distinguish itself from the sibling tools.

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?

It explicitly recommends calling the tool once before condition search, with a concrete reason and example showing how missing units can make range conditions 100x wrong. It lacks an explicit when-not-to-use statement or a direct contrast with sibling tools, but the intended usage context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds genuine value beyond annotations by disclosing the all-axes bundle semantics and the hard prerequisite that the tool only works with a cid obtained from search_apartments. No contradiction with 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?

Two tight sentences, zero filler. The first sentence fronts the core behavioral contract (what it returns), and the second covers workflow plus usage condition. Every clause earns its place.

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?

Completeness is high: there's an output schema so return values need no explanation, the single required param is fully documented with an example, and the description covers the call workflow and usage condition. Nothing an agent needs to select and invoke this safely is missing.

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 100% with a concrete format example for cid. The description adds provenance beyond the schema: it clarifies that the cid must come from a prior search_apartments call ('그 cid로 부른다'), which tells the agent where the parameter value originates - useful semantic context the schema alone doesn't convey.

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 pairs a specific verb (준다 - gives) with the exact resource (하나의 단지 - one apartment complex) and enumerates the return scope as a coherent bundle across all axes (기본·가격·전세월세·거래·등락·AI예측·입지·건물). It also differentiates from search_apartments by framing this as the detail retrieval for a chosen complex.

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?

Names the sibling search_apartments explicitly and prescribes the workflow: choose via search_apartments first, then call this tool with that cid. It also states the selection condition ('특정 단지를 판단해야 할 때 쓴다' - use when judging a specific complex), leaving no ambiguity about when to invoke it.

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

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

Beyond the read-only and idempotent annotations, the description adds critical behavioral context: the tool does NOT calculate, the agent must perform arithmetic, the as_of date bounds the data's validity and must be reported, and the effective loan limit is the smaller of LTV and DSR. It also warns that later revisions are not reflected. This far exceeds annotation coverage.

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 dense but well-structured with bold markers and asterisked caveats. Every sentence carries actionable information—calculation division, as_of handling, min-rule, exclusions, and honesty instructions. It is front-loaded with the core purpose and then layers critical caveats in a scannable format.

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 an output schema present, the description doesn't need to detail return values, but it still references how_to_calculate and explains post-processing rules. It covers all necessary operational context: when to call, what to do with the result, how to handle date-sensitive data, and what is out of scope. Nothing needed for correct invocation is missing.

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 input schema has zero parameters, so the baseline is 4. The description correctly focuses on output semantics and usage instead of parameter details, which is appropriate since there is nothing to parameterize.

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 states a specific verb and resource: it provides current mortgage regulation figures (LTV, DSR, stress rate, regulated areas, price caps). It directly distinguishes itself from siblings like get_apartment and search_properties by framing the tool as a regulatory-facts provider, not a property or transaction data source.

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 explicit call signals with example questions ('5억 아파트 사려면...', '연봉 5천에...') and explicitly says to call this tool first. It also states what is not covered (취득세·중개보수) and instructs the agent to admit lack of knowledge when data is absent, making when-to-use and when-not-to-use clear.

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

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

The description adds substantial behavior beyond the readOnly/idempotent/non-destructive annotations: canceled reports are included with canceled=true, rent transactions have both deposit and monthly rent, kind defaults to apt but supports all types, and results are sorted latest-first. These are critical quirks an agent would otherwise discover only from output data.

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?

Every sentence earns its place: purpose, differentiation, use cases, then high-value caveats about canceled records and rent amounts. The most important usage guidance is front-loaded, and no filler or schema repetition is present.

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 an output schema present and annotations covering safety, the description still handles the important missing context: canceled-report handling, rent price semantics, cid provenance, and the tool's unique role versus aggregate-only tools. Nothing needed for correct invocation is left ambiguous.

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 100%, so the baseline is 3, but the description enriches parameter meaning: it names the exact search tools that supply cid, clarifies that _rent kinds change output format, and explains how to interpret rent amounts. This goes beyond what the schema alone provides.

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?

States a specific verb and resource: gives individual transactions for a complex in latest order, listing date, amount, area, and floor. It explicitly contrasts with aggregation-only tools, so an agent can distinguish get_transactions from siblings that return summaries.

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?

Provides concrete use cases: 'most recent transactions in this complex', 'latest 10 same-plan transactions', and 'price change vs previous trade'. It also explains why other tools are unsuitable, giving both when-to-use and when-not-to-use guidance.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context about the content frequency and scope, namely that it is published almost daily and contains policy summaries plus real transaction data analysis, which goes beyond what annotations alone convey.

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?

Two short sentences deliver the key content, fields, freshness, and intended usage with no unnecessary filler. The output contents are front-loaded and every sentence earns its place.

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 tool is simple, has one optional parameter, a complete input schema, and an output schema. The description states exactly what is returned, gives the topical context, and provides a clear use case, which fully covers what an agent needs to invoke it correctly.

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 only parameter, 'limit', is fully described in the schema with a range and default value, so the description carries no extra parameter burden. Baseline 3 is appropriate since the schema covers the parameter semantically.

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?

States a specific verb and resource: it returns the list of Ribl's real estate briefings with title, summary, publication date, and link. This clearly distinguishes it from the sibling apartment/property search tools, which concern different entities.

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 a clear context for use: when the user asks about recent market conditions or policy trends, this tool provides supporting evidence. It does not explicitly list exclusions or alternatives, but the usage condition is concrete and actionable.

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

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

Annotations already mark it read-only and idempotent, and the description goes further by explaining exact-match semantics for region/brand/builder, numeric _min/_max range behavior, automatic existing-only filtering when using fc* predictions, response shape signals (units and total), and pagination/cost behavior. This adds substantial behavioral context beyond 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 long but every sentence carries operational value: use cases, matching rules, units handling, limit strategy, cost insight, and offset avoidance. It is front-loaded with the core purpose and then adds tactical guidance, so the length is justified.

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 18 optional parameters, full schema descriptions, an output schema, and annotations that establish read-only behavior, the description adds what an agent most needs beyond the schema: filtering semantics, response-shape conventions, cost-efficient limits, and guidance to consult describe_fields for huge result sets. Nothing critical for correct invocation is missing.

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 input schema already covers all 18 parameters with 100% description coverage, so the baseline is 3. The description adds meaningful value by explaining the general <axis>_min/<axis>_max convention, exact-match meaning, price units, and how status interacts with prediction filters, but it does not deeply re-explain each parameter beyond the schema.

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 leads with a specific action—filter nationwide apartments by conditions—and gives concrete example queries. It clearly positions itself as the condition-based search tool versus the focused get_apartment and describe_fields siblings, so an agent can tell them apart even before inspecting schemas.

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 says when to use the tool ('조건이 있는 질문'), when to increase limit to 100 for comparison/ranking/aggregation, why that is cheaper, and when to consult describe_fields instead of paginating with offset. It gives actionable routing advice and even names a sibling tool.

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

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

Goes well beyond the readOnly/idempotent annotations: explains that nationwide queries are impossible due to scale, that aggregation units vary by type (complex vs legal dong), that 'name' means dong name for detached/land/commercial, and that no AI prediction field exists. This is rich behavioral context an agent genuinely needs.

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 dense but each sentence earns its place, with ★ markers front-loading critical constraints. It covers type-specific aggregation, naming, prediction absence, and sibling routing without 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?

Given the large kind enum, 5 parameters, and output-schema presence, the description covers the essential constraints: required region, type-dependent aggregation, naming semantics, and the apartment/non-apartment split. Nothing an agent needs to safely and correctly invoke this tool is missing.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema: it clarifies that region is mandatory, warns that sort axes are meaningless for the wrong types, and explains the semantics of 'name' by type. Minor deduction because the 'sido+gu mandatory' phrasing slightly conflicts with the schema, which only lists gu as required.

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?

States a specific verb and resource: '실거래를 지역별로 준다' for non-apartment property types, and explicitly contrasts with search_apartments. The examples ('송파구 빌라 시세', '제주 토지 평당가') make the intended queries unmistakable.

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?

Explicitly says to use this tool for non-apartment questions and names the alternative search_apartments, stating the two datasets are completely separate. It also gives a hard constraint: region is mandatory and nationwide lists are not provided, which prevents invalid calls.

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