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 계산에서 차감

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "realty_loan_limitDictOutput",
      -  "type": "object"
      -}New value: +null
  2. 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)"
  3. 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"
      +}
  4. 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"
      +}
  5. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint=true, idempotentHint=true, openWorldHint=true), so the description focuses on behavioral context it *can* add: the rate_type-dependent DSR split (기본값 '변동'이 최악 가정), the declaration-vs-fact boundary for borrower type (inputs_declared 에코), the 'not an approval' caveat, and the mandated transmission of uncertainties·disclaimer. This is rich beyond the annotations. It doesn't quantify rate limits or latency but for a read-only calculator that matters less.

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

Conciseness3/5

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

Front-loaded with the core purpose, followed by three numbered boundary constraints — the intended order is sound. However, the numbering restarts (① appears twice: '① 차주 유형은 선언' and then a second '① 규칙 원표·근거는…', plus a duplicated ③), which is a structural defect in an otherwise dense but information-efficient paragraph. Every sentence earns its place, but the numbering error hurts navigability.

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?

For a 15-parameter, no-output-schema, read-only calculator, the description covers purpose, scope limits, rate_type sensitivity, the by_rate_type comparison instruction, sibling routing, and disclaimer transmission. Missing: explicit pagination or return-shape hints are not needed (no output schema), but the description could state that inputs_declared is echoed (it does) and that it never makes loan-approval claims (it does). It is complete enough for an agent to call and interpret correctly; no output schema means the description carries the return-value burden lightly and handles it.

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

Parameters4/5

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

Schema coverage is already 100%, so the schema documents every parameter fully. The description adds meaning marginally above baseline by explaining *why* default rate_type='변동' produces the smallest limit, why credit_loan_10k should not be hand-computed, and by referencing the by_rate_type comparison table rather than restating param names. Baseline for 100% coverage is 3; the extra modeling guidance on rate_type default and desired_loan_10k semantics lifts it.

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?

States a specific verb (결정론으로 계산한다) and resource (주담대 규제 상한: LTV 상한액, 가액구간 한도, 만기 상한, 스트레스 DSR 최대 대출액). It names the sibling it is *not* — realty_policy_rules (원표·근거), realty_presale_funding_plan (분양 시점별 자금 판정) — and anchors itself with an example query ('10억 집, 생애최초, 연소득 8천이면 얼마까지 나와?'). An agent can route correctly without opening any schema.

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 ('~류 질문의 자리다'), explicit when-not (규칙 원표는 realty_policy_rules, 규제지역 지정은 regulated_area, 취득세는 acquisition_tax, 분양 자금은 realty_presale_funding_plan), and explicit boundaries (대출 승인·확약이 아니다). Alternative routing for the sibling realty_loan_eligibility would have been a bonus but the alternative mapping given is thorough.

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.