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?

Beyond the readOnly/idempotent annotations, the description discloses the outlier filter (excluding contract cancellations and certain direct trades below 50% of the median), explaining why results differ from realty_region_price_stats. It also reveals by_dong behavior: only cells with 3+ samples are shown, and band labels use exclusive-area pyeong rather than the user's '분양평' intuition.

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 the structure is efficient: purpose first, then alternatives, then filters, then label conversion. The bolded key phrases and short line breaks make it scannable, though a few clauses are dense enough to require careful re-reading.

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 conveys the core behavior, band definitions, filtering rules, and parameter semantics. It does not explicitly describe the exact return shape (e.g., whether each band returns median values or ranges), but the title, sample thresholds, and '중앙값' references make the expected result reasonably inferable.

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 parameters at 100%, so the baseline is 3. The description adds real value on top: region may contain a legal dong and warns that using a whole gu hides old/new downtown differences, and by_dong's 'where is cheap in this district' use case is illustrated with a concrete price range example.

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 queries regional sale prices divided into four pyeong-size bands by exclusive area. It also distinguishes itself from siblings by positioning it as the default tool for comparing regional price levels and explicitly directing complex-specific questions to realty_search_complexes.

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?

Usage is clearly scoped: it is for questions like 'what price range is a given pyeong band in ○○구?', it is the default for level comparison, and it names alternatives — realty_region_price_stats for monthly trends and realty_search_complexes when a specific complex is known. It even says to prefer this tool when level estimates diverge.

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, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: results must be presented as candidates needing verification, not recommendations, and it warns that many failed bids can signal rights issues or property defects. This interpretive/presentation guidance is valuable 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 a few tight sentences, front-loaded with the core purpose, followed by narrowing guidance, interpretation caution, presentation rule, and sibling differentiation. Each sentence earns its place — no filler. It is slightly longer than strictly necessary, but every clause adds functional value for the agent.

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 filtered search tool, the combination is nearly complete: annotations cover safety (readOnly, openWorld, idempotent, non-destructive), the schema covers all parameters with ambiguity and mapping caveats, and the description covers purpose, usage routing, interpretation, and presentation. The return format is not described, but no output schema exists and the tool's output (a list of matching auction properties with discount details) is predictable from the name and purpose. Nothing critical is missing for 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 description coverage is 100% — all 7 parameters are documented in the schema with rich detail (ambiguity warnings for '광주' and '중구', usage_name mapping notes for '빌라', max_discount_pct extreme-discount caveat). The description adds no parameter-level semantics beyond schema, which is acceptable per the baseline-3 rule for high schema coverage. The description's sido/sigungu narrowing hint maps to existing schema docs rather than adding new param 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 opens with a specific verb and resource: '유찰이 쌓여 최저입찰가가 크게 떨어진 경매 물건을 골라낸다' (selects auction properties where failed bids accumulated and the minimum bid dropped significantly). It states the selection criterion (accumulated failed bids → big price drop) and explicitly names the sibling it is not — realty_search_auctions(min_fail_count) — so an agent can distinguish them without opening 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?

Usage guidance is explicit and actionable: narrow by sido/sigungu for '○○에서 유찰 많은 물건' queries, and the tool explicitly routes to the sibling — realty_search_auctions(min_fail_count) for condition filtering/list, this tool for big-discount candidate discovery (including extreme discount cuts). It also warns not to combine both because the same items appear in both, preventing duplicate-result confusion.

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 (readOnly, idempotent, non-destructive), but the description adds substantial behavioral context an agent could not infer: photos survive only in a snapshot since court sources delete them, fail_count can legitimately disagree with the schedule rows, tracking/price_events may be empty and empty ≠ no change, and current_min_bid_10k may be stale when min_bid_source='item_list'. This is exactly the value-beyond-annotations case.

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 and each paragraph addresses a real failure mode, but it is long and dense with parenthetical warnings and emoji emphasis that could be trimmed. It earns most of its length but is not tight; several caution clauses (kind_note, fail_count_note, min_bid_note) could be consolidated.

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?

No output schema exists, so the description must carry return-value semantics, and it does: it explains the meaning of 유찰 rows, null result rows, min_bid_10k absence with kind_note, note fields, and snapshot-emptiness caveats. It is near complete for a read-only lookup, missing only a compact restatement of the primary return shape or pagination 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?

Schema description coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it warns not to invent meaning for null result rows, explains that min_bid_source=item_list indicates staleness for the returned current_min_bid_10k, and clarifies what court_schedule rows represent. These are output-semantics not captured in parameter docs.

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 (경매 사건 하나의 유찰 이력·가격 변동·물건 사진 조회) and distinguishes itself from siblings like realty_get_auction_case and realty_search_auctions by naming the exact fields it owns (유찰 이력, min_bid_10k 저감, 사진 URL). An agent can tell it 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?

Gives an explicit trigger question class ("몇 번 유찰됐어? 얼마나 떨어진 거야? 사진 있어?") which tells the agent when to call this. However, it never names the alternative tool (e.g. realty_get_auction_case) or an exclusion case, so routing is clear only by field ownership, not by explicit contrast.

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, so the description does not need to restate safety. It adds rich non-obvious behaviors: unsupported period parameters are silently ignored, '빌라' is auto-mapped to '다세대' with disclosure, '면적 미상' means missing area labels rather than zero, and the sample_period field must be reported. 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 paragraph carries a distinct operational warning or instruction: formula, period handling, usage_name mapping, area_band bias, and denominator distinction. The bold headers ('평형을 섞지 마라', '이 축의 자리') front-load the highest-risk guidance, making the length justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately explains the key response fields (sample_period, by_fail_count, by_area_band) and their interpretation. It covers the main traps an agent would need: area-band bias with empirical evidence, known data-quality issues like '빌라', and the correct relationship to a sibling tool. Nothing essential is missing for 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 adds real value beyond the schema: bid_count_max is clarified as an upper bound with the trend that more failures lower the ratio, area_band is strongly recommended when the property size is known, and usage_name's '빌라' mapping behavior and pitfalls are explained.

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 the exact user question the tool answers — '이 지역 이 물건은 보통 감정가의 몇 %에 낙찰되나' — and defines the metric formula (낙찰가율 = 낙찰가 / 감정가 × 100). It clearly distinguishes itself from realty_compare_auction_vs_market by emphasizing the appraisal-based denominator, which prevents confusion with the market-comparison 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?

