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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds valuable context about area band definitions being based on exclusive area (전용평) and provides conversion to 분양평, which is critical for correct interpretation. 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?

Two sentences: first states purpose and output structure, second gives use case and alternative. Every sentence adds value; 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?

Given the tool's low complexity (2 parameters, output schema exists), the description is fully complete. It explains the critical aspect of area band definitions and provides usage context, leaving no gaps for an AI agent.

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

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

Schema description coverage is 100%, so baseline 3. Description implicitly mentions region via example but does not explain the 'period_months' parameter. The added value about area definitions pertains to output, not input parameters.

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

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

Clearly states the tool queries regional sale prices by four area bands (소형/중소형/중형/대형 based on exclusive area) and distinguishes from the sibling tool realty_search_complexes for specific complexes.

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

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

Explicitly states when to use ("무슨 평수대가 얼마쯤 해?" type questions) and when to use an alternative (realty_search_complexes for specific complexes). No ambiguity.

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 indicate a safe read operation (readOnlyHint, idempotentHint, destructiveHint false). The description adds crucial behavioral context: results are not recommendations and require further verification, which goes 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 concise with two clear paragraphs: first explaining the tool's action, second explaining the context and usage instruction. It is front-loaded and efficient, though could be slightly more compact.

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 presence of an output schema and annotations, the description covers the essential behavioral caveat (non-recommendation). It does not detail return format or sorting, but the output schema handles that. It feels complete for the intended 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 high (75%), with descriptions for limit, min_bid_count, and min_discount_pct. The description does not add parameter-specific details beyond the schema, but the schema itself provides sufficient meaning. 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 finds auction items with significantly dropped minimum bids due to accumulated failed bids. It distinguishes from siblings like realty_search_auctions by emphasizing the specific criteria (multiple failed bids) and the non-recommendation intent.

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 instructs not to present results as recommendations but as candidates needing verification, which is a strong usage guideline. It does not directly compare with sibling tools but the purpose implies a specific 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?

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description adds critical behavioral context: photos are preserved from collection time only (may disappear), tracking/price_events are daily snapshots after 2026-07-23 and empty does not imply no change, with court_schedule as authoritative. 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 compact yet informative, using bullet-like structure for key points. It front-loads the main action and example questions. Minor redundancy could be trimmed, but overall efficient for the 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 presence of an output schema, the description adequately covers return value interpretation, edge cases (empty tracking, null results), data provenance, and authoritative sources. It leaves no significant gaps for an AI agent to misuse 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 description coverage is 0%, but the description provides no explanation of the parameters (case_no, court_name). It does not clarify their purpose, format, or optionality. The tool's purpose is clear from context, but the description fails to add meaning beyond the schema's bare structure.

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 specifies querying auction history including failure bids, price reduction time series, price change events, and photo URLs. It provides an example user question and clearly distinguishes the tool's scope from siblings by naming specific data types.

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

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

The description explicitly states when to use this tool (questions about failure counts, price drops, photos) and gives detailed interpretation rules: rows with result='유찰' are failure history, null result rows are future/undecoded, tracking/price_events may be empty, and warns against fabricating meaning for null codes.

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 non-destructive. The description adds behavioral context: it uses actual sale results, defines the calculation formula, and mentions the distribution by failure count. 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 very concise: three sentences that front-load the purpose, then explain usage and formula. Every sentence adds value; no wasted words.

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 4 optional parameters and 0% schema coverage, the description does not adequately explain how parameters filter the results. It mentions by_fail_count but does not map to bid_count_max. The output schema exists but the description does not prepare the agent for parameter selection.

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%, and the description does not explain the parameters (sido, sigungu, usage_name, bid_count_max). It mentions by_fail_count, but this is not a parameter; the parameter bid_count_max is not connected to the description. The description fails to compensate for the lack of schema documentation.

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

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

The description clearly states the tool's purpose: answering what percentage of the appraisal price an item in a given area sells for, based on actual sale results. It distinguishes from siblings by focusing on aggregate statistics rather than individual cases, and it defines the sale rate formula.

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

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

The description explicitly states this is a key indicator for setting bid prices ('입찰가를 정할 때 쓰는 핵심 지표다'). It also provides a concrete example using by_fail_count. However, it does not explicitly mention when not to use or compare to alternative tools among the many siblings.

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

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

