리치고 부동산 (Richgo)

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description earns extra credit by disclosing the shape and breadth of the payload (profile fields + per-size estimates, trades, listing count, asking-price range, absorption period), which is valuable since there is no output schema.

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

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

The core resource and its fields are front-loaded in the first clause. The Korean sentence largely restates the English one, which costs some space, though it does add '매물 소화 기간' (listing absorption period) that the English omits.

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

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

With no output schema, the description carries the return-value burden and does so thoroughly across both profile and pricing dimensions. Minor gaps remain around error behavior for an invalid or stale danji_id, but for a single-object read this is close to 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?

Only one parameter, and the schema already documents it fully with 100% coverage ('7자리 단지 ID from search_apartments'). The description adds no format, validation, or sourcing detail about danji_id, 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 names the concrete resource — an apartment complex profile plus per-floor-plan prices — and enumerates exactly which fields are returned (households, completion date, builder, FAR, parking, estimated sale/jeonse, latest trade, listings). An agent can distinguish it from siblings like get_recent_trades or get_fair_asking_price by content, though it never explicitly contrasts itself with them.

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

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

There is no explicit 'use this when' statement or named alternative. The only usage signal is indirect: the schema notes danji_id comes from search_apartments, implying a search-then-overview flow. Usable but left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value by framing the data as a 'Public overview' and by enumerating the exact content scope (schedule history, appraisal notes, rights summary), which tells the agent what will come back without calling the tool. It does not mention pagination or gaps, but neither applies to a single-item read.

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 correctly, and the English field list earns its place, because there is no output schema. However, the Korean sentence repeats the English content almost verbatim, which pads the definition without adding information for an agent that already reads the English. Removing that duplication would make it tighter.

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

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

Because there is no output schema, the description is responsible for explaining the return shape, and it does so comprehensively by naming the case number, court, prices, failed rounds, bidding date, history, appraisal notes and rights summary. Combined with annotations covering the safety profile, an agent has enough to call it correctly. Usage routing to search_auctions is the only missing piece.

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?

There is only one parameter and schema description coverage is 100%, so the schema fully explains auction_id, including its format example (C88PQDUZ) and source. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description opens with a specific statement of what the tool does: 'Public overview of one court auction item,' and then lists every field it returns, so an agent can tell it apart from list-oriented siblings such as search_auctions. Is it explicitly stated that this tool returns a single item rather than a set, but it does not name the sibling it complements or say how it relates to 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?

There is no sentence explaining when to use this tool versus search_auctions or get_auction_stats. The only pointer to an alternative is in the auction_id schema text ('search_auctions 로 얻은'), and that is structured data, not description guidance. The usage pattern (fetch an ID, then get the details) is implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral fact: the window is fixed at 12 months and aggregation is done both monthly and by property type, which tells the agent no custom date range is possible. No rate limits, response size, or error behavior are mentioned.

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 metric list is front-loaded and useful, but the English and Korean sentences are near-verbatim duplicates of each other, roughly doubling length without adding information. The content is otherwise tight with no wasted filler.

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

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

There is no output schema, so the description carries the burden of explaining return shape, and it does: counts, sale ratio, and price ratio, sliced monthly and by property type. An agent knows what it will get; only the nationwide default behavior and relative sizing of results are left implicit.

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

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

Schema description coverage is 100%, and the schema itself documents sd ('비우면 전국') and sgg ('sd 와 함께'). The description only restates 'province/district' and adds no format or interaction detail beyond the 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?

It gives a specific verb+resource ('Court auction statistics') and enumerates the exact metrics returned: auction counts, sale counts, sale ratio, and winning-bid-to-appraisal ratio, broken down monthly and by property type. That clearly distinguishes it from search_auctions and get_auction, though those siblings are never named explicitly.

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

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

Use is implied by the fixed 'last 12 months' window and the region scoping, and the Korean text adds that an empty sd means nationwide (which duplicates the schema). There is no explicit statement of when to choose this over search_auctions or get_region_market, and no exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value by disclosing the return contents (estimated range per floor band, quick-sale level, reference week, listing count) — the 'reference week' being a useful temporal-validity hint absent from structured fields.

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

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

Front-loaded with the core resource and scope, then the usage trigger. Some bilingual redundancy since the Korean restates the English, but overall appropriately sized and each part maps to a needed detail.

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 2-parameter read-only query with no output schema, the description supplies the return dimensions the schema can't, and annotations cover safety. Sufficient for an agent to call it correctly, with only minor gaps around edge cases or formatting.

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 both parameters (danji_id, pyeong) are already documented, including the pyeong default of '대표 평형'. The description adds no parameter syntax or format detail beyond the 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?

States a specific resource (Richgo fair asking-price range) with precise scope: floor bands (low/mid/high), one floor-plan size, plus quick-sale level and listing count. This is clearly distinguishable from price-sibling tools like get_price_history and get_price_forecast_3m, though it doesn't name those siblings explicitly.

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

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

Explicitly tells the agent when to use it: for '이 가격 적당해?' (is this price appropriate?) questions. Clear context is provided, but no exclusions or named alternatives are given for when this tool is the wrong choice.

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, closed-world, so the safety profile is covered. The description does add real context beyond them: the tax basis is 고시 공시가격 and the calculation mirrors the Richgo tax calculator, signalling this is a modeled estimate rather than an official assessment. It stops short of noting exclusions, rounding, or that the figure depends on the current year's rates.

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 the core purpose and the tax components, then the assumptions. The English and Korean sentences are largely duplicative, which costs a little, but the bilingual phrasing is defensible for a Korea-specific real-estate tool and nothing is padded.

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

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

Given a read-only, closed-world, two-parameter compute tool with fully described inputs and no output schema, the definition tells the agent enough to invoke it correctly and interpret the result as an estimate. The only real omission is the scope of the calculation (what taxes/fees are excluded and that results are indicative).

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 both parameters (pyeong, danji_id) are already documented in the schema, including the fallback '비우면 대표 평형'. The description adds only marginal semantics — that the result is keyed to the given size and driven by the complex's published price — which is the expected baseline-3 outcome when the schema does the heavy lifting.

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

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

States a specific computation: this year's holding tax (property tax + comprehensive real estate tax) for one home of a given size, under a single-home owner-occupier assumption, based on the official published price. That is far more specific than the title alone and is distinguishable from all the sibling listing/market tools, though it never names a sibling to contrast with.

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

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

The assumptions embedded in the text ('single-home owner-occupier', 'based on the official published price') implicitly define the conditions where the result is valid, which is genuinely useful routing information. But there is no explicit statement of when to use this versus e.g. get_apartment_overview, nor what happens with multi-home or non-owner-occupied cases.

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

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, so the safety profile is handled. The description adds real value beyond them by disclosing that the result is an estimate produced by a statistical model extrapolating the last 12 months' price trend, and that it is not investment advice.

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

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

The core scope is front-loaded, but the English sentence and the Korean sentence say essentially the same thing, so a meaningful share of the text is duplication rather than added information. The caveat sentence earns its place; the bilingual restatement does not.

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

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

With no output schema, the description does the needed work by naming the returned fields (baseline price, change rate, up/flat/down outlook) and flagging the estimate caveat. Nothing critical is missing for a two-parameter, closed-world read, though expected error/coverage behavior is unstated.

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 danji_id (7-character ID from search_apartments) and pyeong (defaults to the representative floor plan) are already fully documented. The description only restates that the unit of prediction is one complex plus one floor-plan size, adding no syntax or format detail. Baseline 3 applies.

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

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

The description names a specific verb and resource: a 3-month-ahead sale-price forecast for one apartment complex and one floor-plan size, plus what it returns (baseline price, change rate, outlook). Siblings like get_price_history and get_fair_asking_price are implicitly separated by the word forecast/projection, but no sibling is named explicitly.

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

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

"○○아파트 전망" 질문에 쓰세요 gives a concrete trigger tied to a user question shape, and "one floor-plan size" signals a per-floorplan call pattern. It stops short of saying when NOT to use it (e.g., actual historical trades should go to get_price_history) or naming alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the return contents (monthly estimated sale/jeonse prices, 1/3/5-year changes, peak position), which matters since there is no output schema. However, it does not mention limitations such as data freshness, units, or whether the current month is included.

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

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

The description is front-loaded and reasonably short, but it repeats the same content in English and Korean, which adds redundancy for an agent rather than new information. The core meaning is efficient, but the bilingual duplication slightly reduces conciseness.

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, idempotent, 3-parameter tool with no output schema, the description sufficiently explains what is returned: monthly estimated sale/jeonse trends plus 1/3/5-year change rates and peak comparison. Some finer details are absent (e.g., units, data source, handling of missing pyeong), but the description is complete enough for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents danji_id, pyeong, and months clearly. The description adds no parameter-specific syntax or format details beyond what the schema provides; baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states a specific resource and verb: monthly Richgo estimated sale and jeonse price trends for an apartment complex size, including 1/3/5-year change rates and peak comparison. It is distinguishable from siblings like get_recent_trades or get_price_forecast_3m by emphasizing estimated historical trend data, though it does not explicitly name 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?

There is no explicit guidance on when to use this tool versus alternatives such as get_recent_trades, get_apartment_overview, or get_price_forecast_3m. The scope implies a historical trend use case, but the description does not state when-not-to-use or direct the agent to 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's job is to add scope context — and it does: a 3-year lookback window, newest-contract-first ordering, and the MOLIT data source. It does not mention pagination or behavior when no transactions exist, which caps it at 4.

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 the English statement of purpose, then the Korean sentence which is not pure duplication — it adds the 3-year window and the returned field list. Slightly redundant for bilingual readers but each sentence carries distinct 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?

There is no output schema, so the description usefully enumerates the returned fields (contract date, price, floor, building, transaction type, registration date) and discloses the 3-year scope. Combined with full schema coverage and complete annotations, an agent has everything needed to call it correctly; only result-volume/pagination behavior is unstated.

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 all three parameters (danji_id, pyeong, limit) are already documented including defaults and the 30-record cap. The description only echoes the complex-plus-floor-plan scoping, adding no syntax or interpretation beyond the schema. 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 uses a specific verb and resource ("recent recorded sale transactions") and scopes it to one apartment complex plus a floor-plan size, so it is clearly distinguishable from the pricing/forecast siblings like get_price_history or get_price_forecast_3m. It does not explicitly name those siblings, which keeps it from a 5.

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

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

Usage is implied rather than stated: the agent can infer this is the tool for actual recorded transaction prices once a danji_id is known, but there is no explicit 'use this instead of X when Y' or any stated prerequisite beyond the schema's note that danji_id comes from search_apartments. No exclusions or edge-case guidance are given.

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, closed-world and non-destructive, so the safety profile is covered. The description adds genuine beyond-schema context: it discloses the contents of the response and flags conditional availability ('where published') for the contribution basis, warning the agent a field may be absent.

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

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

The response contents are front-loaded, which is good, but the entire English sentence is then repeated verbatim in Korean, adding zero new information and roughly doubling length. Appropriate content, wasteful packaging.

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

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

No output schema exists, so the description carries the return-value burden entirely — and it does so by enumerating each field returned plus the conditional nature of the contribution estimate. Only the pagination/format and error behavior for an unknown site_id are unstated.

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 site_id (source and example format) and previous_asset_manwon (units, example, empty-case behavior) are fully documented in the schema. The description adds nothing about parameters, so it sits at the baseline for a fully-covered 2-param tool.

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

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

Names a specific resource ('redevelopment/reconstruction site') and enumerates exactly what is returned (stage, timeline, AI expected approval month, supply plan, permit history, contribution basis). This clearly contrasts with search_redevelopment, though the description itself never names that sibling — the differentiation is only in the schema.

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

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

