Skip to main content
Glama

korea-realty

by app.sallim

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

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부부합산 연소득(만원) — 정책상품 소득요건 대조에 쓴다

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, the description discloses that declarations like home count, first-time, and newlywed are not fact-checked by the server, that the tool does not compute limits for certain categories, and that rule uncertainty lives in the result's topic field. This is exactly the behavioral context an agent needs.

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 description is dense but structured clearly with bolded sections and numbered boundary. It has some redundancy with the title and includes a historical rationale that could be trimmed, but each sentence conveys a reason why. It is more thorough than concise, which is justified for a cross-product routing tool.

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?

The description fully compensates for a missing output schema: it says the response contains eligible products and reason, and references the topic field for rule details. It covers edge cases like declarations, non-computed limits, and boundary reads for a tool with 8 parameters and multiple cross-cutting rules.

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?

The input schema already provides 100% parameter coverage with rich descriptions, including the warning not to confuse 전세 and 전세반환 and the role of total_assets_10k for. The description adds routing context but no additional per-parameter meaning, so the 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?

The description states the tool's specific job: given purpose, region, and homes-owned, it lists allowable loan products side-by-side with reasons, acting as a router so the caller does not need to know a rule topic. It also clearly distinguishes itself from realty_loan_limit, which handles loan amount calculation.

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?

The description gives explicit when and when-not guidance: use this tool for eligibility or routing, use realty_loan_limit for purchase limit amounts, and do not expect limits for jeonse/midterm-loan categories because those are governed elsewhere. It also instructs the caller to read the returned topic for rule details.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources