Skip to main content
Glama

쓸 수 있는 대출 상품 나열 — 용도×지역×주택수 교차 판정

realty_loan_eligibility
Read-onlyIdempotent

내 조건에서 쓸 수 있는 대출 상품을 상품별로 나란히 판정한다.

**"내 조건이면 어떤 대출을 쓸 수 있나"**를 상품별로 나란히 낸다 — 사용자가 어느 규칙 토픽을
물어야 할지 몰라도 되게 하는 라우터다.

이 도구가 존재하는 이유: 대출 규칙이 상품별 토픽 7곳에 흩어져 있어서, 지금까지는 **호출자가
어느 토픽을 물어야 할지 알아야** 했다(2026-08-14). 용도·지역·주택수만 주면 **쓸 수 있는 상품과
못 쓰는 이유**를 함께 낸다.

경계: ① **주택 수·생애최초·신혼은 선언**이다(서버가 사실판정하지 않는다) ② **한도 금액을
계산하는 건 구입 목적의 은행권뿐**이고 그건 realty_loan_limit이 한다 — 이 도구는 **자격 대조와
라우팅**이다 ③ 전세·중도금은 보증기관·사업장이 지배해 **한도를 계산하지 않는다**, 전세반환은
**경과조치 해당 여부가 서류로 보는 사실판단**이라 계산하지 않는다 ④ 규칙의
근거·불확실성은 각 상품 토픽(응답의 `topic`)에 있으니 함께 읽어라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNo소재지(시군구까지, 예: '서울 마포구'·'세종특별자치시') — 수도권·규제지역 판정에 쓴다
purposeYes자금 용도 — **같은 담보라도 용도가 규제를 가른다**(구입=LTV·가액구간 한도, 생활안정=1억 한도·다주택 금지, **전세반환=세입자에게 보증금 돌려주는 목적(퇴거자금) — 원칙 1억이지만 6·27 이전 계약분 경과조치가 붙는 유일한 축**, 전세=세입자로 들어갈 때 쓰는 전세자금대출, 중도금=집단대출). ⚠️ **'전세'와 '전세반환'을 섞지 마라** — 방향이 반대다. 모르면 물어라
homes_ownedNo**세대 기준** 보유 주택 수(선언) — 0=무주택, 1, 2+=다주택. 명의가 갈려도 세대로 센다. 서버는 주택 수를 판정하지 않는다 (허용 범위 0~9)
is_newlywedNo신혼 해당 여부(선언)
is_first_timeNo생애최초 해당 여부(**선언** — 서버는 판정하지 않는다)
house_price_10kNo대상 주택 가격(만원) — 정책상품 가격요건 대조에 쓴다
total_assets_10kNo총자산(만원) — **버팀목 전세는 자산 요건이 핵심 관문**이라 전세 문의면 받아라
annual_income_10kNo부부합산 연소득(만원) — 정책상품 소득요건 대조에 쓴다

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "realty_loan_eligibilityDictOutput",
      -  "type": "object"
      -}New value: +null
  2. Changed1 schema field changed
    • changedInput schema / properties / homes_owned / description
      Previous value: -"**세대 기준** 보유 주택 수(선언) — 0=무주택, 1, 2+=다주택. 명의가 갈려도 세대로 센다. 서버는 주택 수를 판정하지 않는다"New value: +"**세대 기준** 보유 주택 수(선언) — 0=무주택, 1, 2+=다주택. 명의가 갈려도 세대로 센다. 서버는 주택 수를 판정하지 않는다 (허용 범위 0~9)"
  3. Changed2 schema fields changed
    • changedInput schema / properties / purpose / description
      Previous value: -"자금 용도 — **같은 담보라도 용도가 규제를 가른다**(구입=LTV·가액구간 한도, 생활안정=1억 한도·다주택 금지, 전세=별도 상품군, 중도금=집단대출). 모르면 물어라"New value: +"자금 용도 — **같은 담보라도 용도가 규제를 가른다**(구입=LTV·가액구간 한도, 생활안정=1억 한도·다주택 금지, **전세반환=세입자에게 보증금 돌려주는 목적(퇴거자금) — 원칙 1억이지만 6·27 이전 계약분 경과조치가 붙는 유일한 축**, 전세=세입자로 들어갈 때 쓰는 전세자금대출, 중도금=집단대출). ⚠️ **'전세'와 '전세반환'을 섞지 마라** — 방향이 반대다. 모르면 물어라"
    • changedInput schema / properties / purpose / enum
      Previous value: -[
      -  "구입",
      -  "전세",
      -  "생활안정",
      -  "중도금"
      -]New value: +[
      +  "구입",
      +  "전세",
      +  "생활안정",
      +  "전세반환",
      +  "중도금"
      +]
  4. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare a safe read-only, idempotent profile, and the description adds substantial context beyond them: inputs like home count/first-time/newlywed are self-declared (server does not fact-judge), the tool performs eligibility matching and routing only, and it deliberately does not compute limits. This is rich behavioral disclosure.

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?

Core purpose and the router framing are front-loaded, and the boundary list is well-structured. It is somewhat long with bolded repetition of the routing rationale, but nearly every sentence carries usable information.

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?

No output schema exists, yet the description points to the `topic` field in the response for evidence and uncertainty, and covers the declaration semantics and scope limits. Complete for a routing/eligibility tool of this complexity.

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 schema already documents all eight parameters, including the purpose enum warning about '전세' vs '전세반환'. The description reinforces the purpose/region/home-count axes but adds little syntax or format detail beyond what the schema provides, so baseline 3 is appropriate.

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 (list/judge usable loan products per product) and frames the tool as a router that spares the caller from picking a rule topic. It explicitly distinguishes itself from realty_loan_limit, so an agent can tell them apart without opening either 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?

Names the alternative (realty_loan_limit for purchase-purpose bank loan limits) and the condition that routes to it, plus explicit when-not boundaries for jeonse/mid-payment (no limit calculation) and jeonse-return. Nothing is left to inference.

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.