Skip to main content
Glama
Sign In

korea-realty

by app.sallim
OverviewDiscussionsAdmin

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

realty_loan_eligibility
Read-onlyIdempotent

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

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

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

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

Input 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. Changed2 schema fields changed
    • changedInput schema / properties / total_assets_10k / anyOf
      Previous value: -[
-  {
-    "minimum": 0,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / total_assets_10k / description
      Previous value: -"총자산(만원) — **버팀목 전세는 자산 요건이 핵심 관문**이라 전세 문의면 받아라"New value: +"순자산(만원, 자산−부채 — 부채가 더 많으면 음수) — 버팀목·디딤돌 자산 요건은 **순자산가액** 기준이다. **버팀목 전세는 자산 요건이 핵심 관문**이라 전세 문의면 받아라"
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_loan_eligibilityDictOutput",
-  "type": "object"
-}New value: +null
  3. Changed1 schema field changed
    • changedInput schema / properties / homes_owned / description
      Previous value: -"**세대 기준** 보유 주택 수(선언) — 0=무주택, 1, 2+=다주택. 명의가 갈려도 세대로 센다. 서버는 주택 수를 판정하지 않는다"New value: +"**세대 기준** 보유 주택 수(선언) — 0=무주택, 1, 2+=다주택. 명의가 갈려도 세대로 센다. 서버는 주택 수를 판정하지 않는다 (허용 범위 0~9)"
  4. 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: +[
+  "구입",
+  "전세",
+  "생활안정",
+  "전세반환",
+  "중도금"
+]
  5. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context on top: inputs like homes_owned/first-time/newlywed are declarations the server does not fact-judge, limits are deliberately not calculated here, and rule uncertainty lives in each product `topic`. This is substantive disclosure well beyond what annotations provide.

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 core purpose is front-loaded and each boundary clause carries useful information. It is somewhat verbose, with bold markup and meta-narrative (the pinned date, '이 도구가 존재하는 이유') that could be trimmed, but the structure remains readable and front-heavy.

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 still tells the agent what comes back (usable products plus reasons for exclusion, and the `topic` pointer for rule basis/uncertainty). All 8 parameters are documented in the schema, and the read-only safety profile is covered by annotations, so an agent has everything needed to call this correctly.

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 per-parameter descriptions are already extremely rich (defining 세대 기준, 순자산, 전세 vs 전세반환 direction). The description only restates that purpose/region/homes are the judgment axes and adds no syntax or format detail beyond the schema. Baseline 3 is correct when the schema carries the load.

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 action (side-by-side eligibility judgment) on a specific resource (loan products), with the exact axes (purpose × region × homes owned). It explicitly names the sibling it is not (realty_loan_limit) and explains its router role, so an agent can distinguish it from siblings 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?

Gives explicit when-to-use (the caller does not know which of the 7 rule topics to ask), an explicit alternative (realty_loan_limit handles limit amounts for purchase-purpose bank loans), and explicit when-NOT-to-expect-calculations (jeonse/mid-payment governed by guarantee agencies, jeonse-return being document-based). Routing guidance is unambiguous.

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

All korea-realty toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources