realty_reconstruction[유료] 건령·거래활성 기반 재건축 후보 스크리닝 상위 단지를 조회한다.
점수 = 건령(최대 70, 30년 연한 기준) + 최근 12개월 거래활성 전국 백분위(최대 30).
사업성(용적률·대지지분·안전진단·조합 단계)은 반영되지 않는다 — 후보 발굴용이지
투자 판단 근거가 아니며, 응답의 disclaimer를 사용자에게 그대로 전하라.
(구버전 점수 포화로 2026-07-30 보류했다가 산식 v2 재계산 검증 후 재개 — DATA-060)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | (허용 범위 1~50) | |
| district | No | 지역명 (예: 서울, 구로구). 비우면 전국 상위 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds valuable behavioral context: the score formula (age 70%, transaction activity 30%), the current version status/date (2026-07-30), the fact that the API was temporarily deprecated and resumed, and a mandatory customer disclosure instruction. It also mentions the output includes a disclaimer, which is a behavioral expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and informational. It front-loads the paid/screening purpose first, then the formula, then the caveat and the resumption history. The addition of DATA-060 is a useful internal note. It is appropriately sized for a paid tool with a special data status; a few details could arguably be moved to an external doc, but every line contributes value in this particular context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong given the tool's low complexity: only two optional parameters, an output schema is absent, and annotations carry the safety burden. It covers purpose, scope, input, output expectations, and usage instructions. The main remaining gap is that it does not define exactly what the 'response disclaimer' contains or what the output top-N list looks like, but the output schema is absent and the tool seems intentionally simple. Complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, and the description does not add any new parameter-level semantics. The description's score formula does not explain either 'limit' or 'district' beyond the schema. The baseline for full description coverage is 3. The description does contextualize the result ordering (상위 단지) which relates to how parameters shape the output, but that is indirect, so a 3 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: it queries the top ranked redevelopment candidate complexes based on a '재건축 후보 스크리닝' (reconstruction candidate screening) formula. It distinguishes itself from general searches and related realty tools by specifying the paid nature, the scoring model, and its intended screening-only purpose. Although sibling tools like realty_redevelopment exist, the description explicitly spells out that business feasibility is not reflected, making it distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use this tool: when you need top candidate complexes based on building age and transaction activity. It also says what not to rely on it for (not an investment basis) and tells the agent to pass the disclaimer to the user, which is a user-handling guideline. It does not mention a sibling alternative by name, but the negative scope ('business feasibility not included') helps select among sibling tools. Missing explicit when-not-to-use vs realty_redevelopment, but the absence of business feasibility is a strong cue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The set has very explicit cross-tool guidance and each tool is often given a specific 'role', but there are still many overlapping clusters: auction search vs auction list vs auction detail, regional price bands vs price stats vs rankings, and court auction rate vs public auction rate. The descriptions reduce misselection, but with 51 tools including pairs like `fetch` and `realty_get_auction_case`, confusion is still likely for an agent.
Most tools follow a clean `realty_` prefix and use consistent snake_case noun-phrases or verb-noun patterns, e.g. `realty_search_auctions`, `realty_get_auction_case`, `realty_presale_cost`. The exceptions are the generic `fetch`, `search`, and `report_issue`, which break the uniform prefixed convention but are only a small minor deviation from an otherwise consistent naming system.
51 tools far exceeds the recommended threshold, even for a deliberately broad real-estate area; it is effectively an extreme number for a single MCP server. The tool count becomes the hardest usability problem, since agents must handle many tightly related micro-tools instead of interacting with a smaller, more manageable surface.
The tool set covers an impressively complete range: auction and public-auction workflows, apartment and non-apartment market, presale/cheongyak processes, tax and loan rules, subscription scoring, redevelopment, demographics, supply, POI, and even a reporting and routing tool. Boundaries and unsupported cases are explicitly documented, so there are no major obvious dead ends.