korea-realty

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds critical behavioral context: the id format, the output contains full case details, and a crucial warning about not fabricating rights analysis when the rights field is absent. This adds significant value beyond annotations.

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

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

The description is three sentences with no wasted words. The first sentence states the primary purpose, the second gives the id format and a crucial caveat, the third provides a behavioral guideline for interpreting results. Every sentence earns its place.

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

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

Given there is an output schema (not shown but present), the description does not need to detail return fields. It covers the essential context: prerequisite (search), id format, and handling of the rights field. For a single-parameter tool, this is complete and sufficient.

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

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

The schema has no description for the 'id' parameter (0% coverage). The description provides essential semantics: the id format ('법원명|사건번호') and warns that without the court name the result may be a list of candidates. This fully compensates for the lack of schema description.

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

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

The description clearly states the tool fetches the full content of an auction case using an id from search. The verb '가져온다' and resource '경매 사건의 전체 내용' are specific. It differentiates from sibling 'search' by referring to its id, establishing a clear sequential relationship.

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

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

The description explains when to use the tool (after search, with the id) and provides the id format and a caveat about omitting the court name leading to multiple candidates. It also includes handling instructions for the rights field. However, it does not explicitly mention alternatives or when not to use.

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

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

Despite readOnly/idempotent annotations already present, the description adds meaningful behavior: outlier filter (P75의 50% 미만 제외), difference from realty_region_price_stats, and the priority rule '수준이 갈리면 이쪽을 우선하라'. It also clarifies the pyeong type (전용평 vs 분양평), which is not in annotations.

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

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

The description is dense but well-structured with bold section headers and bullet-like separation. No sentence is redundant; each adds purpose, usage context, or conversion guidance.

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

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

For a read-only query tool with output schema and rich annotations, the description covers the core scenario, filtering behavior, sibling relationships, and unit interpretation. The by_dong example with real observed range (마포구 6개월) further grounds expected output.

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 fields are well-documented. The description further enriches parameter interpretation by defining the four bands and providing an approximate conversion from 전용평 to 분양평, which helps users reason about region and by_dong results.

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

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

The description clearly states the tool queries regional sale prices in four pyeong bands (소형/중소형/중형/대형) using '조회한다'. It also distinguishes itself from realty_search_complexes and realty_region_price_stats, making the purpose unmistakable.

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

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

Explicit usage guidance is provided: typical question type, default choice for regional price level comparison, preference rule when results differ from region_price_stats, and explicit alternatives for trends or specific complexes. The by_dong parameter description adds additional when-to-use context.

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

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

Even though annotations already declare readOnly/openWorld/idempotent, the description adds important behavioral context: many failed auctions can indicate cheapness but also hidden problems ('권리관계·물건 하자 등 팔리지 않는 이유'), results should not be treated as recommendations, and the same property may appear in the sibling tool so counts should not be summed. No contradiction with annotations.

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

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

Three short, front-loaded paragraphs: first states the core purpose, second gives an important interpretative caution, third provides the sibling comparison. Every sentence earns its place, and the bold sibling section is scannable without bloat.

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

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

Given the output schema and annotations cover return values and safety, the description supplies the missing strategic context: when to prefer this tool, how to narrow queries, the caution about candidate status, and the overlap warning with realty_search_auctions. It is fully complete for an agent to select and invoke 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 86%, so the schema already documents most parameters well, including max_discount_pct guidance about extreme discounts. The description adds some usage-level direction (narrowing with sido/sigungu, extreme discount cutoff considerations) but does not substantially enrich individual parameter meaning beyond what the schema provides.

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

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

The description opens with a specific verb and resource: '유찰이 누적돼 최저입찰가가 크게 떨어진 물건을 찾는다' (finds properties with accumulated failed auctions and sharply lowered minimum bids). It clearly distinguishes itself from the sibling tool realty_search_auctions by framing its purpose as candidate discovery for large discounts rather than general filtered listing.

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

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

Provides explicit when-to-use vs alternative guidance: '조건 필터·목록이 목적이면 그쪽, 저감 큰 후보 발굴이면 이쪽' (if filtering/listing is the goal, use realty_search_auctions; if discovering large-discount candidates, use this). It also instructs narrowing with sido/sigungu and advises presenting results as candidates needing verification, not recommendations.

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

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

Discloses many behavioral traits beyond annotations: photos exist only as preserved snapshots because the court source removes them after the date; empty tracking/price_events doesn't mean no change; rows without min_bid have kind_note and aren't bidding dates; min_bid_source may be stale. This richly supplements the readOnly/openWorld annotations with actionable data caveats.

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?

Though long, every sentence earns its place: the first sentence states the core function, the example questions anchor intent, and each subsequent sentence adds critical data-quality or interpretation warnings. Bold formatting and line breaks make the density navigable.

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

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

For a tool with this many data-source caveats (court_schedule vs list vs tracking), the description is remarkably complete: it explains result nulls, kind_note, fail_count_note, snapshot empty semantics, current_min_bid_10k staleness, and the authoritative source hierarchy. Output schema covers the return structure, so no further return documentation is needed.

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

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

Schema descriptions cover 0% of parameters, and the description doesn't explain case_no or court_name at all. It focuses entirely on output field semantics. The required parameter's format and the optional disambiguation role of court_name are left implicit, failing to compensate for the schema gap.

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

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

The description opens with a specific verb+resource: queries the auction case's failed bid history (per-date minimum bid reduction time series), price change events, and photo URLs. The example questions ('How many times did it fail? How much did it drop? Are there photos?') and the '담당 도구' phrasing clearly distinguish it from siblings like realty_get_auction_case or realty_search_auctions.

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

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

It explicitly claims responsibility for the '몇 번 유찰됐어?' style questions and provides extensive interpretation rules: null result rows should be relayed as-is, fail_count_note explains discrepancies, and court_schedule is the authoritative source. However, it doesn't name alternative tools for when this tool isn't appropriate, so it misses explicit 'when not to use' guidance.

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

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

Annotations already declare read-only/idempotent, but the description adds valuable behavioral context: backend silently ignores unsupported date-range parameters, '빌라' is auto-mapped to '다세대' to avoid sample distortion, and the '면적 미상' band represents missing area data, not zero. These details go well beyond the annotations and prevent misuse.

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

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

The description is long but front-loaded with the core purpose, and every section adds essential operational detail (e.g., the empirical stats for area_band, the mapping caveat, and the comparison with the sibling tool). Minor redundancy could be trimmed, but the density is justified by the tool's complexity.

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

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

Given the tool's 5 optional parameters, output schema, and annotations, the description covers all necessary context: output fields (sample_period, by_fail_count, by_area_band), parameter usage, known backend quirks, and distinction from a closely related sibling tool. It is complete enough for an agent to select and invoke the tool correctly.

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

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

With only 20% schema description coverage, the description compensates substantially for area_band (explains the by_area_band breakdown, warns against mixing area bands, and clarifies the 'missing' band) and usage_name (auto-mapping behavior). However, bid_count_max is not explicitly explained in the description, though it is indirectly related to the output field by_fail_count.

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 clearly states the tool's purpose: answering 'what percentage of the appraisal value does a property in this area/type typically sell for at auction' using actual sale results. It further distinguishes itself from realty_compare_auction_vs_market by specifying the denominator (감정가 vs 시세).

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

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

The description explicitly positions this as the key metric for setting bid prices and contrasts it with realty_compare_auction_vs_market for market-price comparisons, warning not to mix the two. It also gives specific usage rules: use area_band when the unit size is known, use usage_name='연립주택' for row houses, and include sample_period when answering 'recent' 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 and idempotentHint, but the description adds crucial behavioral context: all inputs are declared and the server does not adjudicate facts (e.g., holding period start, number of houses, regulated area). It discloses that it does not handle 1-household-1-home exemption, high-priced home apportionment, or special deductions, and that results assume full taxation. It also warns that pending 2027+ legislation can flip results and that the response includes traps, pending_legislation, and disclaimer.

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

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

The description is well-structured: the first paragraph states purpose and use cases, the second defines boundaries with numbered points and bolded keywords. Every sentence carries meaningful information, and the length is appropriate for the tool's complexity. No redundant or vague wording.

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?

It covers all necessary context: what the tool does, when to use/not use, exclusions, truth sources, legislative risk, and required response elements. With an output schema present, return-value details are not needed. For a 14-parameter calculator with scenario comparison, this description is complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the deterministic algorithm, the second-asset comparison (same-year combined vs split-year vs loss-offset), and the share_pct nuance that each co-owner must call separately with their own share. This enriches the agent's understanding of how parameters like asset2_* and share_pct work together beyond the schema.

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

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

The description states exactly what the tool does: it deterministically applies the capital gains tax rate table to declared transfer/acquisition/expenses/holding period, including standard/short-term/presale rates, long-term holding deduction, basic deduction, multi-home surcharge, and 10% local tax. It also explains the second-asset comparison scenario and explicitly differentiates itself from realty_policy_rules, which is the truth source for rules.

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

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

