korea-realty

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds real behavioral context beyond that: the return is document-form text rather than structured data, and a court-name-less lookup degrades to a candidate list. Only the exact return content remains thinly described.

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 and id contract are front-loaded in the first three lines and the routing rule is clearly separated. The '이 축의 자리' framing adds some meta-verbosity that slightly dilutes an otherwise tight 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 no output schema, the description carries the return burden and does so adequately by declaring document-form text output and the candidate-list fallback. Combined with the rights-citation constraint, an agent has enough to call and interpret it correctly, though the exact response shape stays vague.

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 documents the pipe-delimited format, court-name prefix, and case-number shape. The description largely restates this, adding only the firm constraint to pass the id through unchanged and the candidate-list consequence — 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 ('search가 돌려준 id로 경매 사건의 전체 내용을 가져온다') and explicitly positions itself against the two closest siblings, realty_get_auction_case and realty_auction_history, by input/response form. An agent can distinguish it 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: use realty_get_auction_case when the user speaks the case number or structured fields are needed, and realty_auction_history for foreclosure history/discount schedules. It also states a bound on use — do not fabricate rights relationships if rights is absent.

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, yet the description adds substantive behavioral context: the outlier filter (excludes contract cancellations and direct trades below 50% of the band's brokered median), which explains why its values differ from region_price_stats' unfiltered average. It does not describe the output/pagination shape, keeping it from a 5.

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 purpose in the first sentence and each following block (question routing, tool positioning, filter methodology, alternative routing, band-label semantics) earns its place. It is dense and somewhat long, which slightly hurts scannability, but there is no filler.

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

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

No output schema exists, so the description must carry return semantics; it explains the 4 bands, the exclusive-pyeong vs presale-pyeong mapping, the outlier filter, and the footnotes switch. This covers what an agent needs to call and interpret the tool, though exact response field names are left implicit.

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 region, by_dong, period_months and include_footnotes (including the min-3-sample rule and a worked example). The description mostly adds band-label and pyeong-conversion semantics, which are output concepts rather than parameter guidance, so baseline 3 is correct.

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 (regional sale prices in 4 exclusive-area bands) and explicitly separates itself from siblings, naming realty_search_complexes for specific complexes and realty_region_price_stats for trends. An agent can distinguish this tool from the other two price 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?

Gives explicit routing: use this by default for regional price *level* comparison, use region_price_stats for monthly trends, and search_complexes when a specific complex is identified. It even states the tie-break rule ('수준이 갈리면 이쪽을 우선하라') for when this and region_price_stats 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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuine context beyond that: many failed bids signal rights/hazard problems, and results should be framed as candidates needing verification, not recommendations. It does not cover auth needs, rate limits, or result ordering.

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 first two sentences are near-duplicates ('유찰이 쌓여 최저입찰가가 크게 떨어진 경매 물건을 골라낸다' vs '유찰이 누적돼 최저입찰가가 크게 떨어진 물건을 찾는다'), which is redundant. The useful routing and caveat content is front-loaded but preceded by that repetition.

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 7-parameter, no-output-schema tool, the description covers purpose, caveats, regional narrowing, and the key sibling distinction. It is largely complete; only return-format nuances (which the schema does not provide) are absent.

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 schema carries the heavy parameter detail. The description still adds useful guidance by tying sido/sigungu to the region-narrowing use case, slightly above the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it selects auction properties whose minimum bid price has dropped sharply due to accumulated failed bids. It explicitly names the sibling realty_search_auctions and the axis distinguishing them, so an agent can separate 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?

Gives explicit when-to-use guidance ('조건 필터·목록이 목적이면 그쪽, 저감 큰 후보 발굴이면 이쪽') plus a concrete warning not to combine the two because items overlap. It also instructs how to narrow ('○○에서 유찰 많은 물건' → sido/sigungu).

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 read-only/idempotent annotations: it warns that photos exist only as collection-time preserved copies because court originals are destroyed after the hearing date, that null result rows are future hearings or undecoded court codes, that kind_note marks non-bid rows, that fail_count_note explains count mismatches, and that min_bid_source=item_list may be stale. These are exactly the non-obvious traits an agent needs.

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

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

Purpose is front-loaded in the first sentence, and the dense remainder is operational caveats rather than filler. It is long and crowded with bolded warnings, which makes it harder to scan, but almost every clause carries actionable meaning.

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 full burden of return-value semantics — and it does, defining what fail_count, min_bid_10k, kind_note, fail_count_note, min_bid_source, and the tracking/price_events emptiness each mean and how they should be relayed. An agent would not misstate results after reading this.

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 two parameters (case_no format rules, court_name uniqueness) are already fully documented in the schema. The description adds no independent parameter guidance, 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 opening sentence gives a specific verb and resource set — retrieves a single auction case's failed-bid history, price-change timeline, and property photo URLs. The question-type framing ("몇 번 유찰됐어? 얼마나 떨어진 거야? 사진 있어?") pins down the intent precisely. It does not explicitly distinguish itself from the closest sibling realty_get_auction_case, so it stops short of a 5.

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

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

Clearly states the situations this tool owns (failed-bid counts, price-drop history, photos) and explains what to do when sub-sources are empty (tracking/price_events may be blank; court_schedule is authoritative). It gives no explicit when-not or named alternative such as realty_get_auction_case or realty_search_auctions, so it is context-rich but not routing-complete.

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/non-destructive); the description adds non-obvious behavior the agent could not infer: period-narrowing parameters are silently ignored by the backend (so none are exposed), '빌라' is silently remapped to '다세대' with the mapping disclosed in the response, and the '면적 미상' band is missing data rather than zero. These are exactly the quirks that prevent wrong 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?

Core definition and formula are front-loaded, then exclusions, then caveats — a logical funnel with bold anchors for scanning. It runs long, and the 2026-10-17 measurement figures are illustrative evidence rather than instruction, but nearly every line carries actionable content.

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 contract itself: sample_period (매각기일 min~max) for recency framing, by_fail_count distribution, by_area_band, and the include_footnotes toggle. Combined with the denominator warning against sibling tools, an agent has everything needed to call it and to interpret the numbers 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 rationale the schema lacks — why area_band should '반드시' be used (78.8% national vs 75.7%/81.4% by band, 서울 82.4% vs 98.1%), why bid_count_max should match the subject's fail count, and why no period parameter exists. It does not, however, restate or extend sido/sigungu disambiguation beyond what their schema entries already say.

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 states a specific verb and resource ('이 지역 이 물건은 보통 감정가의 몇 %에 낙찰되나'를 실제 매각결과로 답한다) and pins the metric with an explicit formula (낙찰가/감정가×100). It actively distinguishes itself from siblings with the same domain — realty_policy_rules, realty_auction_history, realty_compare_auction_vs_market — 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?

Explicit when-not guidance is given ('감정가 12억에 최저가 7.68억이면 몇 번 유찰됐나'는 이 도구가 아니다) with the correct alternative named and even sub-arguments (realty_policy_rules topic='auction_rights', section='minimum_price_reduction'). The '경매 가격판단 3종 중' paragraph also states when to prefer realty_compare_auction_vs_market, including the reason (different denominator).

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 covered. The description layers on genuinely useful out-of-band caveats (무순위 ≠ 최종 미분양, 청약홈 밖 공급 미포함, co-construction full attribution, meta.match_rate, not a financial-soundness ruling). However, much of this is result-interpretation guidance rather than invocation behavior, and it discloses no auth/rate-limit/pagination traits, so it exceeds the annotation bar without being fully transparent.

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 purpose sentence, then usage patterns, then disclosure caveats, then the exclusion — a sensible order for a 9-parameter tool. It is long and the disclosure block repeats material that also lives in parameter descriptions, but nearly every sentence carries non-redundant caveat 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?

With no output schema, the description carries the return-value burden and does so: it describes the company row, the attached site list columns, the top-N ranking shape, and the per-row national baseline for comparison. Combined with the disclosure caveats, an agent has enough to call the tool and interpret its response.

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 substantive inline description (aliases, partial matching, ranges, defaults), so the baseline is 3. The description adds the interaction rule for builder+developer and the effect of region, but that overlaps heavily with what the schema already says.

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 enumerates the exact measures returned (공고 수·공급 세대·무순위 세대·비율·청약 1순위 배수·미달 세대). It explicitly distinguishes itself from a sibling by ruling out brand-name notice counting and routing that to realty_notice_facts(keyword).

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?

Enumerates the exact user-question shapes it answers ('○○건설 분양 성적', 'GS건설 현장 무순위 많이 나왔나', '대전 시공사별 분양'). It also states the argument-driven behaviors (builder/developer → company row + site list; no arg → top-N ranking; region → narrowed) and names the alternative tool for the excluded case.

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

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

Annotations declare readOnly/idempotent/non-destructive, and the description goes well beyond them: all inputs are declared (the server does not adjudicate holding-period start, home count, or regulated-area status), exemptions are explicitly out of scope, and the response is stated to carry traps, pending_legislation and disclaimer fields. That is the kind of boundary disclosure annotations cannot convey.

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

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

