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

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 대신/우선 적용
stress_stageNo스트레스 금리 단계 가정. 기본 '현행'. **지방(비수도권 비규제) 주담대만** 갈린다 — 지방은 2026-12-31까지 한시 2단계(0.75%p)이고 이후 연장 여부는 미정이다. '3단계'를 주면 유예가 끝나 3단계(1.5%p×적용비율 3단계)가 그대로 적용되는 가정으로 계산한다. 수도권·규제지역은 이미 3단계라 값이 같다현행
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억 받으려는데 되나요'류 질문의 자리 — 최대치만 받아 모델이 역산하게 두지 마라. credit_loan_rate_pct를 함께 주면 **이 주담대를 먼저 받은 뒤 남는 신용대출 추가 여력**(desired.credit_room_after_mortgage)까지 계산한다 — credit_loan_10k를 주면 그 잔액을 기존 신용대출로 보고 추가분만 센다
rate_fixed_yearsNo혼합형의 고정금리 기간 또는 주기형의 금리변동주기(년). 미지정이면 시중은행 통상인 5년으로 가정하고 가정 사실을 응답에 싣는다. 변동·순수고정에는 무의미 (허용 범위 0~50)
annual_income_10kNo연소득(만원) — interest_rate_pct와 함께 주면 DSR 상한 대출액까지 계산
include_footnotesNotrue면 계산값 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다. 기본은 행마다 한 줄 요지
interest_rate_pctNo약정금리 가정(%, 예: 4.2) — DSR 계산에 필요. 없으면 DSR 금액 계산은 생략된다 (허용 범위 0 초과~20)
credit_loan_rate_pctNo신용대출 약정금리(%) — credit_loan_10k를 줬으면 필수다(이자 없이는 원리금을 못 낸다) (허용 범위 0 초과~20)
existing_annual_debt_payment_10kNo기존 대출의 연간 원리금 상환액 합계(만원) — DSR 계산에서 차감

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_footnotes
      Added value: +{
      +  "default": false,
      +  "description": "true면 계산값 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다. 기본은 행마다 한 줄 요지",
      +  "title": "Include Footnotes",
      +  "type": "boolean"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / desired_loan_10k / description
      Previous value: -"받으려는 주담대 금액(만원). 주면 '이만큼 되나'를 판정하고, DSR에 막히면 **무엇을 얼마나 바꾸면 들어가는지**(금리유형·만기·신용대출 축소·금리)를 함께 낸다. '4억 받으려는데 되나요'류 질문의 자리 — 최대치만 받아 모델이 역산하게 두지 마라"New value: +"받으려는 주담대 금액(만원). 주면 '이만큼 되나'를 판정하고, DSR에 막히면 **무엇을 얼마나 바꾸면 들어가는지**(금리유형·만기·신용대출 축소·금리)를 함께 낸다. '4억 받으려는데 되나요'류 질문의 자리 — 최대치만 받아 모델이 역산하게 두지 마라. credit_loan_rate_pct를 함께 주면 **이 주담대를 먼저 받은 뒤 남는 신용대출 추가 여력**(desired.credit_room_after_mortgage)까지 계산한다 — credit_loan_10k를 주면 그 잔액을 기존 신용대출로 보고 추가분만 센다"
    • addedInput schema / properties / stress_stage
      Added value: +{
      +  "default": "현행",
      +  "description": "스트레스 금리 단계 가정. 기본 '현행'. **지방(비수도권 비규제) 주담대만** 갈린다 — 지방은 2026-12-31까지 한시 2단계(0.75%p)이고 이후 연장 여부는 미정이다. '3단계'를 주면 유예가 끝나 3단계(1.5%p×적용비율 3단계)가 그대로 적용되는 가정으로 계산한다. 수도권·규제지역은 이미 3단계라 값이 같다",
      +  "enum": [
      +    "현행",
      +    "3단계"
      +  ],
      +  "title": "Stress Stage",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "realty_loan_limitDictOutput",
      -  "type": "object"
      -}New value: +null
  4. Changed4 schema fields changed
    • changedInput schema / properties / credit_loan_rate_pct / description
      Previous value: -"신용대출 약정금리(%) — credit_loan_10k를 줬으면 필수다(이자 없이는 원리금을 못 낸다)"New value: +"신용대출 약정금리(%) — credit_loan_10k를 줬으면 필수다(이자 없이는 원리금을 못 낸다) (허용 범위 0 초과~20)"
    • changedInput schema / properties / interest_rate_pct / description
      Previous value: -"약정금리 가정(%, 예: 4.2) — DSR 계산에 필요. 없으면 DSR 금액 계산은 생략된다"New value: +"약정금리 가정(%, 예: 4.2) — DSR 계산에 필요. 없으면 DSR 금액 계산은 생략된다 (허용 범위 0 초과~20)"
    • changedInput schema / properties / loan_term_years / description
      Previous value: -"희망 만기(년). 수도권·규제지역은 30년 상한으로 조정되며 조정 사실을 응답에 싣는다"New value: +"희망 만기(년). 수도권·규제지역은 30년 상한으로 조정되며 조정 사실을 응답에 싣는다 (허용 범위 1~50)"
    • changedInput schema / properties / rate_fixed_years / description
      Previous value: -"혼합형의 고정금리 기간 또는 주기형의 금리변동주기(년). 미지정이면 시중은행 통상인 5년으로 가정하고 가정 사실을 응답에 싣는다. 변동·순수고정에는 무의미"New value: +"혼합형의 고정금리 기간 또는 주기형의 금리변동주기(년). 미지정이면 시중은행 통상인 5년으로 가정하고 가정 사실을 응답에 싣는다. 변동·순수고정에는 무의미 (허용 범위 0~50)"
  5. Changed3 schema fields changed
    • addedInput schema / properties / credit_loan_10k
      Added value: +{
      +  "anyOf": [
      +    {
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "신용대출 잔액 또는 받을 예정액(만원). **직접 연 원리금을 계산해 넣지 마라** — 산정만기 5년 강제·산식 두 갈래·스트레스 1억 문턱이 전부 함정이라 서버가 계산한다. existing_annual_debt_payment_10k와 함께 주면 둘 다 합산한다",
      +  "title": "Credit Loan 10K"
      +}
    • addedInput schema / properties / credit_loan_rate_pct
      Added value: +{
      +  "anyOf": [
      +    {
      +      "exclusiveMinimum": 0,
      +      "maximum": 20,
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "신용대출 약정금리(%) — credit_loan_10k를 줬으면 필수다(이자 없이는 원리금을 못 낸다)",
      +  "title": "Credit Loan Rate Pct"
      +}
    • addedInput schema / properties / desired_loan_10k
      Added value: +{
      +  "anyOf": [
      +    {
      +      "exclusiveMinimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "받으려는 주담대 금액(만원). 주면 '이만큼 되나'를 판정하고, DSR에 막히면 **무엇을 얼마나 바꾸면 들어가는지**(금리유형·만기·신용대출 축소·금리)를 함께 낸다. '4억 받으려는데 되나요'류 질문의 자리 — 최대치만 받아 모델이 역산하게 두지 마라",
      +  "title": "Desired Loan 10K"
      +}
  6. Changed2 schema fields changed
    • addedInput schema / properties / rate_fixed_years
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 50,
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "혼합형의 고정금리 기간 또는 주기형의 금리변동주기(년). 미지정이면 시중은행 통상인 5년으로 가정하고 가정 사실을 응답에 싣는다. 변동·순수고정에는 무의미",
      +  "title": "Rate Fixed Years"
      +}
    • addedInput schema / properties / rate_type
      Added value: +{
      +  "default": "변동",
      +  "description": "주담대 금리유형 — **스트레스 금리 적용비율이 갈리는 축이다**(변동 100%, 혼합형·주기형은 고정기간 비중별 차등, 순수고정 미적용). 기본값 '변동'은 최악 가정이라 한도가 가장 작게 나온다. 사용자가 상품을 안 정했으면 응답의 by_rate_type 비교표를 함께 전하라. 혼합형=고정기간 후 변동, 주기형=N년 주기로 금리 재산정, 순수고정=만기까지 고정",
      +  "enum": [
      +    "변동",
      +    "혼합형",
      +    "주기형",
      +    "순수고정"
      +  ],
      +  "title": "Rate Type",
      +  "type": "string"
      +}
  7. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real behavioral context: borrower type is a user declaration the server does not adjudicate (echoed in inputs_declared), the output is a ceiling that banks may cut further, DSR swings sharply with rate_type (default '변동' being the worst case), and the agent must relay uncertainties/disclaimer rather than assert 'N억까지만 된다'.

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 purpose is front-loaded and the boundary list is dense and useful for a 17-parameter domain tool, so the length is largely earned. Minor flaws: the circled-number marker ③ is used twice and the third bullet restates guidance already present in the schema, adding slight redundancy.

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 compensates well: it names expected response pieces (inputs_declared echo, dsr.by_rate_type comparison table, desired.credit_room_after_mortgage, footnotes, uncertainties, disclaimer) and explains what changes appear in the output (e.g., maturity adjustment surfaced in the response). An agent has enough to call it and to interpret the result.

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%, so the per-parameter semantics (rate_type axis, stress_stage limited to non-metro, credit_loan_10k traps, desired_loan_10k judging) are already carried by the schema. The description largely restates those same caveats rather than adding new parameter meaning, so the baseline of 3 applies.

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 opening sentence states a specific verb and resource (deterministically computing the mortgage regulatory cap) and enumerates the concrete outputs: LTV cap, metro/regulated-area price-band caps (6/4/2억), 30-year maturity cap, stressed-DSR max loan, and which rule is binding. It even anchors the canonical user question ('10억 집, 생애최초, 연소득 8천이면 얼마까지 나와?'), and names the siblings it is not (realty_policy_rules, realty_presale_funding_plan).

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?

It gives explicit routing: this is the seat for 'how much can I get' questions, while rule tables go to realty_policy_rules, regulated-area status to topic=regulated_area, acquisition-tax rates to topic=acquisition_tax, and time-phased presale funding to realty_presale_funding_plan. It also states a clear exclusion — the result is a regulatory ceiling, not an approval or commitment.

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.