The description gives clear when-to-use questions ('지금 팔면 양도세 얼마?', '두 채를 올해 같이 팔까 나눠 팔까?') and a clear when-not-to-use condition: if a tax exemption is possible, the agent should not use this calculator and instead guide the user to HomeTax or a tax accountant. It also names alternative tools: realty_policy_rules for original texts and topic=regulated_area for designation status.

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

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

Annotations only declare safe read-only/idempotent behavior, but the description adds rich behavioral details: default filtering to future auction dates, exact matching with normalized addresses, 50–150% appraised value filter, area-matched baseline calculation (±10%), null behavior for discount_vs_market_pct, warning about min_bid_source and stale minimum prices, and the 2–4 second latency. This goes far beyond what annotations provide and sets clear expectations.

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

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

The description is lengthy but every paragraph delivers critical caveats, default behaviors, and sibling comparisons. It is well-structured with line breaks and bold emphasis, and front-loads the core purpose. The historical fix dates (2026-08-08, 2026-08-16) add credibility but could be considered slightly extraneous; still, they explain why current behavior differs from past flaws.

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

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

Given the tool's complexity (7 parameters, output schema, annotations), the description is highly complete. It covers output signals, null handling, edge cases (unsold items, area mismatch), denominator differences with related tools, performance trade-offs, and manual alternative workflows. The presence of an output schema means return values need not be repeated, and the description fills all major contextual gaps.

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 43%, and the description adds meaningful parameter relationships: court_name must be used with case_no due to non-unique case numbers, include_past defaults to false and is ignored for case_no lookups, and limit is capped. However, sido/sigungu/usage_name are not explicitly elaborated in the description, though their names and defaults provide some self-evident meaning. The description partially compensates for the coverage gap.

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

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

The description opens with a specific verb and resource: '경매 물건의 최저입찰가를 같은 단지 실거래 시세와 대조해 할인율·표면수익률을 낸다' (compares auction minimum bid against same-complex market transactions, producing discount rate and surface yield). It further distinguishes itself from siblings by naming its role as the primary tool for '이 물건 싸?' (is this property cheap?) and differentiating from realty_auction_sale_rate and manual baseline tools.

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

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

The description gives explicit when-to-use guidance: use it first for auction price judgment ('이 축의 자리... 1차다'), combine with realty_auction_sale_rate for bid pricing but warns against mixing denominators, and suggests realty_area_price_bands/region_price_stats when manually setting baselines. It also explains default behavior (future dates only) and the slower performance, helping the agent decide when to call it.

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

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

The description discloses critical data quality caveats beyond the annotations: it warns that avg_price should not be treated as the region's market price because outliers are not filtered and complex-level data are mixed, and instructs reading warning_baseline and warning_dispersion first. This goes far beyond the readOnlyHint and idempotentHint annotations.

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

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

The description is well-structured and front-loaded with the main function, followed by usage guidance and a warning. Every sentence adds value, though it is slightly longer than necessary due to the warning's detail. The [유료] is repeated from the title, but this is minor.

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

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

Given the tool's complexity (data quality issues, alternative tools), the description covers purpose, usage, alternatives, and behavioral caveats. An output schema exists, so not explaining return values is fine. The warning about misinterpreting avg_price is essential for safe usage, making the description highly complete.

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

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

Schema description coverage is 100%: both parameters (regions and months) have clear descriptions in the schema. The tool description does not add additional parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool compares sale and jeonse prices and trends across multiple regions side by side, which is a specific verb+resource. It also explicitly distinguishes itself from realty_region_rankings, saying this tool is for when comparison targets are already decided, not for ranking/exploration.

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

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

The description provides explicit when-to-use guidance: use it for moving/investment comparison when targets are fixed, and not for ranking/exploration. It names the alternative tool (realty_region_rankings) and even clarifies that the alternative is free, implying this tool is paid. This is clear and actionable.

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

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

Even though annotations already declare readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial behavioral context beyond annotations: transactions are sorted by contract date descending, average/median are based on recent 5 transactions, outliers are kept with outlier=true, floor bands include *_ex_outliers values, and longer-named neighboring complexes are excluded with details in meta.complex_isolation. It even instructs how to treat unseparated areas. No contradictions with annotations.

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

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

The description is long, but every sentence earns its place. It is front-loaded with the primary purpose, uses bold for key terms, and is organized into logical paragraphs covering response structure, sorting/outlier semantics, complex isolation, and parameter usage. It is not concise in word count, yet it avoids fluff and maintains high information density, justifying a 4 rather than a lower score.

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

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

Given the tool's complexity (7 parameters, nuanced behaviors like outlier handling, floor band aggregation, and complex name isolation) and the presence of an output schema, the description is remarkably complete. It covers ordering, summary basis, outlier flags, floor band semantics, meta.complex_isolation behavior, parameter selection, and explicitly excludes rent transactions with a pointer to a sibling tool. No important behavioral aspect is left unexplained.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds selection guidance for the twin parameters pyeong_supply and pyeong_exclusive ('평수는 pyeong_supply(분양)·pyeong_exclusive(전용) 중 사용자가 쓴 쪽에 넣어라 — 하나는 필수'), which is not present in the schema. It reinforces the intent of the quoted_price parameters implicitly by stating the tool's purpose, but it does not add detail for every parameter; still above baseline.

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

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

The description opens with a precise statement: '특정 단지·특정 평형의 최근 6개월 매매 실거래를 건별(계약일·층·가격)로 조회한다.' It clearly identifies the resource (specific complex + specific area type), verb (조회한다), scope (6-month sales transactions), and granularity (per transaction). It also distinguishes from siblings by naming realty_search_complexes for summary needs and assigning floor-specific price questions to this tool.

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

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

Explicit when-to-use guidance is abundant: '평형별 시세 요약만 필요하면 realty_search_complexes의 prices_by_area로 충분하다' gives an alternative; '층별 시세 질문은 이 도구가 담당이다' clarifies responsibility; '이 도구는 매매 전용이다 — 전월세는 realty_complex_rent_by_pyeong을 쓴다' states exclusion and lists the correct tool for a different use 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 mark the tool as read-only, idempotent, and non-destructive. Beyond that, the description adds key behavioral context: the supply_pyeong row key definition using the 분양평 formula, the server-side calculation of jeonse rate when compare_sale is enabled, and the historical note about corrected window alignment. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose, followed by concise usage guidance and a precise definition of the pyeong key. Every sentence carries meaningful information with no redundancy or filler. The formatting (line breaks and bold) improves scannability.

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

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

Despite being a moderately complex tool with a rich output schema, the description covers what the tool does, the critical constraint about key identification, the meaning of the pyeong key, and the optional compare_sale behavior. No critical information is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100% for all three parameters, so baseline is 3. The description enriches this by stating that at least one of complex_key or complex_name is required (not enforced by schema), clarifying the partial-match risk, and explaining the supply_pyeong key's meaning. This adds practical semantic value beyond the schema.

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

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

Description opens with a specific verb and resource: '단지의 평형별 전세 보증금·월세 중앙값을 조회한다.' It clearly states the scope (by pyeong type) and explicitly frames the tool as the jeonse axis for jeonse rate calculation, distinguishing it from sibling price tools like realty_complex_pyeong_price.

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 instructions are given: one of complex_key or complex_name is required, and the description recommends using realty_search_complexes to obtain the exact complex_key first, warning about partial-match ambiguity. This directly guides when and how to use the tool vs. the recommended alternative.

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, openWorldHint, idempotentHint, and no destructive behavior. The description adds valuable context about the output containing coordinates and complex_key, and integrates multiple data types, which is useful beyond the annotations.

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

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

Two concise sentences: first states purpose, second provides actionable output and usage chain. No redundancy, front-loaded, every sentence earns its place.

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

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

With an output schema present, the description doesn't need to detail return values. It provides helpful hints about output fields (coordinates, complex_key) and a follow-up workflow. Could mention what 'basic info' includes, but overall sufficient for the tool's complexity.

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

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

Schema description coverage is 100% with both parameters documented. The description does not add further meaning about parameter usage or constraints (e.g., whether name or complex_key should be provided). Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the verb '조회한다' (inquiry) and resource '단지 통합 리포트' (complex integrated report), specifying it provides market price, jeonse, and basic info. This distinguishes it from sibling tools that focus on specific aspects like region prices or auction history.

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 instructs the agent to use the output coordinates and complex_key in subsequent tools (realty_poi_nearby and realty_predict_price) for deeper analysis. This provides clear sequential guidance, though it does not explicitly contrast with 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?

The description goes beyond annotations by disclosing data freshness (meta.data_as_of), year-series dating, and the households/naming defect. Annotations already mark it read-only and idempotent, but the description adds operational context.

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

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

The description is concise, but slightly dense. It packs key warnings into a few sentences, which is efficient, though a bullet list could improve readability slightly.

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

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