Annotations indicate read-only, open-world, idempotent, and non-destructive traits. The description adds substantial behavioral context: address normalization, appraisal range filter (50-150%), signal categories, the mixed-average warning, and performance note. 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 compact and front-loaded with the primary function. It uses bullet-like symbols to highlight warnings, but includes some redundancy. Every sentence adds value, though it could be slightly more streamlined.

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, the description doesn't need to detail return fields, but it only mentions 'signal' and not discount rate or surface yield. It provides core logic and caveats, but lacks an overview of output structure, making it moderately 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 only 20% (only 'limit' described). The description does not explain the meaning or usage of parameters like sido, case_no, sigungu, or usage_name. It mentions address normalization but doesn't map to parameters, leaving the agent to infer from names.

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: comparing the minimum auction bid with actual transaction prices for the same complex to derive discount rate and surface yield. It explicitly mentions input constraints and distinguishes from sibling tools like realty_auction_history and realty_compare_regions.

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 context for use (comparing auction vs market) and warns about caveats (mixed average pricing, slowness). However, it lacks explicit when-not-to-use guidance or alternatives, though the purpose is clear enough to separate from siblings.

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

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

Annotations already declare read-only, idempotent, non-destructive. Description adds the critical paid nature and specifies the metrics (sale and jeonse prices/trends). No contradictions; disclosure of cost is valuable 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?

Two sentences, front-loaded with primary action and use case. Every word is informative; no wasted text. Title also signals paid nature.

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 simple 2-param schema and presence of output schema, the description sufficiently covers purpose, usage context, and key constraints (paid, currency type). Minor gap: no mention of the months range or output format, but these are in schema/output schema.

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

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

Schema has 100% coverage with descriptions for both parameters. The description supplements with concrete examples for 'regions' (array or comma-separated string), adding value beyond the schema alone.

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?

Clear verb ('compares') and resource ('regions'), with specific scope (sale and jeonse prices and trends). Distinguishes from siblings by focusing on side-by-side multiple region comparison, unlike single-region or auction-vs-market 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 context: 'for moving and comparing investment destinations.' This implies when to use, but no explicit exclusions or alternatives are given. The sibling list is extensive, so more guidance would help.

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 indicate readOnlyHint, idempotentHint, etc. The description adds context: returns individual records for the last 6 months with specific fields (contract date, floor, price), and it is strictly for sales transactions. This additional behavioral detail is useful but not extensive.

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 sentences: purpose, alternative usage, parameter instructions. No unnecessary words. 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 complexity of the tool (5 params, 100% schema coverage, has output schema), the description covers the core purpose, usage context, and parameter hints. It does not explain limit or region parameters, but schema and output schema fill those gaps. Adequately complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond schema by explaining the distinction between pyeong_supply and pyeong_exclusive and stating that one must be provided (though schema marks both as optional). This adds meaningful guidance.

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 actual sales transaction details (contract date, floor, price) for a specific complex and specific area (pyeong) for the last 6 months. It distinguishes itself from sibling tools like realty_complex_rent_by_pyeong (rent) and realty_search_complexes (summary prices).

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 tells when to use this vs alternatives: for price summaries, use realty_search_complexes; for rent, use realty_complex_rent_by_pyeong. Also gives guidance on which pyeong parameter to use (supply vs exclusive) and notes that one is required.

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, non-destructive behavior. The description adds value by explaining that returned values are medians and clarifying the pyeong unit definition (분양평 formula). It does not contradict annotations and provides useful context beyond structured fields.

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

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

Three sentences: first for purpose, second for parameter usage, third for pyeong definition. Every sentence is essential and earns its place. Front-loaded with the main purpose.

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

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

Given the tool's complexity (2 params, no required params, output schema exists), the description is sufficient for an agent to understand the tool's purpose and usage. The pyeong definition detail addresses a potential confusion. However, the minor discrepancy between 'one required' and schema allowing both nulls slightly reduces completeness.

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 descriptions for both parameters. The description adds meaning by noting that one parameter is required (though schema lists both as nullable), explaining the trade-off between complex_key (precise) and complex_name (partial match risk). This guidance goes 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 retrieves median jeonse deposit and monthly rent per pyeong type, and explicitly mentions its role in calculating jeonse-to-sale ratio. The verb '조회한다' (retrieves) and resource are specific, and the purpose is distinct among 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 specifies that either complex_key or complex_name is required, warns that partial matching may mix same-name complexes, and recommends using realty_search_complexes to first obtain complex_key. This provides explicit when-to-use and when-not-to-use guidance with a named 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?