Core capability is front-loaded in the first sentence, followed by scope and then boundaries. It runs long and dense across two paragraphs, but each block (capability, declared-input boundary, exemption boundary, routing) carries distinct information, so little is wasted.

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 17-parameter, no-output-schema tool this is thorough: it covers the declaration philosophy, the not_curated exemption gap, the escape hatch to realty_policy_rules, and the response fields (traps/pending_legislation/disclaimer). An agent has enough to both invoke it correctly and avoid over-promising on exemption cases.

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 17 parameter descriptions are already unusually detailed (asset_type tax split, share_pct per-person taxation, asset2 holding-year recomputation). The description adds only the general 'everything is declared' framing rather than per-parameter meaning beyond the schema, so the baseline 3 is correct.

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 and resource — applying the capital gains tax rate table deterministically to declared transfer/acquisition/expense/holding values — and adds the multi-asset comparison scope (합산 vs 연도분산 vs 차손통산). It also distinguishes itself from siblings by naming realty_policy_rules as the statute source of truth rather than repeating it.

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 frames the two questions it answers ('지금 팔면 양도세 얼마?' / '두 채를 올해 같이 팔까 나눠 팔까?') and states what it does NOT do (1세대1주택 비과세, 12억 초과 안분, 감면 특례 = not_curated). It then routes the agent to a concrete alternative, realty_policy_rules(topic='one_home_exemption_map'), with a prescribed order of operations before falling back to 홈택스/세무사.

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, yet the description adds substantial non-obvious behavior: default is today-or-later dates only, exact address/complex normalization, a 50–150% appraisal-value filter that excludes 지분경매/특수물건, the ±10% same-area baseline rule, null + '판정보류' fallback when area can't be matched, a warning about stale min_bid_source on failed auctions, and an explicit 2–4s latency 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 is front-loaded and bold section headers organize the axis/alternative guidance well. However the two date-stamped repair notes (2026-08-08, 2026-08-16) read as changelog noise that a calling agent does not need, slightly bloating an otherwise tight 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?

There is no output schema, and the description compensates by explaining the returned signal values (주의/관심/보통/낮음/판정보류), the meaning of a null discount_vs_market_pct, the footnotes toggle, and the stale-min_bid caveat. Nothing needed to call or interpret the tool is missing.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters including the sido/sigungu/case_no/court_name relationships. The description reinforces the date-scoping and area-matching semantics but adds little parameter syntax beyond what the schema provides, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: compares an auction item's minimum bid against same-complex real transaction prices to produce a discount rate and surface yield. It also positions itself explicitly within the '경매 가격판단 3종' axis and names the sibling it must not be confused with (realty_auction_sale_rate), so an agent can distinguish it 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: '이 물건 싸?'는 이게 1차다, use realty_auction_sale_rate together for bid pricing but never mix the two denominators, and use realty_area_price_bands/region_price_stats when setting a manual baseline. Both when-to-use and when-not-to-mix conditions 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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds high-value interpretive context: warning_baseline/warning_dispersion must be read before avg_price, because the source is outlier-unfiltered and mixes complex-level data, so citing avg_price as the regional price can flip a comparison conclusion. That is exactly the kind of non-obvious caveat 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 correctly: purpose sentence, then routing rule, then caveat. Every block is load-bearing, though the warning paragraph is somewhat long and references a sibling source in a way that could be tightened.

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 the description partially compensates by naming return-side fields (warning_baseline, warning_dispersion, avg_price, footnotes) and their interpretation. It does not describe overall return shape or pagination, but for a comparison tool the critical interpretive guidance is present.

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

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

Schema description coverage is 100% (regions format, months range 1-60, include_footnotes behavior are all documented in the schema). The description adds no syntax or format detail beyond that, so the baseline 3 applies; it does visually surface the footnotes/warning fields but not the parameters themselves.

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: it compares multiple regions' 매매·전세 시세와 추이 side by side, and adds the use case (갈아타기·투자처 비교). An agent can distinguish it from realty_region_price_stats and realty_region_rankings 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?

Explicitly routes ranking/exploratory questions ('어디가 제일 ○○해?') to the free realty_region_rankings first and states the exact condition for using this tool instead ('비교 대상이 정해졌을 때'). This is a when/when-not/alternative rule stated outright.

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), yet the description adds substantial behavior: price_by_floor_band aggregation with *_ex_outliers, transactions sorted by contract date descending with average/median over the recent 5, outliers flagged not deleted, longer-named neighbor complexes split out and logged in meta.complex_isolation, unit-mismatch rejections instead of silent conversion, and presale rights carried separately in presale_rights_trades.

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 and the primary alternative are front-loaded, but the body is very long and much of the unit-handling and reject behavior duplicates what the schema descriptions already state. For a 14-param tool length is partly justified, yet several bolded asides repeat structured content instead of adding new 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?

With 14 params and no output schema, the description carries the return-value burden and does so thoroughly: it explains price_by_floor_band, transactions ordering, outlier handling, meta.complex_isolation, quote_check, and presale_rights_trades. An agent has everything needed to call it and interpret the 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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter rules beyond the schema: mixing ㎡ and 평 args is rejected rather than converted, and quoted_price_10k is framed as preventing the model from treating a user-stated price as an unverified premise (quote_check). It consolidates and contextualizes the unit arguments rather than merely restating them.

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: fetch item-level (contract date, floor, price) recent-6-month sale transactions for a specific complex and specific pyeong. It explicitly distinguishes itself from siblings by naming realty_search_complexes.prices_by_area for summaries and realty_region_price_stats for multi-complex floor breakdowns, so an agent can route 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?

Gives explicit when-to-use ('층별 시세 질문은 이 도구가 담당'), when-not ('평형별 시세 요약만 필요하면 realty_search_complexes'), and named alternatives for adjacent needs (realty_region_price_stats.compare_from for multi-complex/6mo+ windows, realty_complex_rent_by_pyeong for rent). It even instructs what to do when pyeong is unknown (call without area) and how to answer 'any recent trades' via latest_contract.

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, so the safety profile is covered. The description adds real behavioral context beyond that: compare_sale defaults on and the server now performs the sale-side fetch in the same 12-month window to avoid ratio distortion, and include_footnotes controls whether full derivation text or a one-line summary is returned. That is substantive disclosure a caller could not infer from annotations.

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

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

Front-loaded with purpose, then routing guidance, then the row-key caveat. Every line carries information, though the compare_sale paragraph's historical aside ('종전엔 note가 ... 호출자가 손으로 했고') is longer than strictly 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?

No output schema exists, so the description must carry return-shape information — it identifies the row key (supply_pyeong as 분양평), states that compare_sale adds 전세가율/전환율/갭 values, and explains footnotes verbosity. Minor gaps remain (pagination, whether missing complexes return an empty set), but the essentials for a correct call are present.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not carry — notably the row-key definition that supply_pyeong is 분양평, derived as 전용㎡ ÷ 3.3058 ÷ 0.745 rounded. It also restates the complex_key/complex_name at-least-one requirement and the compare_sale computation 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 a specific verb and resource ('단지의 평형별 전세 보증금·월세 중앙값을 조회한다') and immediately scopes itself as the jeonse axis of the jeonse-to-sale ratio, which separates it from the sale-side sibling realty_complex_pyeong_price. An agent can tell what this returns 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 a concrete prerequisite path: '가능하면 realty_search_complexes로 complex_key를 먼저 특정하라', and explains that partial matching with complex_name risks mixing same-named complexes. The region parameter's role in disambiguation is covered in the schema. No explicit when-not-to-use, 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 readOnly/openWorld/idempotent/destructive=false, but the description adds real value beyond them: it flags the tool as paid ('[유료]'), names the data source (poi 원장), and warns that score_demotion makes certain scores unverified reference values. It also discloses that the response carries latitude/longitude and complex_key, which an agent needs for chaining.

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?

Purpose is front-loaded in the first line, followed by interpretation rules and chaining advice, with bold emphasis aiding scanability. It is somewhat dense and multi-clause, but every sentence carries actionable content (do-not-use warning, follow-up tool names).

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 partly compensates by naming key response fields (location.facts contents, coordinates, complex_key) and their reliability caveat. For a two-optional-param paid report tool this is largely complete, though it leaves other returned sections (전세/시세 detail shape) unmentioned.

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 name ('단지명, e.g. 반포자이') and complex_key are already documented in the schema, establishing the baseline of 3. The description only incidentally notes that complex_key appears in the response for reuse, adding no lookup semantics or precedence rules between the two optional, mutually-substitutable parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: an integrated lookup of 시세·전세·기본정보 for a single complex, with '[유료]' scope and '단지 하나' narrowing. This differentiates it from sibling specialists like realty_complex_pyeong_price or realty_complex_rent_by_pyeong by its aggregated nature, though it never explicitly contrasts itself with them.

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

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

Gives concrete qualitative guidance: answer location questions using location.facts, do NOT use overall_score/scores for ranking or 'good location' judgments, and feed the returned coordinates/complex_key into realty_poi_nearby and realty_predict_price. It covers how to use the output and which tools to chain, but does not state when to pick this tool over the other complex-level siblings.

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 declare the generic safety profile (readOnly, openWorld, idempotent, non-destructive). The description adds genuinely non-obvious behavior: meta.data_as_of is the authoritative recency, warnings must be surfaced to the user, stale figures must not be asserted as 'current population', annual series require disclosing the base year, and households uniquely rejects same-name districts (중구·서구) due to a source-data defect. That is exactly the extra context annotations cannot carry.

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 purpose followed by trigger examples, then the recency/caveat block — good ordering with each sentence doing work. Minor redundancy between the opening line and the second paragraph, which restate the same 'query regional demographics' purpose, keeping it from a 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?