The description covers all essential aspects: data freshness, metric-specific constraints, error handling suggestions, and usage alternatives. With an output schema present, no further details are needed.

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

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

The description enriches each parameter: metric values are spelled out, region constraints are detailed (age only at 시도 level, households issues), and months scope is clarified. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool queries regional demographics with example questions and lists four specific metrics. It distinguishes itself from sibling tools (focused on real estate prices, auctions, etc.) by its demographic scope.

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

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

The description provides explicit guidance on when to use the tool (demographic queries), warns about data timeliness and regional naming issues, and advises alternative metrics when data is unavailable (e.g., households rejecting 동명 시군구).

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

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

Despite strong annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), the description adds substantial behavioral context beyond that: duplicate resolution behavior, rights field semantics (null means not collected, include disclaimer), claim_amt_10k meaning as creditor's claim not tenant deposit, and min_bid_source staleness implications. This rich context goes far beyond what annotations convey and does not contradict them.

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

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

The description is dense but every sentence contributes essential caveats or clarifications. It is front-loaded with the core purpose, followed by a critical duplicate warning, then field-level semantics, and a sibling pointer. Its length is justified by the tool's complexity, though it could be slightly tightened without losing 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 an output schema present and strong annotations, the description focuses on the gaps: it explains the meaning of key fields (rights, claim_amt, min_bid_note), warns about missing data (no deposit amount), and tells the agent how to handle null rights (never fabricate). This ensures the agent can confidently use the tool and interpret results correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains court_name's disambiguation role and the consequences of omitting it. case_no is inherently clear from the tool purpose, but no explicit format or examples are given. The description adds meaningful semantic value for the less obvious parameter, making this a strong but not perfect compensation.

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

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

The description opens with a specific verb+resource statement: 'Retrieves auction case details by case number.' It also clearly distinguishes itself from related tools by explicitly stating that auction history, bid reductions, and photos are handled by realty_auction_history. This makes the tool's purpose unambiguous and differentiates it from its siblings.

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

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

The description provides explicit when-to-use guidance and critical usage constraints: it warns that case numbers are not unique across courts, instructs callers to specify court_name to avoid duplicates, and describes the fallback error behavior when court_name is omitted. It also explicitly directs history-related queries to realty_auction_history, offering a clear alternative.

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?

Description adds the disclaimer requirement beyond annotations, which already indicate read-only and non-destructive behavior. However, it does not mention the paid nature explicitly (though title does) or return value format.

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

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

Two sentences: first states purpose concisely, second gives critical instruction. No wasted words; front-loaded with key 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 simple one-parameter tool with good annotations and an output schema, the description is mostly complete. It might benefit from explaining the paid nature, but the title covers that. adequately covers core behavioral and usage constraints.

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

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

Schema coverage is 100%, so baseline 3. The description adds no additional meaning to the 'region' parameter beyond what the schema provides (string, example).

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

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

Description clearly states the tool scores investment risk of a region on three specific axes (volatility, liquidity, supply pressure), distinguishing it from sibling tools like realty_location_scores and realty_rental_yield. The verb 'scores' and resource 'risk' are specific.

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?

No explicit guidance on when to use this tool vs alternatives. The description lacks context about ideal scenarios, prerequisites, or exclusions, relying solely on the tool's name and title to imply purpose.

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

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

Beyond the read-only/idempotent annotations, the description discloses that homes_owned, is_first_time, and is_newlywed are user declarations not verified by the server, and that limit calculation is intentionally excluded for certain purposes. This adds valuable behavioral context without contradicting the annotations.

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

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

The description is structured with a bold lead sentence, a rationale paragraph, and numbered boundary points. It is somewhat long but each section adds necessary context for a complex domain, and the front-loaded purpose statement ensures quick understanding.

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

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

Given the complexity (8 parameters, many sibling tools, output schema with topic references), the description is complete. It covers what the tool does, what it does not do (limit calculations), where to find rule details, and the declarative nature of key inputs, making it sufficient for an agent to invoke 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. The tool description reinforces the three core inputs (purpose, region, homes_owned) and frames them as the minimal conditions for eligibility matching. While it doesn't detail each parameter, it does add semantic grouping and routing logic that complements the schema.

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

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

The description clearly states the tool's function: listing usable loan products ('쓸 수 있는 대출을 상품별로 나란히 낸다') and acting as a router across 7 product topics. It specifies the key inputs (purpose, region, homes_owned) and contrasts with realty_loan_limit, making the purpose unambiguous and distinct from siblings.

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

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

The description explicitly explains when to use this tool versus realty_loan_limit (limit calculation only for purchase loans), and states exclusions for jeonse/mid-payment/jeonse-return limit calculations. It also instructs the agent to read product topics for rule details, providing clear context and alternatives.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description reveals critical behavioral traits: the server does not verify borrower type (echoed in inputs_declared), the output is a regulatory cap not a commitment, the default '변동' rate_type yields the most conservative DSR result, and uncertainties/disclaimer must be passed to the user. These details significantly affect interpretation and align with the openWorldHint.

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

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

The description is well-structured: an opening bolded summary, then numbered boundary conditions, and references to sibling tools. It uses formatting marks (bold, newlines) to enhance scannability, and every sentence carries actionable information with no redundancy, making it both concise and comprehensive.

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

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

Given the tool's complexity (15 params, multi-factor calculations, output schema), the description covers the core purpose, key output components, binding constraint logic, rate_type sensitivity, explicit links to other tools, and instructions to forward uncertainties/disclaimer. It also clarifies that the result is deterministic and not a loan approval, which is essential for correct usage.

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

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