The description gives no when-to-use, prerequisites, or alternative routing. The only hint of workflow ('site_id from search_redevelopment') lives in the schema property description, not the tool description, so the description alone leaves usage to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description's main added value is disclosing the return payload's contents, which matters since there is no output schema. It says nothing about behavior when a region is ambiguous or not found, or about default granularity when only `region` is supplied.

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 content is front-loaded with the reportable metrics, which is good. However, the English and Korean sentences are near-verbatim duplicates of the same information, so roughly half the text is redundant for a bilingual-reading agent.

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

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

With no output schema, enumerating returned metrics is genuinely necessary and done. But the tool has zero required parameters, and the description never says whether `region` or `bjd_code` alone suffices, what happens if both are omitted, or what resolution order applies — a meaningful gap for a two-optional-parameter lookup tool.

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

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

Schema coverage is 100% and the schema descriptions are strong — `region` gives concrete format examples and `bjd_code` explains that it comes from a prior result's bjd_code for drilling into sub-regions. The description reinforces the drill-down path by naming sub-regions ranked by price, adding mild context beyond the schema. Nothing new about parameter syntax, but the baseline for full coverage is 3 and the sub-region linkage gives a small lift.

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

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

States a specific resource (province/district/neighborhood apartment market data) and enumerates the metrics returned — price per pyeong, rank, change rates, jeonse ratio, transactions, listings, sub-region ranking. That is far more concrete than a tautology. It does not, however, distinguish itself from siblings like get_apartment_overview, get_recent_trades, or get_price_history, which appear to overlap with subsets of this 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?