Adds significant context beyond annotations: explains non-uniqueness of case numbers, error handling for duplicates, details on rights field (disclaimer, null handling).

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?

Well-structured with main purpose upfront, but slightly verbose in parts; every sentence adds value but could be trimmed.

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

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

Covers duplicate handling, rights field semantics, limitations, and explicitly states what is not included (history, full registry). Complete for a complex 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 has 0% description coverage; the description fully compensates by explaining the purpose and behavior of both parameters (case_no, court_name).

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 retrieves auction case details by case number, and explicitly distinguishes from sibling tool realty_auction_history for history 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?

Provides explicit guidance on when to omit court_name, explains duplicate resolution behavior, and directs to realty_auction_history for related data.

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?

Annotations declare safe, non-destructive, idempotent, open-world. Description adds crucial context: school score is a screening indicator based on city-level academy data, subway_distance_m is straight-line not walking distance, and not_found is honest. 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?

Two concise paragraphs: first covers purpose and usage modes, second covers caveats and data limitations. Every sentence adds unique value, no redundancy.

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

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

Given 3 parameters, full schema coverage, and output schema existence, the description covers all relevant behavioral aspects: score interpretations, data limitations, error handling (not_found), and integration with sibling tool. Complete for its purpose.

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 parameter descriptions. Description adds value by explaining parameter interaction: region alone vs with complex_name, and that complex_key should come from realty_search_complexes. Provides semantics beyond 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 school district (v5) and transportation (subway/bus) scores for a complex or region. It distinguishes between single complex query and regional aggregation, and explicitly ties it to user questions like '이 아파트 학군 어때? 역세권이야?'.

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: use for location scores, check realty_search_complexes for existence if not_found. Warns against interpreting school score as definitive school assignment/quality, and against using it as a definitive measure. Gives when-not-to-use advice.

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 indicate safe, read-only behavior (readOnlyHint, idempotentHint, no destructiveHint). Description adds critical context: data may be stale and agent must verify timestamp via meta.data_as_of before citing. No contradiction with annotations.

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

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

Two paragraphs with no fluff. The warning is essential and placed prominently. Sentences are direct and informative. Could be slightly more concise, but each sentence adds 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?

Output schema exists, so return values need no explanation. Description covers purpose, parameters, usage context, and data staleness warning. For a read-only tool with clear annotations, this is sufficiently 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% with descriptions for both parameters. The description lists example indicator values for the 'indicators' parameter but adds no semantic nuance beyond the schema. Baseline 3 is appropriate.

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

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

Description uses specific verb '조회한다' (query) and names specific resources (기준금리, KOSPI, M2, etc.). It distinguishes from sibling realty tools by its macro-economic focus and provides a use-case example ('금리가 집값에 어떤 영향?').

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 warning about data staleness and instructs to check meta.data_as_of and cite the timestamp. Mentions it's for background analysis. Lacks explicit 'when not to use' but the warning sufficiently guides the agent.

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 readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context: response structure (recent + stats), field naming differences per property type (e.g., area_m2 vs land_* vs building_*), and a warning about land share_type for comparison. This exceeds what annotations provide.

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

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

The description is front-loaded with the main action and is reasonably concise at about 6 sentences. However, some details (like field naming per type) could be part of the output schema, and the parentheticals slightly reduce readability. Still, it is well-structured and informative without being verbose.

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

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

Given the tool's complexity (5 parameters, multiple property types) and the presence of an output schema, the description covers response structure, field naming conventions, and behavioral rules (e.g., land share_type exclusion). It provides enough context for an agent to use the tool correctly without additional lookup.

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. The description adds meaning to the 'property_type' enum by explaining each value in Korean. It also clarifies that price_min/max are in 만원 and that 'region' supports partial matching. This added context justifies a score 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 clearly specifies the verb '조회' (query) and the resource '비아파트 시세' (non-apartment prices), listing specific property types (villa, officetel, house, land). It distinguishes itself from apartment query tools like realty_region_price_stats, making it the primary tool for non-apartment 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?