For a 4-parameter, no-output-schema tool this covers what an agent needs: metric-specific applicability, region granularity, the data-recency contract, how to handle warnings, and the one known hard failure with a prescribed alternative. Nothing material to 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 the baseline is 3, and the schema already documents the metric enum, months window (1–60), and region granularity. The description still adds a cross-parameter constraint not in the schema: households' region rejection and the required fallback to population/migration (which use official names), plus the annual-vs-monthly applicability of the base-year disclosure. Marginal but real added value over 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?

Opens with a specific verb+resource scope ('지역 인구·가구·고령화·순유입 통계를 조회한다') and the four metric families named (population, households, aging, migration) map cleanly onto the enum. An agent can distinguish this from price/auction siblings like realty_region_price_stats or realty_region_trend_basket 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 concrete user-question triggers ('인구 줄고 있어?', '1인 가구 비율은?', '순유입 되는 동네야?') that map to specific metrics, and explicitly routes around the households failure case to population·migration. It stops short of stating when NOT to use this tool versus demographic-adjacent siblings (e.g. compare_regions, location_scores), so it is clear context without full exclusions.

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, so safety and repeat-safety are covered structurally. The description still adds genuinely behavioral context: rights may be null (spec sheet uncollected, never fabricate), claim_amt_10k is the applicant creditor's claim not a tenant deposit, and min_bid_source=item_list means a possibly stale minimum bid requiring min_bid_note. These are real caveats, but they lean toward output interpretation rather than undisclosed operational traits like auth or rate limits, so a 3 fits against an already-covered annotation set.

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?

Purpose and the duplicate-court workflow are front-loaded in the first paragraph, and the rest is organized around return-field caveats. It is dense and longer than most definitions, but nearly every sentence carries a distinct warning or routing rule 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?

There is no output schema, so the description carries the full burden of explaining return values, and it does: rights contents and disclaimer, null-rights meaning, claim_amt_10k semantics, min_bid_source/min_bid_note staleness, and the market_context payload. Nothing an agent needs to call or interpret this tool is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mostly echoes the schema (case_no is not unique across courts, omitting court_name returns candidates), but it adds actionable semantics by framing those parameters as a retry loop and warning against inventing a year for a bare case number. That is marginal added meaning above a fully documented 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 opening sentence states a specific verb and resource (look up auction property details by case number), and the closing paragraph explicitly distinguishes this tool from its siblings: realty_search_auctions handles condition-based sweeps, realty_auction_history owns price-reduction history and photos, and fetch returns the id blob as document text. An agent can route between all three 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?

It states when to start here (per-case sale conditions like re-auction deposit ratios), gives an explicit recovery workflow when court_name is omitted (error plus candidate court list, then re-call with a court), and names the alternative tools for the queries it does not serve. When-not and alternative coverage is unusually complete.

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 a safe, read-only, idempotent profile, so the description's job is to add traits beyond that — and it does: it flags the tool as [유료] (cost-bearing) and discloses that the response carries a disclaimer field the agent must relay. That is genuine behavioral context beyond the structured annotations. It stops short of describing output shape or limits, so not a 5.

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 axes, then a single operational instruction. Two short sentences with no filler; the only minor cost is that the paid/disclaimer notes are interleaved with purpose rather than separated.

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 conveys what is computed (three axes), that the result is a score, and an important response-side obligation (disclaimer). What is missing is any hint at the return structure or how scores should be interpreted, which matters slightly more given the absence of an output 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% with a single well-described 'region' parameter (시군구명 예: 강남구), so the schema already carries the semantics. The description adds no parameter-level detail (e.g., accepted granularity or edge cases) beyond the schema, which is the baseline-3 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (점수화한다 / scores) and resource (지역 투자 위험도 / regional investment risk) and even enumerates the scoring axes (변동성·유동성·공급압력 / volatility, liquidity, supply pressure). This is clear on its own, but it does nothing to distinguish itself from plausible siblings like realty_market_signals, realty_supply_demand_balance, or realty_location_scores, so it stays below 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?

There is no statement of when to use this tool versus the many adjacent risk/market tools, nor any prerequisites or exclusions. The only guidance provided is a post-call instruction about relaying a disclaimer, which is not usage guidance for selecting the tool. The [유료] marker signals cost but not applicability.

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 adds real behavioral context on top: inputs like homes_owned/first-time/newlywed are declarations the server does not fact-judge, limits are deliberately not calculated here, and rule uncertainty lives in each product `topic`. This is substantive disclosure well beyond what annotations provide.

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 each boundary clause carries useful information. It is somewhat verbose, with bold markup and meta-narrative (the pinned date, '이 도구가 존재하는 이유') that could be trimmed, but the structure remains readable and front-heavy.

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 comes back (usable products plus reasons for exclusion, and the `topic` pointer for rule basis/uncertainty). All 8 parameters are documented in the schema, and the read-only safety profile is covered by annotations, so an agent has everything needed to call this 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 the per-parameter descriptions are already extremely rich (defining 세대 기준, 순자산, 전세 vs 전세반환 direction). The description only restates that purpose/region/homes are the judgment axes and adds no syntax or format detail beyond the schema. Baseline 3 is correct when the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action (side-by-side eligibility judgment) on a specific resource (loan products), with the exact axes (purpose × region × homes owned). It explicitly names the sibling it is not (realty_loan_limit) and explains its router role, so an agent can distinguish it from siblings 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 when-to-use (the caller does not know which of the 7 rule topics to ask), an explicit alternative (realty_loan_limit handles limit amounts for purchase-purpose bank loans), and explicit when-NOT-to-expect-calculations (jeonse/mid-payment governed by guarantee agencies, jeonse-return being document-based). Routing guidance is unambiguous.

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 still adds real behavioral context: borrower type is a user declaration the server does not adjudicate (echoed in inputs_declared), the output is a ceiling that banks may cut further, DSR swings sharply with rate_type (default '변동' being the worst case), and the agent must relay uncertainties/disclaimer rather than assert 'N억까지만 된다'.

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 and the boundary list is dense and useful for a 17-parameter domain tool, so the length is largely earned. Minor flaws: the circled-number marker ③ is used twice and the third bullet restates guidance already present in the schema, adding slight 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?

With no output schema, the description compensates well: it names expected response pieces (inputs_declared echo, dsr.by_rate_type comparison table, desired.credit_room_after_mortgage, footnotes, uncertainties, disclaimer) and explains what changes appear in the output (e.g., maturity adjustment surfaced in the response). An agent has enough to call it and to interpret the result.

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 per-parameter semantics (rate_type axis, stress_stage limited to non-metro, credit_loan_10k traps, desired_loan_10k judging) are already carried by the schema. The description largely restates those same caveats rather than adding new parameter meaning, so the baseline of 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 opening sentence states a specific verb and resource (deterministically computing the mortgage regulatory cap) and enumerates the concrete outputs: LTV cap, metro/regulated-area price-band caps (6/4/2억), 30-year maturity cap, stressed-DSR max loan, and which rule is binding. It even anchors the canonical user question ('10억 집, 생애최초, 연소득 8천이면 얼마까지 나와?'), and names the siblings it is not (realty_policy_rules, realty_presale_funding_plan).

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: this is the seat for 'how much can I get' questions, while rule tables go to realty_policy_rules, regulated-area status to topic=regulated_area, acquisition-tax rates to topic=acquisition_tax, and time-phased presale funding to realty_presale_funding_plan. It also states a clear exclusion — the result is a regulatory ceiling, not an approval or commitment.

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 read-only/idempotent profile, but the description adds substantial behavioral context: scores are labeled unverified reference values with 82% of transit scores ≥90 and no discriminative power, null means unmeasured (not 0), school score is a v5 composite not school assignment, complex_key is normalized to a single space, and missing complexes yield not_found with a no-fabrication rule.

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

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

Dense but front-loaded: the bolded 'location_facts first' directive leads, followed by field contents, caveats, and sibling routing. Some parenthetical asides (30km rural examples, v5 composition) add length, but nearly every sentence carries information an agent needs.

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 and delivers: it names the response container (location_facts), the specific sub-fields, the score_demotion flag, and the fallback behavior. Nothing essential 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 the baseline is 3, but the description genuinely adds meaning beyond the schema — it explains the region-alone case (region aggregate + top-5 complexes by score, with ranking citation forbidden) versus complex_key/complex_name (complex rows, raw values for the first 5), which the schema only states tersely.

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 (returns raw location facts — nearest subway name/line/distance, station/bus-stop counts, school counts, hospital/mart counts) and explicitly contrasts itself with the unverified reference scores in the same row. An agent can distinguish it from realty_poi_nearby and 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?

Explicit routing: use realty_search_complexes once for multiple complexes (rank by price_per_exclusive_m2), use [paid] realty_poi_nearby for facility name-level lists, and do NOT call this tool for reputation/resident reviews. It also states when-not (no ranking by score, no '역세권/학군 좋음' verdicts) and the not_found fallback.

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, it discloses a critical behavioral trait: per-series data freshness differs, meta.series_as_of is the real latest timestamp, and some series (KR base rate, KOSPI) are frozen at 2024-12 pending ECOS re-harvest. It even instructs the agent to state each series' timestamp rather than quoting stale data as current — exactly the kind of context annotations cannot carry.

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?