It explicitly states when to use the tool ('입찰가를 정할 때 쓰는 핵심 지표'), tells the agent to include sample_period in '요즘'-type answers, warns that period-narrowing parameters are unsupported, and directs 연립주택 queries to usage_name='연립주택'. It also names the alternative tool for market-price comparisons and instructs not to mix the two percentages.

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 the safe read-only/idempotent profile, but the description adds substantial behavioral context beyond them: the meta.disclosures warnings that 무순위 세대 is not final unsold inventory, that off-Cheongyak supply (지주택·자체분양·선착순) is excluded and deflates ratios in some regions, that this is not a financial-soundness verdict, joint-construction full attribution, and meta.match_rate. These are genuine caveats an agent needs to avoid misreporting.

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 and dense, but it is front-loaded (what it is, then trigger questions, then per-parameter behavior, then disclosure list) and every section carries actionable content. The disclosure block is verbose but not redundant against the schema or annotations.

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 9-parameter, multi-mode tool with no output schema, the description still tells the agent what comes back: company rows, site lists with specific columns, a national baseline attached per row, and meta.disclosures/match_rate. Nothing needed to invoke or interpret results 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: builder matches partially with alias absorption ('지에스건설'→GS건설), and combining builder+developer narrows to a single site. It also clarifies that in sites mode `since` is reinterpreted as the most recent round month, which goes beyond the schema's '하한' wording.

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 line names a specific verb+resource: presale performance broken down by 시공사/시행사, enumerating exactly which metrics (공고 수, 공급 세대, 무순위 세대·비율, 청약 1순위 배수, 미달 세대). The example-question list ('○○건설 분양 성적', 'GS건설 현장 무순위 많이 나왔나') anchors this as a builder/developer-level aggregation tool, distinguishing it from sibling per-complex tools like realty_presale or realty_presale_context.

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 routing rules are given: pass builder (or developer) to get that company's row plus its site list, pass nothing to get top-N supply companies, pass region to narrow to a province. view='sites' is also explicitly framed with its own intent ('무순위 청약에서도 신청이 모자란 단지'). No inference required to pick the right mode.

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 mark this as read-only, idempotent, and non-destructive, but the description adds substantial behavioral detail: it is slower (2-4 seconds), uses exact address/complex matching, filters to future dates by default, excludes properties outside the 50-150% appraisal band, and produces a specific signal set. It also discloses edge-case behavior — when area match fails, discount_vs_market_pct is null and signal is '판정보류', explicitly warning not to substitute with discount_vs_all_types_pct. The warning about 유찰 properties and the min_bid_source check further enhances transparency. 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 extremely well-structured, using bold markers, warnings, and sections. It front-loads the main purpose, then logically covers filters, edge cases, and usage guidance. Every sentence adds value — no fluff or repetition. The use of bullet-like breaks and emoji warnings makes it scannable despite length, earning the high 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?

For a tool with 7 parameters, no output schema, and significant complexity, this description is thorough. It explains behavior, defaults, exclusions, failure modes, performance, and how it relates to sibling tools. An agent has everything needed to call it correctly and interpret results without external documentation. The absence of an output schema is compensated by explicit description of the signal values and the discount fields.

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% and each parameter has a description, the tool description adds crucial context beyond the schema: for case_no it mandates court_name due to court-level duplication, for sido it explains the ambiguity rejection and how to disambiguate (e.g., '광주'), and for sigungu it clarifies the rejection if sido is omitted. It also explains the default for usage_name and the meaning of include_past. This goes well beyond the schema's basic field hints.

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: comparing the minimum bid of auction properties against the market transaction price of the same complex to produce a discount rate and surface yield. It also distinguishes itself from siblings by explicitly positioning it as the primary tool for 'is this property cheap?' and naming realty_auction_sale_rate as the alternative for bid pricing based on appraisal ratio.

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 provides explicit when-to-use guidance: it is the first choice for auction price judgment with automatic market join, and it lists alternatives for specific needs — realty_auction_sale_rate for bid pricing, realty_area_price_bands/region_price_stats for manual baseline. It also warns against mixing denominators and details default filtering (future dates only) and exclusion criteria (appraisal band, area match).

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?

Beyond the readOnly/idempotent annotations, the description reveals sorting order (계약일 내림차순), the 5-transaction basis for summary stats, outlier handling with outlier=true and *_ex_outliers fields, complex-name isolation via meta.complex_isolation, server-side unit conversion with refusal on mismatch, and the absence of asking-price data (호가 데이터가 없다). These are significant behavioral traits not visible in 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 and the description uses paragraph breaks and bolded warnings for scannability. It is lengthy and partially repeats unit-conversion details already present in the schema, and the historical bug-report parentheticals (0.58.0, 2026-08-22 제보) add context but push it beyond a minimal 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 10 parameters and no output schema, the description thoroughly explains return-value semantics: price_by_floor_band, summary_basis, outliers.method, meta.complex_isolation, presale_rights_trades, and quote_check. It also covers data limitations, failure modes, and the rental alternative, leaving an agent fully equipped to invoke and interpret the 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% with very detailed per-parameter descriptions, so the baseline is 3. The tool description adds cross-parameter rules: use the user's chosen unit, call without area when pyeong is unknown ('평형을 모르면 면적 없이 불러라'), and do not guess pyeong. This is meaningful synthesis beyond individual schema entries, though some unit warnings duplicate 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 opens with a specific verb and resource: '특정 단지·특정 평형의 최근 6개월 매매 실거래를 건별(계약일·층·가격)로 조회한다', clearly defining a transaction-level sales lookup. It also differentiates from siblings by naming realty_search_complexes for summary-only needs and realty_complex_rent_by_pyeong for rent.

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 routing is provided: '평형별 시세 요약만 필요하면 realty_search_complexes의 prices_by_area로 충분하다', '층별 시세 질문은 이 도구가 담당이다', and '전월세는 realty_complex_rent_by_pyeong을 쓴다'. The guidance covers both when-to-use and when-not-to-use with named 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 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 declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the [유료] paid cost, the data-validity disclosure that location.overall_score·scores are unverified (location.score_demotion), the provenance of location.facts as raw counts from the POI ledger, and the chaining contract that the response carries coordinates and complex_key. 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?

Three dense sentences, each earning its place: the core purpose, the critical location-data protocol, and the downstream chaining instruction. Purpose is front-loaded. Slightly long sentences keep it from a 5, but there is zero 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 must carry return semantics — and it does for the critical parts: what location.facts contains, why overall_scores are untrustworthy, and that coordinates + complex_key are returned for chaining. Missing is guidance on parameter selection (prefer complex_key vs name, and that realty_search_complexes can resolve a key), which would fully close the loop for a paid, 2-param 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% — both name and complex_key have Korean descriptions ('단지명 (예: 반포자이)', '정확한 단지 키'). The description reinforces that complex_key appears in the response for chaining, but it doesn't add parameter-level meaning such as which parameter takes precedence or how to discover a complex_key. Baseline 3 is appropriate since 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?

The description states a specific verb and resource: '단지 하나의 시세·전세·기본정보를 통합 조회한다' (integrated query of price, jeonse, and basic info for one complex). This clearly differentiates it from siblings like realty_complex_pyeong_price, realty_complex_rent_by_pyeong, and realty_location_scores, which each target a narrower slice.

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 workflow routing: the response's coordinates and complex_key should be fed into realty_poi_nearby and realty_predict_price for deeper analysis, and warns that location.overall_score/scores must not be used for ranking or comparison. However, it doesn't explicitly state when to prefer this tool over alternative single-complex tools, leaving some selection logic implicit.

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/idempotentHint/destructiveHint=false, but the description adds non-obvious behavior: meta.data_as_of is the true latest timestamp, warnings must be relayed verbatim, lagged figures must not be presented as current, annual series need a stated reference year, and households has a source-data defect that rejects same-named districts.

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?

Content is front-loaded (purpose, then usage questions, then behavioral caveats) and dense with useful detail, but there is mild redundancy between the opening sentence and '지역 인구통계를 조회한다'.

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 back (data_as_of, warning) and how to report it, and it covers metrics scope, time-window limits, and the geographic granularity restriction for age — enough 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 the schema already documents metric/months/region, but the description contributes param-relevant guidance the schema lacks: the households same-name city/district rejection and the population·migration workaround, plus the annual-vs-monthly window distinction.

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 line names a specific verb (조회한다 = retrieves) and a specific resource (지역 인구·가구·고령화·순유입 통계 = regional population/household/aging/net-inflow statistics), which cleanly separates it from price-oriented siblings like realty_region_price_stats or realty_macro_indicators.

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 enumerates the exact user questions this tool answers ('인구 줄고 있어?', '1인 가구 비율은?', '고령화 심해?', '순유입 되는 동네야?'), and gives an explicit alternative path: when households rejects same-named districts, fall back to population·migration.

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?