The description explicitly states when to use this tool ('아파트 밖 질문의 1차 도구') and when not to use it (for rental data: '전월세를 물으면 이 축엔 데이터가 없다고 답하라(추정 금지)'). It also provides a caution about land share_type, guiding the agent to avoid using such rows for price comparisons.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds that the tool is paid ([유료]) and retrieves data sorted by distance, which are behavioral traits beyond annotations. 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?

Two sentences: first states purpose, second gives source and use case. No wasted words, front-loaded with essential information.

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

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

With output schema present (not shown but known), description covers purpose, coordinate source, and use case. Sufficient for a read-only, idempotent tool with low 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 100% for all 4 parameters, so baseline is 3. Description adds context that coordinates should come from realty_complex_report and provides examples for poi_type, but this is mostly already in 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 clearly states it retrieves nearby POI elements (subway, schools, hospitals, marts) sorted by distance, for judging proximity to stations or schools. It is specific and not a tautology, and distinguishes from siblings like 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?

Description mentions that coordinates should come from realty_complex_report and gives a clear use case: '역세권인가', '초품아인가' 판단용 (judging if near station or school). It does not explicitly list when not to use, but 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?

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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context: it's a paid tool, uses XGBoost, requires passing a disclaimer about model accuracy and backtest results, and emphasizes predictions are reference indicators not investment guarantees. This goes beyond the annotations without contradicting them.

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

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

The description is very concise: two sentences plus a line about the disclaimer. Every sentence provides essential information. No fluff or repetition. The most critical information (purpose, requirements, disclaimer handling) 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 tool's simplicity (3 parameters, no nested objects) and the existence of an output schema, the description is complete. It covers purpose, required parameters, usage flow, and disclaimer handling. It does not need to explain return values since the output schema presumably handles that.

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 clear parameter descriptions: months (min/max/default), complex_key (exact key from complex_report), complex_name (example). The description adds usage-level semantics: one of complex_name or complex_key is needed, and complex_key takes precedence for disambiguation. This extra guidance elevates the score above the baseline 3.

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

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

The description clearly states the tool predicts future apartment complex prices using XGBoost. It specifies the verb 'predict', the resource 'apartment complex price', and the method. The title includes '[유료]' indicating it's a paid service. This distinguishes it from siblings like realty_complex_report which likely provide current 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 gives explicit guidance: either complex_name or complex_key is required, advises using realty_complex_report to disambiguate duplicate names before calling with complex_key, and instructs to pass the disclaimer to the user. It does not explicitly state when not to use this tool, but the provided context is clear enough for an agent to make appropriate decisions.

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 and idempotentHint=true, so the description does not need to reiterate safety. It adds behavioral context by explaining the meaning of price_min/price_max fields and that multiple house types may exist, and that eligibility data is absent. This goes 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 brief: two sentences plus a clarifying note about price fields and a warning. It front-loads the purpose and key output fields. Every sentence adds value, no wasted words.

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 4 parameters, an output schema, and rich annotations, the description covers the core purpose, output fields, and limitations. It does not detail pagination or the limit parameter, but the output schema likely covers return format. Overall, it provides sufficient context for an agent to use 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 75% (3 of 4 input parameters have descriptions). The description adds minimal direct explanation for input parameters; its main additions are about output fields (price_min, price_max, house_type_count). The example queries indirectly guide parameter usage, but the burden is partially on the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool queries apartment subscription announcements (청약 분양 공고) and lists the fields it returns. It is specific about the resource and action, but does not explicitly differentiate from sibling tools. However, the unique purpose among siblings is implied.

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 example queries (e.g., '다음 달 청약 넣을 만한 데 있어?') indicating when to use the tool. It explicitly warns that subscription eligibility and points are not included in the data, advising against fabrication. It does not compare to alternatives, but the context is clear.

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

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

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds critical behavioral context: data source does not provide num_households or completion_date, so they are null and must not be fabricated. Also clarifies lack of stage filter, adding 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?

Description is dense with information but well-structured: summary followed by bullet-like notes in Korean. Every sentence adds value, though slightly longer than necessary. Front-loaded with purpose.

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

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

