Skip to main content
Glama

법령·규제 규범 — 세율표·규제지역·대출·임대차·청약·정비사업 규칙

realty_policy_rules
Read-onlyIdempotent

단지에 종속되지 않는 일반 규범을 근거 조문·확인일과 함께 준다 — 취득세율표, 규제지역 현재 지정 현황, 주담대 규제 원표, 개인회생×대출, 주택임대차 갱신(갱신권· 5% 상한·매수인 실거주 거절), 양도세(세율·필요경비·중과·개편 계류), 청약통장·가점 배점표, 정비구역 요건·조합원 지위양도, 재개발 분양자격 갈림길(서울). "취득세 얼마야?", "갱신권 썼는데 집주인이 팔면?", "지금 팔면 중과야?"류 질문의 자리다. 특정 조건의 상한 계산은 realty_loan_limit, 가점 점수 계산은 realty_subscription_score, 비례율·분담금 계산은 realty_redevelopment_burden, 양도세 시나리오 계산은 realty_capital_gains_tax, 조합원 지위양도 가능 판정은 realty_member_transfer_check — 이 표가 그 계산기들의 진실원이다.

클라이언트에 세율을 하드코딩하지 마라 — "85㎡ 이하 1.1%"는 6억 이하일 때만 맞고,
9억 초과에 그대로 쓰면 수천만원 틀린다(실측: 16.9억 84타입에서 3,700만원 차).

