Skip to main content
Glama

korea-realty

by app.sallim

조합원 지위양도 가능 판정 — 투기과열지구×사업유형×단계 (도시정비법 39조)

realty_member_transfer_check
Read-onlyIdempotent

투기과열지구에서 재건축·재개발 물건을 지금 사면 조합원 지위를 승계받을 수 있는지를 도시정비법 39조 2항으로 결정론 판정한다 — 투기과열지구 여부(regulated_area) × 사업 유형 × 진행 단계(서울은 정보몽땅 목록에서 자동 결합). "한남3구역 지금 사도 입주권 나와?"의 자리다.

경계를 지켜라: ① 판정은 **원칙 제한 여부**까지다 — 예외(양도인의 근무·질병·상속·해외이주,
10년 소유+5년 거주 등)는 양도인 사정의 사실판단이라 갈림길로만 주고, **사업지연 예외
3종은 인가일·착공일 데이터가 없어 판정 불가를 실토한다**. ② 재개발엔 부칙 함정(2018-01-25
이전 사업시행인가 신청 구역은 제한 밖)이 있어 선언 없이는 단정하지 않는다. ③ 제한이 없어도
**토지거래허가구역은 별개 제도**다(서울 전역 지정 중 — 실거주 의무 등). ④ 조문 원문·예외
전체 목록은 realty_policy_rules(topic=redevelopment_rules), 투기과열 지정 현황은
topic=regulated_area, 분양자격 자체가 불확실하면 topic=redevelopment_entitlement,
사업장 목록·단계 열람은 realty_redevelopment. 응답의 exceptions·disclosures를 함께 전하라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNo사업장 소재지(시군구까지, 예: '서울 용산구'·'성남시 수정구') — 투기과열지구 판정과 (서울이면) 단계 자동 조회에 쓴다. 모호하면 후보를 돌려주니 is_speculation_zone을 직접 선언해도 된다
project_nameNo사업장·구역 이름(예: '한남3구역') — 서울이면 정비사업 목록에서 진행 단계를 자동으로 잇는다(유일 매치만). 서울 밖은 목록이 없어 project_stage 선언이 필요하다
project_typeYes사업 유형 — 제한 개시 시점이 갈린다(재건축=조합설립인가 후, 재개발=관리처분인가 후). 가로주택·소규모재건축 등 소규모정비사업은 별도 법제라 이 도구가 판정하지 않는다
project_stageNo진행 단계 직접 선언 — project_name 조회 대신/우선 적용. 허용값은 서울 정비사업 목록(정보몽땅)의 실측 어휘 전량이라, **자동 조회가 돌려준 stage를 그대로 다시 넣으면 같은 판정이 재현된다**(예: '철거'·'철거 및 착공'·'추진위구성')
is_speculation_zoneNo투기과열지구 여부 직접 선언 — region 대신/우선 적용
first_approval_application_after_20180125No**재개발 부칙 선언** — 이 구역의 최초 사업시행계획인가 신청이 2018-01-25(법률 제14943호 시행일) 이후인가. 이전이면 관리처분인가 후에도 지위양도가 가능하다(서울 22개 구역 실재). 모르면 비워두라 — 서버가 미확인으로 실토한다

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the readOnly/idempotent annotations by disclosing actual behavior: the outcome is deterministic ('결정론적'), it only returns the general restriction not the transferor-specific exceptions ('갈림길로만 주고'), and it will ambiguously semantics '실토한다' (admit it cannot determine) when data is missing. It also exposes the 2018-01-25 renewable account trap and instructs that exceptions/disclosures be conveyed to the user — which is exactly the kind of unsaid runtime behavior an agent could not infer from annotations.

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

Conciseness5/5

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

The core purpose is front-loaded in the first sentence, immediately followed by a concrete user question ('한남3구역 지금 사도 입주권 나와?') to anchor the agent. The following paragraph is superficially long, but each numbered clause contributes a boundary/referential constraint that keeps the tool from being misused, and with no output schema this dense listing is earned. Nothing is fluff.

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

Completeness5/5

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

Despite having no output schema, the description tells the agent what the tool will and won't produce: it will return a determination of the main supplier/restriction, hand off transferor exceptions as a decision-tree branch, and explicitly give '판정 불가' where data is absent. It also names response fields exceptions and disclosures (`응답의 exceptions·disclosures를 함께 전하라`) the exact behavior the agent must preserve, making the whole conversational contract complete.

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

Parameters3/5

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

The input schema already provides descriptions for all 6 parameters, with coverage of 100%, so baseline is 3. The tool description does not provide parameter-specific syntax details beyond what the schema already says; it merely repeats the tripartite structure (regulated_area × project_type × stage) in a sentence. Despite some hints about auto-combination for Seoul and the refusal to assert without first_approval declaration, the schema itself already contains this, so no meaningful additional meaning is added.

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

Purpose5/5

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

The description states a specific verb+object: '도시정비법 39조 2항으로 결정론적 판정한다' and defines the actual question '지금 사면 조합원 지위를 승계받을 수 있는지' — the core decision. It also draws a contrast with where to go for the source text, exemption lists, and entitlement, so the tool is clearly distinguishable from siblings.

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

Usage Guidelines5/5

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

The '경계를 지켜라' section explicitly directs the agent to realty_policy_rules with different topics for the oracle text, for the speculation zone status, and for entitlement uncertainty, and to realty_redevelopment for project-only list/stage. It also names what the tool does not decide (transferor factual exceptions, land transaction zone, small-scale projects in the schema) — explicit when/when-not guidance.

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

All korea-realty toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count1/5

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.

Completeness5/5

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.

Resources