Given output schema exists, description need not explain return values. It covers key points: coverage, missing fields, lack of stage filter, and alternative tool. For a 4-param tool with good annotations, this is largely 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 75% (3 of 4 params have descriptions). Description mentions project types but does not detail each parameter beyond what schema already provides. Baseline 3 is appropriate as the schema does most of the work.

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 provides a list of redevelopment/reconstruction project sites in Seoul with name, type, stage, and location. It specifies use case for questions like 'How far has redevelopment progressed in XX district?' and distinguishes from sibling realty_reconstruction by noting the latter handles 'promising 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?

Explicitly states coverage is Seoul-only and that other regions cannot be answered. Notes stage filtering is not supported, and directs to realty_reconstruction for 'promising scores'. Provides clear when-to-use and when-not-to-use guidance.

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

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

Beyond annotations (readOnly hint, etc.), the description reveals that rental returns a snapshot, months is ignored for rental, and pyeong_supply is internally converted by 0.745. Also discloses backend limitation (no monthly rental trend as of 2026-07-30), aiding realistic 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?

Well-structured with front-loaded purpose, then region, metric, and pyeong sections. Some details (e.g., backend as-of date) are slightly verbose but not excessive. Could be tightened without losing clarity.

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

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

Covers input semantics thoroughly and mentions return value context (baseline for auction). With an output schema present, explanation of return values is unnecessary. Might lack guidance on handling missing data, but overall complete for a data query 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?

With only 40% schema description coverage, the description compensates thoroughly: explains region formatting with example, metric enum details (rental snapshot vs. price trend), months applicability, and pyeong definitions including conversion and usage rule (only one of two).

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 actual transaction price trends of apartments in a region, with a specific verb and resource. It distinguishes from sibling tools by focusing on regional stats and explicitly positioning itself as a baseline for auction price judgment.

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: tells when to use (baseline for auction prices), when not to use rental for trends, and how to format region names. Contrasts price and rental modes, and clarifies that months is ineffective for rental, which helps avoid 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 indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral details: price metric requires at least 5 transactions and may have incomplete data for the latest month; growth uses a fixed 60-85㎡ pyeong type to avoid distortion. These go beyond the annotations without contradiction.

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

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

The description is well-structured, starting with the core purpose, then bullet-like explanations of each metric. It is somewhat verbose but every sentence adds value. The front-loading of purpose helps agents quickly grasp the tool's function.

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 4 parameters, annotations, and an output schema, the description is thorough. It covers the ranking logic, each metric's derivation, and even instructs to reflect methodology in answers. No gaps are apparent for typical use cases.

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

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

Schema description coverage is 75% (limit missing). The description adds meaning to the 'metric' parameter by explaining each option's calculation (e.g., 'growth=전용 60-85㎡ 고정 YoY(평형 구성 왜곡 제거)') and clarifies that 'region' can be a city or district to filter rankings. This adds context beyond the schema's brief descriptions.

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

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

The description clearly states the tool's purpose: ranking regions (시군구) by various metrics like price, growth, investment, transit, school. It includes example questions and distinguishes itself from related tools (e.g., realty_region_price_stats) through the scope of metrics and ranking orientation.

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 example queries (e.g., '제일 비싼 동네 어디야?') indicating when to use this tool. It explains each metric's context (e.g., growth filters out distorted averages). However, it does not explicitly state when not to use this tool or name alternatives beyond the sibling tools list.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate safe, read-only behavior. The description adds the critical note that the tool is 'paid' (유료), which is a key behavioral trait not captured in annotations. It also clarifies that data is returned by district (시군구별), adding context beyond the schema.

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

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

The description is a single, well-structured sentence that front-loads the key purpose and use case. It is concise without being overly terse, though it could be slightly more 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 that an output schema exists, the description does not need to detail return values. The description covers the tool's input region granularity and core metrics. Combined with annotations, it provides sufficient context for an agent to understand the tool's role.

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 does not add significant meaning beyond what is already in the parameter descriptions; it merely summarizes the output. This is adequate but not exceptional.

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 monthly rental yields, average sale prices, and average monthly rents by region, and explicitly mentions its use case for yield investment screening. While it doesn't explicitly differentiate from siblings, the focus on rental yields distinguishes it from related 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 description implies usage for investment screening but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. No alternative tools are referenced.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior. Description adds crucial behavioral caveats: potential inconsistency between fail_count and min price due to collection timing, and fact that returned list has only summary fields. This provides transparency 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?