Purpose is front-loaded in the first sentence, usage context second, and the staleness caveat last as a warning block. It is appropriately sized, with only mild redundancy in restating specific indicator names already given in the 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?

There is no output schema, so the description compensates by revealing the meta.series_as_of field and warning about per-series staleness — the main correctness trap for this tool. Combined with the 100%-covered parameter schema, an agent has what it needs, though it never notes pagination/volume limits for up to 240 months across eight series.

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%: months and indicators are both fully described in the schema, including the comma-separated indicator names and the reject-unknown-names behavior. The description adds nothing parameter-specific beyond what the schema already provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (조회한다) and an enumerated resource (KR base rate, KOSPI, M2, US Fed rate, S&P500 monthly series), so an agent can immediately tell it returns macro time series rather than property-level data. It does not, however, name or differentiate itself from the potentially confusable sibling realty_market_signals.

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 a concrete usage context — background analysis for questions like 'how do interest rates affect home prices?' — which tells the agent when this tool fits. It offers no explicit exclusions or named alternative tools, so the routing guidance is clear but not complete.

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, openWorld), and the description adds real behavioral content beyond them: the default 6-month window, that nationwide windows drop oldest months and surface this in meta.truncated / meta.truncated_note, and that region restores the full window. It does not mention the '유료' (paid) cost/auth implications flagged only in the title.

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 combined purpose, then layered detail on output keys and windowing. Sentences are dense but each covers distinct information (response keys, window default, truncation semantics); no filler.

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

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

With no output schema, the description carries responsibility for return shape and does so partially by naming the unsold_completed and unsold_sigungu keys and the meta.truncated fields. It stops short of describing the sentiment-index output structure, but the annotations and 100% schema coverage cover the rest.

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 already documents months (including the truncation caveat and 1-36 range), region, sigungu, and include_footnotes. The description largely restates the schema's own param behavior (default window, sigungu separate key), so it adds only marginal value over structured fields.

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 specific verbs and resources: querying unsold-inventory trends (미분양) and the market sentiment index together, framed as a macro buy-timing signal. The scope is concrete enough to distinguish it from pure price tools, but it never names a sibling (e.g. realty_macro_indicators or realty_supply_demand_balance) that an agent might confuse it with.

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?

Implies usage via '매수 타이밍 판단의 거시 신호' and explains the months/region window tradeoff, which is useful operational guidance. However there is no explicit when-to-use versus alternatives, and no statement of when another tool would be preferable.

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/open-world, so the bar is lower, and the description still adds substantial behavioral context: it declines to assert without a declaration, admits '판정 불가 실토' when 인가일·착공일 data is missing, and flags the 부칙 trap plus the separate 토지거래허가구역 regime. No contradictions. Slightly short of 5 only because it leaves response-shape specifics to '전하라' without describing the output it will actually return.

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 judgment and the concrete example before the boundary list. The four numbered boundaries and the sibling-routing sentence are dense but each earns its place by preventing a misuse; only mild verbosity keeps it from a 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?

For a deterministic multi-factor legal judgment with no output schema and 100% schema coverage, the description supplies everything an agent needs: inputs to declare, what the tool will and will not judge, the addendum edge case, the separate permit-zone caveat, and where to route adjacent questions. 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, but the description adds real meaning beyond the schema: it explains that region/project_name auto-join the Seoul stage list, that project_name matches only unique matches, that outside Seoul project_stage must be declared, and that re-declaring the returned stage reproduces the same judgment. That elevates it above the schema-only 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 (판정) and resource (조합원 지위양도 승계 가능 여부) with the exact legal basis (도시정비법 39조 2항) and the three-way determinant (투기과열지구 × 사업유형 × 단계). The '한남3구역 지금 사도 입주권 나와?' framing makes the concrete decision it renders unmistakable and separates it from sibling policy 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?