Usage is implied by the region granularity (시도·시군구·읍면동) and by the mention of sub-regions ranked by price, which hints at drill-down exploration. But there is no explicit 'use this when…' statement and no guidance on when to prefer get_recent_trades or get_price_history over this aggregated view.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds a content inventory (useful given there's no output schema) but says nothing about error behavior for mismatched level/school_id or any limits on returned nearby apartments.

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 English and Korean sentences say essentially the same thing twice, roughly doubling length without adding information for an agent. The content itself is front-loaded and the field list is dense and useful, but the duplication is real waste.

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

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

With no output schema, the description carries the return-value burden and does it well by enumerating each data block per school level. Gaps are minor: no mention of failure modes, and the school_id→get_school_district dependency appears only in the 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 coverage is 100%, so baseline is 3, but the description adds real meaning: it explains that the admission-data section of the response differs semantically by the 'level' enum value, which the bare enum does not convey. The school_id format guidance lives in the schema rather than the 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 states a specific resource ('School profile') and enumerates exactly what it returns: type, student/teacher counts, province rank, admission outcomes, and nearby apartments. It is clearly distinct from list-style siblings, though it doesn't name get_school_district as its feeder tool in prose (only the schema does).

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

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

Usage is only implied: the description tells you the output varies by school level (special-purpose high school admission rates for middle schools, university entrance for high schools), which implicitly guides level selection. There is no explicit 'when to use this vs. get_school_district' statement or stated prerequisite in the description itself.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive lookup. The description adds useful behavioral scope by disclosing that results are nearest schools ordered by distance and include provincial school-district rank and school IDs, which goes beyond the annotations.

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

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

The definition is short and front-loads the core result: nearest schools, distance, and district rank. The Korean sentence largely duplicates the English one, which is redundant for an AI agent, but the overall size 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?

For a simple two-parameter read-only lookup with full schema coverage and no output schema, the description provides enough context about returned concepts: nearest schools, walking distance, provincial rank, and school IDs. It could be stronger by clarifying how it relates to get_school, but it 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 100%, and both parameters are documented in the schema, including the source of danji_id and the per_level range. The description does not add parameter-level meaning beyond the schema, so the baseline score 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 states a specific resource and operation: nearest elementary, middle, and high schools for an apartment complex, including walking distance and school-district rank. It is clear what data is returned, but it does not explicitly distinguish this tool from the sibling get_school, which could also concern schools.

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 the tool is used for school-district information around a specific apartment complex, but it gives no explicit when-to-use guidance, exclusions, or comparison with get_school. The only helpful routing hint, that danji_id comes from search_apartments, is in the schema rather than the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds beyond that: it names the returned key (danji_id) despite there being no output schema, and positions the call as a prerequisite step in a workflow. It does not say whether multiple candidates may come back for an ambiguous name.

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

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

Three short sentences, front-loaded with the purpose and ending with the actionable sequencing directive. The Korean half is a near-verbatim translation of the English half, which is mild duplication for an agent reader but still compact overall.

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

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

For a one-parameter, read-only resolver with rich annotations and no output schema, the description supplies the essential missing piece (the returned danji_id) and the workflow role. The only gap an agent might hit is handling ambiguous or zero-result queries, which the description leaves unaddressed.

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

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

Schema description coverage is 100% and the single parameter's description already gives examples ('메이플자이, 반포동 래미안'), so the schema does the heavy lifting. The description's 'by name or neighborhood' merely restates that distinction rather than adding format or matching semantics, which is the expected baseline-3 case.

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

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

States a specific verb and resource ('Find Korean apartment complexes by name or neighborhood') and the concrete return value ('get their danji_id'), which no sibling tool claims. The Korean sentence repeats and confirms the same scope, so an agent can distinguish this lookup tool from get_apartment_overview and the other ID-consuming siblings at a glance.

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 closing line '다른 도구를 쓰기 전에 먼저 부르세요' ('call this before using other tools') gives an explicit sequencing rule, which is exactly the guidance an agent needs for a gateway/resolver tool. It stops short of naming a when-not case or explaining what to do when the query is ambiguous, so it is clear context without full exclusion 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?

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds real behavior beyond them by declaring the default sort (nearest sale date first) and enumerating what each result row carries (appraisal value, minimum bid, failed-bid count, sale date). It does not say what happens with zero filters or how results are truncated at the limit.

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

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

Two sentences, purpose front-loaded, no filler. The English and Korean sentences are near-duplicates rather than complementary, which costs a bit of density, but total length stays well within bounds.

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

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

With no output schema, the description usefully names the returned fields, and all six parameters are covered by the schema at 100%, so an agent has enough to call it. The only real gap is default behavior when no filters are supplied and whether sd/sgg must be paired, which is only partially covered in the schema.

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

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

Schema description coverage is 100%, so sd/sgg/court/category/item_type/limit are already fully documented, including the enum and the limit cap — the description only restates the filter axes in prose. It adds no syntax or interaction rules (e.g. whether category and item_type can be combined) beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource (search in-progress Korean court auction items) plus the exact filter dimensions and result ordering. The 'in-progress' scope and plural result set distinguish it cleanly from the singular get_auction sibling without needing the schema.

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

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

Usage is implied by listing the filter dimensions (province/district, court, use type), but there is no explicit when-to-use guidance, no exclusions, and no mention of when to prefer get_auction or get_auction_stats instead. An agent must infer the list-vs-detail split from the names alone.

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

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

Annotations already cover readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds useful context: the 1 km radius, distance-sorted results, and that the return value is a site_id — details not present in 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 English and Korean sentences convey identical content, so roughly half the text is redundant. The useful scope constraint (1 km, distance order, site_id) is present but not front-loaded in a single efficient sentence.

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

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

With no output schema, the description only states that a site_id is returned; it does not indicate what else accompanies it (name, distance, project stage) or how results are ordered beyond 'distance.' Adequate but leaves gaps for an agent interpreting the response.

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

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

Schema description coverage is 100%, so both query and danji_id are already documented with examples and source hints. The description only echoes the two modes and adds the distance-sort detail, which is baseline-appropriate but not compensating beyond the schema.

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

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

States a specific verb (find) and resource (redevelopment/reconstruction project sites) with two search modes (within 1 km of a complex, or by name). It does not, however, distinguish itself from the sibling get_redevelopment, leaving the agent unsure which tool to pick.

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

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

The two modes are implied by 'near an apartment complex (within 1 km) or by name,' but there is no explicit when-to-use-this-vs-get_redevelopment guidance and no stated precondition (e.g., requiring a danji_id from search_apartments even though the schema notes it).

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