Description is well-structured: purpose front-loaded, then warning note, then instruction about summary fields. All sentences are informative. Slightly verbose but each part earns its place; no redundant 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?

Given complexity (9 params, output schema exists), description covers essential behavioral details (pagination via offset, price unit, data inconsistency caveat) and links to related tools for full info. Output schema handles return fields, so description doesn't need to repeat. Complete for agent's needs.

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

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

Schema coverage is 100%, so parameters are well described in schema. Description adds value by clarifying price unit (manwon) with example (5억=50000) and explaining effect of min_bid_count on price. However, this is marginal improvement; 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 tool filters court auction items by region, type, appraised price, and number of failed bids (specific verb '조회한다' and resource). It distinguishes from sibling tools by noting that list contains summary fields, and full details require realty_get_auction_case, while schedule info is in realty_auction_history. Purpose is precise and well-differentiated.

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 implicitly guides when to use this tool: for listing filtered auction items, while full details or history should use other tools. It mentions realty_auction_history for schedule and realty_get_auction_case for complete info. Though not explicit about when not to use, the context is clear enough for an agent to decide.

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, destructiveHint false. The description adds valuable behavioral context: response is heavy (limit note), pyeong_exclusive vs pyeong_supply_est distinction, avg_price is mixed average. 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 compact (4 sentences) and front-loaded with purpose, then usage guidelines, then data field hints. Every sentence adds value without redundancy.

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

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

Given the output schema exists, the description does not need to explain return values. It covers search criteria, result field usage, and inter-tool relationships completely for an agent.

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

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

Schema coverage is 100%, but the description adds meaning for all parameters: query is partial name, region is city/district, period_months for aggregation, limit notes heavy response, sort explains order, page starts at 0. This goes beyond 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 searches apartment complexes by name/region and returns actual transaction prices by pyeong type. It distinguishes from siblings by specifying it is the primary tool for pyeong-specific price queries and mentions related tools via complex_key.

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

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

The description explicitly states this is the primary tool for queries like '○○아파트 34평 얼마야', requires either query or region, warns against using avg_price for pyeong questions, and advises using pyeong_supply_est to match user's '34평'. It also mentions complex_key usage in other 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?

Discloses that the report is sent to server operators for correction and that the tool should be followed by a corrected answer. Annotations (readOnlyHint=false) are consistent with a write operation. 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?

Four sentences, all necessary and front-loaded. No fluff, clear instructions.

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

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

Given 5 parameters (1 required) and the existence of an output schema, the description sufficiently covers the tool's purpose, usage, and behavior. No 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 100% with detailed descriptions, so the description adds no new parameter-specific meaning beyond what the schema already provides.

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

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

The description explicitly states the tool reports errors in answers derived from server data, with specific user phrases that trigger its use. It is clearly distinct from sibling tools, which are all data retrieval or analysis 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 clear when-to-use (user points out error), when-not-to-use (do not call based on guesswork), and ordering (call before correcting). No sibling tool serves a similar purpose, so no alternative needed.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds beyond annotations by explaining it's a minimal adapter that cannot handle all axes (area, date, floor) and that unapplied_conditions will be populated in the response, warning against misinterpreting narrow results.

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

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

The description is concise at five sentences, front-loading the main purpose and examples, then limitations and fallback. Every sentence is informative without repetition, though slightly verbose for a simple 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?

Given the simple input (one parameter), an output schema (implied), and comprehensive annotations, the description is complete. It covers the limitation, fallback, and how to use results with fetch. Slight deduction for not explicitly stating the output structure, but the output schema presumably does that.

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 0% schema description coverage, the description fully compensates by explaining the 'query' parameter should contain region, property type, number of bids, appraised value, and provides concrete examples. This adds substantial meaning beyond the bare 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 searches court auction properties using natural language. It specifies the verb '검색한다' (search) and the resource '법원경매 물건' (court auction properties). It also distinguishes itself from sibling tool 'realty_search_auctions' by noting when to use that alternative.

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 guidance on when to use this tool (natural language search for court auctions) and when not to (when unapplied_conditions is non-empty, use realty_search_auctions). It also provides examples and suggests using fetch(id) for details, offering 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.