Skip to main content
Glama

주담대 규제 상한 판정 — LTV·한도·만기·DSR (선언 조건 기준)

realty_loan_limit
Read-onlyIdempotent

선언된 조건(지역·시가·차주 유형·소득)에 대해 주담대 규제 상한을 결정론으로 계산한다 — LTV 상한액, 수도권·규제지역 가액구간 한도(6/4/2억), 만기 상한(30년), 스트레스 DSR 반영 최대 대출액과 어느 규제가 최종 상한인지(binding). "10억 집, 생애최초, 연소득 8천이면 얼마까지 나와?"류 질문의 자리다.

경계를 지켜라: ① 차주 유형은 **선언**이다 — 생애최초·주택 수 해당 여부는 사실판단이라
서버가 판정하지 않는다(응답 inputs_declared가 그 선언을 에코한다). ② 결과는 규제
상한이지 **대출 승인·확약이 아니다** — 은행 심사(소득 인정·방공제·신용도)로 더 줄 수
있다. ③ **DSR 상한은 금리유형(rate_type)에 따라 크게 갈린다** — 기본값 '변동'은
스트레스 금리 전액 가산이라 가장 작은 값이다. 사용자가 상품을 안 정한 상태면
`dsr.by_rate_type` 비교표를 함께 전하고 "N억까지만 된다"고 단정하지 마라. ③ 규칙 원표·근거는 realty_policy_rules(topic=loan_rules), 규제지역 지정 현황은
topic=regulated_area, 생애최초 취득세 감면의 세율표 본체는 topic=acquisition_tax.
특정 분양 공고에 대한 시점별(계약금·중도금·잔금) 자금 판정은
realty_presale_funding_plan. 응답의 uncertainties·disclaimer를 사용자에게 함께 전하라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lenderNo업권 — DSR 한도가 은행 40% / 제2금융권 50%로 갈린다은행
regionNo주택 소재지(시군구까지, 예: '서울 마포구'·'성남시 분당구'·'부산 해운대구'). 규제지역·수도권 판정에 쓴다. 해석이 모호하면 후보를 돌려주니 is_regulated·is_metro로 직접 선언해도 된다
borrowerYes차주 유형 — **사용자 선언**이다(서버는 생애최초·주택 수를 판정하지 않는다). 생애최초=본인·배우자 모두 주택 소유 이력 없음, 1주택_처분조건부=6개월 내 기존주택 처분 약정, 서민실수요=우대 요건 충족을 선언한 경우
is_metroNo수도권(서울·경기·인천) 여부 직접 선언 — region 대신/우선 적용
rate_typeNo주담대 금리유형 — **스트레스 금리 적용비율이 갈리는 축이다**(변동 100%, 혼합형·주기형은 고정기간 비중별 차등, 순수고정 미적용). 기본값 '변동'은 최악 가정이라 한도가 가장 작게 나온다. 사용자가 상품을 안 정했으면 응답의 by_rate_type 비교표를 함께 전하라. 혼합형=고정기간 후 변동, 주기형=N년 주기로 금리 재산정, 순수고정=만기까지 고정변동
is_regulatedNo규제지역(투기과열·조정대상) 여부 직접 선언 — region 대신/우선 적용
credit_loan_10kNo신용대출 잔액 또는 받을 예정액(만원). **직접 연 원리금을 계산해 넣지 마라** — 산정만기 5년 강제·산식 두 갈래·스트레스 1억 문턱이 전부 함정이라 서버가 계산한다. existing_annual_debt_payment_10k와 함께 주면 둘 다 합산한다
house_price_10kYes주택 시가(만원 단위, 예: 100000=10억). 가액구간 한도가 '시가' 기준이라 분양가·공시가가 아닌 시세를 넣는다
loan_term_yearsNo희망 만기(년). 수도권·규제지역은 30년 상한으로 조정되며 조정 사실을 응답에 싣는다 (허용 범위 1~50)
desired_loan_10kNo받으려는 주담대 금액(만원). 주면 '이만큼 되나'를 판정하고, DSR에 막히면 **무엇을 얼마나 바꾸면 들어가는지**(금리유형·만기·신용대출 축소·금리)를 함께 낸다. '4억 받으려는데 되나요'류 질문의 자리 — 최대치만 받아 모델이 역산하게 두지 마라
rate_fixed_yearsNo혼합형의 고정금리 기간 또는 주기형의 금리변동주기(년). 미지정이면 시중은행 통상인 5년으로 가정하고 가정 사실을 응답에 싣는다. 변동·순수고정에는 무의미 (허용 범위 0~50)
annual_income_10kNo연소득(만원) — interest_rate_pct와 함께 주면 DSR 상한 대출액까지 계산
interest_rate_pctNo약정금리 가정(%, 예: 4.2) — DSR 계산에 필요. 없으면 DSR 금액 계산은 생략된다 (허용 범위 0 초과~20)
credit_loan_rate_pctNo신용대출 약정금리(%) — credit_loan_10k를 줬으면 필수다(이자 없이는 원리금을 못 낸다) (허용 범위 0 초과~20)
existing_annual_debt_payment_10kNo기존 대출의 연간 원리금 상환액 합계(만원) — DSR 계산에서 차감

TDQS

A4.7/5.0
Behavior5/5

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

The description goes beyond the read-only idempotent annotations: it discloses that the result is a deterministic regulatory cap, that the response echoes inputs via `inputs_declared`, that `dsr.by_rate_type` is provided for rate-type comparison, and that `uncertainties`/ disclaimers must be forwarded. It also warns against overstating 'N억까지만 된다' when the user has not decided the rate type.

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 beginning states the core computation and is followed only by high-value behavioral and routing guidelines; no filler. Although longer than average, every sentence provides either a boundary, an alternative-tool pointer, or a limitation that prevents the agent from giving an incorrect answer.

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?

With no output schema, the description takes on the necessary burden: it names the key response components (`inputs_declared`, `dsr.by_rate_type`, `uncertainties`, `loan_term adjustment`) and important edge cases such as rate-type sensitivity and declared borrower state. It also provides missing sociable boundaries and sibling routing despite the large sibling set.

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?

Parameter descriptions in the input schema already cover 100% of properties, so the baseline is 3. The description adds no new per-parameter syntax or semantics; it does connect the key behavioral parameters (borrower declaration, rate_type, region/regulatory-area) to the larger outcome, but that is not enough for a higher score given the schema already 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 states a specific verb+resource: it computes the regulatory cap for mortgage loans (LTV cap, 6/4/2억 price-band limits, 30-year term cap, and stress-DSR maximum) and gives an example question that anchors the intended use. It also differentiates this from the same-domain siblings by stating that it is the regulatory cap, not a loan approval/commitment, and that policy-rule and presale-funding questions should go to other tools.

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?

Explicit when-to-use guidance is present via the example question and via boundaries: borrower type is only a declared fact, the result is not an approval, and the default variable rate_type is the worst-case assumption. It also says which sibling to use for rule-source and presale-funding cases, and instructs the agent to send the by_rate_type comparison table rather than asserting a single maximum when the user’s product is unspecified.

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.