**판정은 하지 않는다**: "이 사람이 1주택인가"는 분양권·상속지분·일시적 2주택 특례가
얽힌 사실판단이다 — 표의 applicable_if·exceptions를 보고 사용자에게 확인 질문을
던져라. 개별 공고의 규제 플래그(공고일 스냅샷)는 realty_presale, 공고 원문 값은
realty_notice_facts, 이 표를 써서 총 소요자금까지 계산하는 건 realty_presale_cost.
응답의 uncertainties(확인 못 한 것)와 disclaimer를 함께 전하라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo**자유문으로 토픽을 찾는다** — 어느 topic인지 모를 때 사용자 말을 그대로 넣어라(예: '종부세 얼마부터 내요'→topic='comprehensive_real_estate_tax', '부모님이 보태주는 돈'→topic='gift_tax_and_funding_source', '전입은 빠른데 확정일자가 늦으면'→topic='auction_rights'). 이름 25개를 외워 고르는 대신 이걸 쓰면 된다. topic 없이 query만 주면 **후보 토픽 목록**이 오고, 후보가 하나면 그 토픽 본문까지 함께 온다. topic과 함께 주면 그 토픽을 그대로 주되 다른 후보가 있으면 알려준다. **아무것도 안 걸리면 지어내지 않고 0건이라고 답한다** — 그때는 이 서버에 그 축이 없는 것이니 표를 추측하지 마라
topicNo**어느 표를 볼지 고른다 — 사용자가 쓰는 말로 찾아라.** axes=상품별 차이·6·27이 뭐에 걸리나·DSR 6축·수도권/규제지역 축 | **횡단 사실의 진실원**(6·27 상품별 적용·DSR 6축·수도권/규제지역·세대/인별/물건 기준 충돌). '어느 상품이 뭐가 다른가'류는 여기부터 — 상품 토픽과 어긋나면 이 표가 맞다, acquisition_tax=취득세·취득세율·다주택 중과·농특세·지방교육세·생애최초 감면 | 취득세율표(표준 구간·중과·부가세목·예외/특례·과표 논점·취득시기), regulated_area=규제지역·조정대상지역·투기과열지구·분양가상한제·토지거래허가 | **현재** 지정 현황, loan_rules=주담대·LTV·DSR·대출한도·스트레스 금리·생애최초 | 주담대 규제 원표(LTV·가액구간 한도·만기·DSR·스트레스 금리·생애최초 절차) — 조건별 판정·계산은 realty_loan_limit, credit_rehab=개인회생·신용회복·면책·공공정보 등록 | 개인회생×신용·대출 규칙 — 공공정보 등록·조기삭제(1년 성실변제, 2025-07)·면책, 기산점(개시≠인가) 함정, lease_rules=전월세·임대차·계약갱신청구권·5% 상한·묵시적 갱신·집주인 실거주 | 주택임대차 갱신 — 갱신요구권(행사기간·거절사유·1회 2년)·5% 증액상한·갱신 후 해지권(3개월)·매수인 실거주 거절 판례(2021다266631), auction_rights=경매 권리분석·말소기준권리·대항력·확정일자·최우선변제·배당요구 | 민사집행법 91조 인수/소멸·주임법 대항력·우선변제권·배당요구·배당순위 — '낙찰받으면 보증금 물어주나'가 여기다. **판정은 안 한다**, 금액표는 realty_small_deposit_check, capital_gains_tax=양도세·양도소득세·세율표·장특공제·필요경비·다주택 중과·이월과세 | 세율표·필요경비 자본적/수익적 분류·중과 현황·2026 개편 계류 — 세액 계산은 realty_capital_gains_tax, **비과세 갈림길은 one_home_exemption_map**, subscription_account=청약통장·청약 가점·배점표·납입 인정·예치금 전환 | 청약통장·가점 규칙(배점표 84점·기산 함정·월 25만원 인정·미납/선납·예부금 전환 2026-09-30 한시) — 점수 계산은 realty_subscription_score, redevelopment_rules=정비구역 지정·노후도 요건·조합원 지위양도·비례율·재건축진단 | 재개발·재건축 — 노후도 60%·서울 조례 지표·39조 지위양도 제한과 예외·비례율 산식. 지위양도 가능 판정은 realty_member_transfer_check, redevelopment_entitlement=재개발 입주권·분양자격·권리산정기준일·뚜껑·도로 지분 | 재개발 분양자격 갈림길 지도(서울 한정) — 5경로·권리산정기준일 3층 경계·확인 체크리스트. 판정은 안 한다, remodeling_rules=리모델링 조합·15년 연한·수직증축·1기 신도시·증축 한도 | 공동주택 리모델링(**주택법** — 도시정비법과 별개 법제): 전용 85㎡ 미만 40%/이상 30%·세대수 15%·수직증축·39조 적용 밖·1기 신도시 특례. redevelopment_rules와 섞으면 오답, one_home_exemption_map=1세대1주택 비과세·2년 보유·2년 거주·12억·일시적 2주택·상속주택·동거봉양·상생임대 | **양도세 비과세 갈림길 지도** — 5관문·5경로+확인 체크리스트. **판정은 안 하지만 무엇을 확인해야 하는지는 다 있다** — 비과세 가능성이 보이면 세무사로 보내기 전에 여기다, comprehensive_real_estate_tax=종부세·종합부동산세·공시가격 문턱·공동명의·보유세 | **종부세 과세 문턱과 명의 축** — 인별 과세라 단독/공동명의가 갈리는 자리. 공시가 기준 문턱·공동명의 특례·2026 개편안(계류). **세액 계산은 안 한다**, gift_tax_and_funding_source=증여세·자금출처·자금출처조사·부모님이 보태주는 돈·차용증·공동명의 지분 | 증여재산공제 문턱 + 소명 — 10년 합산·배우자 6억·직계존속 5천만·혼인출산 1억 통합한도·지분≠기여도면 증여. **세액 계산·절세 설계는 안 한다**, property_tax=재산세·6월 1일 기준일·공시가격 과세표준·보유세 | **재산세(주택분) 구조·기준일·명의 축** — **물건별 과세라 공동명의여도 총액이 같다**(종부세와 반대). 6월 1일 기준일 함정·1주택 특례(2026 일몰). **계산은 안 한다**, jeonse_loan_rules=전세자금대출·버팀목·전세대출 DSR·중소기업 청년 전세 | 자격 + DSR 취급 — 구입자금과 다른 상품군이라 loan_rules 표를 갖다 쓰면 오답. **원금이 DSR에 안 잡히고 이자만**(정책분은 아예 제외). 한도 계산은 안 한다, interim_collective_loan=중도금대출·집단대출·잔금대출 전환·이자후불제 | **분양 중도금(집단)대출 구조·DSR·6억 한도 취급** — 중도금은 DSR 밖이지만 **다른 대출을 받을 땐 내 DSR에 잡히고, 잔금 전환 시 DSR·6억 한도가 걸린다**(계약 통과≠잔금 통과), living_expense_mortgage=생활안정자금·생활자금 대출·보유 주택 담보(구입 아님) | 이미 가진 집을 담보로 — **구입 목적이 아니다**. 수도권·규제지역 **1주택 1억 한도(기존분 합산)·다주택 전면 금지**, DSR은 구입자금과 똑같이 걸린다, jeonse_return_mortgage=전세퇴거자금·전세보증금 반환 대출·세입자 내보낼 돈 | 원칙 1억이지만 **6·27 이전 임대차계약 + 소유권 취득분은 경과조치로 초과 가능**(LTV 70%). 경과조치는 **DSR 예외가 아니다**, auction_balance_loan=경락잔금대출·낙찰 잔금·대금지급기한 | **경락잔금대출**(경매 낙찰 잔금) — 대금지급기한에 대출 실행이 묶이는 구조. 방공제·MCI는 room_deduction_and_mci, funding_plan_report=자금조달계획서·입주계획서·증빙·30일 기한 | **주택취득자금 조달 및 입주계획서** — 제출 대상·증빙·30일 기한과 가족 차용을 적을 때 걸리는 자리, room_deduction_and_mci=방공제·MCI·MCG·실제 대출가능액이 깎이는 이유 | **방공제·MCI/MCG**(매매·경매 공통) — 규제 상한과 별개로 실제 대출가능액을 깎는 구조. 'MCI 되면 4.3억, 안 되면 3.9억'류와 '왜 계약 전에 확정을 못 해주나'의 근거, unit_alteration_rules=내력벽 철거·벽 헐기·욕실 이동·인테리어 허가·층상배관 | 이 집을 내 마음대로 고칠 수 있나 — 내력벽 철거 가부('2016년 유예로 허용'은 통설이고 조문이 깬다)·행위허가 동의율·경미한 행위·층상/층하 배관. 단지별 값은 realty_remodel_feasibility, list=제공 항목 안내(토픽 목차)list
sectionNo**토픽의 하위 항목만 골라 받는다** — 미지정이면 종전과 같이 토픽 전체가 온다. 큰 토픽(auction_rights·unit_alteration_rules·loan_rules)에서 필요한 축만 집을 때 쓴다. 예: topic='auction_rights', section='assumed_regardless_of_rank' → 순위 무관 인수(유치권·법정지상권)만. 쉼표로 여러 개(section='tenant_opposing_power,tenant_priority_payment')도 된다. **없는 이름을 주면 조용히 무시하지 않고 거절하며 유효 목록을 값으로 돌려준다** — 이름을 모르면 section 없이 한 번 부르면 응답 meta.sections_available에 전 목록이 있다. topic='list'에는 하위 항목이 없다

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already carry readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds substantial context beyond those: time-sensitivity ('**현재** 지정 현황', '2026 개편 계류'), the no-judgment boundary ('판정은 하지 않는다'), the no-fabrication promise ('지어내지 않고 0건이라고 답한다'), invalid-section refusal behavior, and the requirement to convey uncertainties and disclaimer ('응답의 uncertainties(확인 못 한 것)와 disclaimer를 함께 전하라'). The hardcoding warning with a concrete measured error (16.9억 84타입 3,700만원 차) is a vivid, actionable behavioral guardrail.

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