Explicitly routes alternatives: realty_policy_rules for statute text, realty_redevelopment for project lists/stage, realty_redevelopment_entitlement when subscription eligibility itself is uncertain, and topic=regulated_area for designation status. It also states scope exclusions (소규모정비사업 not judged, exceptions handed off as forks).

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/non-destructive/openWorld), but the description adds the crucial behavioral caveat that results are a lower bound: announcements land ~30 months before move-in, so windows beyond today+30 months are mostly unannounced. It also discloses the Sejong 실사고 (676 vs ~6x actual), the reading/interpretation labels, and meta.window_direction — none of which the annotations provide.

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 opening sentence '지역의 입주 예정 물량을 연월별로 집계한다.' is duplicated verbatim, and several caveats (lower-bound, window direction, don't-sum) are restated across sections. Purpose is front-loaded, but the redundancy costs it points.

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 return-value burden and does so: it names by_sido, meta.window_direction, reading/interpretation, and coverage.region_recent_annual_rate, and explains how to interpret each. For a 5-param tool with a subtle aggregation semantics, nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: region accepts only sido while sigungu goes to the sigungu param (server relocates and logs to meta.unapplied_conditions), and it flags that realty_supply_pipeline's region contract differs. It also explains that from_ym defaults to the current month so months counts forward, not backward.

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 — aggregates expected move-in (입주 예정) volume by year-month for a region — and explicitly distinguishes itself from realty_supply_pipeline by noting that pipeline carries approved-but-not-announced volume. 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 triggering questions ('입주장 리스크 있어?', '내년에 입주 물량 얼마나 쏟아져?'), names the alternative tool (realty_supply_pipeline) and the condition that selects it, and warns not to sum the two axes due to double-counting. This is explicit when-to-use, when-to-switch, and when-not-to-combine 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 only supply readOnly/idempotent/openWorld, but the description discloses far more: the response shape (recent rows + stats with sample count, price, composition), the silent-failure mode where a mistyped property_type still returns HTTP 200 with populated rows backed by a dated QA incident, the 도시형생활주택 gap with its urban_housing_notice signal, and that aggregation excludes 지분/해제 rows. These are exactly the traps an agent cannot infer from structured 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?

Front-loaded and forceful — the exclusion and the routing alternatives come first, and bolding makes the decision points scannable. It is longer than needed: the '아파트는 이 도구가 아니다' exclusion is restated four times across description and schema, which is defensive reinforcement rather than new 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, and the description compensates by explaining what comes back (recent transactions plus stats, by_area_band distribution, footnotes toggled by include_footnotes, note/urban_housing_notice). With 7 parameters, one enum, and zero nested objects, nothing an agent needs to call and interpret this 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 coverage is 100% and the schema itself already repeats the apartment warning on property_type and the house/전용면적 caveat on area_band, so much of the parameter text is duplication. The description still adds cross-parameter meaning the schema lacks: the land 면적 기준 (계약면적·지목·용도지역), the rule that share_type='지분' rows must not be used for per-area price comparison, and the 'don't call this just to narrow by 동' guidance on region.

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 immediately scopes what it is NOT (아파트는 이 도구가 아니다). It names the sibling tools that own the apartment axis (realty_region_price_stats, realty_search_complexes, realty_complex_pyeong_price), 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?

Explicit when-to-use and when-not: '질문에 아파트가 있으면 여기서 멈추고 아파트 축으로 가라' with the three named alternatives and the specific question each answers. It also adds the reverse exclusion (동 단위로 좁히려고 이 도구로 오지 마라) and states the domain limit (매매 데이터만 있다 — 전월세를 물으면 데이터가 없다고 답하라).

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: discloses the 64KiB result cap, the truncation mechanism (drops the largest sections first), the meta.truncated / meta.omitted_sections signals, and how to re-fetch a dropped section via section=. Also states the unverified fallback, the total_matched for keyword fan-out, and a hard anti-hallucination rule ('못 봄 ≠ 없음').

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?

Information is front-loaded (resource → covered fields → citation rule → truncation → keyword), but the field enumeration in the first half repeats terms twice (전매제한/재당첨 등 listed in prose and again in the question list) and runs long. Dense but every block earns a distinct purpose; minor redundancy keeps it from a 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?

No output schema, so the description carries the full burden — and it covers the failure modes an agent will actually hit: truncation + recovery, unverified notices, multi-match on keyword, and scope boundaries to sibling tools. Nothing needed to invoke 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 bar is baseline 3; the description adds real meaning on top: keyword is treated as a brand/partial name with multi-match behavior and total_matched, and section is described with a recovery workflow (leave empty, read the section list, re-fetch by name) plus the caveat that section names vary per notice. It does not fully document house_manage_no's format, but that's already 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 resource (factsheet extracted and verified from the original 입주자모집공고) and enumerates the exact fields it covers: 전매제한, 재당첨제한, 거주의무, 층별 분양가표, 특별공급 배정, 발코니 확장/유상옵션, 중도금 회차. It explicitly names the sibling realty_notice_text for full clause text and realty_builder_presale_record for builder-level records, so the agent can distinguish it 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?

Gives explicit when-to-use ('이 값들을 묻는 질문이 이 도구의 자리다'), when-not ('상세 조항 전문은 realty_notice_text로'), and a keyword-counting alternative (realty_builder_presale_record). Also tells the agent how to cite (notice_version + page number) and that unverified notices return unverified_source_text with a disclosure requirement.

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 and openWorldHint, so the safety profile is covered. The description still adds real behavioral context beyond them: table pages may be misaligned by pdftotext so columns must not be over-asserted, the response is capped at 6 pages, meta.matching_pages always carries the full hit list, and pages_only is silently ignored when pages is given (reported via meta.pages_only_ignored). This is strong disclosure, though the fallback mechanics of the 0-page case are only sketched.

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?

Purpose is front-loaded and the dense body is almost all actionable (conflict error, table caveat, page cap, pages_only-first workflow). It loses a point because the opening line is effectively repeated ('원문을 쪽 단위로 읽어 준다' then '원문을 쪽 단위로 읽는다'), a wasted sentence in an otherwise tight 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?

For a 5-parameter read tool with no output schema and no nested objects, the description covers everything needed to call it correctly: return size limit, where the full matching-page list lives, error naming, fallback behavior, and the pages_only-first workflow. Nothing material is left for the agent to guess.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents match, pages, query, pages_only and house_manage_no. The description still adds semantic value the schema does not: the AND semantics of multi-word queries with concrete examples, the workflow of using pages_only to pick pages before narrowing with pages, and the documented fallback result set when a query returns 0 pages.

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 scopes it to page-level reading of the recruitment notice original. It distinguishes itself from the fact-sheet sibling by saying the details absent from 팩트시트 (특별공급 소득·자산 기준, 부적격 처리, 계약 유의사항) are exactly what this tool is for, so an agent can separate it from realty_notice_facts.

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: use this when the fact sheet lacks detail, use pages_only=true first when the page is unknown, and if 0 pages come back, narrow with per-word hits / partial-match pages or widen via match='any'. It also names the query-vs-pages tradeoff and the conflict error, covering when-not and alternatives rather than leaving them 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 (readOnly/idempotent/non-destructive), but the description adds substantial behavior beyond them: a 3-month sample window, only successful bids entering the ratio, 2,896 of 3,824 bids having a usable ratio with missing treated as unknown rather than zero, median mandated because outliers inflate the mean, and region fields silently dropping unparsed rows.

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 answer it produces, then the sibling differentiation, then labeled caveats (이 축의 자리, ⚠️ blocks). Despite the density, each block carries decision-relevant information and nothing is redundant filler for a tool this caveat-heavy.

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 names the fields an agent must report (median_pct, p25_pct, p75_pct, outcome_mix, ratio_missing, region_basis, by_property_type) and explains their meaning, leaving no gap between calling the tool and interpreting 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?

Schema description coverage is 100% and the schema already documents each parameter in depth, including the 광주 ambiguity and region_ambiguous rejection. The description reinforces these but adds little parameter-specific meaning the schema lacks, 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?

States a specific verb+resource: it answers what percent of appraised value 공매 properties sell at and how often they fail to sell. It explicitly distinguishes itself from the identically-named sibling realty_auction_sale_rate ('같은 이름의 다른 지표다') and from realty_search_onbid as the statistics vs. individual-listing axis.

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: individual properties and per-round minimum prices go to realty_search_onbid, and when a user asks about '경매 낙찰가율' the description instructs the agent to confirm which of the two metrics is meant. It also directs reading by property_type, which is a usage instruction, not just a fact.

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 read-only/idempotent/open-world safety, but the description adds the crucial non-structured fact that this is a paid ([유료]) tool, which is the key cost decision an agent must weigh against free siblings. It does not describe rate limits or result volume, but the cost signal is the meaningful addition.

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 tight paragraphs: purpose first, coordinate source second, alternative-tool routing third. The paid tag is front-loaded and every sentence carries routing or sourcing 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?

With no output schema, the description supplies the essential inputs source, scope, and sibling distinctions an agent needs. It could say more about result shape or limits, but 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%, so the schema already documents lat/lng source, poi_type combinations, and radius bounds. The description restates the coordinate source but adds no syntax or behavioral detail beyond the schema, so the baseline 3 applies; note the description's mention of 마트 slightly overstates the schema's three coordinate-searchable types.

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 (조회 of nearby POI by coordinates), names the concrete facility categories, and specifies the output ordering (거리순). It is clearly separable from realty_location_scores and realty_poi_stats by the stated purpose.

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 routes the agent: use this when a facility list with per-name distances is needed; use the free realty_location_scores for nearest-station distance and in-radius counts; use realty_poi_stats for non-coordinate categories. It also names the upstream tool that supplies lat/lng.

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/destructive=false, so the safety profile is covered. On top of that the description discloses a genuine data-coverage limitation (지방 시군구 may return 0 due to collection scope) and instructs how to phrase results, which is real behavioral context not present in any structured field.

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?

Purpose is front-loaded in the first line, followed by the region-key rule and the zero-value caveat. Every sentence carries distinct information; the only slight cost is the somewhat fragmented multi-paragraph layout for a two-parameter tool.

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

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

For a read-only, two-parameter tool with no output schema, the description covers purpose, region key format, limit behavior is handled by the schema, and the key interpretation pitfall (zeros). Nothing critical to a correct call is missing, though return shape is only implied.

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 goes beyond the schema by specifying the exact region key format ('시도축약 시군구' 2 tokens, 세종 as 1 token), which is format guidance the schema does not state, and reinforces that empty input means nationwide.

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 gives a precise verb and resource: counts of hospitals, schools, and subway stations aggregated per 시군구, scoped as a paid tool. The '지역 간 인프라 비교용' framing implicitly separates it from the per-POI sibling realty_poi_nearby, though no sibling is named 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?

States the use case clearly (cross-region infrastructure comparison) and gives a meaningful usage constraint: don't interpret 0 counts as absence because collection is centered on 수도권/광역시. It stops short of naming an alternative tool or an explicit 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 readOnly/idempotent/non-destructive, so the bar is lower, and the description adds real context: it returns 근거 조문·확인일, surfaces uncertainties and a disclaimer, explicitly answers '0건' rather than fabricating, and warns against hardcoding rates (with an observed-error example). It does not discuss volume/size of tables or output format, but for a read-only reference tool this is well above the annotation baseline.

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?

Purpose is front-loaded in the first sentence and the length is justified by a 26-topic router with many sibling overlaps. However, substantial content (the exhaustive topic-by-topic enumeration and the sibling routing list) is restated in the topic enum descriptions, so there is measurable duplication rather than zero 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?

For a complex, judgment-adjacent policy lookup with no output schema, the description covers scope, what is returned (조문·확인일·uncertainties·disclaimer), the no-judgment boundary, the anti-hallucination behavior, and the sibling hand-offs. 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 description coverage is 100% and the schema itself carries very rich per-parameter semantics (query fallback behavior, topic enum, section subsetting with rejection on unknown names). The description body adds essentially no parameter meaning beyond what the schema already provides, 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 opening line states a specific resource (단지에 종속되지 않는 일반 규범 — 세율·규제·대출·임대차) delivered with citations, which is a distinct verb+resource. It immediately positions itself as the reference-table '진실원' behind a set of sibling calculators, so an agent can tell it apart from realty_loan_limit, realty_subscription_score, etc. 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 routing: it names the exact sibling that owns each computation (realty_loan_limit for 상한 계산, realty_subscription_score for 가점, realty_capital_gains_tax for 양도세 시나리오, realty_member_transfer_check for 지위양도 판정) and states what it does NOT do (판정은 하지 않는다). It also names realty_presale / realty_notice_facts for notice-level flags and the case-level siblings for individual matters — full when/when-not/alternative coverage.

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 non-obvious behavior: a fixed 1-month horizon that ignores the months param, honest refusal outside coverage, measured error rates (2-4x off for new builds, 16.3% exceeding ±10%), and mandatory relaying of caution/as_of_ym/disclaimer. This goes well past 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?

Purpose and the required-identifier rule are front-loaded, and each subsequent sentence carries a distinct operational fact (horizon limit, refusal cases, rerouting, mandatory field relaying). It is dense rather than padded, though the length is near the upper bound for a 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 by naming the response fields an agent must surface (predictions[].caution, as_of_ym, disclaimer) and the footnotes behavior toggled by include_footnotes. Nothing needed to call or report this tool correctly appears to be 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 each field, making 3 the baseline. The description nonetheless adds what the schema cannot: an at-least-one-of complex_name/complex_key constraint (the schema shows 0 required params) and the dependency on realty_complex_report to obtain complex_key.

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: predicting next month's average sale price by pyeong band via a named model version. It is clearly distinguished from similar siblings like realty_complex_pyeong_price (current price) by explicitly framing the output as a forecast for 익월.

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 the alternative and the condition: if multiple complexes share a name, resolve with realty_complex_report first and call with complex_key. It also defines when the tool will NOT answer (under 3 monthly transactions in 3 months, brand-new complexes with no history) and routes the agent to 실거래 도구 in that case.

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), and the description goes far beyond them: apply_status/apply_status_text are pre-judged against meta.today and must not be re-derived, rank1_result=published-false means unknown (not 'no competition'), unsold_history absence is not proof of no history, and regulation flags are announcement-date snapshots that must not be asserted as current. This is unusually rich 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?

Front-loads the purpose and the answer-shaping rule (status='접수중') before the caveats, and every paragraph maps to a real failure mode. It is dense and long, with some redundancy against the schema's own parameter descriptions, but no sentence is filler.

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

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