Annotations already declare a safe read-only, idempotent profile, and the description adds substantial context beyond them: inputs like home count/first-time/newlywed are self-declared (server does not fact-judge), the tool performs eligibility matching and routing only, and it deliberately does not compute limits. This is rich behavioral disclosure.

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?

Core purpose and the router framing are front-loaded, and the boundary list is well-structured. It is somewhat long with bolded repetition of the routing rationale, but nearly every sentence carries usable information.

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?

No output schema exists, yet the description points to the `topic` field in the response for evidence and uncertainty, and covers the declaration semantics and scope limits. Complete for a routing/eligibility 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?

Schema description coverage is 100%, so the schema already documents all eight parameters, including the purpose enum warning about '전세' vs '전세반환'. The description reinforces the purpose/region/home-count axes but adds little syntax or format detail beyond what the schema provides, so 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?

States a specific verb and resource (list/judge usable loan products per product) and frames the tool as a router that spares the caller from picking a rule topic. It explicitly distinguishes itself from realty_loan_limit, so an agent can tell them apart 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?

Names the alternative (realty_loan_limit for purchase-purpose bank loan limits) and the condition that routes to it, plus explicit when-not boundaries for jeonse/mid-payment (no limit calculation) and jeonse-return. 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 cover safety (readOnlyHint=true, idempotentHint=true, openWorldHint=true), so the description focuses on behavioral context it *can* add: the rate_type-dependent DSR split (기본값 '변동'이 최악 가정), the declaration-vs-fact boundary for borrower type (inputs_declared 에코), the 'not an approval' caveat, and the mandated transmission of uncertainties·disclaimer. This is rich beyond the annotations. It doesn't quantify rate limits or latency but for a read-only calculator that matters less.

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, followed by three numbered boundary constraints — the intended order is sound. However, the numbering restarts (① appears twice: '① 차주 유형은 선언' and then a second '① 규칙 원표·근거는…', plus a duplicated ③), which is a structural defect in an otherwise dense but information-efficient paragraph. Every sentence earns its place, but the numbering error hurts navigability.

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 15-parameter, no-output-schema, read-only calculator, the description covers purpose, scope limits, rate_type sensitivity, the by_rate_type comparison instruction, sibling routing, and disclaimer transmission. Missing: explicit pagination or return-shape hints are not needed (no output schema), but the description could state that inputs_declared is echoed (it does) and that it never makes loan-approval claims (it does). It is complete enough for an agent to call and interpret correctly; no output schema means the description carries the return-value burden lightly and handles it.

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 already 100%, so the schema documents every parameter fully. The description adds meaning marginally above baseline by explaining *why* default rate_type='변동' produces the smallest limit, why credit_loan_10k should not be hand-computed, and by referencing the by_rate_type comparison table rather than restating param names. Baseline for 100% coverage is 3; the extra modeling guidance on rate_type default and desired_loan_10k semantics lifts it.

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 (주담대 규제 상한: LTV 상한액, 가액구간 한도, 만기 상한, 스트레스 DSR 최대 대출액). It names the sibling it is *not* — realty_policy_rules (원표·근거), realty_presale_funding_plan (분양 시점별 자금 판정) — and anchors itself with an example query ('10억 집, 생애최초, 연소득 8천이면 얼마까지 나와?'). An agent can route correctly without opening any 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?