Conciseness4/5

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

The description is long but every block earns its place: core purpose is front-loaded ('단지에 종속되지 않는 일반 규범을 근거 조문·확인일과 함께 준다'), followed by question examples, sibling routing, a high-value hardcoding warning with a measured discrepancy, and the no-judgment boundary. It does not repeat schema content. Given the tool's complexity (25-topic enum, 3 params, 49 siblings), the density is justified rather than bloated.

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

Completeness4/5

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

There is no output schema, and the description partially fills that gap by stating the response carries legal basis clauses, confirmation date, uncertainties, and a disclaimer. Combined with the schema's behavioral notes (candidate topic list on query-only, 0-건 answer on no match, meta.sections_available for valid section names), an agent has what it needs to invoke and interpret results. The only minor gap is the absence of an explicit statement of the response envelope (format/size), which is acceptable for a reference-lookup tool.

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?

Schema description coverage is 100%, and the schema's parameter descriptions are already rich — query explains free-text topic search and candidate-list behavior, topic has a 25-value enum with per-value coverage notes, section explains sub-selection and refusal-return behavior. The tool description itself contributes no additional parameter-level meaning beyond this, so the baseline 3 applies: the schema does the heavy lifting.

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 opens with a specific verb and resource — '단지에 종속되지 않는 일반 규범을 근거 조문·확인일과 함께 준다' — and then enumerates exact content areas (취득세율표, 규제지역 현황, 주담대 규제 원표, 임대차 갱신, 양도세, 청약 가점, 정비사업). It explicitly distinguishes itself from siblings by declaring '이 표가 그 계산기들의 진실원이다' and naming realty_loan_limit, realty_subscription_score, realty_redevelopment_burden, realty_capital_gains_tax, realty_member_transfer_check as the calculators. Question examples ('취득세 얼마야?') additionally anchor the tool's territory.

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?

Usage guidance is explicit and bidirectional. It states when to use ('취득세 얼마야?', '갱신권 썼는데 집주인이 팔면?'류 질문의 자리) and when not to ('판정은 하지 않는다' — ask the user confirmation questions instead). It names specific alternatives for specific jobs: realty_loan_limit for limit calc, realty_subscription_score for points, realty_capital_gains_tax for CGT scenarios, realty_presale for notice flags, realty_notice_facts for notice text, realty_presale_cost for total funding. Even topic-level warnings exist: jeonse_loan_rules says 'loan_rules 표를 갖다 쓰면 오답' and remodeling_rules warns 'redevelopment_rules와 섞으면 오답'.

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

Try in Browser

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.