No output schema exists and the tool has 9 params with layered output fields, yet the description explains the returned status fields, the rank1_result semantics, the unsold_history caveats and the routing fields (meta.today, house_manage_no, question_routing). Nothing an agent needs to call or interpret it 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 interpretation beyond the schema: status and upcoming are mutually exclusive and status supersedes upcoming, notice_kind='접수마감' switches the response from a list to per-complex 회차 집계, and price_min/price_max are per-house-type extremes. Much of this is mirrored in the schema, so it is not fully additive, but the aggregation behavior adds real 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?

Opens with a specific verb+resource (아파트 청약(분양) 공고를 조회한다) and enumerates the returned fields (분양가·접수 일정·당첨자 발표일·입주 예정·위치). It also names the siblings it is NOT — realty_presale_vs_market, realty_subscription_odds, realty_presale_price_trend, realty_notice_facts — so an agent can separate it 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?

Explicitly routes questions: '오늘/지금 접수 가능한' → status='접수중', upcoming=true only covers pre-start notices, '넣을 만해?' → hand off to realty_presale_vs_market, 경쟁률 → realty_subscription_odds, 추이 → realty_presale_price_trend, 원문 규제 → realty_notice_facts. When-to-use and when-to-use-something-else are both stated.

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/no-destructive, so the description focuses on domain behavior: minimum-3-sample suppression of percentiles, '표본 부족' verdict being the answer, unknown 중도금 meaning undetermined rather than interest-bearing, per-year coverage gaps, and 전용면적 vs 공급면적 axis mismatch. These are non-obvious traps that materially change interpretation, though return shape/pagination is not described.

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 valuable but lengthy and repetitive — the opening restates the same 5-axis comparison twice (once in prose, once as a numbered list), and several caveats repeat across sections. Front-loading is good, but the busywork sentences dilute it.

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 no-output-schema analysis tool: it covers what the tool returns (5-axis values plus percentile, or slice distribution alone), the sample-size gate, and the routing to siblings. Missing only return shape details and how the 'slice distribution only' mode is triggered (e.g., which params).

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% (baseline 3), and the description adds semantics beyond the schema: keyword vs house_manage_no may yield candidate list, region is background-only and not a conclusion basis, sigungu vocabulary form, and the uniform filter applied to all cells. Adds real meaning but the schema already carries the per-param detail.

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 (견준다/compare), resource (분양 공고), and scope (same sigungu·same pyeong, 5 named axes), and explicitly frames itself as a cross-sectional comparison across notices versus sibling tools that handle individual facts, text, market fit, or trends.

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 four alternative siblings (realty_notice_facts, realty_notice_text, realty_presale_vs_market, realty_presale_price_trend) and states what each covers so the agent can route correctly. Also states the when-not conditions: don't draw year-crossing trends, don't fall back to background (시도) values, don't use market comparison alone.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the calculation is deterministic on the factsheet, defaults assume standard tax rates while 중과·감면 live in realty_policy_rules, and — critically — it instructs the agent that assumptions must be surfaced to the user. It stops short of describing return shape in detail, but the disclosure of the assumption-handling obligation is valuable.

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 and boundary are front-loaded well, but the text is dense with self-referential asides (신고 #43의 선 그대로, 실측 124만원) that add persuasion rather than actionable content. Several parentheticals could be dropped without losing invocation-relevant meaning, so it reads as verbose rather than tight.

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 7-parameter, no-output-schema financial calculation, the description supplies the missing context: deterministic vs. personal-parameter split, assumption disclosure duty, and the sibling that owns each excluded concern. It also hints at return shape ('행마다 한 줄 요지' vs footnotes), which is enough given no output schema. Minor gap: no explicit note on which parameters are needed to get a meaningful result when all are optional.

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 (keyword, house_ty, movein_ym, mid_rate_pct, house_manage_no, extra_options_krw, include_footnotes) is already documented in the schema with defaults, ranges, and cross-tool hints. The description adds only the general note that rates may differ from the default; it does not extend parameter semantics meaningfully, 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?

States a specific verb (계산한다) and a precisely bounded resource (분양 한 건의 층별 총 소요자금), then enumerates the exact components: 분양가·발코니·중도금이자·취득세. The agent can immediately tell this apart from sibling cost tools like realty_presale_funding_plan without reading 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?

Explicitly draws the boundary: it computes only what is deterministically derived from the notice + tax law, and names the alternatives for everything outside that line — realty_complex_rent_by_pyeong for jeonse prices, realty_presale_funding_plan for loan/funding judgment, realty_policy_rules for the tax table itself. This is a textbook when/when-not/alternatives statement.

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 establish read-only/idempotent safety, but the description adds substantial behavior the annotations cannot: judgment is deterministic and locked to current regulation and current own funds (no projection of future rates/regulation/savings), borrower type and income are user declarations rather than server-verified facts, output is not an approval or commitment, and parallel 시세·전세 scenarios appear only when declared.

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?

Purpose is front-loaded in one sentence and the numbered ①–⑤ boundary block is easy to scan. It is dense and the opening sentence is echoed by the title, which costs a little, but essentially every clause carries routing or constraint 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?

For a 22-parameter, no-output-schema tool this is complete: it covers the required inputs' contract (house_manage_no, own_funds_10k, borrower), the movein_ym dependency, the conditional scenarios returned (scenario_at_expected_price, jeonse_scenario), and the assumptions/uncertainties the response carries. Nothing needed 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%, so the baseline is 3, but the description adds cross-parameter meaning: own_funds_10k is modeled as fully deployed from 계약금 to 잔금 (0 is valid and honestly fails at the 계약금 gate), borrower/credit_loan share the realty_loan_limit contract, and rate_type's 변동 default is the most conservative stress case. These interpretive notes go beyond the per-field schema text.

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: deterministically judges whether one presale closes with own funds + loans at each stage (계약금→중도금 회차→잔금), including the loan's regulatory cap check. It explicitly positions itself against siblings (realty_loan_limit engine, realty_presale_cost, realty_presale_vs_market, realty_policy_rules), so an agent can distinguish it 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?

Names the exact question it answers ('이 분양 당첨되면 진행 가능해?') and enumerates five boundaries, including explicit when-not routing: savings planning, 갈아타기 strategy and purchase-appropriateness are out of scope, price comparison goes to realty_presale_vs_market, and the raw rule table to realty_policy_rules. It also tells the agent to relay assumptions/uncertainties.

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 by defining the metric basis (분양평 평당 최고 분양가, 만원/평, excluding 발코니 확장·유상옵션) and disclosing a statistical caveat about median instability when the housing-type mix differs by year. This is genuine analytical behavior an agent cannot get 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?

Bold header lines and a front-loaded purpose are good, but the opening sentence '같은 지역 분양 공고들의 연도별 평당 분양가 추이를 낸다' is then repeated verbatim in the second paragraph, which is pure redundancy. The philosophical framing around 기다림의 비용 earns its place, but the duplicated lead-in 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?

For a 5-param, all-optional, no-output-schema tool, the description covers method, caveats, sibling positions, and filter usage. It stops short of describing what the returned time series looks like (e.g., yearly buckets, price units per row), which an agent producing downstream answers would benefit from.

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 semantic guidance: exclusive_m2_min/max pins the pyeong band (국평=80~85), and it directs neighborhood/district-level analysis to keyword. It even flags the sigungu contamination caveat. Minor gap is it doesn't explain region scoping in detail.

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?

Starts with a specific verb+resource: '같은 지역 분양 공고들의 연도별 평당 분양가 추이를 낸다'. It then distinguishes itself explicitly from two siblings (realty_presale_vs_market for individual-announcement appropriateness, realty_region_price_stats for 실거래 trend) by declaring '이 도구는 분양가끼리의 시계열이다'. An agent can route correctly without opening the schema.

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

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

Gives explicit when-to-use framing ('지금 넣을까, 기다릴까' — cost-of-waiting axis, especially for 재당첨 제한 decisions) and when-NOT-to: 'announcements가 1~2건인 연도는 추이로 읽지 말고'. It also names the correct alternative tool for adjacent questions, so the agent knows both the selection and the exclusion conditions.

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

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

Annotations cover the safety profile (readOnly/idempotent/non-destructive), so the description's added value is the output-interpretation behavior: gap_pct follows whichever baseline gap_basis names (nearby_baseline vs regional average), region-avg figures always sit in gap_pct_region_avg, and baseline_divergence signals when the two baselines disagree — with an explicit warning not to call something 'expensive' off the regional figure in that case. It also discloses the multi-candidate re-call behavior and the single-announcement scope limit.

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, then announcement identification, then baseline semantics, then sibling routing — a logical order with no filler sentences. It is dense and long, with minor redundancy around the '넣을 만해?' framing and a stray trailing quote character, but nearly every clause carries operational meaning.

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

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

There is no output schema, so the description must carry the return-value burden, and it does: it names the key output fields (gap_pct, gap_basis, gap_pct_region_avg, baseline_divergence, comparison_truncated, footnotes) and how to interpret each. For a 6-parameter join-computation tool, an agent has everything needed to call it and read the result correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further than the schema by explaining that omitting pyeong auto-selects the top 5 by household count, and that pyeong is the escape hatch for housing types dropped from comparison_truncated. It reinforces that house_manage_no is the most precise identifier and ties region+keyword to the search fallback.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it computes, per housing type, whether a subscription announcement's presale price is cheap/expensive versus surrounding actual transaction prices. It explicitly frames its reason for existing (the presale×transaction join that web search can't do) and names the siblings it is NOT (realty_subscription_odds, realty_area_price_bands, realty_presale_price_trend).

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 house_manage_no is absent, search by region+keyword, and if multiple candidates return, pick one and re-call rather than guessing. It names alternatives and conditions ('넣을 만해?' → pair with realty_subscription_odds; regional cross-check → realty_area_price_bands; time series of presale prices → realty_presale_price_trend).

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

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