Explicit when-to-use ('~류 질문의 자리다'), explicit when-not (규칙 원표는 realty_policy_rules, 규제지역 지정은 regulated_area, 취득세는 acquisition_tax, 분양 자금은 realty_presale_funding_plan), and explicit boundaries (대출 승인·확약이 아니다). Alternative routing for the sibling realty_loan_eligibility would have been a bonus but the alternative mapping given is thorough.

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 discloses that scores are unverified and have no discrimination power (transit 90+ even for far-away complexes), null means unmeasured not 0, output structure (location_facts at front), and not found behavior (don't fabricate, use search). This is rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured, starting with the core purpose, then the output format, then critical score caveats, then input modes, then fallback. Every sentence adds value, and the use of bold and line breaks 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 fully explains the output fields, the meaning and caveats of scores, null handling, input modes, and the alternative tool for facility lists. It is complete for an agent to call this tool correctly and interpret results.

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 the schema covers all three parameters, the description adds crucial semantics: the combination of region with complex_name as search scope, the difference between complex_key/complex_name (complex row) vs region alone (aggregation + top 5), and the normalization of complex_key to single space for 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 clearly states the tool answers with raw location values (station distance, nearby schools, stop counts) and explicitly distinguishes it from score-based tools. It answers specific queries like '역세권이야?' and '학군 어때?', and names the sibling realty_poi_nearby for facility lists, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use and when-not-to-use guidance: use this tool for raw values and specific questions, use realty_poi_nearby for facility lists, and use realty_search_complexes to confirm existence for not found cases. It also warns against ranking by scores, giving clear boundaries.

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 already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description earns credit by disclosing a non-obvious runtime behavior: nationwide widening drops the oldest months to fit a budget and reports this via meta.truncated and meta.truncated_note, while region-scoped queries return the full window.

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 purpose and scope, then the truncation caveat — good ordering. Slightly repetitive: the truncation/budget behavior is stated in the prose and again inside the months parameter schema, so a bit of the text does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description tells the agent what comes back structurally — both the 미분양 series and 준공후 미분양(unsold_completed, regional total) in the same shape, plus the meta.truncated fields. For a 2-param read-only tool with full annotation coverage, 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 coverage is 100%, so baseline is 3, but the description adds rationale beyond the schema: why months defaults to 6 (minimum needed for direction judgment), the multiplicative blow-up of 18 시도 × months rows, and the region-scoping workaround. That is real added meaning over the parameter definitions.

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 set — 미분양 추이(unsold trend) and 시장심리지수(sentiment index) queried together — plus the downstream purpose (매수 타이밍 판단의 거시 신호). An agent can distinguish it from generic siblings like realty_macro_indicators or realty_supply_demand_balance because it names the exact two signal sources it bundles.

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 context for the default window (6 months is the minimum for 방향 판단) and a conditional rule: widen months when a longer trend is needed, but narrow to a region first because nationwide widening hits the result limit. It does not name an alternative sibling for nationwide long-window queries, which keeps it from 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavioral context beyond that: it admits the three construction-delay exceptions are unjudgeable due to missing 인가일·착공일 data, warns the 재개발 부칙 trap prevents a verdict without a declaration, and instructs the agent to relay exceptions·disclosures from the response. This is unusually candid about limits.

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-loads the core decision in the first sentence, then uses a numbered boundary list that each earn their place as routing rules. It is long, but the length is spent on genuine scope limits and alternatives rather than 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?

Despite no output schema, the description tells the agent what the response contains (exceptions, disclosures) and where the judgment stops, and it enumerates the fallback tools for the questions it refuses. For a read-only judgment tool with 6 params, this is complete enough to call 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%, so every parameter is already documented in the schema; baseline is 3. The description adds only marginal parameter meaning (that the judgment multiplies regulated_area × 사업 유형 × 단계 and that Seoul auto-combines stage), which is largely a restatement of the schema's own notes.

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 (조합원 지위양도 가능 여부를 도시정비법 39조 2항으로 결정론 판정한다) and anchors it to a concrete user question ('한남3구역 지금 사도 입주권 나와?'). It is trivially distinguishable from siblings like realty_redevelopment or realty_policy_rules because it says exactly what it decides and what it will not decide.

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 routing: 조문 원문·예외 목록 → realty_policy_rules(topic=redevelopment_rules), 지정 현황 → regulated_area, 분양자격 불확실 → redevelopment_entitlement, 사업장 목록·단계 → realty_redevelopment. It also states the when-not boundary (소규모정비사업은 별도 법제라 판정하지 않는다). 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 cover the safety profile, and the description adds substantial behavior beyond them: the default window points forward, results are a lower bound with a ~30-month notice lag, meta.window_direction self-labels the window, and the reading/interpretation fields must be honored in the conclusion. The 세종 실사고 example concretely shows the failure mode.

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 and the default-window trap, and dense with actionable detail rather than filler. It is long, but nearly every sentence prevents a specific misreading, so the length is justified rather than 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, the description proactively explains the return-shape fields that matter (meta.window_direction, reading/interpretation, coverage.region_recent_annual_rate) and how to phrase conclusions from them. Nothing an agent needs to call and interpret it 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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-tool contract context (region takes 시도 only here vs. 시군구/동 in realty_supply_pipeline) and reinforces the months/from_ym mutual exclusivity and the past-vs-future framing that trips agents up.

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: aggregating a region's scheduled move-in volume by year-month, and frames it against the sibling it is not (realty_supply_pipeline). An agent can distinguish it from realty_supply_pipeline and realty_supply_demand_balance without opening a 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?

Explicitly names the question types it answers ('○○ 입주장 리스크 있어?', '내년에 입주 물량 얼마나 쏟아져?'), states when to switch to realty_supply_pipeline (when coverage.region_recent_annual_rate is far below), and warns not to sum the two axes due to double counting.

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

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

Goes well beyond the readOnly/idempotent annotations: sale-only data with no 전월세 (must refuse rather than estimate), 도시형생활주택 absent from the type enum and unsplittable from source codes, 지분 rows excluded from stats and unsuitable for per-area pricing, and the critical failure mode that a wrong property_type still returns HTTP 200 with populated rows so errors are silent.

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 and reasonably organized, but the apartment-exclusion warning is repeated in the description, again in the region and property_type schema fields, and again in the title — some of that emphasis is redundant rather than load-bearing for an already long block.

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 defines the response shape (recent rows + stats with 표본 수·가격·상위 구성) and flags the urban_housing_notice and note fields. For a disambiguation-heavy, high-mis-invocation tool, nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description nonetheless adds real meaning — area basis differs by type (villa/officetel use 전용면적, house splits 대지/건물, land returns 계약면적·지목·용도지역), and share_type='지분' handling is documented nowhere in 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+resource+scope: 조회 of 매매 실거래가 for 빌라·오피스텔·단독주택·토지, and explicitly negates the sibling category ('아파트는 이 도구가 아니다'). An agent can distinguish it from realty_region_price_stats / realty_search_complexes without opening any 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?

Gives explicit routing rules: if the query mentions 아파트, stop and go to realty_region_price_stats (region/동 monthly trend), realty_search_complexes (단지/평형 시세), or realty_complex_pyeong_price (건별 내역). It also warns that legal-dong narrowing is not a reason to pick this tool, pre-empting the most likely mis-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 only cover the safety profile (readOnly/idempotent/openWorld), and the description adds a lot beyond them: a 64KiB result cap, the meta.truncated / meta.omitted_sections signal, the re-fetch path via section='분양가', the p (page number) citation convention with notice_version, and the unverified_source_text fallback with a required disclaimer. These are exactly the operational traits the 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?

Front-loaded with the value proposition and the field list, but the opening line ('입주자모집공고 원문에서 추출·검증한 팩트시트를 항목별로 준다') is then repeated almost verbatim in the bolded second paragraph, and the field list appears twice (once inline, once expanded). The truncation warning earns its space; the duplication does not.

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?

No output schema exists, so the description carries the return-shape burden and does: it tells the agent values come with page numbers, that an uncited answer set is possible (unverified_source_text), how truncation is surfaced, and how to recover omitted sections. Nothing an agent needs to interpret or re-request results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning on top: it shows that section='분양가' retrieves one section in full and that this is also the recovery path for sections dropped by truncation, and it explains why keyword matches without regard to spaces. It does not restate the schema, but it does extend it usefully.

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 (extract/verify a fact sheet from the original 입주자모집공고) and enumerates the exact fields it returns: 전매제한, 재당첨제한, 거주의무, 층별 분양가표, 특별공급 배정, 발코니 확장·유상옵션, 중도금 회차, 예비입주자 규칙. It also names the sibling it is not (realty_notice_text for full clause text), so an agent can separate it from the other presale tools without opening 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?

Explicitly defines the question types it owns ('이 값들을 묻는 질문이 이 도구의 자리다', 추정하거나 웹에서 찾을 필요 없이), routes detailed clause text to realty_notice_text, and gives two negative rules: do not fabricate values not present, and do not infer absence in the notice from absence in the fact sheet. That is when-to-use, when-not, and alternatives all in one.

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/openWorld, and the description layers substantial operational detail on top: table columns may be misaligned due to pdftotext (so don't assert), zero-hit responses degrade gracefully with per-word and partial-match pages, full-text responses cap at 6 pages, and meta.matching_pages always carries the full list. This is exactly the beyond-annotation context the dimension rewards.

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 action and its differentiator, and the bolded pages_only guidance is well placed. Slightly long, and the opening sentence is near-duplicated in the title ('읽어 준다' / '읽는다'), which is the only real waste.

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 carries the return burden itself and does so: response shape (max 6 pages, meta.matching_pages), pages_only output (page numbers + excerpts), and the zero-hit fallback payload. Nothing needed to call this 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?

Schema coverage is 100%, so the baseline is 3, but the description adds workflow meaning: query words are ANDed with worked examples ('가점제 추첨제', '신혼부부 소득'), match='any' widens, and pages_only is framed as a scan-then-narrow pattern. Some of this (the query/pages conflict, pages_only_ignored) is echoed in the schema, so it is reinforcement rather than pure addition.

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 ('입주자모집공고문 원문을 쪽 단위로 읽는다') and explicitly distinguishes itself from the sibling realty_notice_facts by naming the factsheet as the thing it supplements. An agent can tell this apart from realty_notice_facts 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?

Gives explicit when-to-use ('팩트시트에 없는 세부...는 이 도구로 원문을 직접 확인하라'), a recommended first call ('쪽을 모를 땐 pages_only=true로 먼저 훑어라'), a widening path ('match=any로 넓힐 수도 있다'), and the query-vs-pages exclusivity. 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 cover readOnly/idempotent safety, and the description layers on extensive behavioral disclosure: the 3-month sampling window, the 113,673/688,264 coverage and 3,824-bid subset, outcome_mix being 성립률 not 낙찰가율, the apslPrcCtrsScfbPrcRto source-value passthrough with 2,896/3,824 missing treated as unknown not zero, median-vs-mean distortion (386% outlier), region recovered from property-name prefix at 90.0% bid coverage, and silent drops from region filters. No annotation contradiction.

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 a distinct operational fact and the ⚠️-marked warnings make caveats scannable. Front-loading the 경매/공매 distinction up front is the right prioritization. Slightly dense, but the complexity of the data source justifies the length; the bold headers aid skimming.

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-optional-param statistical tool with no output schema, the description is exceptionally complete: it names response fields (region_basis, outcome_mix, ratio_missing, median_pct, p25_pct, p75_pct), discloses data provenance and coverage gaps, explains missing-data semantics, and documents the region-recovery methodology including its failure mode (silent drop). Nothing an agent needs to interpret results 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?

Schema coverage is 100% and the schema descriptions are already rich (the '광주' ambiguity and sigungu single-token limitation live in the schema). The main description adds the key semantic emphasis that property_type is the axis that must not be omitted (실측 31.6% vs 106.3% spread) and that usage_name vocabulary diverges from the property list. It reinforces rather than repeats the schema, which is the right division of labor.

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 (answers 공매 sale-rate and bid-failure statistics from actual bid-opening results) and immediately distinguishes itself from the same-named court-auction metric realty_auction_sale_rate. It also names realty_search_onbid as the sibling for individual properties, so an agent can route correctly without opening 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?

Explicitly says not to mix the two percentages (경매 vs 공매), tells the agent to confirm which one is being asked, and directs per-property queries to realty_search_onbid. It also instructs to read by property_type and to cite median_pct rather than the mean, with the p25/p75 spread. Exclusions and alternatives are spelled out.

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 as read-only and idempotent. The description adds useful behavioral context: it is a paid tool, returns results sorted by distance, depends on coordinates from realty_complex_report, and only supports coordinate search for subway, hospital, and school. It does not detail the full response structure, but it does say it returns a facility list with distances.

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 main behavior appears first, followed by source-coordinate context, use-case framing, and alternative routing. Every sentence serves a purpose, with no filler or unnecessary repetition beyond the paid marker.

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 compensates by explaining the return shape as a facility list with distances, noting the paid nature, providing coordinate provenance, and routing to alternatives. It is sufficient for an agent to select and invoke the tool correctly, though a precise response-structure note would make it fully 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%, and the schema itself already explains latitude source, poi_type allowed values, combination syntax, and radius bounds/defaults. The tool description does not add much parameter-level meaning beyond the schema, 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 a specific action: retrieve surrounding location factors such as subway, school, hospital, and mart around given coordinates, sorted by distance. It also distinguishes itself from siblings like realty_location_scores and realty_poi_stats by clarifying it returns a facility list, not aggregate scores or regional statistics.

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 guidance: use this tool when a facility list with distances is needed, and use the free realty_location_scores location_facts instead when only nearest-station distance or count-in-radius is required. It also points out that mart/pharmacy data belongs to realty_poi_stats, and that coordinates should come from realty_complex_report.

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 already declare readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds real behavioral context beyond that: the response carries uncertainties and a disclaimer, it refuses to fabricate (returns zero hits rather than guessing) when the axis is absent, and it warns that conditions matter (the '85㎡ 이하 1.1%' only holds under 6억, with a quantified 16.9억/84타입 error example).

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?

Scope and routing are front-loaded well, but the opening sentence is duplicated almost verbatim ("단지에 종속되지 않는 일반 규범…을 근거 조문과 함께 준다" twice), and the routing paragraph is very dense. The volume is partly justified by the breadth of topics, but the redundant lead-in is clear waste.

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 must convey what comes back, and it does: norms with citations and confirmation dates, tables carrying applicable_if/exceptions, plus uncertainties and disclaimer. It also maps the surrounding ecosystem (realty_presale, realty_notice_facts, realty_presale_cost) so the agent knows where adjacent data lives. Minor gap: no explicit note on return shape or topic-count/pagination 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?

Schema description coverage is 100% and the enum/section descriptions are extremely detailed, so the schema does the heavy lifting. The description adds conceptual framing (topic tables as truth source, applicable_if/exceptions fields) but no parameter syntax or usage detail beyond the schema, 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 names a specific resource and scope: general legal/regulatory norms (tax rate tables, regulated areas, loan rules, lease rules) that are NOT tied to a specific complex, delivered with citations and confirmation dates. It distinguishes itself from calculation siblings by naming them explicitly (realty_loan_limit, realty_subscription_score, realty_redevelopment_burden, realty_capital_gains_tax, realty_member_transfer_check) and positioning itself as their source of truth.

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 states the question shapes it belongs to ("취득세 얼마야?", "갱신권 썼는데 집주인이 팔면?") and explicitly routes calculations elsewhere by name and condition. It also sets a when-not boundary: it performs no judgment — the agent must ask the user clarifying questions using the table's applicable_if/exceptions rather than decide facts like one-home status.

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 already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: minimum sample threshold of 3 with a '표본 부족' verdict, n_known/n_unknown split for 중도금, coverage disparity across years (meta.coverage.by_year), and percentile-in-distribution output. This is rich behavioral context an agent could not infer.

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 comparison, then a clearly delimited '읽는 법' rules block and a positioning paragraph — easy to scan. Minor redundancy: the title and the first two sentences restate the same 'compare to same sigungu/pyeong notices' framing.

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?

No output schema exists and all six params are optional, yet the description explains return shape (five-axis values plus percentile, or distribution-only), edge-case verdicts, and interpretation caveats. Nothing needed to call or interpret 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?

Schema description coverage is 100%, so the schema already documents all six parameters including the keyword/house_manage_no tradeoff and the exclusive_m2 filter scope. The description reinforces semantics (region is background only, exclusive area basis) but adds little parameter-level detail the schema lacks; 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?

Names a specific verb (견준다/compare) and resource (분양 공고 vs 같은 시군구·평형 공고들), then enumerates the five exact axes compared. It explicitly positions itself against siblings (realty_notice_facts, realty_notice_text, realty_presale_vs_market, realty_presale_price_trend), so an agent can route without opening any 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?

States when to use it, what it returns with and without a notice specified, and several explicit 'do not' rules: don't fall back to 시도 background values when a cell has <3 samples, don't build year-spliced time series, use realty_presale_price_trend for yearly trend. Alternatives are named with the condition that selects them.

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/safe, but the description adds real behavioral context: the result is a deterministic fact-sheet computation, differing move-in assumptions can swing the total by ~1.24M KRW, and the computed assumptions (중과·감면 etc.) must be surfaced to the user. It stops short of describing the return shape, which matters since there is no output 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?

Front-loads the formula and the scope, then the boundary and cross-tool routing in a second block; every sentence carries information. It is dense and slightly long, with heavy inline emphasis and a stray trailing quote character, but there is little true 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?

For a 6-parameter, zero-required calculation tool with no output schema, the description gives enough to call it correctly: inputs implied, deterministic basis, assumption caveat, and sibling handoffs. The one gap is that the return shape (per-floor breakdown fields) is only sketched as '층별 총액' rather than described.

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 already 100%, so the baseline is 3, but the description adds domain meaning beyond the schema: it frames mid_rate_pct and movein_ym as assumptions with material impact on the total and flags that acquisition tax uses the standard rate while heavier rates live in assumptions. That is genuine added semantics, not schema 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?

States a specific verb (계산한다) plus the resource and scope (분양 한 건의 층별 총 소요자금) and spells out the formula components (분양가·발코니·중도금이자·취득세). It also names the sibling tools it is not (realty_complex_rent_by_pyeong, realty_presale_funding_plan, realty_policy_rules), so an agent can route 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?

Explicitly draws the boundary: this tool computes only what is deterministically derivable from the notice plus tax law, and it states what it deliberately does NOT compute (월 상환액, 매수 vs 전세 손익분기) along with the alternative tools that do. The 'when not to use' guidance is unusually concrete.

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, lowering the bar. The description adds meaningful behavioral context beyond that: deterministic verdict, assumptions/uncertainties carried in response, no future-rule extrapolation, parallel scenarios (scenario_at_expected_price, jeonse_scenario) only when declared, and honest failure when movein_ym absent.

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?

Scope and the core verdict are front-loaded, but the body is dense with five numbered boundary clauses and interleaved ASCII markers, which slightly obscures readability. Content largely earns its place, but it is thick for a tool an agent must parse quickly.

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 22-parameter, 3-required, no-output-schema tool, the description supplies the essential contracts: declaration semantics, assumption propagation, parallel scenario gates, failure mode when movein_ym is missing, and sibling routing. Missing only explicit response-shape hints, which is acceptable given no output schema is provided.

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 already carries a rich inline description (units, defaults, ranges, cross-references). The description adds the declaration-vs-judgment contract and cross-engine consistency with realty_loan_limit/realty_presale_cost, but little per-parameter syntax. 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?

States a specific deterministic verdict verb ('판정') with clear resource (시점별 계약금→중도금→잔금 필요액 × 잔금대출 규제 상한) and explicitly frames the question it answers ('이 분양 당첨되면 진행 가능해?'). It names sibling engines it shares logic with (realty_loan_limit) and boundaries with realty_presale_vs_market / realty_policy_rules, distinguishing it clearly.

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 scopes the question type it serves and lists four boundaries (①선언 vs 판정, ④전략·적정성은 이 도구 밖 → points to realty_presale_vs_market, realty_policy_rules). Strong context. No explicit negative 'when NOT to call' beyond the out-of-scope items, so not 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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds useful behavioral caveats: that median can be affected by housing-type mix, that years with 1-2 announcements shouldn't be read as a trend, and that the metric uses supply-area pyeong maximum price excluding balcony/options. However, it still doesn't disclose return format or pagination, and the caveats, while helpful, are somewhat scattered.

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 repetitive: the first two sentences say almost the same thing ('같은 지역 분양 공고들의 연도별 평당 분양가 추이를 낸다' twice). It front-loads the core purpose but then mixes usage rationale, metric definition, caveat, and sibling positioning without clear structure. It could be trimmed.

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 and full annotation coverage, the description needs to convey what the tool produces and when to use it. It covers the metric definition, caveats about data quality, and how it relates to sibling tools. The main gap is the lack of explicit usage conditions (when to choose this over alternatives), but overall it's fairly complete for a trend-extraction 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 schema already documents all five parameters. The description only adds a note that exclusive_m2_min/max should be used to fix unit size (e.g., 80-85 for national pyeong) and a warning that sigungu is corrupted for Sejong, which is valuable beyond the schema. But it doesn't explain the region or keyword parameters beyond what the schema already provides, so it's a marginal addition.

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 ('연도별 평당 분양가 추이' for same-region presale notices) and contrasts itself with siblings realty_presale_vs_market and realty_region_price_stats. It clearly carves out its niche as '시분가끼리의 시계열'. The '축' framing is slightly abstract but the core purpose is 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 indicates this axis answers the 'wait or not' question, especially under a re-application restriction. But it doesn't state explicit when-to-use or when-not-to-use conditions beyond mentioning siblings. It names the alternatives but doesn't provide clear selection criteria (e.g., 'use this when you want cross-announcement trends, not single-announcement fairness').

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 readOnly/idempotent annotations, it discloses important behaviors: how announcement lookup falls back to region+keyword when house_manage_no is missing, that multiple candidates are returned and must be disambiguated without guessing, and the exact baseline-selection logic including nearby_baseline vs region-average fallback and baseline_divergence warnings. It also clarifies output fields like gap_pct and gap_pct_region_avg.

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 sentence carries operational value, and it is well-structured into lookup, baseline, and sibling-routing sections. The core purpose is front-loaded in the first 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?

With no output schema, the description compensates by naming key fields (gap_pct, gap_basis, nearby_baseline, gap_pct_region_avg, baseline_divergence, comparison_truncated) and explaining ambiguous selection flows. It also covers recommendation behavior and sibling hand-offs, making it 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?

The input schema already provides 100% rich parameter descriptions, so the baseline is 3. The description adds extra value by explaining how house_manage_no relates to region+keyword, the candidate-list rerouting behavior, and the pyeong auto-selection context via comparison_truncated, so it earns a 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?

The description states a specific verb+resource: it calculates whether a subscription announcement's presale price is cheap/expensive relative to nearby actual transaction prices, by housing type. It clearly separates itself from siblings such as realty_presale_price_trend, realty_area_price_bands, and realty_subscription_odds.

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 user questions it answers ('이 청약 넣을 만해?', '분양가 적정해?') and gives alternatives: realty_subscription_odds for competition/score cutoffs, realty_area_price_bands for region-level cross-checking, and realty_presale_price_trend for time-series patterns. It also warns when not to use region-average numbers.

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?

Annotations already carry readOnly/idempotent/non-destructive, so the description focuses on the gaps those annotations can't express: coverage is Seoul-only, stage filtering is unsupported (agent must filter client-side on the stage field), and generation count/completion dates come back null and must not be invented. These are meaningfully non-obvious behaviors; return shape specifics are the only notable omission.

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-loads the paid-scope and subject, then layers coverage limits and sibling routing. Slightly dense with bracket tags and repetition of the '[유료]' marker across sentences, but every sentence carries routing or constraint 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?

For a read-only filtered-list tool with a fully covered schema and no output schema, the description covers scope, coverage ceiling, null-field guidance, filtering limitation, and sibling routing. It could say a word about pagination/return shape, but for this complexity it is substantively 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% and each parameter (limit, offset, sigungu, project_type) is already documented, including the enum label mapping for project_type. The description adds no syntax beyond the schema, so it sits at 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?

States a specific verb (조회한다/목록) plus resource (서울시 정비사업 사업장) and enumerates the project categories it covers. It explicitly distinguishes itself from two named siblings (realty_reconstruction, realty_member_transfer_check), so an agent can route 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?

Provides explicit when-to-use ('○○구 재개발 어디까지 진행됐어?'류 질문), when-not (타 시도는 이 도구로 답할 수 없다고 밝혀라), and names the alternative tools for adjacent needs. Boundaries are stated rather than implied.

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 the safety profile (readOnlyHint, idempotent, no destruction), and the description adds substantial context beyond them: all inputs are user-declared and unverified, the formula is a practical convention rather than statutory, and the proportion rate is an estimate that keeps changing until completion. These are meaningful behavioral caveats an agent would otherwise miss.

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 action, then the formula, then numbered boundaries, which is well structured. The opening two lines overlap somewhat (both restate the purpose), costing a little tightness, but the boundary list earns its space.

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 the response contains (sensitivity with ±10%p swing and disclosures), which is exactly the information needed to present results responsibly. For a 6-param, 2-required calculation tool 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 schema already documents every parameter, including the unit convention and the role of the three optional total_* fields. The description's formula relates the parameters to each other but adds no syntax or format detail beyond the schema; 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?

States a specific verb+resource (재개발·재건축 조합원의 권리가액과 추가 분담금 계산) and gives the exact formulas (권리가액 = 종전자산 감정평가액 × 비례율, 분담금 = 조합원분양가 − 권리가액). It also frames the concrete user question it answers, making it clearly distinct from realty_redevelopment 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?

Explicitly names when-not/where-else: for formula provenance and 변동 함정 go to realty_policy_rules(topic=redevelopment_rules), and if 분양자격 itself is uncertain, start with topic=redevelopment_entitlement. It also specifies the requirement to relay sensitivity and disclosures, an operational usage instruction rather than just 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 declare readOnly/idempotent/non-destructive, and the description adds substantial non-obvious behavior: outlier filtering gap ('이상치...필터되지 않아 평균이 눌리며'), ambiguous-region rejection with candidate list, rejection when ㎡ is passed to pyeong parameters, warning_pyeong_fallback semantics for rental, and the top_n boundary ('창 안의 고가 거래'이지 신고가가 아니다). 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 front-loaded with purpose and organized with bold headers, but it is bloated with provenance parentheticals ('2026-08-08, 8/7 테스터 제안 수용', '2026-09-07 외부 신고 T-2026W34-352') and meta-rationale (S364) that don't help an agent invoke the tool. Sections like the rental/pyeong warning also duplicate what is already in each parameter schema 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?

With no output schema, the description compensates well: it names monthly_trend fields, top_transactions fields, warning_pyeong_fallback, and rejection modes, covering the tool's trickiest behaviors. Minor gaps remain, such as the exact top-field snapshot structure and full error shapes, but an agent has enough context to call 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% with already-rich descriptions, so the baseline is 3. The description adds cross-parameter meaning beyond the schema: Sejong-specific need for dong-level narrowing, token-exact region matching ('동구'는 '남동구'가 아니다), server-side unit conversion, and the semantic distinction that top_n is not an all-time high. Some duplication exists, but the added context justifies a 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?

Opens with a specific verb + resource: '지역의 아파트 실거래 시세 추이(월별)를 조회한다', making the core function unmistakable. It also distinguishes itself from realty_area_price_bands and realty_search_complexes in the same opening section, so an agent can pick the right tool without deep schema inspection.

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 ('월별 흐름·방향이 필요할 때 이걸 쓴다') and when not to ('가격 수준을 인용할 거면 realty_area_price_bands를 쓰라', complex-specific questions → realty_search_complexes, pyeong-specific rental → realty_complex_rent_by_pyeong). It even suggests combining with realty_move_in_supply for reverse-jeonse judgments, which is 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?

Despite annotations already indicating readOnly, openWorld, and idempotent behavior, the description adds important behavioral details: growth uses 60-85㎡ fixed YoY to avoid distortion, price uses volume-weighted average with a minimum of 5 transactions, and current month may be incomplete. It explicitly states that investment, transit, and school are unavailable and why (source halted, score lacks discrimination). This goes beyond annotations and provides critical context for correct interpretation.

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 concise and front-loaded with the core purpose. It uses whitespace and bullet-like separators to break down metric explanations. While it contains quite a bit of text, every sentence serves a purpose: defining purpose, giving example queries, explaining metric formulas, and routing to alternatives. The only minor inefficiency is redundancy between the title and the first line, but it's not significant.

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 tool's complexity (multiple metrics, some unavailable, need for methodology awareness), the description is remarkably complete. It covers all metrics, explains why certain ones are unavailable, provides alternatives, and tells the agent to reflect methodology in responses. The output schema is absent, but the description hints at what the response will contain (rankings, methodology details). An agent can call and use this tool correctly with just this description.

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 documented, but the description adds crucial nuances beyond the schema. For metric, it explains what each value means and explicitly lists which are unavailable ('보류'), which the schema also mentions but in a more terse way. For region, it clarifies how the value filters (시도 vs 시군구 vs 전체). limit and order are left to schema, but those are straightforward. Overall, the description adds meaningful value 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 the tool's purpose: to look up 시군구 rankings by various axes such as price, growth rate, and jeonse-to-sale ratio. It provides concrete example queries ('제일 비싼 동네 어디야?', etc.) that an agent can match to user intent. It also differentiates from sibling tools by specifying what this tool is NOT for (comparison) and what to use instead.

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 (ranking/exploration queries) and when not to use it. It names alternatives for specific cases: realty_compare_regions for fixed comparisons, realty_location_scores for transit/school queries. It also warns about unavailable metrics and directs to realty_rental_yield for investment-related needs. This is exceptionally clear 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?

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 cover the safety profile (readOnly/idempotent/non-destructive), and the description goes well beyond them: it discloses real coverage numbers (2,294 of 2,851 with source text, 258 mentioning structure type, 0% for pre-2020 completed complexes), that coverage is emitted on every response, that missing values return 'unknown' which is not a negative, and that the agent should route to how_to_find_out rather than dead-end.

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, but the body is heavy: bolding, scare-quoted questions, repeated framing of the 'two false common beliefs', and coverage statistics restated across paragraphs. Much of the content earns its place, yet the same points are made more than once and the layout is denser than needed.

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 takes on that burden and does so thoroughly: it describes the two response layers (100% normative vs sparse complex-level), how coverage is reported per response, and the presence of a how_to_find_out field for the unknown case. An agent has everything needed to interpret results.

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 enum for axis is already documented in the schema, so the schema carries the parameter burden. The description reinforces that complex_name is optional and what happens when it is omitted, but adds no syntax or format detail beyond what the schema already states. 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?

States a specific decision it enables (whether an apartment's walls and plumbing can be altered) split into two explicit axes, ①load-bearing wall removal ②plumbing/stack relocation. It names the sibling that holds the full statutory text (realty_policy_rules(topic='unit_alteration_rules')), so an agent can tell the two apart 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?

Gives concrete trigger questions ("can I move the bathroom?", "do I need a district office permit?") and spells out the conditional behavior: leave complex_name empty to get the normative layer alone, supply it for complex-level notice citations. It routes to a named alternative for the full statute text, though it never states a clear when-not-to-use condition.

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 behavior, and the description adds important non-obvious behavior: results are truncated to one month and sorted descending, with a truncated field to inspect. This genuinely helps the agent avoid misinterpreting partial 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?

Two short paragraphs: the first states purpose and audience, the second states the critical caveat about truncation and how to override it. Every sentence earns its place and the key warning is 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?

For a read-only query tool with no required parameters and a well-annotated schema, the description covers purpose, default behavior, and the main parameter to adjust. It could clarify whether a null region returns nationwide data, but the truncation warning covers the most important 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?

Schema coverage is 100% and parameter descriptions already explain limit, region, year_month, and pyeong_supply, including default behaviors and conversion logic. The description reinforces the sorted/truncated default but adds little 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?

Description states a specific verb ('조회한다') and resource ('시군구별 월세 수익률·평균 매매가·평균 월세'), making the tool's function clear. It does not explicitly differentiate from the many realty siblings, so it falls 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?

Gives practical usage context: default returns only the latest completed month sorted by yield, not the full period or region, and directs the user to use year_month for a specific month. It does not name alternatives or exclusions, but the guidance is actionable.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior, and the description layers on substantial caveats: past-auction rows are mixed in, sort=date_asc puts stale rows first, empty items with has_more=true does not mean no matches, and min_bid_source can be stale. It also warns against mixing court-auction and public-auction ledgers, adding behavior beyond what annotations 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 text is long but organized with bold axes, warning blocks, and bullet lists; each section prevents a concrete mistake such as pagination errors, stale-date misinterpretation, unit errors, or unreliable minimum-bid sources. The core filtering statement is front-loaded before the caveats.

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?

Since there is no output schema, the description carries the return-shape burden and covers has_more, next_offset, requested_offset, past_auction_count, min_bid_stale_risk_count, past_auction_note, and meta.past_prefix_skipped. It also tells the agent to call realty_get_auction_case for full case details, so 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?

Despite 100% schema coverage, the description significantly enriches parameter meaning: price units are in 10k won with the example 5억=50000, usage_name supports partial matching and rejects '토지', sido and sigungu ambiguity handling is explained, and pagination via offset/has_more/next_offset is documented. This goes well beyond the schema 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 opens with a specific verb and resource: filters court-auction properties by region, type, appraised price, and bid-failure count. It explicitly separates this tool from search, realty_get_auction_case, fetch, and realty_search_onbid, so an agent can distinguish it 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?

Provides explicit routing: use search first for a natural-language query, use realty_get_auction_case or fetch for details, use realty_search_onbid and realty_onbid_sale_rate for public auctions, and use realty_auction_alerts for bargain discovery. It also instructs when to set exclude_past=true and warns against combining auction ledgers.

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 read-only/idempotent profile, and the description adds non-obvious behavior that annotations cannot express: sort='unit_price' is rebuilt only from returned rows and cannot be paged, area/year bands affect price computation but not filtering, households=null means 'not in ledger' not 'small', and scores.composite changed meaning in 0.84.0 with composite_legacy as the comparable value. This materially changes how a model should interpret 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 front-loaded with purpose and uses bold section labels, but it is very long and repeats key cautions (e.g., '검색을 거르지 않는다' appears for both bands). The density is justified by the tool's complexity, but it is not 'appropriately sized' in the sense of a crisp definition.

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 10 parameters, no output schema, and many sibling tools, the description covers response fields, pagination caps, null semantics, sort order caveats, version changes, and even the external report ID for the households feature. An agent has enough context to invoke the tool correctly and interpret the response 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 coverage is 100%, so the baseline is 3, but the prose adds deep meaning for sort, area_band_m2, construction_year_band, and min/max_households beyond the schema. One flaw: it asserts 'query·region 중 하나는 필수' while the schema declares zero required parameters, which could mislead an agent about call validation.

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 combination: '아파트 단지를 이름·지역으로 검색하고 평형별 실거래 시세를 함께 돌려준다.' It then positions the tool as the '1차 도구' for complex questions, which distinguishes it from regional-average siblings before any schema inspection.

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 names realty_region_price_stats and realty_area_price_bands as the wrong tools for complex-level questions and the right tools for region-level trends. It also routes floor-band questions to realty_complex_pyeong_price and 'oldest first' queries to realty_reconstruction/realty_redevelopment, leaving no ambiguity about 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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, and the description builds on this without contradicting it. It discloses deep behavioral traits: rows are auction rounds not properties (with measured 3.51 rows/property and 71% overcounting risk), min_bid returns null (not 0) when '비공개', seized-property addresses are masked at the street-number level, and sido values are re-standardized with sido_source/sido_basis provenance fields. No annotation contradiction.

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 bolded section carries operationally distinct knowledge that prevents a real error, and the most critical fact (not court auction + sibling routing) is front-loaded. The emoji-warning headers aid scanning. It could be tightened slightly, but given 11 parameters and a non-obvious row-vs-property data model, the density is largely earned.

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 an 11-parameter tool with no output schema, the description is unusually complete: it documents the response envelope (rounds_total, rounds_remaining, next_round, last_round, condition_rows, min_bid_undisclosed_rounds, not_court_auction), all parameter caveats, data-quality pitfalls, and what is absent from the ledger (권리분석·감정평가서·공고 원문). Nothing an agent needs to call it 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?

Schema coverage is 100%, giving a baseline of 3, but the description adds substantial meaning beyond the schema: '광주' ambiguity returning error='sido_ambiguous', sigungu partial-match and region_ambiguous rejection requiring sido, usage_name's 3-level hierarchy ('아파트' is a subclass so it won't match mid-class '주거용건물'), open_only's default-true rationale (25,669 vs 10,327 active properties), and property_type being flagged as the most important axis with distinct legal natures. The description also corrects semantics: limit is property count, cltr_mng_no is the detail view that returns per-round schedules.

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 precise verb+resource+scope: '한국자산관리공사 온비드 공매 물건을 지역·용도·재산구분·감정가로 조회한다' and immediately draws the boundary against court auction (법원경매가 아니다). It names the exact legal basis (국세징수법·국유재산법·공유재산법) and the operator (캠코), and distinguishes itself from realty_search_auctions and realty_onbid_sale_rate. An agent cannot confuse this with any 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?

Exceptional routing guidance: explicitly names realty_onbid_sale_rate for sale-rate questions, realty_search_auctions for court auction, says to ask the user when they only say '경매', and warns never to merge/average the two. Also warns not to transplant realty_policy_rules answers because the rights-acquisition rules differ. This is explicit when-to-use, when-not-to-use, and 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가 이미 안전한 읽기 동작을 알려주지만, 설명은 그 이상으로 '날짜가 없으면 표를 고르지 않는다', '연도만 알면 서버가 연도 기준임을 응답에 명시한다', '판이 갈리는 해에는 등기 접수일을 되묻는다', '범위 내 포함이 곧 최우선변이 수령 판정은 아니다(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?

Even though annotations already mark this as read-only/idempotent, the description discloses important runtime behavior: empty arrays can mean either not_yet_published or not_yet_collected, disambiguated by freshness_verdict.verdict; not-found and lookup-failed produce error responses with distinct error/result values; estimate_superseded is attached when estimates conflict with actuals; and null cutoffs mean no winners/no point system, not zero points. It also explicitly states the tool does not calculate win probability, preventing a common LLM hallucination.

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 text is long, but it is front-loaded with the core purpose and organized into bolded warning blocks, numbered pathways, and a 'don't fabricate' section, so an agent can locate the relevant guidance quickly. It earns most of its length given the tool's complexity and missing output schema, though a few dated changelog asides could be trimmed for tightness.

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 full burden of explaining response semantics, and it does: freshness_verdict verdict values, result_status_legend as canon, error/result keys on rejection, allocated_households_rank1_local as denominator source, sample-concentration warnings, and estimate_superseded behavior. The two operational paths and their data caveats are fully covered, so an agent has what it needs to interpret results 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%, so the baseline is 3, but the description adds substantial parameter-level guidance beyond the schema: my_score should come from realty_subscription_score if unknown, breakdown must be sigungu/quarter/year depending on question type, omitting budget_max_10k when a budget was stated can mix in unaffordable complexes, and house_manage_no absent from both ledgers must produce a not_found rejection rather than 'not published'. This transforms raw parameter names into decision rules.

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 computes 청약 경쟁률 and 실제 당첨 가점 커트라인, and frames them as the quantitative basis for 'will my 52-point score win?'. It also names the sibling realty_subscription_score for users who need to compute their score first, so an agent can distinguish this tool from related subscription 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 explicit routing conditions: if the user doesn't know their score, use realty_subscription_score and pass my_score; if only a regional benchmark is needed, call without house_manage_no using region/sigungu; and for price reasonableness, continue to realty_presale_vs_market. It also explains when the tool falls back from published results to regional benchmarks, and warns against treating missing data as 'not published', which is exactly when/not-to-use guidance.

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