korea-realty

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

Annotations already declare the tool read-only, idempotent, and non-destructive. Beyond that, the description adds substantial behavioral detail: it returns a document-style text rather than structured fields, may produce candidate lists when court name is omitted, and instructs the agent to treat rights data as a court citation only, not to invent relations. This goes well beyond default annotation semantics.

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 well-structured: a core opening sentence, then id format, then important behavioral caveats, then a disambiguation paragraph. Every chunk has a purpose. It is a bit longer than strictly necessary, and it repeats some id-format details already present in the schema, but the payout is rich guidance in return for the length.

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 single-parameter, read-only tool with no output schema, the description covers the input origin, id format, fallback behavior, the nature of the response (document-form text), and clear differentiation from the two nearby alternatives. This is enough for an agent to invoke the tool correctly and interpret its results in context.

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, id, is already thoroughly described in the input schema with format, examples, and the no-court name caveat. Schema coverage is at 100%, so the description's mention of the same id format does not add new parameter meaning. It reinforces the correct usage but does not compensate for a coverage gap that does not exist.

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 opens with a clear statement: it fetches the full auction case content using the id returned by search. This verb+resource pairing is immediate and specific. It then explicitly contrasts this with realty_get_auction_case and realty_auction_history, making the tool's niche 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?

It gives explicit when-to-use guidance: this tool is for taking the exact search-returned id and getting document-like text. It names realty_get_auction_case for structured value handling and realty_auction_history for bid history, providing a clear decision rule among alternatives. The caveat about not fabricating rights relations also guides usage.

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 safety and idempotence. The description adds key behavioral context beyond that: the outlier filter (excluding values below P75's 50%), the resulting discrepancy with region_price_stats, and the area-unit conversion (전용평 vs 분양평). It stops short of explaining the exact return shape or median semantics, so it is strong but not perfect.

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 front-loaded and each sentence earns its place: core behavior, use-case positioning, sibling alternatives, outlier caveat, and unit conversion are all compact and organized under clear headings. Although dense, the structure makes it easy to scan and every block addresses a distinct decision or knowledge need.

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 tool with no output schema and three parameters, the description covers the main scoping, alternatives, exception-handling rule, and the important user-facing unit conversion. The only clear gap is that the base result's exact value measure (whether median or other) is not spelled out for the non-by_dong call, though by_dong's schema mentions median. It is very close to complete but has this minor ambiguity.

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 is already very descriptive for all parameters (region example, by_dong explanation, period range), so schema coverage is 100%. The description contributes the pyeong-band conversion table, but that relates more to result interpretation than to the actual parameter schema. It adds no new constraint or format guidance for the inputs, 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 clearly states the tool '조회한다' (retrieves) '지역의 매매 시세' split into four specific sizes by dedicated area. It also distinguishes the tool from realty_search_complexes immediately, making the purpose unmistakable and separable from siblings.

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 names the default use case (지역 가격 수준 비교), and gives clear exclusions: for monthly trends use region_price_stats, for specific complexes use search_complexes. It also adds the rule to prioritize this tool when price levels conflict with the unfiltered stats. This is exemplary routing 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?

The description warns that many failed auctions may signal rights issues or defects, and instructs presenting output as candidates needing verification rather than recommendations. It also discloses cross-tool overlap ('same property appears on both sides'), adding behavioral context beyond the readOnly/idempotent 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: the core purpose appears in the first sentence, with interpretation and sibling routing following in clearly separated sections. Every sentence earns its place, and the bolded alternative guidance is high-density rather than verbose.

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 read-only discovery tool with no output schema, the description supplies purpose, usage boundaries, interpretation guidance, and an overlap warning. Combined with the rich parameter schema, nothing essential for selecting and invoking the tool correctly 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 provides 100% parameter coverage with detailed descriptions, including the ambiguous '광주' handling, usage_name mapping, and discount-rate guidance. The description adds general context about sido/sigungu narrowing and failed-auction/discount logic, but no per-parameter semantics beyond what the schema already 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?

The opening sentence states a specific verb and resource: finding properties where accumulated failed bids have driven minimum bid prices down significantly. It also explicitly contrasts the tool with realty_search_auctions, so an agent can distinguish it from a sibling without needing to inspect the schema.

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 names realty_search_auctions(min_fail_count) as the alternative and gives a decision rule: use that tool for condition-filtering/list purposes and this tool for deep-discount candidate discovery. It also instructs narrowing by sido/sigungu and warns not to merge counts because the same property can appear in both tools.

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 annotations, the description provides substantial behavioral caveats: preservation limits of photos, null-row semantics, `fail_count` discrepancy rules, possible empty `tracking`/`price_events`, and the `min_bid_source` warning. These are exactly the kind of quirks an agent must know before interpreting results. No contradiction with the readOnly/intent 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 dense but every paragraph conveys a necessary behavioral or interpretive constraint. It front-loads the main purpose and then adds important caveats in an organized way. It is long, yet the information density justifies almost every sentence.

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, this description does an unusually thorough job of making interpretation independent of hidden knowledge. It explains how to identify 유찰 records, how to handle null rows, how to treat disagreement with `fail_count`, and how to interpret `current_min_bid_10k` when `court_schedule` is empty. An agent has enough context to avoid a whole class of errors.

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 the tool description itself does not add new meaning to `case_no` or `court_name` beyond what the schema already provides. Per the guidance, a baseline of 3 applies when parameters are fully documented in an external 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?

Description states a specific verb+resource 관계: '유찰 이력(기일별 최저가 저감 시계열)·가격 변동 이벤트·물건 사진 URL을 조회한다' and maps it to a concrete user question class. The scope is clear and easily understood. It doesn't explicitly name sibling tools like realty_get_auction_case or realty_search_auctions, so no direct sibling differentiation.

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 clear usage context by showing example questions and calling it the '담당 도구' for those questions, so an agent can infer when to call it. It does not explicitly state when to prefer a sibling tool or when not to use this one, so it falls short of the 5-level criterion.

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 the tool as read-only and idempotent, and the description adds substantial behavioral context: the sample_period field, the fact that unsupported period parameters are silently ignored, the automatic '빌라'→'다세대' mapping with a warning about sample distortion, and the clarification that '면적 미상' means no area listed, not zero. It also clearly explains the denominator (감정가 vs 시세) to prevent misleading answers.

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 front-loaded with the core purpose and formula, then organized into bold-headed sections for caveats and cross-references. It is longer than strictly necessary—especially the empirical data in the area_band section—but each section serves a distinct purpose and the structure makes it scannable.

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 no output schema, the description compensates by naming and explaining the key response fields: sample_period, by_fail_count, and by_area_band. It also covers edge cases (ambiguous sido, '빌라' mapping, unknown area band) and directs the agent to the correct sibling tool for market-price comparison, making the definition effectively complete for a statistics tool.

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; however, the description adds meaning well beyond the schema. It explains that bid_count_max is an upper bound and that the response's by_fail_count gives the distribution by failure count, advises when to set area_band with concrete empirical examples, and details the usage_name mapping behavior. This materially improves an agent's ability to choose parameter values correctly.

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: answers what percentage of the appraisal value a property is typically auctioned at, based on actual sale results. The description explicitly distinguishes this from realty_compare_auction_vs_market, which uses market price as the denominator, so an agent can clearly identify the tool's niche.

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 explicit when-to-use context: it is the key metric for setting a bid price, and the description advises using area_band when the property's size is known, bid_count_max according to the number of failed auctions, and usage_name='연립주택' for rowhouse statistics. It also explicitly routes market-price comparison to realty_compare_auction_vs_market and warns that period-narrowing parameters are silently ignored.

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 (readOnly, idempotent, non-destructive) are rich, because the description builds further: the '모든 입력은 선언' oversight rule where the server Judgements facts; the stated assumption that 양도 전액이 과세; that a second asset triggers re-computation of holding years (+1) for split-year scenario disclosed in scenarios.split_years.asset2_recomputed; that pre-2025 transfers and post-2026 pending legislation cause uncertainty (traps/changements) plus mandate to pass via traps·pending_legislation·disclaimer. Beyond the 2026–2026 support range is arrayed. No contradiction with annotations (pure computes/read-only).

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?

Long density is use-safe: front-loaded purpose then the key boundary caveat (not_curated, plained a decisive fork map realty_policy_rules) before any secondary guidance. The three paragraph sections (what it does / boundaries+routing / source-of-truth+delivery mandate) each earn their place; zero filler. For a 14-param tax tool with no output schema, this length is necessary and well-structured overall.

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 complexity+no output schema, the description covers the computation breadth, the declared-input boundary, exclusions, the routing to topic siblings and third-party guidance, and names required response fields (traps, pending_legislation, disclaimer, split.asset2_recomputed). The only gap: the presence of outlined singled-asset return value (the computed tax amount seems implied by '산출한다' but not inspi), so an agent's reply is concise — minor given the amount of guidance otherwise holds.

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 highly detailed per-parameter docs (share_pct при-person, holding_years, fact declaration, asset2_holding_years recomputation, multi_home_surcharge declaration semantics). The description contributes the two-asset conditional behavioral framing (correctly: '두 번째 자산을 주면...') and the mental model of '입력은 모두 declaration', but does not add new individual-parameter meaning beyond what the schema's rich property descriptions already provide. Baseline 3 is correct when the schema carries the burden.

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+resource: applies 양도소득세 세율표 deterministically to declared transfer/acquisition/cost/holding inputs, and with a second asset computes '같은 해 합산 vs 연도분산 vs 차손통산' comparisons. It explicitly contrasts itself with realty_policy_rules and orients the agent with canonical questions ('지금 팔면 양도세 얼마?', '두 채를 올해 같이 팔까 나눠 팔까?'). This distinguishes it from all 56 siblings without needing to open 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?

Automatically: when to use (selling decision, multi-asset compare), when NOT to use (1세대1주택 exception, 고가주택 12억 안분, 감면 특례 — explicitly not_curated), and then explicit alternatives: realty_policy_rules(topic='one_home_exemption_map') with the 5-gate/5-path, realty_policy_rules(topic=capital_gains_tax) for the source, topic=regulated_area for zone map. It even prescribes the route to be followed ('everything from exemption map first, only if factual remains go to 홈택스/세무사'). Beyond explicit.

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 readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: dated bug fixes (2026-08-08, 2026-08-16), the 50-150% appraised-value filter to exclude share/special properties, the null discount_vs_market_pct behavior with an explicit 'don't substitute discount_vs_all_types_pct' instruction, the 유찰 stale-min-bid caveat via min_bid_source/min_bid_note, and the 2-4s latency warning. 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?

Front-loaded with the core purpose, then logically progresses through defaults, matching algorithm, null behavior, caveats, performance, and sibling positioning. Every section earns its place given the tool's complexity; only the two dated bug-fix notes are slightly expendable, which keeps it just below a perfect score.

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 no output schema, the description fully explains the signal vocabulary (주의/관심/보통/낮음/판정보류), the null-vs-fallback output fields, and the min_bid_source/min_bid_note interpretation. A 7-param tool with no required params and subtle algorithmic traps is completely specified for correct invocation and result interpretation.

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 detailed per-parameter descriptions, so the baseline is 3. The description adds consequential context above that: usage_name defaults to '아파트' because same-complex matching degrades for other types, and include_past is tied to the future-dates-only default. The schema still does most of the heavy lifting, hence 4 rather than 5.

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: '경매 물건의 최저입찰가를 같은 단지 실거래 시세와 대조해 할인율·표면수익률을 낸다' — compares auction minimum bid against same-complex market transactions to produce discount rate and surface yield. Distinguishes from siblings explicitly: realty_auction_sale_rate (감정가 대비) is called out as having a different denominator, and realty_area_price_bands/region_price_stats are identified as the manual-baseline alternatives.

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 names this tool as the first-line answer to '이 물건 싸?' with automatic market join, and says when to combine it with realty_auction_sale_rate for bid pricing. It warns against mixing denominators (시세 대비 vs 감정가 대비) and routes manual-baseline use to realty_area_price_bands (수준) and region_price_stats (추이). The case_no/court_name bypass behavior is also stated clearly.

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 safety, so the bar is lower — but the description adds genuinely non-schema-discoverable behavior: the tool is paid, the source has unfiltered outliers and complex-level mixed data, and avg_price must not be cited directly (warning_baseline/warning_dispersion should be read first). This is the kind of data-quality disclosure that prevents an agent from drawing reversed conclusions.

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 structure is front-loaded: purpose first, then when-not/when-to, then the critical warning. Every section earns its place; only slight density exists in the warning paragraph, which elaborates the 'conclusion can flip' scenario with an example. Slightly wordy but well-organized and non-redundant.

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 2 parameters fully documented in the schema and no output schema, the description compensates by naming the key return fields (avg_price, warning_baseline, warning_dispersion) and their priority, along with the paid status and the decision boundary against rankings. Nothing an agent needs to invoke it correctly and interpret its core warning 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%: regions (2+ targets, array or comma-string) and months (1–60, default 12) are fully documented in the schema. The description adds no new parameter-level syntax or constraints beyond the schema; the multi-region implication ('여러 지역') restates what the schema already requires. Baseline 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 first sentence states a specific verb+resource: comparing 매매·전세 시세와 추이 for multiple regions side by side. It explicitly differentiates itself from realty_region_rankings (rank/exploration questions) and notes the same data notice as realty_region_price_stats, so an agent can pick this tool apart from siblings.

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 NOT to use it ('어디가 제일 ○○해?' exploratory questions should go to 무료 realty_region_rankings first) and when to use it (when comparison targets are already decided). This is a clear when/when-not rule with the alternative named, requiring zero inference.

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?

With readOnlyHint=true and destructiveHint=false already in annotations, the description still adds significant behavioral context beyond them: transactions are sorted by contract date descending, average/median are based on the most recent 5 records, outliers are not deleted but marked with outlier=true, and floor bands report both raw and *ex_outliers values. It also discloses the complex-name partial-match isolation behavior (0.58.0) and the refusal-with-reason rejection of silently converting user-given units. No contradiction with annotations exists.

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 front-loaded: the primary purpose is stated in the first sentence, and each following paragraph delivers a distinct behavioral contract (sorting, outliers, isolation, units, rent routing). A few maintenance details such as version '0.58.0' and the dated bug report are near-noise for an agent, but the density per sentence is high and no paragraph is 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?

There is no output schema, so the description must carry the full burden of return semantics — it does, naming price_by_floor_band, meta.complex_isolation, outliers.method, summary_result, *_ex_outlier fields, and quote_check. It also explains edge behavior (unseparated equal-myeong is kept but reported, rejected input returns the reason plus two exit doors). For a 9-parameter domain tool with a subtle unit-conversion pitfall, an agent has what it needs to call and interpret the tool 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?

Schema coverage is 100%, so each parameter is already documented individually. The description adds semantic relationships the schema does not spell out: the four area parameters are mutually coordinated with '네 개 중 하나는 필수' and the rule '면적은 사용자가 말한 단위 그대로 넣어라 — 환산은 서버가 한다', including the concrete failing example of putting 84 in pyeong_exclusive. This materially clarifies parameter interplay and prevents a known mis-call, which is beyond the per-parameter schema coverage.

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 opening sentence names a specific verb + resource + scope: '특정 단지·특정 평형의 최근 6개월 매매 실거래를 건별(계약일·층·가격)로 조회한다'. It is further differentiated from its siblings by explicitly stating what it is not: summary-only pricing goes to realty_search_complexes prices_by_area, and rental questions go to realty_complex_rent_by_pyeong. An agent can tell this tool apart without opening the schema.

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 when-to-use and when-not-to-use guidance with named alternatives: use realty_complex_rent_by_pyeong for 전월세, and use realty_search_complexes' prices_by_area when only 평형별 시세 요약 is needed. It also assigns floor-band price questions ('저층 사면 손해야?', '고층 프리미엄 얼마야?') to this tool because 그 층 밴드 축은 다른 도구에 없다, leaving no ambiguity about tool selection.

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 the call as read-only/idempotent, so the bar is lower; the description still adds valuable non-schema behavior: partial matching can conflate same-name complexes, the result row key supply_pyeong uses a precise 분양평 conversion formula, and the tool is the jeonse input to a jeonse/sale ratio calculation. These are real operational cues an agent needs and cannot infer from annotations alone.

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, front-loads the purpose and metric, and each sentence earns its place: query scope, calculation role, call prerequisite/disambiguation strategy, and row-key semantics. The bolded terms and line breaks make it skimmable without wasting tokens.

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 moderately complex tool with no output schema, the description plus the rich per-parameter schema covers the input contract, ambiguity handling, and return metric. It stops short of specifying the full response shape or units, so an agent has a small amount of runtime uncertainty, but it is enough to select and invoke the tool 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?

Schema description coverage is 100% and every parameter is already documented in the schema, so the baseline is 3. The description adds one piece the schema's required list does not encode: a one-of constraint (complex_key or complex_name) and a preference for complex_key, which materially improves parameter selection.

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 opens with a precise verb+resource: '단지의 평형별 전세 보증금·월세 중앙값을 조회한다', naming the exact resource (rent medians by pyeong) and the metric (median). It also states the tool's role as the '전세 축' of the 전세가율 calculation, which separates it from sale-price counterparts in the same domain even without naming them explicitly.

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 gives clear call-guidance: one of complex_key/complex_name is required, partial name matching risks mixing same-name complexes, and the recommended path is to use realty_search_complexes to obtain a complex_key first. This is clear context for when and how to use the tool, though it does not explicitly enumerate sibling tools to avoid beyond the implied jeonse-side scope.

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 establish readOnlyHint and idempotentHint, so the description only needs to add extra behavioral detail. It does by revealing response contents (coordinates, complex_key) and the paid nature of the report. This meaningfully goes beyond annotations without contradicting them.

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 very concise: a single purpose sentence plus one downstream-routing sentence. It is front-loaded with the core action and wastes no words. The paid indicator and chaining guidance both add clear value.

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?

This is a simple read-only two-parameter tool with no output schema, and the description provides enough context for the main call: what it returns, and how to use that output next. It could be slightly more explicit about whether the user must provide name or complex_key; otherwise the description is sufficiently complete for a tool of this complexity.

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?

Both parameters (name and complex_key) are already described in the schema at 100% coverage, so the baseline is 3. The description adds a bit by saying complex_key will appear in the response and can be reused downstream, but it does not clarify whether one parameter is preferred, required, or how the two relate.

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 clearly states the tool's verb and resource: it queries an integrated report for a single complex (시세, 전세, 기본정보). It conveys scope and content well, but does not explicitly distinguish it from related sibling tools like realty_complex_pyeong_price or realty_complex_rent_by_pyeong.

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 paints a concrete workflow: call this tool first, then feed the returned latitude/longitude and complex_key into realty_poi_nearby and realty_predict_price. That is actionable and clarifies a natural continuation. It does not explicitly mention when not to use the tool or truly contrast alternatives.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is for the description to add context. It discloses substantive temporal behavior: response meta.data_as_of is the true recency point, warnings must be forwarded to users, and lagging figures must not be asserted as 'current'. It also reveals a first-party data collection defect for households and the correct alternative route — genuinely useful non-obvious behavior 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 compact, front-loaded with purpose and example questions, then progressive: temporal caveats, then the metric-specific bug and fallback. Each sentence adds value and none repeats schema content, though the opening could be slightly shorter without losing clarity.

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 tool with no output schema, the description provides the most critical response-level guidance: full data recency via meta.data_as_of, warning propagation, and base-year framing for annual series. It does not describe the response shape or grouping beyond what metric implies, which is a minor gap given no output schema exists, but the operational essentials for the agent are covered.

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%, and the schema already documents each enum value, the months window (1–60, max 5 years), and age's row-level constraints, so the description need not repeat them. The description adds only indirect param context (which metrics are monthly vs annual, that months cap applies to population·migration). Baseline 3 applies because the schema carries the weight and the prose adds limited extra meaning.

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+resource ('지역 인구통계를 조회한다') plus concrete example questions ('인구 줄고 있어?', '1인 가구 비율은?') that make the tool's scope unmistakable. The title and opening line also enumerate the four metric dimensions. It does not explicitly name or differentiate from sibling tools like realty_macro_indicators, so it falls just short of a 5.

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 strong 'when to use' signals via realistic user questions covering population decline, household composition, aging, and migration. It also gives a metric-specific exclusion (households rejects same-name 시군구) with an instructed fallback to population·migration. It stops short of explicitly contrasting with sibling alternatives (e.g., when to prefer realty_macro_indicators or realty_compare_regions).

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 a safe read-only, idempotent, open-world operation, and the description substantially extends this without contradiction: case numbers are non-unique across courts (avg 2.8), duplicate errors return candidate court lists, rights=null means 미수집 and forbids fabrication, claim_amt_10k is the creditor's claim amount rather than the tenant deposit, min_bid_source=item_list signals staleness, and the server's fallback re-search when the named court lacks the case. This is rich disclosure far beyond the annotation fields.

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 purpose is front-loaded in the first sentence, followed by a logical ordering: duplicate-number caveat, rights handling rules, the ⚠️ claim_amt trap, stale min_bid warning, sibling exclusions, and a final positioning paragraph (이 축의 자리). It is long, but every sentence addresses a real failure mode or routing decision with zero filler, and the ⚠️ markers highlight the highest-risk misinterpretations.

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 no output schema, the description bears the burden of explaining return-value semantics and does so thoroughly: the rights object and its disclaimer requirement, rights_note for null, claim_amt_10k/claim_amt_note, and min_bid_source/min_bid_note. It states clear boundaries (등기부·임차인 현황 전체 아님, 보증금 액수 없음, history/photos handled elsewhere) and documents error/retry flows. An agent has everything needed to call it safely and interpret its response 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?

Schema coverage is 100% with already rich per-parameter descriptions (case_no format, hyphen expansion, missing-year trap; court_name formal-name/abbreviation handling and fallback behavior). The description adds the operational retry pattern — on duplicate error, specify the court and call again — and clarifies the tool's input contract as separate structured fields versus fetch's combined id, so it adds genuinely useful value above the schema-dominant baseline of 3, though the schema carries most of the semantic weight.

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 sentence states a specific verb and resource: '사건번호로 경매 물건의 상세를 조회한다' (query auction property detail by case number). It actively distinguishes itself from siblings across the description — realty_search_auctions for condition-based sweeping, realty_auction_history for 유찰 이력·기일별 저감·사진, and fetch for document-form text from a combined id. An agent can select this tool unambiguously.

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?

Gives explicit when/when-not guidance: omitting court_name triggers a candidate-court list and the imperative retry instruction '그걸 보고 법원을 지정해 다시 호출하라'. It explicitly routes history/session-reduction/photo needs to realty_auction_history, condition sweeping to realty_search_auctions, and the combined-id document case to fetch, stating '둘은 대체재가 아니라 입력·응답 형태가 다른 짝이다'. Nothing is left to inference.

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 this readOnly, idempotent, and non-destructive. The description adds useful behavioral context: the tool is paid, and the disclaimer in the response must always be conveyed to the user. This goes beyond what annotations provide, though exact output rendering is not detailed.

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 short and front-loaded with the core scoring concept. It loses a little efficiency because the title already notes it is paid, and the same '[유료]' prefix is repeated in the description.

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 single-parameter, low-complexity, readOnly tool, the description conveys the core purpose, scoring axes, required output handling, and paid aspect. Since no output schema exists, a little more detail on response format or score interpretation would improve completeness, but it is not markedly incomplete.

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 schema already fully documents the only parameter ('region'). The description adds no new parameter-related semantics beyond indicating that output is a regional risk score.

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 clearly states a specific verb and resource: it 'scores' 'regional investment risk' across volatility, liquidity, and supply pressure. This distinguishes it from nearby realty tools, though it does not explicitly name sibling alternatives.

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 no direct guidance on when to use this tool versus other realty analysis tools. It mentions a required user-facing disclaimer, but not conditions for selection or alternatives, leaving usage largely to inference.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, the description discloses that declarations like home count, first-time, and newlywed are not fact-checked by the server, that the tool does not compute limits for certain categories, and that rule uncertainty lives in the result's topic field. This is exactly the behavioral context an agent 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 structured clearly with bolded sections and numbered boundary. It has some redundancy with the title and includes a historical rationale that could be trimmed, but each sentence conveys a reason why. It is more thorough than concise, which is justified for a cross-product routing tool.

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 description fully compensates for a missing output schema: it says the response contains eligible products and reason, and references the topic field for rule details. It covers edge cases like declarations, non-computed limits, and boundary reads for a tool with 8 parameters and multiple cross-cutting rules.

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 provides 100% parameter coverage with rich descriptions, including the warning not to confuse 전세 and 전세반환 and the role of total_assets_10k for. The description adds routing context but no additional per-parameter meaning, so the baseline 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 the tool's specific job: given purpose, region, and homes-owned, it lists allowable loan products side-by-side with reasons, acting as a router so the caller does not need to know a rule topic. It also clearly distinguishes itself from realty_loan_limit, which handles loan amount calculation.

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 when and when-not guidance: use this tool for eligibility or routing, use realty_loan_limit for purchase limit amounts, and do not expect limits for jeonse/midterm-loan categories because those are governed elsewhere. It also instructs the caller to read the returned topic for rule details.

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 goes beyond the read-only idempotent annotations: it discloses that the result is a deterministic regulatory cap, that the response echoes inputs via `inputs_declared`, that `dsr.by_rate_type` is provided for rate-type comparison, and that `uncertainties`/ disclaimers must be forwarded. It also warns against overstating 'N억까지만 된다' when the user has not decided the rate type.

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 beginning states the core computation and is followed only by high-value behavioral and routing guidelines; no filler. Although longer than average, every sentence provides either a boundary, an alternative-tool pointer, or a limitation that prevents the agent from giving an incorrect answer.

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 no output schema, the description takes on the necessary burden: it names the key response components (`inputs_declared`, `dsr.by_rate_type`, `uncertainties`, `loan_term adjustment`) and important edge cases such as rate-type sensitivity and declared borrower state. It also provides missing sociable boundaries and sibling routing despite the large sibling set.

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?

Parameter descriptions in the input schema already cover 100% of properties, so the baseline is 3. The description adds no new per-parameter syntax or semantics; it does connect the key behavioral parameters (borrower declaration, rate_type, region/regulatory-area) to the larger outcome, but that is not enough for a higher score given the schema already does the heavy lifting.

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+resource: it computes the regulatory cap for mortgage loans (LTV cap, 6/4/2억 price-band limits, 30-year term cap, and stress-DSR maximum) and gives an example question that anchors the intended use. It also differentiates this from the same-domain siblings by stating that it is the regulatory cap, not a loan approval/commitment, and that policy-rule and presale-funding questions should go to other 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?

Explicit when-to-use guidance is present via the example question and via boundaries: borrower type is only a declared fact, the result is not an approval, and the default variable rate_type is the worst-case assumption. It also says which sibling to use for rule-source and presale-funding cases, and instructs the agent to send the by_rate_type comparison table rather than asserting a single maximum when the user’s product is unspecified.

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 annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable caveats beyond those annotations: the score is a screening indicator, city-level hagwon data may skew outer areas, subway_distance_m is straight-line not walking distance, not_found is an honest response, and returned complex_key is normalized with a single space. 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?

The description is long but information-dense; every sentence carries a distinct caveat, routing rule, or normalization behavior. Key facts are front-loaded, and bolding makes the warnings scannable. There is 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?

Given no output schema, the description still covers expected response shapes (regional aggregation, top-5, complex scores), the not_found behavior, the score_lineage lineage marker, and how to reuse the returned complex_key. This is sufficient for an agent to select and invoke the tool 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?

Although schema coverage is 100%, the description adds semantically important detail: complex_key must be exact and comes from realty_search_complexes, complex_name is partial match, and region alone changes the result into a regional aggregate plus top-5 list. It also notes the returned complex_key is normalized for direct reuse in other tools.

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 queries a complex's school-district (v5) and transit (subway/bus) scores. It also differentiates itself from multiple siblings by clarifying what it is not, such as not being a school-assignment judgment and not being the realty_region_rankings scoring version.

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 gives explicit usage rules: complex_key/complex_name yields complex scores, while region alone yields regional aggregation plus top-5 complexes. It tells the agent to verify existence via realty_search_complexes when not_found, and routes actual POI lists/distances to realty_poi_nearby. It also warns against mixing with realty_region_rankings.

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, 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.

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, and the description adds non-obvious behavior: widening the window in a nationwide query causes older months to be trimmed to fit a budget, with the fact surfaced via meta.truncated and meta.truncated_note. This is meaningful 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 compact and front-loaded, opening with the purpose and paid indicator, then explaining the default window and the critical truncation behavior. Every sentence conveys essential information without filler, and the trailing context is structured clearly.

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 read-only two-parameter tool with no output schema, the description covers the key context: what is returned, default behavior, when to increase the window, and how truncation is reported. It does not fully describe the response shape beyond the meta fields, but this is sufficient for the tool's simplicity.

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 parameters are already documented. The description nevertheless adds semantics: it explains why months interacts with a nationwide query, the multiplication of rows across an 18-region grid, the truncation limit, and how specifying region avoids it. That's a clear value-add 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 clearly states a specific verb and resource: it 'queries' unsold housing trends and market sentiment index at once, positioning itself as a macro signal for buy timing. It is specific enough to be distinguished from most sibling tools, but it does not explicitly differentiate itself from a named alternative, so it stops short of a 5.

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 clear usage context: default 6-month window, when to increase months, and the truncation trade-off for nationwide queries. It does not explicitly say when to prefer this tool over alternatives, so it misses the highest bar, but it provides solid situational 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?

The description goes well beyond the readOnly/idempotent annotations by disclosing actual behavior: the outcome is deterministic ('결정론적'), it only returns the general restriction not the transferor-specific exceptions ('갈림길로만 주고'), and it will ambiguously semantics '실토한다' (admit it cannot determine) when data is missing. It also exposes the 2018-01-25 renewable account trap and instructs that exceptions/disclosures be conveyed to the user — which is exactly the kind of unsaid runtime behavior an agent could not infer from 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 core purpose is front-loaded in the first sentence, immediately followed by a concrete user question ('한남3구역 지금 사도 입주권 나와?') to anchor the agent. The following paragraph is superficially long, but each numbered clause contributes a boundary/referential constraint that keeps the tool from being misused, and with no output schema this dense listing is earned. Nothing is 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?

Despite having no output schema, the description tells the agent what the tool will and won't produce: it will return a determination of the main supplier/restriction, hand off transferor exceptions as a decision-tree branch, and explicitly give '판정 불가' where data is absent. It also names response fields exceptions and disclosures (`응답의 exceptions·disclosures를 함께 전하라`) the exact behavior the agent must preserve, making the whole conversational contract complete.

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 provides descriptions for all 6 parameters, with coverage of 100%, so baseline is 3. The tool description does not provide parameter-specific syntax details beyond what the schema already says; it merely repeats the tripartite structure (regulated_area × project_type × stage) in a sentence. Despite some hints about auto-combination for Seoul and the refusal to assert without first_approval declaration, the schema itself already contains this, so no meaningful additional meaning is added.

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+object: '도시정비법 39조 2항으로 결정론적 판정한다' and defines the actual question '지금 사면 조합원 지위를 승계받을 수 있는지' — the core decision. It also draws a contrast with where to go for the source text, exemption lists, and entitlement, so the tool is clearly distinguishable from siblings.

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 '경계를 지켜라' section explicitly directs the agent to realty_policy_rules with different topics for the oracle text, for the speculation zone status, and for entitlement uncertainty, and to realty_redevelopment for project-only list/stage. It also names what the tool does not decide (transferor factual exceptions, land transaction zone, small-scale projects in the schema) — explicit when/when-not 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?

The description reveals behavior that annotations do not cover: the result is a lower-bound settlement based on Cheongahon announcements since 2020-02; announcements typically appear ~30 months before occupancy; and far-future slices are systematically understated. It additionally exposes output semantics such as meta.window_direction, interpretation, and coverage.region_recent_annual_rate, so an agent knows how to interpret the response.

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 well structured: each bolded segment carries a distinct and genuinely useful point, such as future-window semantics, lower-bound counting, and follow-up to the pipeline. There is little filler, and the concrete example helps the agent understand the practical stakes, though some steps are dense and could have been tightened further.

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 5 loose parameters, no output schema, and a data caveat, the description remarkably covers the required output interpretation, delusion-prone pitfall, and follow-up path. An agent can correctly select and use the tool, interpret reading.lower_bound, and decide when to call the pipeline.

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 the parameter descriptions already explain from_ym, months, to_ym, region, and sigungu well, including forward/backward timing and mutual exclusivity of months and to_ym. The tool description mainly restates those semantics in prose rather than adding new parameter detail 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 explicitly states the tool's function: it aggregates regional move-in supply by year-month. It answers concrete questions like '입주장 리스크 있어?' and '물량이 얼마나 쏟아져?', and it differentiates itself from realty_supply_pipeline by clarifying that this tool covers announced supply while the pipeline covers approved-but-not-yet-announced supply.

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 clearly identifies when to use the tool, when to switch to realty_supply_pipeline, and when to avoid double-counting: if coverage.region_recent_annual_rate is low relative to the result, the shortage is likely due to announcement timing, not supply cessation. The description also tells the agent not to state 'no risk' when the tool only reports the lower bound.

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 signal read-only, idempotent, and non-destructive behavior, but the description adds serious non-obvious facts: an apartment query can return HTTP 200 with plausible rows when a wrong property_type is selected, land share transactions must not be used for price-per-area comparisons, and different property types have different area and field conventions. This goes well beyond the safety hints.

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 front-loaded with the single most important warning and organized into clear thematic blocks: core purpose, routing instructions, data limitations, and type-specific area semantics. It is dense, but nearly every sentence carries decision-relevant information; the small amount of redundancy with the schema keeps it from a top score.

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 lack of an output schema and the high conceptual complexity, the description fully explains what the response contains, how each property type handles area, and the notable exclusion rules for share-type land rows. It also gives the agent an explicit script for handling requests outside the data scope, making it complete for safe, correct invocation.

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. The description does add value: it explains that no property_type value corresponds to apartments, that area_band only makes sense for villa/officetel, and that land-specific fields like land_category or zoning are part of the data. Still, much of this is already duplicated inside the schema's parameter descriptions, so it doesn't fully break away from 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 states the exact scope: '빌라(다세대·연립)·오피스텔·단독주택·토지 전용 실거래 매매가 조회' and the response shape '최근 거래 + 집계'. The emphatic '아파트는 이 도구가 아니다' and the explicit naming of sibling tools distinguish it sharply from other realty 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 gives precise routing conditions: if the request contains '아파트', stop and use realty_region_price_stats, realty_search_complexes, or realty_complex_pyeong_price; do not use this tool for dong-level narrowing because sibling tools already accept legal-dong input. It also instructs the agent to answer that no jeonse/wolsae data exists rather than guessing.

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 readOnly/idempotent annotations, it discloses p-page citations, notice_version, the unverified_source_text fallback, the 64KiB truncation limit, meta.truncated and meta.omitted_sections behavior, and the '못 봄 ≠ 없음' semantic. This is rich, non-obvious behavior that an agent needs before calling.

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 organized into tool scope, alternate/full-text fallback, risk warning, and truncation semantics, with the most important definition first. It is long but mostly each section earns its place; however, the first and second paragraphs repeat a similar list of fact categories, adding slight redundance.

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?

Despite having no output schema, the description covers the necessary usage context: how to cite results (notice_version, p), how to handle unextracted notices, what to do when results exceed the tool limit, and how to recover omitted portions. That is complete for a read-only, idempotent lookup tool.

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%, so the schema already documents keyword, section, and house_manage_no. The description adds workflow guidance around the truncation case but does not materially add parameter-level meaning beyond the schema, which is the baseline 3 case.

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 concrete resource (입주자모집공고 원문) and a concrete operation (추출·검증한 팩트시트), then enumerates the exact fact categories. It also distinguishes itself from realty_notice_text by stating that full provisions belong to that tool, so an agent can tell them apart.

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 says these fact-value questions are the tool's place, that the agent need not estimate or web-search, and that unextracted notices return unverified_source_text. It also gives an explicit alternative: read full clauses via realty_notice_text, and warns not to claim a fact is absent just because it is absent from the fact sheet.

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 read-only/idempotent, and the description adds substantial behavioral detail: pdftotext table alignment caveat, AND matching across tokens, zero-hit fallback with partial pages, 6-page response cap, always-present meta.matching_pages, and pages/query conflict behavior. 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?

Dense but efficient Korean description; every sentence earns its place. It front-loads the core purpose and differentiator, then layers workflow, error behavior, and output guarantees in logical order 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?

With no output schema, the description still tells the agent what to expect: page numbers and excerpts in pages_only mode, matching_pages metadata always present, and max 6 pages. Combined with detailed parameter docs, an agent has enough to call and interpret the result 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond schema: zero-hit behavior returns per-word hit pages and partial matches, response is capped at 6 pages, and pages_only together with pages is ignored and confessed. This enriches the agent's understanding without duplicating 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?

States a specific verb and resource: reads the original recruitment notice text page-by-page. It explicitly positions itself against the fact sheet ('팩트시트에 없는 세부...는 이 도구로'), distinguishing it from realty_notice_facts and making its job 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?

Gives clear when-to-use guidance: use when the fact sheet lacks qualification details, contract cautions, option details. It also provides a concrete workflow (pages_only=true first, then pages) and explains match='any' for broadening. It does not name the sibling alternative explicitly, but the fact-sheet contrast is enough routing.

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 readOnly/openWorld/idempotent/non-destructive, and the description adds substantial beyond-annotation behavior: sample coverage (113,673 of 688,264 bid results, only 3,824 낙찰), missing-value semantics (ratio_missing is unknown, not 0), a documented median-vs-mean distortion (386% outlier from share/forest property), and region reconstructed from item names with silent dropping. These are exactly the traps annotations cannot express.

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 front-loaded: purpose first, sibling differentiation second, axis positioning third, then structured ⚠️ warnings each paired with a concrete action ('median_pct가 정본', 'region_basis를 함께 전하라'). The raw population counts could be trimmed, but the density is justified because every warning block maps to a real data-quality trap the agent must relay to the user.

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 no output schema, the description compensates by naming the essential response fields (median_pct, p25_pct, p75_pct, ratio_missing, outcome_mix, region_basis) and the error behavior (sido_ambiguous). It does not enumerate the full response shape, but for a read-only statistics tool whose annotations cover the safety profile, all invocation-critical context is present.

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% and the schema itself already carries rich warnings (sido '광주' ambiguity, sigungu chunk-parsing limit, property_type's 31.6% vs 106.3% split). The description adds meaning beyond this by instructing the agent to always report region_basis alongside region filters and to treat property_type as the decisive axis. This exceeds the baseline-3 for high coverage, though the schema carries much of the parameter burden.

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 opens with a specific verb+resource: it answers '보통 감정가의 몇 %에 낙찰되나' and '얼마나 유찰되나' using actual 개찰 결과 — a statistics tool for public (Onbid) auction outcomes. It explicitly distinguishes itself from the same-named court-auction metric realty_auction_sale_rate and from the individual-item tool realty_search_onbid, so an agent can disambiguate without opening sibling 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 directly instructs that when a user asks for '경매 낙찰가율', the agent must check which side is meant (court vs public auction), naming realty_auction_sale_rate as the alternative. It further routes individual items/minimum prices to realty_search_onbid and tells the agent to read the rate by property_type and cite the median — explicit when, how, and when-not 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 carry the safety profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description adds context beyond them: the paid ([유료]) nature of the call, the distance-sorted behavior, and the coordinate-search scope limited to 3 POI types. It does not describe the return shape, but there is no contradiction with annotations — behavioral coverage is solid.

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?

Three dense sentences with front-loaded purpose, then the input-source note, then a bolded decision rule ('**점수**만 필요하면... 이 도구는 실제 시설 목록·거리를 셀 때'). Every sentence earns its place; no filler or restatement of schema contents.

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 4-parameter, read-only, fully schema-documented lookup, the description covers the essentials: what it returns (facility list by distance), when to use vs. realty_location_scores, and cost. The only gaps are the exact response structure (no output schema exists) and a minor internal wobble where '마트' appears in the description though coordinate search only supports 3 types — the schema's poi_type description promptly resolves the latter.

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 every parameter is already well documented in the schema: lat points to realty_complex_report.latitude, lng is self-explanatory, poi_type lists the allowed tokens ('subway,school'), the default, and the regional-stats fallback, and radius_m carries default/min/max. With the schema doing the heavy lifting, the description adds little extra parameter meaning, so the baseline 3 applies.

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: '좌표 주변의 지하철·학교·병원·마트 등 입지 요소를 거리순으로 조회한다' — a coordinate-based facility lookup ordered by distance. It also names what it is not via the sibling realty_location_scores (scores verdict) and realty_poi_stats (regional stats), so an agent can discriminate without opening either schema.

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?

Decision guidance is explicit: '단지의 학군·교통 **점수**만 필요하면 무료 realty_location_scores로 충분하다 — 이 도구는 실제 시설 목록·거리를 셀 때 쓴다'. The poi_type schema description also routes non-supportable types (마트·약국) to realty_poi_stats, and the description names the input source ('단지 좌표는 realty_complex_report가 준다'). This is exemplary when-to-use vs. alternative 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?

Beyond the annotations (readOnlyHint, openWorldHint), the description discloses a critical behavioral nuance: coverage is limited to Seoul/metropolitan areas, so zero values may mean 'not collected' rather than 'absent'. This prevents a serious misinterpretation of the 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?

The description is compact and front-loaded: the core function is stated first, followed by essential formatting and data-coverage caveats. Every sentence adds value 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 there is no output schema, the description adequately describes what is returned (counts of hospitals, schools, subway stations) and the region key format. The coverage caveat prevents downstream misinterpretation, making the tool's behavior well-understood for an agent.

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 schema already documents both parameters, and the description adds valuable semantics for the region format: '시도축약 시군구' 2-token with a special case for Sejong. This goes beyond the schema's generic 'prefix match' description, guiding correct invocation.

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 ('조회한다') and a precise resource ('시군구별 병원·학교·지하철역 개수 통계'), and adds the purpose '지역 간 인프라 비교용', making it distinguishable from siblings like realty_poi_nearby or realty_region_price_stats.

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 clearly states the intended use case: region-level infrastructure comparison. It does not explicitly name alternative tools or exclusion conditions, but the context is strong enough for an agent to select it when infrastructure counts are needed.

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 (readOnlyHint=true, openWorldHint=true, idempotentHint=true) are consistent with the description — no contradiction. Beyond annotations, the description discloses substantial behavior: the no-determination rule with a directive to ask confirming questions, the no-hallucination rule ('0건이라고 답한다... 표를 추측하지 마라') which operationalizes openWorldHint, a hardcoding anti-pattern warning quantified with a measured 3,700만원 error, and a mandatory output requirement to deliver uncertainties and disclaimer.

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?

Despite being long, the description has zero filler: paragraph 1 establishes identity plus five routing rules, paragraph 2 adds a concrete correctness warning with a measured error, paragraph 3 covers no-determination behavior plus three more routing rules and output delivery. It is front-loaded with the core identity (general norms, citations, confirmation date), and every sentence carries a distinct job proportionate to the tool's complexity.

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?

Complete for the selection and invocation decision: what it covers, when not to use it, how to route calculations, and how to behave when no topic matches. It references table fields (applicable_if, exceptions), meta data (sections_available in schema), and output requirements (uncertainties, disclaimer). The only gap: with no output schema present, the description never fully specifies the response anatomy of a returned topic, leaving the agent to infer the exact return shape.

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%, with each of the 25 topic enum values carrying its own dense Korean description plus detailed query and section semantics, so the baseline of 3 applies. The tool-level description adds only marginal parameter framing (example user questions mapping to query usage); the schema itself does the heavy lifting for parameter understanding.

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+resource: it provides general legal/regulatory norms (세율표, 규제지역, 대출, 임대차, 청약, 정비사업) tied to citations and confirmation dates, explicitly scoped as '단지에 종속되지 않는 일반 규범'. It anchors with concrete user questions ('취득세 얼마야?', '지금 팔면 중과야?') and sharply distinguishes itself from calculator siblings by declaring '이 표가 그 계산기들의 진실원이다'.

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?

Explicit when/when-not guidance with named alternatives: five calculators (realty_loan_limit, realty_subscription_score, realty_redevelopment_burden, realty_capital_gains_tax, realty_member_transfer_check) are each assigned their exact role, plus realty_presale, realty_notice_facts, and realty_presale_cost for notice-specific data. It also states the exclusion rule — factual determinations like 1주택 여부 must be handled by asking the user confirming questions, not answered here.

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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description goes further: discloses fixed 1-month horizon, explicitly admits out-of-coverage rejection rather than fabrication, provides failure-rate evidence (16.3% exceed ±10%), and transparently warns about response fields like caution, as_of_ym, and disclaimer. 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?

Highly informative but tightly written; every sentence carries concrete operational or cautionary value. Key facts (essential parameter, sibling for disambiguation, coverage boundaries, pass-through of warnings) are front-loaded and no filler 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?

Complete for a predictive tool with rich annotations and full schema coverage. The description covers required inputs, disambiguation workflow, model limitations, fallback behavior, and response-field obligations, leaving little an agent needs to infer.

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%, so the schema already documents each parameter. The description adds value by explaining the months parameter is a legacy compatibility field that is ignored and that the API itself 'confesses' this in its response. But it adds no new syntax or format details beyond that; baseline 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 specific verb ('predicts'), a precise resource ('next month's average sale price by pyeong type'), and the model (XGBoost). It clearly differentiates from siblings like realty_complex_pyeong_price by focusing on predictive output, not current market 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?

Explicitly states when to use (requires complex_name or complex_key), how to resolve ambiguity (use realty_complex_report first), and when not to use (coverage gaps, insufficient transaction data), while pointing to alternative tools for market data. This exceeds the minimum viable 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 mark it read-only/idempotent/non-destrictive, and the description adds substantial caveats beyond that: apply_status is pre-computed against meta.today and must be passed through rather than re-derived from dates; regulation flags are a snapshot as of announced_on and must not be presented as current; qualification/priority and resale-restriction data are intentionally absent and must not be invented or inferred; unsold_history absence is not evidence that no unsold occurred. No statement contradicts 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 front-loads the most danerous usage error (upcoming vs status='접수중') and each paragraph covers a distinct pitfall or sibling distinction, with no filler sentences. It loses a point because some status/upcoming caveats are repeated from the parameter schema and output-field explanations add length that would normally live in an output schema.

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 read-only tool with no output schema, the description covers what the tool returns (apply_status, meta.today, unsold_history, regulation flags), what it deliberately lacks (qualifications, resale restrictions), and how to route each follow-up intent to the correct sibling tool. The only minor omission is a concrete call example, which is not critical given the already-rich parameter schema.

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%, so the baseline is 3; all six input params are already thoroughly documented in the schema, including the status/upcoming pitfall. The description mostly reinforces those warnings (e.g., '오늘/지금 접수가능한 청약'은 status='접수중') rather than adding genuinely new parameter-level meaning. It does add useful non-parameter context like price_min/max being across housing types and the size_capped behavior, but those relate more to output interpretation than to input semantics.

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 the exact resource '아파트 청약(분양) 공고' and the specific verb '조회한다' (retrieves), and enumerates key fields (분양가·청약 접수 일정·당첨자 발표일·입주 예정·위치). It also distinguishes itself from siblings by explicitly naming realty_presale_vs_market, realty_subscription_odds, realty_presale_price_trend, and realty_notice_facts for different facets of presale 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?

Gives explicit question patterns that should trigger this tool ('다음 달 청약 넣을 만한 데 있어?', '○○에 분양하는 아파트 있어?') and explicit exclusions: '오늘/지금 접수 가능' 질문은 status='접수중'이지 upcoming=true가 아니며, real incident 2026-08-22를 근거로 든다. It also routes follow-up intents to specific siblings — realty_presale_vs_market for price comparison, realty_subscription_odds for competition rate/qualification, realty_notice_facts for resale restrictions, realty_presale_price_trend for regional price trends.

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 mark it read-only, idempotent, non-destructive, and open-world. The description adds behavioral context such as '표본 부족' verdicts and how missing data is reported, but it doesn't explicitly describe what happens in edge cases like multiple keyword matches (beyond saying candidates list is returned) or zero matches. Overall it provides some added transparency consistent with the open-world and read-only hints.

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 fairly long but every sentence earns its place: it explains the five axes, the danger of misreading the data, the exact reading rules, and positions the tool among its siblings. The only minor dent is its length and the slight repetition of the five-axis list toward the end.

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 no-output-schema tool with 6 parameters and no required parameters, the description is remarkably complete. It explains what output to expect (five-axis values and percentiles, or distribution only if no notice is given), what the verdict means, and where to find alternative tools for neighboring questions. Nothing essential 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 description coverage is 100%, so the baseline is 3. Every parameter has a functional description. The tool's description text reinforces how parameters interact (e.g., '지정하면 모든 셀에 같은 필터가 걸린다' for exclusive_m2_min/max), but description-level semantics mostly mirror the schema descriptions.

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 clearly identifies the tool as a comparative analysis of presale notices across five axes (land cost ratio, optional balcony expansion, mid-term loan interest, floor premium, and per-㎡ price). However, unlike the high-water mark of sibling tools like get_calls, it doesn't explicitly name which sibling it is NOT; instead it lists sibling alternatives only at the end, leaving some differentiation implicit.

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 goes beyond merely stating when to use it and provides explicit 'how to read' rules — including when NOT to substitute background data (D-2026W33-40), when not to plot yearly time series (meta.coverage.by_year), how to interpret 'unknown' mid-term loan values, and a caution about per-㎡ price being based on exclusive area. This is outstanding guidance compared to most definitions.

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 say readOnlyHint, idempotentHint, and non-destructive, so the bar is lower. The description adds meaning beyond those: it is a deterministic calculation, based on specific assumptions, using standard tax rates, and it warns the agent that those assumptions must be conveyed to the user. It also reveals that even the move-in date assumption can change the result by about 1.24M KRW. 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?

The description is well-structured and front-loaded: the first sentence gives the exact formula, the second sentence states the user-facing purpose, and the following sentences give necessary boundary conditions and routing. Each part earns its place without redundant text.

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?

Even without an output schema, the description makes expected output shape clear (“층별 총 소요자금”), enumerates all components that feed into the calculation, and defines the tool’s exact scope. It also conveys key assumptions to pass back to the user, which is essential for correct tool usage.

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?

All 6 input parameters have full descriptions in the schema, so the schema does most of the work and the baseline is 3. The description adds high-level formula context but does not map each parameter to the formula or clarify which parameters interact. That is sufficient, but not beyond the baseline.

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 precise, deterministic computation: floor-level price + balcony expansion cost + interim loan interest + acquisition tax = total cost. It frames the tool as the place to answer “이 분양 실제로 얼마 드나” and distinguishes itself from sibling tools by explicitly naming the boundaries and not claiming to cover monthly payments or funding plans.

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 gives unusually explicit selection guidance: states what the tool does NOT compute (monthly repayments, buy vs. rent decisions), and directly routes the user to realty_complex_rent_by_pyeong for rent prices, realty_presale_funding_plan for funding-plan judgment, and realty_policy_rules for the full tax-rate table. This makes it easy for an agent to choose the right 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?

Even with `readOnlyHint: true` and `idempotentHint: true`, the description adds valuable behavioral context: it is not an approval, it only reflects current regulations and current funds, it intentionally ignores future market changes, and it does not infer future sale/jeonse prices. It also states that response `assumptions` and `uncertainties` should be conveyed, and that optional declarations trigger parallel scenarios.

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 of it contributes: it opens with a precise single-sentence judgment and then groups all boundaries into numbered, scannable items. The use of bolded terms, self-contained bullet sections, and explicit sibling names means there is no wasted or repetitive prose.

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 tool with 22 parameters and no output schema, the description covers the most important contextual ground: core calculation flow, consumer interpretation of input declarations, parallel scenarios, and decisive limitations. Some fine return-structure detail is left implicit, but given the very complete schema cascades of this, the remaining gap is small.

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 schema already covers 100% of parameter descriptions, giving it the baseline score of 3 without needing detailed parameter repetition in the tool description. The tool description does set a high-level declaration-led framing for borrower type and future price inputs, but that level of detail is already reflected clearly in the input schema itself.

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 the exact purpose: 'does this presale close using my own funds?' and gives the deterministically evaluated values: required funds at each payment stage, the necessary final loan amount, whether it fits regulatory caps (LTV/value-band/DSR), and the shortfall. It also clearly names the question type this handles ('이 분양 당첨되면 진행 가능해?') and distinguishes itself from sibling tools by listing what it does not cover.

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 exclusion criteria and alternates: savings planning, refinancing strategy, market-price comparison, and policy rule lookup are called out as outside the tool, with `realty_presale_vs_market` and `realty_policy_rules` named. It also states that the server does not judge borrower type/income and does not estimate future prices or jeonse, so an agent knows exactly when to rely on declarations.

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 the tool read-only and idempotent, and the description adds meaningful behavioral context: the metric is 공급면적(분양평) means the max price per pyeong, excludes balcony expansion and optional add-ons, and uses a median that can be unstable when the housing-type mix varies across years. This is exactly the kind of operational nuance that annotations cannot 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?

The description is longer than minimal but efficient for its purpose: it packs a definition, measurement criteria, a caveat, parameter advice, and sibling-tool routing. A small amount of the message is contextually motivational — e.g., '재당첨 제한... 판단을 가른다' — but it does not prevent an agent from quickly extracting the operational guidance.

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 has no output schema, so the description carries the burden of explaining what comes back; it does so by stating the result is a per-year per-pyeong presale price trend based on announcements in the same region. It also explains what the answer should be based on, how to handle unstable years, how to fix the size band, and which sibling tool should be used when the risk is not presale-presale time series. Nothing functionally necessary 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?

All five parameters have solid schema descriptions, so the baseline is 3. The description adds value beyond the schema by explicitly tying exclusive_m2_min/max to the 80–85 ㎡ national standard range and to the median-stability caveat. It also reinforces the keyword-based zone/area trend use case, which elevates the parameter guidance slightly above baseline.

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: 'same-region presale announcements' annual per-pyeong price trend'. It also separates this tool from adjacent tools by saying it handles presale-to-presale time series, while individual announcement fairness is covered by realty_presale_vs_market.

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 routing: use this tool for presale price time series, realty_presale_vs_market for individual presale vs realized price, and realty_region_price_stats for resale price trends. It adds when-not-to-use guidance: years with only 1–2 announcements should not be read as trends, and exclusive_m2_min/max should be used to hold unit mix constant.

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?

With readOnlyHint, idempotentHint, and destructiveHint already providing the safety profile, the description adds substantial behavioral detail: it warns that the regional average includes all complexes and does not reflect new-build premiums, that market_avg is an unfiltered outlier average, and that comparable_complexes should be prioritized. It also discloses the candidate-list behavior when house_manage_no is absent and advises not to guess. No contradiction with annotations exists.

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 every paragraph earns its place: purpose, disambiguation, limitations, baseline priority, and alternative tools are all clearly separated. It is not the shortest possible, but the length is justified by the number of decision-relevant caveats. It is front-loaded with the core purpose before diving into edge cases.

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 read-only analysis tool with no output schema, the description covers the key behavioral contexts an agent needs: how to identify the correct announcement, what the comparison baseline means, how to use the returned fields, when to prefer comparable_complexes, and which sibling tool handles related but different questions. The only minor omission is explicit mention of the months parameter, but that is already well documented in the schema and the tool cannot be safely invoked without this guidance.

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?

Although schema coverage is 100%, the description goes beyond schema definitions: it explains the house_manage_no-or-(region+keyword) resolution logic, the automatic pyeong selection of the top 5 by number of households, and how to use the pyeong parameter to retry pyeong types listed in comparison_truncated. These operational details materially improve correct invocation and recovery paths.

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 opens with a specific verb and resource: '청약(분양) 공고의 분양가가 주변 실거래 시세 대비 싼지/비싼지를 주택형별로 계산한다.' It clearly distinguishes this tool from siblings by naming realty_subscription_odds and realty_presale_price_trend as the tools for other question types. An agent can tell exactly what this tool computes and what it does not.

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 NOT to use this tool: 청약 경쟁률·당첨 가점 커트라인 belongs to realty_subscription_odds, and 분양가 시계열 belongs to realty_presale_price_trend. It also instructs to combine this with realty_subscription_odds for '넣을 만해?' questions and names realty_area_price_bands for cross-checking regional medians. This goes far beyond implied usage.

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 provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds valuable behavioral context: the score formula (age 70%, transaction activity 30%), the current version status/date (2026-07-30), the fact that the API was temporarily deprecated and resumed, and a mandatory customer disclosure instruction. It also mentions the output includes a disclaimer, which is a behavioral expectation.

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 informational. It front-loads the paid/screening purpose first, then the formula, then the caveat and the resumption history. The addition of DATA-060 is a useful internal note. It is appropriately sized for a paid tool with a special data status; a few details could arguably be moved to an external doc, but every line contributes value in this particular context.

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 description is strong given the tool's low complexity: only two optional parameters, an output schema is absent, and annotations carry the safety burden. It covers purpose, scope, input, output expectations, and usage instructions. The main remaining gap is that it does not define exactly what the 'response disclaimer' contains or what the output top-N list looks like, but the output schema is absent and the tool seems intentionally simple. Complete enough for an agent 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 schema coverage is 100%, and the description does not add any new parameter-level semantics. The description's score formula does not explain either 'limit' or 'district' beyond the schema. The baseline for full description coverage is 3. The description does contextualize the result ordering (상위 단지) which relates to how parameters shape the output, but that is indirect, so a 3 is fair.

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+resource: it queries the top ranked redevelopment candidate complexes based on a '재건축 후보 스크리닝' (reconstruction candidate screening) formula. It distinguishes itself from general searches and related realty tools by specifying the paid nature, the scoring model, and its intended screening-only purpose. Although sibling tools like realty_redevelopment exist, the description explicitly spells out that business feasibility is not reflected, making it distinguishable.

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 clearly states when to use this tool: when you need top candidate complexes based on building age and transaction activity. It also says what not to rely on it for (not an investment basis) and tells the agent to pass the disclaimer to the user, which is a user-handling guideline. It does not mention a sibling alternative by name, but the negative scope ('business feasibility not included') helps select among sibling tools. Missing explicit when-not-to-use vs realty_redevelopment, but the absence of business feasibility is a strong cue.

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 readOnly/openWorld/idempotent annotations, the description adds important behavioral constraints: Seoul-only coverage, source limitations, null fields that must not be invented, no stage filter support, and a paid service marker. It also instructs the agent to derive progression from the stage field rather than assume a filter parameter.

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 purposefully structured: main purpose first, followed by coverage limitations, null-field warnings, filter behavior, and sibling routing. Some repetition of the paid marker and the warning not to invent null data makes it slightly longer than strictly necessary, but the length is justified by the tool’s complexity and the risk of hallucinated data.

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?

Because there is no output schema, the description carries the burden of signaling result semantics. It names the core output fields, describes null behavior, and gives the stage field as the discriminator. It does not fully enumerate every response field or pagination detail, but it provides enough context for a 4-optional-parameter list tool.

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 schema already covers all 4 parameters at 100%, so the baseline is 3. The description adds value by warning that 진행 단계 filtering is not supported and must be determined from the stage output field, and by reinforcing the sigungu-based district example in the usage question.

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 clearly names the resource: a list of Seoul 정비사업 sites (재개발·재건축·가로주택) with the key fields 사업명·유형·진행 단계·위치. It also distinguishes itself from the sibling tools by stating that 유망도 점수 belongs to realty_reconstruction and 조합원 지위 승계 belongs to realty_member_transfer_check.

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 provides an explicit usage pattern: “○○구 재개발 어디까지 진행됐어?” It also states clear exclusions: non-Seoul areas cannot be answered with this tool, and redevelopment potential or membership succession questions should be routed to the named sibling tools.

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는 read-only·idempotent임만 알려 주지만, 설명은 '서버는 검증하지 않는다', '비례율은 관리처분인가 전 추정치라 준공까지 변동한다', '민감도 ±10%p에 대한 정보를 반드시 함께 전달하라'는 중요한 동작 특성을 추가로 공개한다. annotation이 담지 못하는 비모수적·무검증 계산 행동을 정확히 보강한다.

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?

수식, 사용 예시, 세 가지 경계·조건, 대체 도구 안내가 모두 4줄 안에 밀도 있게 담겼다. 불필요한 홍보성 문구나 중복 표현이 없고, 계산 목적이 맨 앞에 와서 핵심을 먼저 파악할 수 있다.

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?

출력 스키마가 없음에도 계산 결과가 무엇인지(권리가액·분담금) 및 함께 보고해야 할 sensitivity·disclosures가 정확히 명시되어 완결성이 높다. 입력 파라미터 조건, 주의사항, 대안 라우팅까지 포함하여 복잡한 재개발 분담금 도구가 에이전트를 오류 상태에 빠뜨릴 요소가 거의 없다.

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의 파라미터 설명이 100% 커버리지이므로 기본 3점 이상이다. 설명은 그 위에 파라미터 간 연산 관계, 즉 종전자산 감정평가액·비례율과 분담금의 산술 관계를 부여해 각 인자가 어떻게 쓰이는지 명확히 해준다. 다만 비례율이 null일 때 3종 시나리오 계산이 되는 분기는 schema 설명에만 있고 description에는 없지만 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?

첫 문장이 자원과 계산 결과를 구체적으로 명시한다: '권리가액과 추가 분담금(또는 환급금)을 계산', '권리가액 = 감정평가액 × 비례율, 분담금 = 조합원분양가 − 권리가액'. 실제 예시 문구('감정평가 3억에 98%면 얼마 더 내?')까지 있어 에이전트가 재개발 관련 형제 도구들과 헷갈릴 여지가 없다.

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?

'경계를 지켜라' 문단에서 입력값은 반드시 조합 자료의 선언값임을 강조하고, 산식이 법정 산식이 아니라 실무 추정치임을 경고하며, 정확성이 불확실하면 realty_policy_rules의 진실원을 따르고 분양자격이 불확실하면 topic=redevelopment_entitlement부터 보라는 전환 안내까지 제공한다. 사용 조건과 대안 경로가 모두 명시되어 있다.

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?

Discloses conditional outputs such as region_candidates, warning_pyeong_fallback, and top_transactions only when top_n is provided. It also explains server-side unit conversion, rejection behavior, and explicitly notes that the top_n list is not a record-high list but a window high-price list. No contradiction with readOnly, idempotent, openWorld, or non-destructive 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 excessively long and includes dated metadata such as '2026-08-08, 8/7 테스터 제안 수용', '2026-08-22 제보', and '2026-09-07 외부 신고 T-2026W34-352' that are not useful for tool selection. The rental pyeong fallback warning is repeated in the main text and in multiple parameter descriptions, adding 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?

Covers all relevant edge cases: region ambiguity and disambiguation, metric differences, pyeong/area unit conversion, top_n conditional behavior, and fallback warnings. Though there is no output schema, the description names the key conditional response fields and directs users to sibling tools when different granularity is needed.

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 descriptions already cover all 8 parameters in detail, and the description adds concrete usage context like Sejong dong-level narrowing, region candidates fallback, and rental monthly_trend structure. It does not receive a 5 because much of the semantic content is already present in the input schema, and some added prose repeats the pyeong/rental fallback warning.

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 clearly states the tool retrieves regional apartment transaction price/rental trends by month, using the verb '조회한다' and specifying the resource. It explicitly distinguishes itself from realty_area_price_bands (price level vs. trend) and realty_search_complexes (specific complex vs. region), making its role obvious.

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 extensive when-to-use guidance: use this tool for monthly trends/direction, use realty_area_price_bands for price levels, realty_search_complexes for specific complexes, realty_complex_rent_by_pyeong for unit-level rents, and realty_move_in_supply for move-in supply. Also covers region disambiguation and metric-specific behavior.

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?

readOnlyHint·idempotentHint 등 annotations이 이미 안전한 읽기 동작을 알려주는 가운데, 설명은 price의 거래량 가중·최소 5건·최신월 집계 중 가능성, growth의 60-85㎡ 고정 YoY, investment 원천 정지 상태, score_lineage 판본 차이까지 추가로 공개한다. 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?

용도와 질문 예시를 앞에 배치하고, 그 뒤에 metric 정의·제약·대안 도구를 줄바꿈과 볼드로 구조화했다. 길지만 반복되거나 군더더기 없는 문장으로 모든 문장이 정보를 전달한다.

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?

복잡한 5개 metric과 보류 상태, 형제 도구와의 관계, 응답 methodology 반영 지시까지 빠짐없이 담겨 있다. output_schema는 없지만 설명이 응답의 산식·단위·score_lineage를 안내하므로 에이전트가 도구를 호출하고 결과를 해석하는 데 필요한 맥락이 충분하다.

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?

input-schema가 100% 커버하지만 그 위에 metric별 산식·단위·보류 상태를 부여하고, region의 시도/시군구 동작도 설명한다. 특히 investment가 enum에는 있으나 실제로는 보류 중이라는 정보는 스키마만으로는 알 수 없는 중요한 의미 보강이다.

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?

첫 문장에서 '지역(시군구) 순위를 조회한다'라는 구체적 동작과 대상을 밝히고, '제일 비싼 동네 어디야?'류 질문 예시로 용도를 명확히 한다. 또한 realty_compare_regions, realty_location_scores 등 형제 도구와의 차이를 직접 언급해 다른 도구와 혼동될 여지가 없다.

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?

순위·탐색용 질문에 쓸 것을 명시하고, 'A vs B'처럼 비교 대상이 정해진 경우에는 realty_compare_regions를 쓰라고 대안을 제시한다. investment가 보류 중일 때 realty_rental_yield로 대체하라는 안내와 transit/school 점수를 realty_location_scores와 같은 축에 놓지 말라는 사용 조건도 포함되어 있다.

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/idempotent annotations, the description discloses key behaviors: only complexes transacting in both windows are included, results are compared as naive vs basket, the composition_effect is exposed, values are per-pyeong, cancellations and direct deals are excluded, and dong/floor composition changes are not corrected. It also explicitly warns about thin-basket unreliability. 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?

The core calculation is front-loaded in the first sentence. The 'why' section earns its place with a concrete worked example of the failure mode, and the limitations paragraph is essential for safe interpretation. There is no filler or redundant restating of schema fields.

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?

This is a complex analytical tool with no output schema, but the description still explains the output shape (naive, basket, composition_effect), the unit used (per-pyeong), what is excluded, and the key limitation to communicate to the user. For an analysis tool with one required parameter and well-documented optional parameters, this is complete.

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%, so the input schema already fully documents every parameter with ranges and caveats. The description adds useful conceptual context such as the basket concept and composition effect, but it does not need to repeat parameter-level syntax or semantics. This matches the high-coverage baseline of 3.

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 opens with a precise statement of what the tool does: it calculates regional price trends using only complexes with transactions in both comparison windows. It clearly distinguishes this from a naive average by introducing the basket/naive contrast and the `composition_effect`, which sets it apart from sibling region-stat 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?

The '왜 필요한가' section gives a clear when-to-use rationale: naive monthly averages are misleading when sample composition shifts, especially with thin samples. It also warns when the basket itself is unreliable. However, it does not explicitly name alternative sibling tools or give an explicit 'do not use when X' rule, so it stops short of a 5.

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 flag read-only, open-world, idempotent, and non-destructive behavior, but the description goes much further: it reveals that coverage may be only 11.2% or 0%, that unknown is not a negative answer, that structure should not be inferred from the year of construction, and that responses must include how_to_find_out. This is substantial value beyond the annotations and no contradiction is found.

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 front-loaded with the core purpose and uses bold headers and two clear 'layer' sections to structure a domain-heavy signal. It is long, but almost every passage carries a specific warning or facility distinction that is needed for this recalcitrant task. The main cost is density, not irrelevance.

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?

There is no output schema, but the description states the two expected response layers, coverage disclosure requirement, unknown handling, and how_to_find_out path, so the sentiment model knows what to expect and how to behave. It does not formally specify response field names or error cases, but for an open-world read-only tool this is sufficient.

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 documents all three parameters well, including enum values, null defaults, and the meaning of omitting the complex name. The description explains only the general behavior of the 'unknown' case and response structure, but it does not add new semantic information about individual parameters beyond what the schema provides. Since schema_description_coverage is 100%, baseline 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 clearly states the tool's job: it answers whether walls can be demolished and plumbing/bathrooms moved, using statute text and the original public-sale notice. It explicitly distinguishes itself from realty_policy_rules by noting the full norm text lives there, which helps an agent select the right sibling.

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 concrete example queries that map to this tool, explains that the normative layer works even without a complex name, and points to realty_policy_rules as the source of the full rule text. It is less clear about when not to use this tool in favor of adjacent realty_* tools, but the axis,building-name, and coverage logic supplies usable routing context.

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 readOnly, idempotent, non-destructive, so the description adds essential behavioral context: the default response is a single latest completed month, sorted by descending yield, not the full period or region, and includes a truncated field to inspect. It also tells the agent to use year_month for specific months. This prevents a serious misuse of the default.

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 efficient: first line states purpose and use case, second line provides the critical behavioral caveat and the relevant parameter workaround. Every sentence 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?

Given no output schema, the description gives sufficient operational context: what is returned, default slicing behavior, and how to request a specific month. It lacks a short enumeration of output fields or additional details about the truncated field, but the schema covers parameters and annotations cover safety.

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 100% of the four parameters, including defaults, value ranges, and examples. The description does not add much beyond what is already in the schema—it repeats year_month and the yield-descending sort. Baseline 3 is appropriate because the schema carries the parameter documentation load.

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?

Description states a specific verb and resource: '시군구별 월세 수익률·평균 매매가·평균 월세를 조회한다' and adds the use case '수익형 투자 스크리닝용'. The unique metric set (rental yield, average sale price, average rent) sets it apart from sibling realty tools even without naming them.

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 purpose context (investment screening) and a direct instruction for using year_month when wanting a specific month, plus clarifies that the default is truncated to one completed month. However, it does not specify when to choose this tool over the many sibling realty_* tools or when not to use 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?

Annotations already cover readOnly/openWorld/idempotent safety, and the description is consistent with them (조회/검색 semantics). Beyond that, it discloses real behavioral footguns with measured evidence: the backend does not filter out past-auction-date rows (48건 중 43건 지난 기일), `sort=date_asc` lets stale rows occupy 60.7% of the prefix, empty `items` with `has_more=true` does not mean 'no matches', and `min_bid_source` values (`court_schedule` vs `item_list`) carry measurably different staleness risk (25~43% 과대). It also warns not to merge the two ledgers or answer '그런 물건 없다' before trying the public-sale tools — matching the openWorldHint.

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 (roughly 800 words) but front-loaded with the purpose sentence and organized into bolded, scannable warning blocks (⚠️, **이 축의 자리**). Each block addresses a distinct high-cost failure mode — past-date pollution, stale min-bid values, cross-registry mixing, pagination semantics — with concrete statistics. It loses a point for modest redundancy with schema-level descriptions (만원 units and exclude_past guidance appear in both) and for being longer than strictly necessary, though the density justifies most of the length.

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 no output schema, the description carries the burden of explaining response semantics, and it names all critical return flags an agent must act on: `past_auction_note`, `past_auction_count`, `meta.past_prefix_skipped`, `requested_offset` vs `offset`, `has_more`/`next_offset`, `min_bid_source`, `min_bid_note`, and `min_bid_stale_risk_count`. It also routes the agent to `realty_get_auction_case` for full case data and to `realty_auction_history` for exact per-round prices. For a 10-optional-parameter search tool with serious data-quality traps, 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?

Schema description coverage is 100%, so the baseline is 3 and each param already carries units, ranges, and the 광주 ambiguity error. The description adds cross-parameter and intent-level meaning: min_bid_count connects to `min_bid_rate` (유찰이 많을수록 최저입찰가가 감정가 대비 낮아진다), and the '지금 살 수 있어?' rule tells the agent when to flip `exclude_past` to true. The price-unit fact (5억은 50000) duplicates the schema, so the value comes from the decision rules, not format repetition.

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 opening sentence states a specific verb plus resource and filter dimensions: '법원경매 물건을 지역·종류·감정가·유찰횟수로 필터링해 조회한다.' The body then explicitly separates it from siblings — `search` (natural-language query parsing), `realty_get_auction_case`/`fetch` (case details), and `realty_search_onbid` (public sales) — so an agent can distinguish it without opening other 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?

Gives explicit routing rules with conditions: one natural-language line → `search` first; individual case detail → `realty_get_auction_case`; public sales (공매) → `realty_search_onbid`/`realty_onbid_sale_rate`; '유찰 많이 돼 싸진 물건' discovery → `realty_auction_alerts`. It also gives parameter decision rules: '지금 살 수 있어?' → `exclude_past=true`, and `sort=date_asc` should be paired with `exclude_past=true`. Nothing is left to inference.

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 annotations (readOnly, idempotent, non-destructive), the description discloses important runtime behaviors: response size capping via meta.size_capped, null households excluding complexes from filters and reporting via meta.households_scope, and the fact that sort=year returns newest first. These are valuable transparency details not present in the schema.

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 critical information: alternatives, edge cases, meta fields, and historical context. It uses bullet points, bold, and warnings to structure the content, making it dense yet navigable. No filler or redundant text.

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?

Although no output schema is provided, the description adequately covers response contents: per-pyeong prices (pyeong_exclusive, pyeong_supply_est), households per row, complex_key for subsequent calls, and meta fields (households_scope, size_capped, total). It also explains which parameters are exclusionary and how errors are surfaced. The agent understands exactly what to expect and how to handle quirks.

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?

All 8 parameters are thoroughly documented with examples, defaults, and edge-case explanations. For instance, region clarifies legal dong support and past QA issues, min_households explains the meaning of null households, and sort warns about reverse ordering. Schema coverage is 100% and descriptions go well beyond basic type info.

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 clearly states the tool searches apartment complexes by name/region and returns per-pyeong prices, using specific verbs ('검색하고', '돌려준다'). It explicitly distinguishes itself from sibling tools like realty_region_price_stats and realty_area_price_bands, making its 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 description provides explicit when-to-use guidance: it is the default for specific complex questions, while region average tools are for area-level queries, and floor/premium questions are directed to realty_complex_pyeong_price. It also gives pagination and sorting warnings (sort=year is newest-first), leaving no room for misuse.

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?

With readOnly/idempotent/non-destructive annotations already covering safety, the description adds substantial behavioral context that an agent would otherwise get wrong: the row-is-not-a-property folding (rounds_total, rounds_remaining, next_round, last_round) with a quantified warning ('행 수를 물건 수로 인용하지 마라(71% 과대)'), that '비공개' minimum bids are null not 0 and excluded from aggregates, the 61.7% street-address masking for seized property, and the sido normalization with sido_source/sido_basis provenance fields. It also discloses what the ledger lacks (권리분석·감정평가서·공고 원문). 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?

The description is long, but every section is load-bearing and addresses a distinct failure mode: legal disambiguation, sibling routing, the rows-vs-properties trap, and three data-quirk warnings. It is front-loaded — the core function and the 'not court auction' disclaimer appear in the first two sentences — and uses bolded section markers ('이 축의 자리', '행이 물건이 아니다', ⚠️ warnings) for scannability. For an 11-parameter tool with a counterintuitive data model, this density is warranted, not padded.

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 no output schema present, the description carries the full burden of explaining return semantics, and it does: it names the key response fields (rounds_total, rounds_remaining, next_round, last_round, condition_rows, min_bid_undisclosed_rounds, not_court_auction, sido_source, sido_basis), quantifies the overcount risk, and states what is absent from the ledger. Given the tool's complexity — 11 optional params, a folded round-based data model, and heavy ambiguity with court auctions — nothing an agent needs to call it correctly or interpret results faithfully 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 description coverage is 100% and the schema itself is unusually rich (광주 ambiguity handling, sort enum semantics, partial sigungu matching, cltr_mng_no as the detail path, open_only's 25,669-vs-10,327 rationale, usage_name taxonomy). The description adds value beyond the schema by explaining the folding data model that underlies limit (counts properties, not rows) and cltr_mng_no (detail = all rounds), and by reinforcing that court case numbers like '2025타경' must not be passed. That incremental context justifies a step above the baseline 3, though the schema is doing most of the per-parameter heavy lifting.

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 sentence states a specific verb and resource: '한국자산관리공사 온비드 공매 물건을 지역·용도·재산구분·감정가로 조회한다', naming the exact platform (Onbid/KAMCO), the object (public auction properties), and the filter dimensions. It explicitly differentiates from siblings by declaring '법원경매가 아니다' and naming realty_search_auctions and realty_onbid_sale_rate as the alternatives, so an agent can route correctly without opening the schema.

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 '이 축의 자리' section explicitly scopes the sibling set ('공매 축은 도구가 둘뿐이다') and assigns each tool its job: property search and round schedules here, sale-rate percentage questions to realty_onbid_sale_rate. It gives an explicit exclusion ('법원경매를 물었다면 여기가 아니라 realty_search_auctions'), a disambiguation instruction for ambiguous requests ('사용자가 그냥 '경매'라고만 했으면 어느 쪽인지 되물어라'), and a warning not to import realty_policy_rules answers since public-auction rights rules differ. Exceptionally actionable routing 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가 이미 안전한 읽기 동작을 알려주지만, 설명은 그 이상으로 '날짜가 없으면 표를 고르지 않는다', '연도만 알면 서버가 연도 기준임을 응답에 명시한다', '판이 갈리는 해에는 등기 접수일을 되묻는다', '범위 내 포함이 곧 최우선변이 수령 판정은 아니다(not_a_conclusion)'는 실제 동작을 드러낸다. 날짜를 조작하지 타야 한다는 제보 사례까지 있어 오남용을 막는다.

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?

첫 문장에 목적과 비목적을 넣고 1~5번으로 나뉜 경계 목록과 실제 선례를 구조화해 복잡한 툴인에도 실용적으로 읽힌다. 다만 제보 일자와 장황한 경고 문구를 스키마와 본문에서 반복하는 부분이 있어 일부 낭비가 있다.

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?

금액표 선택이라는 핵심 경로, 날짜/연도 입력 방식, 결론 비판정, 정책 원천 도구 이름까지 잘 갖추어져 있다. 그러나 '2008-08-21 이전 날짜를 받으면 어떻게 처리되는가' 또는 'security_right_date와 security_right_year가 동시에 들어온 경우 우선순위' 같은 경계 조건이 명시되지 않았다.

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?

입력 스키마 100% cover에 상세 설명이 있어 기본값을 높애 잡을 수 있다. 본문은 security_right_date와 security_right_year의 상호 관계, deposit_10k는 단순 산수일 뿐이라는 해석 한계를 다시 강조한다. 그러나 핵심 파라미터 의미의 상당 부분은 이미 스키마 필드 설명에 있어 '새로 추가하는 설명'만 보면 5점보다는 4점이다.

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?

첫 문장에서 '금액표를 고르는 도구'라는 구체적 목적과 대상을 명시하고, '판정기가 아니다'라고 범위를 못박는다. 두 번째 문단은 '적용되는 표는 최선순위 담보물권을 취득한 날이 속한 시행령 판'이라고 기준을 밝혀 형제 도구들과의 구분을 분명하게 한다.

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?

realty_policy_rules(topic=auction_rights)를 규칙 전체와 갈림길의 진실 원천으로 지목해 상세 규정이 필요할 때의 라우팅을 제시한다. '판정기가 아니라'와 '상가는 별도 법률이 적용된다'는 비사용 조건도 명확하다. 다만 상가·비주택 등 대체 대상에서 어떤 도구를 대신 쓸지는 명시되지 않아 5점에는 조금 못 미친다.

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?

Very transparent about what the tool does not do: it does not compute winning probability, null cutoffs do not mean zero, regional benchmarks are other complexes' results not predictions, missing announcements return error rather than 'not published', and denominator estimation is explicitly forbidden under allocated_households_rank1_local. No contradiction with the read-only/idempotent 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 dense and somewhat long, with many dated warnings and examples. The bold section headers help navigation and most content earns its place, but the length risks diluting key instructions. Still well-structured and front-loaded with the main purpose.

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?

Covers the major operational edge cases: freshness verdicts, not-found vs lookup-failed errors, missing denominators, sample concentration warnings, score limits, and chaining to related tools. Given the tool's complexity and the absence of an output schema, the description is sufficiently complete for correct agent behavior.

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?

Every parameter already has schema-level descriptions, and the description adds concrete semantics, examples, and boundary behavior for my_score, budget_max_10k, breakdown, area_band, house_manage_no, since_years, and region/sigungu. It clarifies units, ranges, and what using or omitting each parameter leads to, far exceeding schema coverage.

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 the core function explicitly: it returns subscription competition ratios and actual winning score cutoffs, and distinguishes itself from related tools such as realty_subscription_score and realty_presale_vs_market. The title and first line together make the resource and verb 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?

Provides explicit when-to-use and when-not-to-use guidance: use realty_subscription_score first if the user does not know their score; use region-only calls for benchmarks; use breakdown='sigungu' vs quarter/year based on the question; and chain to realty_presale_vs_market for price adequacy. It also tells the agent to avoid answering at do-si level alone.

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 behavior beyond the annotations: the tool computes only on declarations, never judges legal/factual status, and returns traps that must be passed along. This is valuable, non-obvious behavior that the read-only/open-world annotations do not fully express.

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 tightly structured: purpose, scoring formula, then three numbered boundary rules. Each sentence earns its place, and the critical operational cautions are front-loaded.

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 5-parameter schema with 100% coverage and no output schema, the description supplies the essential missing context: declarations, legal boundary, trap handling, downstream use, and source of truth. An agent has enough information to call the tool correctly and interpret its role in the larger workflow.

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 adds the scoring decomposition (32 + 35 + 17) that is not present in the input schema, giving the agent a useful mental model of how the parameters combine. Since schema coverage is 100%, the description does not need to repeat ranges or field meanings.

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 precisely what the tool does: it calculates the 민영주택 일반공급 가점제 score (out of 84) by applying the points table to declared values. It clearly distinguishes the tool from downstream siblings like realty_subscription_odds and realty_policy_rules.

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 guidance: inputs are declared, the server does not adjudicate facts, traps must be relayed, the resulting score feeds realty_subscription_odds, and realty_policy_rules is the source of truth. This tells an agent both when to use the tool and how to route the result correctly.

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