Annotations already cover readOnly/idempotent/destructive/openWorld, but the description adds substantial behavioral context beyond them: coverage gaps (meta.coverage.not_covered), cache freshness semantics (meta.freshness), truncation/total_matched, and the crucial 접수예정 vs 접수중 distinction. It warns not to interpret 0 results as 'no recruitment', which is real operational guidance.

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 scope in the first sentence, then example questions, then a bulleted '결론에 반드시 옮길 것' block. Appropriate for a tool with several caveats, though some points (rental type enumeration) overlap the title and 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?

With no output schema, the description carries the return-value burden and does so: it lists returned fields (유형·지역·진행상태·마감일·남은 일수, source_url), sort order, and meta fields (total_matched, truncated, freshness, coverage, next_offset). Combined with annotations covering safety, nothing needed 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 description coverage is 100%, so the schema already documents region, keyword, rental_type, limit, offset thoroughly (including 광주 disambiguation and keyword scope). The description largely restates the rental types and does not add parameter syntax or format detail beyond what the schema provides. 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?

Specific verb+resource (마감 전 공공임대 모집공고) with the source enumerated (LH 행복주택·국민임대·영구임대·통합공공임대·공공임대·매입임대·전세임대). An agent can tell this apart from sibling notice tools (realty_notice_facts, realty_notice_text) because the scope is recruitment notices, not notice text/facts.

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

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

Provides concrete example questions ('행복주택 모집 공고 있어?', '서울 청년 전세임대 지금 신청돼?') that clearly delineate when to use it, plus explicit when-not scope (자격 판정 안 함, SH·GH·iH 미포함). It lacks named sibling alternatives to route to, 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/openWorld), so the description earns credit for adding context beyond them: the exact scoring formula, the explicit disclosure that feasibility factors (용적률, 대지지분, 안전진단, 조합 단계) are excluded, and the requirement to relay the response disclaimer verbatim. Auth/cost implications of '[유료]' are only implied by the title, not explained.

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 tightly packed sentences, front-loaded with the purpose, then the formula, then the limitation. Every sentence carries information the agent cannot get from the schema or annotations; nothing is 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 does enough to set expectations: it reveals the score composition, that ranking is national-by-default, and that the response carries a disclaimer. It could say more about the shape of the returned list (fields, ordering guarantees), which is the one remaining gap for a tool with no output 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 schema already documents limit, region, and district (including the region/district synonymy). The description adds no parameter-level guidance (e.g. how to format a district, or what happens when limit is large), 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 names a specific verb and resource ('재건축 후보 스크리닝 상위 단지를 조회한다') and even enumerates the exact ranking inputs (building age + 12-month transaction percentile). It is precise about what the tool returns, but it never distinguishes itself from the closely named sibling realty_redevelopment, so an agent must guess which one to pick.

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 a clear scope boundary: '후보 발굴용이지 투자 판단 근거가 아니며' explicitly tells the agent this is for candidate discovery, not investment judgment, and instructs relaying the disclaimer. What's missing is naming the alternative sibling (e.g. realty_redevelopment or realty_remodel_feasibility) that would be appropriate for feasibility questions.

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/non-destructive, and the description goes beyond them by disclosing Seoul-only source coverage, that 세대수·준공예정 are null, and that ~2% of rows have a blank stage meaning '단계 미상' not '진행 없음'. These are genuinely useful data-quality and scope caveats. However it does not describe result ordering or how paging interactss with the filters, so it is strong-but-not-exhaustive.

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 capability and caveats, and mostly dense with no filler. The one inefficiency is the near-duplicate opening line ('[유료] 서울시 정비사업… 목록을 조회한다' repeated as '…목록 — 사업명·유형…'), which costs a 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 takes on the job of describing returns (사업명·유형·진행 단계·위치) and pre-empts the obvious failure modes (fabricating null household/completion values, misreading blank stage, answering for non-Seoul regions). For a 7-param read tool with annotations already covering safety, 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 coverage is 100% and the schema already maps every enum (stage, project_type) and alias (region/sigungu), so the description's restatement of the filterable fields adds little new meaning. Baseline 3 applies when the schema carries the parameter burden; no extra semantics or format hints are supplied.

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 enumerates the returned fields (사업명·유형·진행 단계·위치). It names the sibling it does NOT cover — realty_reconstruction for 유망도 점수 and realty_member_transfer_check for 승계 — so an agent can distinguish it 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 concrete triggering questions ("○○구 재개발 어디까지 진행됐어?", "면목동 재개발 어디 있어?"), states the filter dimensions (region/dong/project_type/stage), and explicitly limits scope ('타 시도는 이 도구로 답할 수 없다고 밝혀라'). It also routes two adjacent intents to their correct tools, which is full when/when-not/alternative coverage.

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 read-only/idempotent safety profile, and the description adds substantial behavior the schema cannot convey: inputs are declared and unverified by the server, the formula is common practice rather than statutory, 비례율 keeps changing until completion, and the caller must relay the response's sensitivity and disclosures. This is exactly the added context the annotations leave open.

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 purpose and formula, then numbered boundaries; every section carries real information. Slightly verbose with the title/description overlap and the ①②③ scaffolding, but no padding sentences.

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 return burden and does so by naming the sensitivity and disclosures fields. Combined with the formula, the declared-input caveat, the volatility warning, and sibling routing, an agent has everything needed to call and present 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 schema already documents each parameter, including optionality of 비례율 and the fallback to the three project-total inputs. The description's formula shows how parameters combine into output, but adds no syntax, units, or edge-case detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and two concrete outputs (권리가액, 추가 분담금) and gives the exact formulas that produce them. It also differentiates from siblings by routing formula provenance to realty_policy_rules(topic=redevelopment_rules) and eligibility questions to redevelopment_entitlement.

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 this tool answers ("감정평가 3억에 비례율 98%면 얼마 더 내?") and gives concrete when-to-use-elsewhere rules: go to redevelopment_rules for the formula source, redevelopment_entitlement first if sale eligibility is uncertain. It also warns that results are unstable before 관리처분인가.

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, so the description's job is extra behavior — and it delivers: it discloses a hard rejection (region_ambiguous with exact-token candidate list), a silent-unit-mismatch rejection, the warning_pyeong_fallback for rental+pyeong, contract-cancellation exclusion, a 30-day reporting lag making post-cutoff windows incomplete, and change-rate suppression below 3 transactions.

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 axis positioning, and bold section headers help, but the entry is very long for a description and includes change-log noise (tester-proposal dates, ticket IDs like T-2026W34-352, and an S364 meta-explanation of why field names are omitted) that does not help an agent select or call the tool.

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

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

For an 11-parameter tool with no output schema, the description still tells the agent what comes back where — monthly_trend composition, by_dong cells and the 3-sample floor, top_transactions fields, compare_from before/after blocks, footnotes — plus the window definition, so nothing critical to correct invocation is missing.

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

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

Schema description coverage is 100% and the schema's own parameter descriptions already carry the unit-conversion, top_n-vs-aggregate, by_dong, and compare_from semantics; the prose largely restates them. It adds only marginal framing (e.g., '강남구 신고가 상위 5개' as the trigger phrase for top_n), 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?

States a concrete verb+resource+scope (지역 아파트 실거래 월별 시세 추이) and explicitly positions itself within a named family of three market-price tools. It distinguishes itself from realty_area_price_bands (level vs trend), realty_search_complexes (complex-specific questions), and realty_complex_rent_by_pyeong (pyeong-level rent) by name.

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 routing: use this for monthly direction/trend, bands for price level, search_complexes for a named apartment, complex_rent_by_pyeong when pyeong-level rent is needed, and move_in_supply for 전세 reversal context. It even states which tool to combine with, leaving nothing 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?

Goes well beyond the readOnly/idempotent annotations: it discloses the minimum-5-transaction rule, that the latest month may be mid-aggregation, that transit/school are suspended since 2026-09-26 with a reason (86.7% scoring 90+ ⇒ no discrimination), and the same-pyeong cell-matching method for investment. This is exactly the operational context annotations cannot carry.

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

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

Dense but front-loaded: purpose, then usage questions, then per-metric caveats, then routing. Each sentence carries distinct information, though the opening two lines restate the same purpose and could be merged. No filler beyond that.

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 the description compensates by explaining that responses carry a methodology/footnotes payload and that methodology should be reflected in answers. For a 5-param ranking tool this is close to complete; only minor gaps (pagination, exact row shape) remain.

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 — metric-specific definitions (volume-weighted exclusive pyeong price, fixed 60-85㎡ YoY to remove unit-mix distortion, cell-paired jeonse ratio) and the region parameter's dual behavior (시도 vs 시군구). It stops short of explaining order/limit, but the metric semantics materially exceed the enum text.

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 enumerates the axes (price/growth/investment). It explicitly separates itself from realty_compare_regions, realty_rental_yield, and realty_location_scores, 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?