The input schema covers 100% of parameters with rich descriptions (e.g., rate_type's stress rate impact, credit_loan_10k calculation pitfalls, region ambiguity). The tool description itself only summarizes key inputs (지역·시가·차주 유형·소득) and references rate_type behavior already present in the schema, adding minimal new parameter-level semantics beyond the baseline for high schema coverage.

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

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

The description clearly states the tool computes mortgage loan regulatory upper limits (LTV cap, price band limits, maturity cap, stress DSR max, binding regulation) based on declared conditions. It gives an example question ('10억 집, 생애최초, 연소득 8천이면 얼마까지 나와?') and explicitly distinguishes itself from sibling tools like realty_policy_rules and 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?

The description explicitly says '이런 질문의 자리다' (this is the place for such questions) and provides clear boundaries: borrower type is a declaration, the result is not an approval, DSR depends on rate type, and if the user hasn't chosen a product, present the by_rate_type comparison table. It also directs users to alternative tools for rules (realty_policy_rules), regulated area info, and presale funding plans.

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

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

Beyond the readOnly/idempotent/non-destructive annotations, the description reveals important behavioral traits: the school score is a screening indicator with a city-unit data bias, subway_distance_m is straight-line not walking distance, unscored complexes return not_found, and returned complex_key is normalized to a single space. No contradiction with annotations.

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

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

Every sentence delivers operational value: purpose, modes, data caveats, distance interpretation, not_found behavior, verification pointer, key normalization, and alternative tool. The line breaks and bullet-like structure improve readability without unnecessary verbosity.

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 straightforward read-only lookup with rich annotations and an output schema, the description covers purpose, parameter usage, data limitations, error semantics, and cross-tool relationships. There are no major gaps that would prevent an agent from correctly selecting and invoking the tool.

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

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

Schema descriptions cover all three parameters (100% coverage), so the baseline is 3. The description adds value by explaining the interplay of complex_key/complex_name versus region-only usage and notes the normalized complex_key output for reuse in other tools, but it does not overspecify syntax.

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

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

The description explicitly states the tool retrieves school district (v5) and transportation (subway/bus) scores for a complex, and it distinguishes between mode when complex_key/complex_name is provided versus region-only aggregate/top-5 results. It also sets itself apart from sibling realty_poi_nearby by clarifying the overlapping use case.

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

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

The description gives clear guidance on when to use this tool: for scores and screening (free) versus realty_poi_nearby (paid) for actual nearby facility lists/distances. It also explains the region/complex parameter conditions and instructs to verify complex existence via realty_search_complexes before treating not_found as definitive.

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

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

The description discloses a critical behavioral trait: series freshness varies, and meta.series_as_of must be checked. It gives specific examples (Korean base rate and KOSPI are stuck at 2024-12, while US Fed rate and S&P are current) and warns against citing stale series as current. This goes far beyond the readOnly/openWorld/idempotent annotations.

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

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

The description is compact and front-loaded: a one-sentence purpose, a one-sentence usage context, and a concise but essential freshness warning. Every sentence earns its place; 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 an output schema present, the description does not need to explain return values. It covers the purpose, usage context, and the most important caveat (per-series data freshness via meta.series_as_of). This is ample for an agent to select and invoke the tool correctly.

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

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

The input schema already provides 100% description coverage for both parameters: months ('최근 몇 개월치') and indicators (listing all valid values with units). The tool description does not add additional parameter semantics, so 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 clearly states the tool's function: '한국 기준금리·KOSPI·M2, 미 연준금리·S&P500 등 거시 지표의 월별 시계열을 조회한다' – a specific verb (조회한다) with a specific resource (monthly time series of listed macro indicators). It distinguishes itself from sibling realty-specific tools by focusing on macro background data.

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

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

The description provides clear context for when to use this tool: '금리가 집값에 어떤 영향?'류 배경 분석용 (for background analysis on how interest rates affect housing prices). However, it does not explicitly name alternatives or exclusions, though as the only macro indicator tool among siblings, the context is sufficient.

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

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

The description does not add behavioral details beyond the annotations, which already declare readOnlyHint, idempotentHint, and destructiveHint. It mentions 'at once' but lacks specifics on data freshness, rate limits, or side effects. No contradiction with annotations.

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

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

The description is concise with two sentences: first stating the function, second stating the application. It includes the '[유료]' label, which is important context. No unnecessary details, but slightly more explanation of the return could improve completeness.

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

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

Given the tool has an output schema (unseen but present) and two optional parameters, the description covers the basic purpose. However, it does not clarify what 'unsold trends' or 'market sentiment indices' refer to, leaving some ambiguity about the data content. Annotations compensate partially.

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% for the two parameters (months, region). The tool description does not add meaning beyond the schema; it focuses on output content rather than parameter usage. Baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves unsold inventory trends and market sentiment indices, using the verb '조회한다' (view/retrieve). It identifies the specific resources and mentions its use for purchase timing, which provides purpose clarity. However, it does not explicitly distinguish itself from the many sibling tools, though its focus on macro signals implies differentiation.

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

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

The indication that it's a 'macro signal for purchase timing' gives a usage context. However, there is no explicit guidance on when not to use this tool or mention of alternatives among the many sibling tools, leaving the agent to infer usage scenarios.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive; description adds significant behavioral disclosures: '사업지연 예외 3종은 인가일·착공일 데이터가 없어 판정 불가를 실토한다', the 재개발 부칙 trap, and the instruction '응답의 exceptions·disclosures를 함께 전하라'. No contradiction with annotations.

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

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

Though long, the description is front-loaded with the core decision question and organized into numbered boundary points. Each segment (purpose, limitations, traps, related tools) earns its place for a legally complex tool, avoiding unnecessary fluff.

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

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

The description covers the primary use case, legal caveats, data-source limitations, alternative tools, and even response handling expectations. For a tool with high legal complexity and an existing output schema, this is complete and self-contained.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds strategic meaning by mapping the legal test to parameters: '투기과열지구 여부(regulated_area) × 사업 유형 × 진행 단계' and highlighting the role of first_approval_application_after_20180125 in the 재개발 부칙. This helps the agent decide which parameters to prioritize or fill.

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

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

Description states a specific verb+resource: '투기과열지구에서 재건축·재개발 물건을 지금 사면 조합원 지위를 승계받을 수 있는지' and '도시정비법 39조 2항으로 결정론 판정한다'. It clearly distinguishes from siblings by limiting scope to principle restriction checks and explicitly pointing to alternative tools for exceptions and other matters.

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

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

Provides explicit when-to-use context with the example '한남3구역 지금 사도 입주권 나와?' and gives clear boundaries ('경계를 지켜라') listing exclusions such as exceptions (양도인 사정) and separate land transaction permit zone. It names alternatives like realty_policy_rules(topic=redevelopment_rules) and realty_redevelopment for specific follow-ups.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses the crucial lower-bound behavior, the Cheongyak Home announcement basis, and the coverage/interpretation fields ('reading' 문장, 'interpretation'이 lower_bound). It gives a concrete Sejong example to illustrate underestimation risk and warns against double counting with the pipeline.

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

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

The description is longer than average but front-loaded with the core purpose, followed by clearly bolded behavioral caveats and a concrete examples. Every section earns its place; the real case and the pipeline comparison are essential to correct use.

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

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

Covers lower-bound semantics, temporal blind spot, response-field usage, cross-referencing with sibling tool realty_supply_pipeline, and double-counting prevention. Given the output schema exists and annotations are provided, no essential context is missing.

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

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

The input schema already describes all four parameters (100% coverage), so the baseline is 3. The description adds meaningful context about the time horizon (today+30 months) that affects how to interpret to_ym/from_ym ranges, and warns that far-future queries will mostly return unannounced supply. This is helpful but not detailed parameter-level syntax, so 4.

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

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

The description opens with a clear verb and object: '지역의 입주 예정 물량을 연월별로 집계한다' (aggregates scheduled move-in volume for a region by year/month). It also frames the intended question types (입주장 리스크, 내년 물량) and explicitly distinguishes this lower-bound count from the complementary sibling realty_supply_pipeline.

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 context ('입주장 리스크 있어?', '내년에 입주 물량 얼마나 쏟아져?'), warns about the 30-month announcement lag, and explicitly instructs to call realty_supply_pipeline when the result is much lower than coverage.region_recent_annual_rate, including a don't-add-the-numbers caveat.

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 true and destructive false. The description adds valuable context: only 매매 data exists (no 전세/월세), land share transactions are excluded from aggregates, and the response contains recent + stats with note field. It also clarifies area-basis differences per property type.

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

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

Description is dense but efficient, front-loaded with the main purpose and response shape. The Korean text packs significant guidance in a compact form. Minor deduction for somewhat run-on structure and the note about land share_type being buried mid-paragraph, but overall every sentence earns its place.

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

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

For a 6-param tool with an output schema, this description covers critical edge cases: data coverage limits (매매 only), property-type-specific area semantics, land 지분 warnings, and sibling-tool handoff. The output schema documents return structure so not explaining it fully is acceptable. This is complete for practical agent use.

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

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

Schema coverage is 100%, so baseline is 3. But the description adds meaningful semantics beyond schema: '1차 도구' context, per-type area basis (villa/officetel use area_m2/area_pyeong, house splits land/building, land has land_category/zoning), and that area_band only applies to villa/officetel. This genuinely helps parameter selection beyond the schema.

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

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

Description states a specific verb ('조회한다') and resource (빌라·오피스텔·단독주택·토지의 실거래 매매가), and explicitly distinguishes from sibling realty_region_price_stats/search_complexes which handle apartments. This is a precise 1차 도구 for non-apartment sales price queries.

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

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

Explicitly says this is the first-line tool for non-apartment questions, tells when NOT to use it (전월세 queries should be refused because no data exists), and names alternatives for apartments (realty_region_price_stats·search_complexes). Also warns about land 지분 rows not being comparable, which is a clear usage exclusion.

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 read-only/idempotent, and description adds behavioral context: page numbers attached to values, requirement to report notice_version and page, fallback unverified_source_text with disclosure, and prohibition on fabrication. No contradiction.

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

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

Description is a single structured paragraph, front-loaded with core purpose and followed by usage/fallback/alternative guidance. Somewhat dense but each sentence conveys necessary information; could be broken into bullets but remains efficient.

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

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

Given an output schema exists, return values need not be described. The description covers fallback behavior, page-number reporting, alternative tool routing, and constraints, making it complete for a complex fact-sheet 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 covers 100% of parameters with clear descriptions for keyword and house_manage_no. Description does not add further parameter-level detail beyond schema, so 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?

Description clearly identifies the tool as a fact sheet extracted from recruitment notices, enumerating specific data fields (resale restrictions, eligibility, prices, options, interim payments). It distinguishes from sibling realty_notice_text by explicitly naming the latter for full text.

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

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

Provides explicit guidance: questions about these specific values are this tool's place; for detailed provisions, use realty_notice_text; for unextracted notices, fallback to unverified_source_text. Also instructs not to invent missing values.

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?

Adds substantial behavioral context beyond annotations: pdftotext table alignment issues with a warning not to assert ambiguous columns, AND semantics for multi-word queries, fallback behavior when 0 pages are hit, a 6-page response limit, and the guaranteed presence of meta.matching_pages. No contradiction with readOnlyHint or other 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?

Every sentence earns its place: purpose, table warning, query semantics and zero-hit fallback, recommended workflow, and response limits. No fluff or redundancy, and the most important information is front-loaded.

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

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

Given the 5-parameter complexity, the description covers purpose, usage workflow, edge cases, response size, and metadata. With full schema coverage, read-only/idempotent annotations, and an output schema, no significant gaps 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 description coverage is 100%, so the baseline is 3. The description mentions match='any', pages_only, and pages, but these are already explained in the schema; it adds no new parameter-level semantics beyond strategic use tips.

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

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

The description explicitly states the tool reads the original recruitment notice text page by page ('입주자모집공고문 원문을 쪽 단위로 읽는다') and lists concrete use cases (special supply income/asset criteria, disqualification handling, contract cautions). It contrasts with the fact sheet, distinguishing it from siblings like 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?

Provides clear when-to-use guidance: '팩트시트에 없는 세부...는 이 도구로 원문을 직접 확인하라' (use this tool for details not in the fact sheet), implicitly naming the fact sheet as the alternative. Also offers a workflow: use pages_only=true first, then narrow with pages, and widen with match='any'.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds meaningful context: the tool is paid, supports only subway/hospital/school for coordinate search, and is intended for counting actual facilities and distances. No contradictions, but it doesn't mention rate limits or response ordering beyond 'sorted by distance'.

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

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

The description is three sentences, front-loaded with the main purpose, followed by concise usage guidance. There is no redundant information or fluff; every sentence earns its place.

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

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

The description covers purpose, paid status, coordinate sourcing, alternatives, and data limitations. Since an output schema exists, return values need not be explained. The guidance is sufficient for an agent to select and invoke this tool correctly.

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

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

Schema coverage is 100% with detailed descriptions, including lat sourced from realty_complex_report and poi_type allowed values with alternative tools for marts. The main description reinforces the coordinate source and usage intent, adding cross-tool context beyond the schema, which justifies a score above the baseline.

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

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

The description clearly states the tool retrieves location amenities (subway, school, hospital, mart) around coordinates, sorted by distance. It uses a specific verb ('조회한다'), names the resource, and distinguishes itself from siblings by noting it's paid and contrasting with realty_location_scores and realty_poi_stats.

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

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

The description explicitly directs using realty_complex_report for coordinates, and states that realty_location_scores is sufficient if only scores are needed. It also clarifies via the poi_type schema description that marts/pharmacies should use realty_poi_stats, providing clear when-to-use and alternatives.

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

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

Annotations already declare readOnly, openWorld, idempotent hints. The description adds valuable behavioral context: data collection scope limitations (metropolitan focus), region key format, and the caveat that zero counts may be due to missing data rather than absence. This exceeds the annotation information and aids interpretation.

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

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

The description is three sentences, each adding distinct value: purpose, region key format, and data scope warning. It is front-loaded and contains no superfluous 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?

Given the tool has an output schema and few parameters, the description covers the essential aspects (purpose, region format, data scope). However, it omits noting that the tool is paid (as indicated in the title) and does not elaborate on the output format, though the output schema addresses the latter.

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

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

Schema coverage is 50% (region has description, limit does not). The description enhances the region parameter by explaining the two-token format (e.g., '서울 마포구') and matching behavior, but adds nothing about the limit parameter. Thus it improves semantics for one parameter but neglects the other.

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

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

The description explicitly states it queries statistics on the count of hospitals, schools, and subway stations by city-county-district, and mentions it is for comparing infrastructure between regions. This clearly distinguishes it from siblings like realty_poi_nearby or realty_location_scores.

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

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

The description provides guidance on the region key format and a critical warning about data collection scope being centered on metropolitan areas, advising not to interpret zero as absence. While it does not explicitly mention when not to use this tool versus alternatives, the context is sufficient for correct usage.

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

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

Annotations already mark the tool as readOnly, openWorld, idempotent, and non-destructive. The description adds significant context beyond annotations: it states the tool does not make determinations ('판정은 하지 않는다'), carries a confirmation date, provides current regulated-area status, and requires the agent to pass along uncertainties and a disclaimer. It also warns about subtle data dependencies (e.g., the 1.1% rate only holding below 600M KRW), giving the agent critical behavioral context.

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

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

The description is long but dense and front-loaded. It opens with the core purpose, then usage guidance, then explicit warnings and exclusions. Every sentence adds value; the length is justified by the breadth of topics and the importance of not hardcoding rules. However, the dense comma-separated topic list at the beginning could be slightly more scannable, so not a perfect 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?

Given the tool has one multi-value enum parameter and a rich output schema, the description goes beyond what is structurally required. It tells the agent what types of questions belong here, which sibling tools to delegate to for calculations, what the tool does NOT do (facts/judgments), and what to include in responses (uncertainties, disclaimer). It also covers temporal aspects (current status, confirmation date) and warns against common client-side hardcoding mistakes, making it nearly complete for safe 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?

The input schema already provides complete parameter coverage (100%) with a highly detailed description of every enum value for the only parameter, topic. The tool description reinforces the overall purpose and question types but does not add new parameter-level semantics beyond the schema. Since the schema carries the full burden, a baseline 3 is appropriate.

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

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

The description uses a specific verb ('준다' / provides) and immediately identifies the resource: general legal/regulatory norms with legal basis and confirmation date. It enumerates concrete content areas (acquisition tax, regulated areas, loan rules, lease renewal, capital gains tax, subscription, redevelopment) and explicitly contrasts with sibling calculators like realty_loan_limit and realty_capital_gains_tax, clearly distinguishing this as the source of truth rather than a calculator.

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

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

Explicitly says when to use this tool ('이 표가 그 계산기들의 진실원이다') and names five alternative tools for calculations, plus realty_presale/realty_notice_facts for case-specific data. It also gives strong usage guardrails: don't hardcode tax rates, don't make determinations, ask the user for confirmation, and include uncertainties and disclaimer in the response.

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

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

The description discloses model limitations: fixed 1-month horizon, honest refusal on low coverage, 2-4x error possibility on new construction, and 16.3% of cases exceeding ±10% deviation due to trade-composition changes. It mandates relaying predictions[].caution, as_of_ym, and disclaimer, significantly enriching the readOnly/idempotent annotations.

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

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

The description is dense but intentionally structured: purpose first, then input requirements, coverage rules, and output-handling caveats. Every sentence contributes important operational context, with no redundancy or filler.

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

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

For a paid predictive tool with complex caveats, it covers purpose, input requirements, ambiguity resolution, coverage limits, fallback alternatives, and mandatory response fields. Since an output schema exists, return value structure is already documented, and the description fills all behavioral gaps.

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

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

All 3 parameters have schema descriptions, giving a baseline of 3. The description adds the critical precondition that exactly one of complex_name/complex_key must be supplied (even though the schema does not mark them required), and reiterates that months is ignored. This extra guidance adds value beyond the schema.

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

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

The description clearly states '단지의 다음 달 평균 매매가를 평형대별로 예측한다' (predicts the next month's average sale price by size type), specifying the verb, resource, and output granularity. It distinguishes itself from sibling tools like realty_complex_pyeong_price (current price) and realty_region_price_stats (regional stats).

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

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

It explicitly requires complex_name or complex_key and directs using realty_complex_report for ambiguous names before calling with complex_key. It also states when coverage fails (fewer than 3 monthly trades in recent 3 months, or first month of new construction) and instructs to use real transaction tools instead, plus clarifies that prediction horizons beyond 1 month are not provided.

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?

While annotations already state readOnly=true and openWorldHint=true, the description adds substantial behavioral nuance: regulation-area flags (speculation_zone, adjustment_area, price_cap_applied) are snapshots as of the announcement date and must not be stated as current; the absence of unsold_history does not mean no unsold rounds occurred; and price_min/price_max are per-house-type extrema, not a simple range. These details prevent misinterpretation and are not inferable from annotations alone.

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

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

The description is long but every sentence carries essential caveats, cross-references, or field semantics. It is logically organized: purpose → trigger queries → tool chains → field semantics → data gaps → related tools → flag snapshot behavior → further data exclusions. There is no filler or redundancy; the density of information justifies its length.

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

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

Given the output schema exists, the description successfully covers non-obvious behavioral aspects: unsold_history interpretation, regulation-flag snapshot timing, absent data (qualifications, resale restrictions), and routing to sibling tools. It leaves no critical ambiguity about what the tool returns, what it cannot answer, and how to handle follow-ups, making it fully complete for its complexity.

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

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

Schema description coverage is 80%, so the baseline is 3. The description adds concrete usage semantics for keyword (partial matches by complex/생활권/dong, e.g., '우미린', '5-2생활권') and warns that sigungu is contaminated for Sejong and should be replaced by keyword. It also clarifies the meaning of price_min/price_max and house_type_count, which are likely output fields, though not input parameters. This goes beyond schema descriptions but does not fully compensate for the lack of explicit parameter-level guidance for limit and upcoming.

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

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

The description opens with a specific verb+resource ('아파트 청약(분양) 공고를 조회한다') and enumerates the key result fields (분양가, 청약 접수 일정, 당첨자 발표일, 입주 예정, 위치). It also distinguishes itself from siblings by naming alternative tools for follow-up questions (realty_presale_vs_market, realty_subscription_odds, realty_presale_price_trend, realty_notice_facts) and explicitly states exclusions (청약 자격·순위 요건, 전매제한).

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?

Guidelines are explicit and actionable. The description provides concrete example questions that trigger this tool ('다음 달 청약 넣을 만한 데 있어?', '○○에 분양하는 아파트 있어?') and tells the agent to chain to realty_presale_vs_market when the user asks about worthiness/price fairness. It also routes competition-rate queries to realty_subscription_odds, price-trend queries to realty_presale_price_trend, and restriction-period queries to realty_notice_facts, with clear when-not-to-use warnings.

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 readOnlyHint/idempotentHint annotations, the description discloses that the calculation is deterministic, based on public announcement and tax law, uses assumptions (e.g., move-in date, standard tax rate) that must be conveyed to the user, and excludes heavy taxation/exemptions. This adds substantial behavioral context.

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

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

The description is lengthy but front-loaded with the core formula and structured into purpose, boundary, and redirects. The anecdotal example about hand calculation is slightly tangential but reinforces the deterministic nature. Overall, each sentence provides necessary context.

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

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

For a complex financial calculation tool, the description is complete: it fully specifies what is calculated, what assumptions are made and must be surfaced, what is excluded, and points to sibling tools for related analyses. The presence of an output schema covers return values, so no gaps are obvious.

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

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

The input schema has 100% parameter coverage with descriptions. The description indirectly clarifies the role of movein_ym in interest calculation and extra_options_krw, but does not add significant meaning beyond the schema. The baseline of 3 is appropriate for high schema coverage.

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

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

The description provides a specific verb and resource: it calculates total required funds per floor from floor price, balcony expansion, installment interest, and acquisition tax. It clearly distinguishes itself from sibling tools by describing its deterministic scope and explicitly naming alternatives.

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

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

It explicitly states when to use this tool ('this is the place for how much does this presale actually cost') and when not to, redirecting monthly repayment and buy-vs-jeonse analysis to realty_complex_rent_by_pyeong and realty_presale_funding_plan. It also references realty_policy_rules for tax rates, giving clear 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 annotations (readOnly=true, openWorldHint=true, idempotentHint=true, destructiveHint=false), the description discloses that the judgment is deterministic, based on current regulations/current funds, does not reflect future regulatory/interest/savings changes (stated to be carried in assumptions), is not an approval or commitment, and that the server does not estimate future market prices or jeonse values. No contradiction with annotations.

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

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

The description is front-loaded with a precise core definition, followed by a numbered 'boundary' list that adds usage exclusions and scenario behavior. Every sentence earns its place; however, it is a bit verbose, with some repetition (e.g., '서버는 미래 시세·전세가를 추정하지 않는다' appears both in item ⑤ and is implied elsewhere). Still, the structure is clear and appropriate for a 21-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?

The description covers purpose, usage boundaries, scenario alternatives (expected-price and jeonse), key caveats (not an approval, assumptions/uncertainties to be conveyed), and clarifies the tool's deterministic, current-state basis. With annotations and an output schema present, this is fully sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100% (all 21 parameters have meaningful descriptions), so the baseline is 3. The description adds a conceptual framework about declarations (borrower type, income, future price, jeonse) and the two scenario outputs, but this largely mirrors what the parameter descriptions already say (e.g., '선언' in expected_price_at_movein_10k and jeonse_deposit_10k). It does not add syntax-level detail beyond the schema.

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

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

The description clearly states the tool deterministically judges whether a subscription can be closed with one's own funds, breaking down required amounts by phase (down payment, interim payments, balance), checking the balance loan against LTV, price-band, and DSR caps, and quantifying any shortfall. It explicitly names the use case ('이 분양 당첨되면 진행 가능해?' type questions) and distinguishes from siblings by referencing realty_loan_limit as the same engine and realty_presale_vs_market / realty_policy_rules as alternatives.

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

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

The description provides explicit when-to-use guidance ('이 분양 당첨되면 진행 가능해?' type questions) and clear exclusions: savings plans, refinancing strategies, and purchase suitability are outside, with alternatives named. It also explains that borrower type/income and future price/jeonse are declarations, and that the tool uses current regulations and current own funds only, with a boundary list that prevents misuse.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds substantial behavioral context: it uses supply-area maximum per-pyeong price, excludes balcony/options, and explains that median trends can be distorted by unit mix. The warning about small-sample years and the recommended filtering approach are valuable beyond structured annotations.

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

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

The description is dense yet well-structured: it opens with purpose, then covers calculation criteria and caveats, and closes with sibling positioning. Every sentence earns its place, including the instruction to pass the criteria directly to the answer. The length is appropriate for the domain complexity.

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

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

Given the read-only annotations, complete parameter schema, and presence of an output schema, the description covers the essential aspects: purpose, metric definition, interpretation caveats, and relationship to sibling tools. No important behavioral or usage aspect appears 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 descriptions cover 100% of parameters, so the baseline is 3. The description adds meaningful parameter guidance by recommending exclusive_m2_min/max (80-85) to fix unit mix and stabilize trends. It does not repeat each parameter's schema description but leverages the ones that need behavioral nuance.

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

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

The description states the tool computes yearly per-pyeong presale price trends for same-region announcements, with a clear verb and resource. It explicitly distinguishes itself from sibling tools by naming realty_presale_vs_market and realty_region_price_stats as alternatives. This makes the tool's unique role unmistakable.

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

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

The description explicitly explains when to use the tool (to quantify waiting cost in purchase decisions, especially under resale restrictions) and when not to rely on it (years with only 1-2 announcements should not be read as trends). It names alternatives for other analytical axes, providing both positive and negative usage guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds critical behavioral context: market_avg is an unfiltered regional average and should not be used as the primary baseline; comparable_complexes within comparison_by_size is to be prioritized. It also discloses the limitation that the average includes old complexes and thus does not reflect new-construction premium, and explicitly warns not to fabricate data ('지어내지 말 것').

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

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

The description is longer than average, but every sentence earns its place. It is front-loaded with the core purpose, then structured into clear sections: announcement identification, limitations, baseline priority, and comparisons to alternative tools. The formatting with line breaks and bold bullets improves scannability without redundancy.

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

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

Given the tool's complexity (4 optional params, multi-step invocation, multiple data-quality caveats, and references to output fields like comparison_by_size), the description is complete. It addresses all likely agent errors: guessing candidates, misinterpreting market_avg, overstating conclusions, and confusing the tool with siblings. An output schema exists, so return-value documentation is not required.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful parameter guidance beyond the schema by explaining the relationship between house_manage_no and region/keyword (house_manage_no is preferred if known), and the candidate-list behavior when multiple announcements match. This goes beyond simple field descriptions, though not exhaustively; for example, 'months' is not elaborated beyond the schema, but the core disambiguation logic is valuable.

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

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

The description clearly states the tool computes whether presale prices are cheap or expensive relative to surrounding actual transaction prices per housing type. It uses a specific verb ('계산한다') and resource ('분양가 vs 실거래 시세'), and distinguishes itself from siblings by naming realty_subscription_odds and realty_presale_price_trend as the tools for different questions.

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 identifies the questions this tool answers ('이 청약 넣을 만해?', '분양가 적정해?') and directs users to realty_subscription_odds for competition rates and score cutoffs, and realty_presale_price_trend for price time series. It also gives disambiguation instructions (use house_manage_no if known, otherwise search by region+keyword, and if multiple candidates, pick one from the returned list rather than guessing).

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

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

Description discloses the scoring formula (building age up to 70 points based on 30-year limit, transaction activity percentile up to 30) and what is not included (business feasibility). Annotations already declare readOnlyHint, and description adds context about version history and recalculation. No contradictions.

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?

Description is structured with bullet-like points and front-loads the purpose. It includes necessary details (formula, limitations, version note) but is slightly verbose; could be more concise.

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

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

Given the tool's moderate complexity and presence of output schema, the description covers all essential aspects: purpose, inputs, scoring, limitations, and usage context. No missing critical information.

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 50% (district described, limit not). Description adds context about '건령·거래활성 기반' but does not elaborate on how parameters affect results or provide additional meaning beyond schema. Baseline 3 is appropriate.

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

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

Description clearly states the verb '조회한다' (queries) and resource '재건축 후보 스크리닝 상위 단지' (top complexes for reconstruction candidate screening). It distinguishes itself from siblings by specifying it is for candidate screening and not investment basis.

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?

Description explicitly states the tool is for candidate discovery, not investment decision, and that business feasibility factors are not reflected. It also instructs to convey the disclaimer to the user. However, it lacks explicit when-to-use vs alternatives like realty_redevelopment.

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

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

Beyond annotations (readOnly, idempotent, not destructive), the description discloses key behavioral traits: Seoul-only coverage, null values for household count and completion dates, and unsupported stage filtering. These limitations are critical for correct agent behavior and are clearly stated.

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

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

The description is compact and front-loaded, stating the core purpose first, then limitations, then sibling differentiation. Every sentence adds value—no redundancy or 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 an output schema present, the description doesn't need to explain return values. It covers coverage boundaries, null behavior, filtering limitations, and points to the correct tools for related questions. This is sufficient for an agent to select and invoke the tool correctly in most scenarios.

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 75%, with sigungu, project_type, and offset already described. The description adds little to parameter semantics, though it does clarify that there is no stage filter parameter. Since the schema already carries most parameter meaning, a baseline 3 is appropriate.

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

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

The description clearly states the tool lists Seoul maintenance projects (redevelopment, reconstruction, street housing) with name, type, stage, and location. It also gives an example question type, and explicitly distinguishes itself from realty_reconstruction and realty_member_transfer_check, preventing confusion with siblings.

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

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

The description provides explicit when-to-use guidance (Seoul-only coverage, questions about project progress), when-not-to-use (other regions, reconstruction attractiveness, member status transfer), and names the correct sibling tools. It also instructs the agent not to invent null fields and notes the lack of a stage filter.

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

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

Beyond the annotations (read-only, idempotent), the description adds critical behavioral context: the tool performs deterministic calculation without server-side verification, the proportion rate is an estimate before management disposition approval and keeps changing, and the formula's origin and fluctuation pitfalls are documented in realty_policy_rules. This exceeds the minimal safety hint and gives the agent practical knowledge about reliability and limitations.

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

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

The description is front-loaded with the purpose and formula in the first paragraph, then uses a bulleted 'boundaries' list for warnings. Every sentence contributes meaning, though the text is dense and somewhat long. It could be slightly more compact, but the structure is logical and all content is essential.

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

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

With an output schema present, the description need not explain return values. It covers the tool's role, calculation method, input declaration requirements, sensitivity/disclosure obligations, and linkage to authoritative sources. It even points to an alternative when qualification is uncertain. This is complete for a complex calculation tool given the rich schema and annotations.

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

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

Schema coverage is 100%, so each parameter is already described in the schema. The description adds value by linking the parameters through the core formulas (e.g., how prev_asset_value_10k and proportion_rate_pct combine to produce 권리가액) and by hinting that proportion_rate_pct null triggers calculation from total_* fields. This goes beyond the schema but is not exhaustive, as the schema already covers most 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?

The description clearly states the tool's purpose: calculating rights value (권리가액) and additional burden (분담금) for redevelopment/reconstruction union members. It provides the exact formulas (권리가액 = 종전자산 감정평가액 × 비례율, 분담금 = 조합원분양가 − 권리가액) and even an example question. This distinguishes it from sibling tools like realty_redevelopment or realty_reconstruction by focusing specifically on the burden calculation.

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

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

The '경계를 지켜라' section explicitly tells the agent when to use this tool and what to watch for: inputs are declarations with no server validation, the formula is a practical convention not a legal one, and the output must include sensitivity and disclosures. It also directs the agent to realty_policy_rules for the authoritative formula source and to topic=redevelopment_entitlement if qualification is uncertain, providing clear 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?

Even with annotations (readOnly, idempotent, non-destructive), the description adds substantial behavioral context: outlier filtering is not applied (so averages can be depressed), divergence between tools is resolved in favor of bands, ambiguous region resolution defaults to highest-volume area and exposes region_candidates, and pyeong_supply is internally converted by ×0.745. No contradictions with annotations.

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

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

The description is well-structured with bold labels, bullet points, and practical examples, but contains an internal testing note ('2026-08-08, 8/7 테스터 제안 수용') that is irrelevant for an AI agent. Otherwise every sentence earns its place, and the length is justified given the tool's complexity.

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

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

The description covers all key aspects: purpose, sibling differentiation, regional disambiguation, metric variants, rental trend fields, pyeong handling, and integration with other tools. Given the output schema exists (though not shown), the description need not explain return values, and it is complete for the tool's complexity.

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

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

Schema coverage is only 40% (metric and months have descriptions; region and pyeong fields do not). The description compensates richly: region examples, legal-dong granularity, ambiguity handling; metric explains rental returns monthly_trend breakdown; pyeong_supply clarifies it means '34평' and the conversion factor; pyeong_exclusive is noted as the original data standard. All params are meaningfully elaborated beyond the schema.

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

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

The description opens with a specific verb+resource+scope: '지역의 아파트 실거래 시세 추이(월별)를 조회한다' (queries monthly apartment transaction price trends by region). It also explicitly distinguishes itself from siblings (realty_area_price_bands, realty_search_complexes) by naming them and clarifying the different use cases.

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

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

The description provides explicit when-to-use and when-not-to-use guidance: use for monthly trends/direction, use realty_area_price_bands for price levels, use realty_search_complexes for complex-specific questions. It also suggests combining with realty_move_in_supply for reverse-jeonse analysis, giving clear decision rules.

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

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

Discloses data quality and methodology nuances beyond annotations: price uses a minimum of 5 transactions and may have incomplete data for the latest month; growth uses a fixed 60-85㎡ YoY to avoid distortion; transit/school are averages of complex scores; investment is suspended and will guide alternatives. No contradiction with annotations exists.

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

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

The description is dense but well-structured. Each sentence provides unique value: purpose, metric definitions, limitations, instructions for using responses, and alternative tools. No redundant or filler 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?

The description covers all critical aspects: what the tool does, metric semantics, data caveats, alternative tools, and how to interpret responses. The presence of an output schema reduces the need to explain return values, and the description fills the remaining gaps effectively.

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

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

The description adds significant detail beyond the input schema: it explains the exact calculation for price (volume-weighted avg price per pyeong, min 5 transactions), growth (fixed 60-85㎡ YoY), and transit/school (average of complex scores). It also clarifies the 'investment' metric's current status, something the schema does not reveal.

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

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

The description clearly states the tool's purpose: queries region (si/gun/gu) rankings, and lists example questions like 'Where is the most expensive neighborhood?' and 'Which region has risen a lot?'. It explicitly distinguishes itself from the sibling realty_compare_regions, making the intended scope unambiguous.

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

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

Provides explicit guidance on when to use this tool vs alternatives. It states that for fixed A/B comparisons, realty_compare_regions should be used, and that this tool is for ranking/exploration. It also gives a specific alternative for the 'investment' metric (realty_rental_yield) and warns about its suspended status.

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

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses exclusions (취소·직거래 제외), limitations (동·층 구성 변화 미보정), and methodological details (평당가, composition_effect). No contradiction with annotations.

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

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

The description is well-structured with clear sections (core method, why needed, limitations) and every part earns its place. The concrete example is relevant and illustrative, though the text is slightly longer than the two-sentence ideal; still appropriately sized for a tool with these caveats.

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

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

The description covers purpose, methodology, exclusions, limitations, and output concepts (naive, basket, composition_effect). Since an output schema exists, omitting return-value details is acceptable. The tool's complexity is well addressed.

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

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

Schema coverage is 100% with rich descriptions for all five parameters, so the baseline is 3. The main description adds context about basket thickness and how narrowing pyeong_supply weakens the fixed-basket benefit, but it does not systematically elaborate on each parameter, so no bonus beyond baseline.

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

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

The description clearly states the tool computes regional price trends using only complexes with transactions in both windows (fixed basket), and contrasts this with naive monthly averages. The title and opening sentence give a specific verb, resource, and method, distinguishing it from sibling tools like realty_region_price_stats.

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

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

The '왜 필요한가' section explicitly explains when this tool is needed: when naive monthly averages confound price changes with composition changes, especially with thin samples. It also provides a clear when-not by warning '한계를 반드시 함께 전하라: 바스켓이 얇으면... 이 값도 못 믿는다', and gives a concrete example of a misleading result without this tool.

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

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

The description discloses a key behavioral trait not captured by the read-only/idempotent annotations: the default response is a truncated slice of only the latest completed month, sorted by yield descending, not all periods or regions. It also flags the 'truncated field' for verification, which is important for correct interpretation.

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

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

The description is two sentences: the first states the core function, the second explains the crucial default truncation behavior and how to override it. Each sentence adds value, and the most important caveat (truncated response) is prominently placed.

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

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

The description covers the essential information: paid nature, data scope, default behavior, and month override. Given that the output schema exists and annotations declare safety, the description is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with clear descriptions for all four parameters. The description adds behavioral context by stating that a specific month should be queried via year_month, and that the default is the latest completed month. This reinforces the year_month parameter's role, though it does not add new parameter-level syntax or constraints.

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

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

The description clearly states it queries '시군구별 월세 수익률·평균 매매가·평균 월세' (rental yield, average sale price, average rent by city/county/district). It also labels it for '수익형 투자 스크리닝' (yield investment screening), which distinguishes it from sibling tools that focus on auctions, price bands, or macro indicators.

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

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

The description provides a clear usage context: it is for yield-oriented investment screening. It also instructs how to query a specific month using year_month. However, it does not explicitly state when not to use this tool or mention alternatives, so it falls short of full exclusion guidance.

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

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

Annotations already promise readOnly/openWorld/idempotent, but the description goes far beyond: it reveals that past-auction rows are mixed in and backend doesn't filter them, discloses min_bid_source caveats with measured percentages (28.8%, 3%, 25~43%), warns that min bid can be stale or even rise due to re-appraisal, and explicitly states the open-world behavior '여기서 안 나온다고 그런 물건 없다고 답하지 마라'. No contradiction with annotations; substantial added context.

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

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

The description is long but every section earns its place: front-loaded purpose, then critical caveats (past auctions, min_bid_source), then cross-reference to related tools. Bold warnings and bullet-like lists ('· court_schedule', '· item_list') make it scannable despite length. No filler or 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?

For a 10-parameter search tool with output schema, the description covers filtering semantics, pagination via next_offset, data-quality warnings (past_auction_count, min_bid_stale_risk_count), return-level guidance (only summary fields, call realty_get_auction_case for full info), and sibling-tool routing. It anticipates realistic agent and user queries and closes gaps that annotations and schema leave open.

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%, but description adds essential meaning: min_price_10k/max_price_10k are in 만원 units (5억=50000), min_bid_count affects minimum bid, exclude_past controls inclusion of past-auction rows and attaches past_auction_note, and min_bid_source distinguishes court_schedule from item_list with accuracy implications. This is far beyond the terse 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?

The description opens with '법원경매 물건을 지역·종류·감정가·유찰횟수로 필터링해 조회한다', clearly stating the tool's action, resource, and filtering dimensions. It distinguishes itself from siblings like realty_auction_alerts ('유찰 많이 돼 싸진 물건' discovery) and realty_get_auction_case (full case details), making its role unambiguous.

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

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

Provides explicit routing rules: states 공매/온비드 is not in this ledger and instructs agents to direct users to 온비드 instead of claiming no match. Recommends exclude_past=true for '지금 살 수 있어?' queries, and points to realty_auction_alerts for item-finding questions and realty_auction_history for exact failing-bid prices. This is a model of when-to-use vs alternative guidance.

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

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

Adds substantial behavioral context beyond the read-only/idempotent annotations: requires at least one of query or region, explains that complex-level avg_price is a mixed average not suited for pyeong questions, notes the absence of a floor axis, and describes how complex_key integrates with other tools. No contradiction with annotations.

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

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

Front-loaded with the core purpose and structured with bold headers for readability. Every sentence adds value, including the illustrative example of why regional tools fail for complex queries. The length is justified by the density of actionable guidance.

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

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

Highly complete given the rich output schema and annotations. Covers sibling differentiation, usage constraints, interpretation of returned fields, and integration with other tools via complex_key. No important aspect seems missing for an agent to select and invoke the tool correctly.

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

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

Even with 100% schema coverage, the description adds essential parameter semantics: specifies that query or region is mandatory (not in schema), explains how to match user's '34 pyeong' to pyeong_supply_est, and warns against using avg_price. This significantly exceeds schema descriptions.

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

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

Clearly states it searches apartment complexes by name/region and returns actual transaction prices by pyeong size. Identifies itself as the primary tool for specific complex questions, distinguishing it from regional average 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 says this is the default when a complex is specified and warns against using regional average tools for complex questions, with a concrete example of a 24% discrepancy. It also directs floor-specific questions to realty_complex_pyeong_price and regional questions to the other two tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, but the description goes far beyond these: it exposes the freshness ambiguity (empty arrays can mean not_yet_published vs not_yet_collected and how to disambiguate via freshness_verdict), warns that regional benchmarks reflect other complexes' performance, alerts about sample-concentration pitfalls, and explains that null cutoffs mean 'no winner/not applicable' not zero. This is rich behavioral context that annotations alone cannot 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 description is dense and well-structured with bolded warnings and clear numbered path explanations. While long, every sentence earns its place by providing essential operational guidance (collection frequency, failure modes, measurement evidence). The front-loading of critical caveats (empty-check first, don't answer with a single city) makes it scannable. A slight trim of spacing and bold styling could improve readability, but content-wise it is appropriately sized for a tool of this complexity.

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

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

For a tool with 10 parameters, no required fields, and a rich output schema, the description is exceptionally complete. It covers execution paths, freshness semantics, sample-size warnings, result interpretation (result_status_legend), and explicitly states what the tool cannot do (calculate win probability due to missing data). It references output schema fields appropriately and provides actionable protocols for common user questions without needing additional documentation.

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?

While schema description coverage is 100%, the tool description adds substantial meaning beyond schema text: for breakdown it provides concrete measurement evidence (Seoul Eunpyeong 45 vs Gangnam 74 points) to guide parameter selection; for budget_max_10k it warns that omission yields answers with unaffordable complexes; for sigungu it advises widening to province level when samples are zero. This deepens agent understanding of when and why to set each parameter.

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

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

The description states the tool computes subscription competition rates and actual winning score cutoffs, with two distinct execution paths (published results vs. regional benchmarks). It clearly distinguishes itself from siblings like realty_subscription_score (which generates a user score) and realty_presale_vs_market (for price adequacy), and explicitly instructs users when to chain to those 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?

Provides exceptionally detailed usage guidance: instructs users who lack a score to first call realty_subscription_score, tells when to use breakdown='sigungu' vs 'quarter'/'year' with concrete measured examples, warns against single-city answers and against omitting budget_max_10k when a budget is mentioned, and specifies when to chain to realty_presale_vs_market. Explicitly names alternatives and exclusion conditions, e.g., 'not a probability calculator' and 'never answer no competition when it's a collection gap'.

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

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

Beyond the readOnly/idempotent annotations, the description discloses that the server does not verify declaration facts (base point, dependent recognition) and that the response includes traps for incorrect entries that can cause disqualification. It also flags conditions like is_homeowner/under30_unmarried zeroing out the no-house score, adding behavioral context not present in annotations.

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

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

The description is efficiently organized with bolded key terms and a numbered list for boundaries. Every sentence adds value: introducing the tool, explaining the declaration concept, warning about traps, and linking to related tools. No fluff or redundancy.

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

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

Given the output schema exists, the description correctly focuses on usage context rather than return values. It covers the tool's purpose, the declarative nature of inputs, the trap mechanism, integration with realty_subscription_odds, and the authoritative source of rules, making it fully sufficient for an agent to select and invoke the tool correctly.

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

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

Although the schema already covers all parameters, the description adds semantic meaning by explaining the scoring weights (32+35+17), clarifying that all values are declarations, and noting how is_homeowner/under30_unmarried affect the no-house period score. This goes well beyond the baseline and enriches the agent's understanding of how the inputs should be handled.

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

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

The description clearly states the tool calculates the merit-based score for private housing general supply (max 84) by applying a scoring table to declared values, breaking down the weights (no-house 32, dependents 35, account 17). It explicitly positions itself as the place for '내 청약 가점 몇 점이야?' and distinguishes itself from siblings like realty_subscription_odds and realty_policy_rules.

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

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

It provides explicit usage boundaries shown as numbered items: all three core inputs are declarations and the server does not judge factual determinations; it names the next step of passing the score to realty_subscription_odds' my_score; and it directs users to realty_policy_rules(topic=subscription_account) as the source of truth for the scoring table.

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

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

With annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false), the description adds critical behavioral context: structural incompleteness of business_body until completion, floor values being planned (not confirmed) max/floor tiers, absence semantics (max_floor_absent_reason to be passed verbatim, don't interpret as 'low floor', business_body structurally empty), meta.announced_cross_check for cross-validation. These are behaviors beyond what annotations declare and significantly aid correct interpretation.

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

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

The Korean description is dense but highly informative - every sentence earns its place, covering core purpose, sibling differentiation, usage context, data sourcing, field semantics, and behavior notes. The structure uses bold for key claims and clear topic breaks. Length is justified by the richness of content; could be trimmed slightly but it's intentionally a knowledge-heavy real estate tool. The 2026-08-20 dated note is a nice touch for freshness.

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

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

Despite having an output schema (not shown here but flagged as existing), the description explains return semantics: interpretation of min_floor, max_floor_source origin, announced_notice field meaning, meta.announced_cross_check, empty-value semantics (business_body structurally empty, max_floor absent reasons). It covers edge cases (pre-approval as lower bound, double-counting risk, cross-referencing with realty_notice_text/other tools). Extremely complete for a complex real-estate tool.

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

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

Schema coverage is 100% (all 4 params described with Korean descriptions including defaults). The description adds context on how parameters interact: region uses partial match examples, to_ym defaults to from_ym+60개월, from_ym defaults to current month. It doesn't add syntax beyond examples but the schema descriptions are already specific. The description reinforces 'don't add two axes' but not directly param-related. Slight deduction for not explaining how limit interacts with result ordering or pagination, but overall solid.

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

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

The description uses a specific verb ('본다' - looks at) with explicit resource: pre-announcement supply based on business plan approval. It distinguishes from siblings by naming realty_presale and realty_move_in_supply which only record post-announcement supply, and provides specific use cases ('지금 넣을까, 다음 걸 기다릴까', '이 동네 앞으로 입주 폭탄 있나'). The title supports this (공고 전 공급 파이프라인).

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?

Excellent guidelines: explicitly says to use this tool when consulting on subscription apply-or-wait decisions, mentions it complements realty_presale and realty_subscription_odds for already-announced projects, explains the cross-check meta.announced_cross_check, warns against double-counting, and clarifies pre-approval supply is a lower bound. It also provides guidance on new floor dimension handling with max_floor_absent_reason.

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 sparse annotations (readOnlyHint=false, destructiveHint=false), the description discloses critical operational behavior: quota exemption, shared hourly rate limits (60 total/20 per sender), server operator notification, and the design rationale for combining two kinds into one write surface.

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