Gives concrete triggering questions ('제일 비싼 동네 어디야?', '전세가율 높은 곳은?'), states when NOT to use it (two-target comparison → realty_compare_regions) and where to go for suspended axes (realty_location_scores for 교통/학군). Explicit when/when-not/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?

Beyond the read-only/idempotent annotations, it discloses meaningful operational behavior: cancellations and direct deals are excluded, building/floor composition within a complex is not corrected, and thin baskets make the value untrustworthy. It also tells the agent the response contains naive vs basket side by side and how to interpret the gap via composition_effect.

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 definition and scope are front-loaded in the first sentence, followed by a rationale, output description, and caveats with bold labels that make skimming easy. It is somewhat long and the limitation sentence runs several clauses together, but each block carries distinct information rather than repetition.

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 six-parameter analytical tool with no output schema, it covers the essential ground: what is computed, the data exclusions, the known unmodeled variance, and the named output fields (naive, basket, composition_effect, footnotes). The response shape is only sketched rather than specified, which is a modest gap given there is no output schema to fall back on.

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 interpretation the schema does not: values are per-pyeong so pyeong-mix shifts inside a complex are absorbed, and narrowing pyeong_supply thins the basket and erases the tool's advantage, prompting the agent to check the returned complex count. Parameter mechanics themselves are still left largely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific, non-obvious operation: computing a regional price trend restricted to the same complexes that transact in both comparison windows, returning naive and basket values plus a composition_effect. It conceptually separates itself from the naive 'old monthly average' trend approach, but never names the actual sibling tool (e.g. realty_region_price_stats) that an agent would otherwise reach for, leaving the routing decision partly inferential.

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 context for when this tool is the right choice: when the sample is thin enough that composition churn dominates the regional average (illustrated with the 2026-08-14 Yongsan incident). However, it states no explicit exclusions and names no alternative tool for the cases where a plain average is fine.

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, openWorld), and the description goes far beyond them: it discloses per-layer coverage rates (100% normative vs 11.2% structure-type mentions, 0% for completed apartments), warns that 'unknown' is not 'no', and states that coverage plus how_to_find_out always accompany the response. This is unusually 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?

Heavy but front-loaded: the two-axis framing and the 'model is confidently wrong here' hook come first, followed by coverage facts and the unknown-handling rule. The dense archive statistics earn their place by calibrating trust, though a few sentences could be tightened.

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 comes back (two layers, embedded coverage, how_to_find_out) and how to relay it. Nothing an agent needs to call this 3-parameter, zero-required 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 baseline is 3; the description adds meaning about how axis maps onto the two analytical layers and what an empty complex_name yields (normative-layer-only answer with its own validity). It reinforces rather than merely repeats the schema's parameter text.

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 judgment task (can this apartment be altered, on a wall axis and a plumbing axis) with the concrete questions it resolves. It differentiates itself from siblings by naming realty_policy_rules (full statute text) and realty_presale/realty_notice_facts (house_manage_no source), though the boundary with realty_policy_rules is slightly blurred since the normative layer's full text is said to live there.

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?

Lists the exact user questions it answers and explicitly says complex_name may be omitted (normative-only answer). It adds a negative rule (do not infer structure type from completion year) and directs the agent to how_to_find_out when values are missing, but offers no explicit 'use sibling X instead when Y' routing for the general case.

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), yet the description adds the critical behavioral fact that the default response is truncated to the latest complete month, sorted by yield descending, and is NOT the full period or region — with the pointer to check the truncated field. That is exactly the kind of default-scope disclosure an agent needs to avoid misreading 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?

Three short sentences with zero padding; the core capability comes first, then the truncation caveat, then the override for a specific month. Front-loaded and every sentence carries 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?

With no output schema, the description still explains the shape of the default result (one latest complete month, yield-descending, truncated flag) so the agent can interpret returns. Minor gaps remain around non-default behavior and region coverage limits, keeping it from 5.

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 still adds value by tying year_month to the default (latest complete month) and explaining why the default result set is limited. Parameter-level detail (limit, region, pyeong_supply) is left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (조회) and concrete resource: 시군구별 월세 수익률, 평균 매매가, 평균 월세, plus the intended job (수익형 투자 스크리닝). It does not explicitly differentiate itself from nearby siblings such as realty_region_price_stats or realty_region_rankings, so it lands at 4 rather than 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 clear context for use ('수익형 투자 스크리닝용') and tells the agent how to widen scope ('특정 월은 year_month로 조회하라'). No named alternatives or explicit when-not guidance, so it stops short of 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 readOnly/idempotent/non-destructive, but the description adds substantial non-obvious behavioral context: past-기일 rows are mixed into the list, `sort=date_asc` lets them occupy the front (60.7% measured), empty `items` with `has_more=true` does not mean no matches, and `min_bid_source` distinguishes authoritative `court_schedule` values from potentially stale `item_list` values. It also warns against blending court-auction and onbid ledgers.

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 purpose, then sibling routing, then caveats under bold headers, so the important routing information is reachable immediately. It is long and carries some date-stamped statistics that could age, but nearly every sentence is a substantive correctness warning 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?

For an 11-parameter, open-world search with no output schema, the description covers the return surface an agent needs: `past_auction_note`/`past_auction_count`, `min_bid_source`/`min_bid_note`/`min_bid_stale_risk_count`, `has_more`/`next_offset`, and the note field that disambiguates the two empty-page cases. Nothing required to call or interpret the result 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-parameter behavior the schema does not: the interaction of `offset` with `exclude_past` (server skips the past prefix, reported via `meta.past_prefix_skipped` vs. `requested_offset`), the unit convention for 감정가 (만원, 5억=50000), and the relationship between `min_bid_count` and falling 최저입찰가.

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 with its filter axes ('법원경매 물건을 지역·종류·감정가·유찰횟수로 필터링해 조회한다'), and explicitly contrasts itself with `search` (value-known vs. natural-language), `realty_get_auction_case`/`fetch` (detail retrieval), and `realty_search_onbid` (공매). An agent can route among these without opening a single 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 and when-not-to-use: this tool when conditions are already known as values, `search` when the user only has a free-text line, detail tools for per-case info, onbid tools for 공매. It also names the exact trigger for `exclude_past=true` ('지금 살 수 있어?' questions) and points 발굴 questions at `realty_auction_alerts`.

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/non-destructive, yet the description adds substantial extra context: null semantics (미상 ≠ 소규모), which params filter search vs only affect price calculation, meta fields reporting exclusions (households_scope, price_year_scope, coverage), the composite vs composite_legacy scale change, and explicit warnings not to rank complexes by the facility-count scores. This is far beyond the annotation baseline.

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?

Purpose and axis placement are front-loaded and bold headers aid scanning, but the text is extremely long with repetitive warnings and restated caveats (the unit_price page-only caveat and the 미상≠저회전 point recur). For a 13-parameter tool some length is justified, yet several sentences could be trimmed without losing meaning.

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, yet the description documents the response shape thoroughly: prices_by_area, pyeong_exclusive vs pyeong_supply_est, per-row scores, complex_key hand-off, nearest_station/subway_distance_m, turnover fields, and the sort_applied/coverage/meta transparency fields. For a tool of this complexity the description leaves no material gap 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, but the description adds genuine meaning the schema lacks: that area_band_m2/construction_year_band affect only price computation and do not filter the result set, the year vs year_asc inversion pitfall, that max_trade_price_10k is judged by minimum in-window trade rather than average, and that sort='unit_price' is page-scoped. These are cross-parameter behaviors the per-field schema text does not fully convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (검색) plus resource (아파트 단지) and explicitly names the return payload (평형별 실거래 시세). It further distinguishes itself from siblings by naming realty_region_price_stats and realty_area_price_bands as the wrong tools for complex-level questions. An agent can identify this as the primary complex-level price tool 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?

Explicitly routes between this tool and its three nearest alternatives: region average tools for area-level questions, realty_complex_pyeong_price for floor-band questions, and realty_redevelopment for 정비사업. It gives a concrete selection rule (complex specified → this; area trend → the others) plus a motivating stat (24% spread). 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 read-only/idempotent safety, but the description adds substantial behavioral context the annotations cannot: rows are bidding rounds (not items) folded per item, the returned fields (rounds_total/rounds_remaining/next_round/last_round), null-vs-0 for undisclosed minimum bids, address masking on seized property, and the sido normalization with sido_source/sido_basis. Some of this shades into output-shape detail, but it is genuinely useful 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?

Front-loaded with the core purpose and organized with bold headers and ⚠️ markers so an agent can scan. However it is lengthy for a search tool, and the court-auction exclusion plus the `not_court_auction` directive are stressed twice, which is slight 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?

No output schema exists, yet the description names the key return fields (condition_rows, rounds_*, not_court_auction) and three data-quality caveats (undisclosed prices, masked addresses, sido normalization), and explicitly states what is absent (권리분석, 감정평가서, 공고 원문) plus which sibling's answers must not be transplanted. Complete for an 11-param filter tool.

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

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

Schema description coverage is 100%, so the baseline is 3; the description nevertheless adds framing beyond the schema — that 재산구분 is 'the most important axis' whose categories differ in legal nature, that a single cltr_mng_no lookup IS the detail view returning per-round schedules, and that open_only is bypassed by cltr_mng_no. It reinforces rather than replaces the schema, so not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.