Skip to main content
Glama

분양 자금 흐름 판정 — 계약금·중도금·잔금 시점별 필요액 × 대출 규제 상한

realty_presale_funding_plan
Read-onlyIdempotent

공고 하나에 대해 **"내 자기자금으로 닫히는가"**를 결정론으로 판정한다 — 시점별 (계약금→중도금 회차→잔금) 필요액, 잔금 시점의 필요 대출액, 그 대출이 규제 상한 (LTV·가액구간 한도·DSR — realty_loan_limit과 같은 엔진) 안에 드는지, 부족하면 얼마가 부족한지. "이 분양 당첨되면 진행 가능해?"류 질문의 자리다.

경계: ① 차주 유형·소득은 **선언**이다(서버는 판정하지 않는다). ② 판정은 **현행
규제·현재 자기자금 기준**이다 — 잔금 시점(수년 뒤)의 규제·금리·저축 증가는 반영하지
않으며 그 사실을 assumptions에 싣는다. ③ 승인·확약이 아니다. ④ 저축 계획·갈아타기
전략·매수 적정성 판단은 이 도구 밖이다 — 시세 비교는 realty_presale_vs_market,
규칙 원표는 realty_policy_rules. 응답의 assumptions·uncertainties를 함께 전하라.
⑤ 입주시 시세·전세보증금도 **선언**이다 — 선언하면 각각 시세 기준 잔금대출 시나리오
(scenario_at_expected_price)와 전세 잔금 시나리오(jeonse_scenario — 거주의무·대출
병행 불가 게이트)를 병렬로 준다. 서버는 미래 시세·전세가를 추정하지 않는다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lenderNo업권은행
regionNo규제 판정용 지역 덮어쓰기 — 생략하면 공고 소재지로 판정한다
borrowerYes잔금대출 차주 유형(사용자 선언 — realty_loan_limit과 동일 계약). 계약자 명의 기준으로 선언하라
house_tyNo주택형 (예: '59', '84B')
is_metroNo수도권 여부 직접 선언
movein_ymNo입주 년월 YYYYMM 덮어쓰기 — 공고에 입주예정이 없으면 이걸 안 주는 한 총 소요자금이 계산되지 않아 자금 판정도 못 한다(realty_presale_cost와 같은 계약·같은 이름). 후보는 realty_presale의 move_in_ym
rate_typeNo잔금대출 금리유형 — realty_loan_limit과 동일 계약. 기본 '변동'은 스트레스 금리 전액 가산이라 가장 보수적이다(안 닫힌다는 판정이 유형 때문일 수 있다)변동
floor_zoneNo층 구분(예: '5~9층') — 생략하면 첫 밴드로 계산하고 나머지 밴드 총액을 병기한다
is_regulatedNo규제지역 여부 직접 선언
mid_rate_pctNo중도금 대출 연이율 %(기본 5.0) (허용 범위 0 초과~20)
own_funds_10kYes동원 가능한 자기자금(만원) — 계약금부터 잔금까지 전액 투입 가정으로 계산한다. 0도 유효하다(전액 대출 시나리오 — 계약금 게이트에서 정직하게 걸린다)
credit_loan_10kNo신용대출 잔액·예정액(만원) — realty_loan_limit과 동일 계약(서버가 산정만기 5년 규제식으로 계산한다). 직접 연 원리금을 계산해 넣지 마라
house_manage_noYes공고 관리번호 (realty_presale의 house_manage_no)
loan_term_yearsNo잔금대출 만기(년) (허용 범위 1~50)
rate_fixed_yearsNo혼합형 고정기간 또는 주기형 변동주기(년) — 미지정 시 5년 가정 (허용 범위 0~50)
annual_income_10kNo차주 연소득(만원) — 주면 잔금대출의 DSR 상한까지 반영해 판정한다
extra_options_krwNo발코니 외 유상옵션 합계(원)
interest_rate_pctNo잔금대출 약정금리 가정(%) (허용 범위 0 초과~20)
jeonse_deposit_10kNo입주 시점 예상 전세보증금 선언(만원) — 주면 '세입자 보증금으로 잔금 치르기' 시나리오를 판정한다(거주의무·대출 병행 불가 게이트 포함). 시세 확인은 realty_complex_rent_by_pyeong·region_price_stats(metric=rental)
credit_loan_rate_pctNo신용대출 약정금리(%) — credit_loan_10k를 줬으면 필수 (허용 범위 0 초과~20)
expected_price_at_movein_10kNo입주(잔금) 시점 예상 시세 선언(만원) — 잔금대출 LTV는 실무상 입주시 시세·감정가 기준이라, 선언하면 그 값 기준 판정을 병렬로 준다. 서버는 미래 시세를 추정하지 않는다(선언 없으면 분양가 기준만)
existing_annual_debt_payment_10kNo기존 대출 연간 원리금(만원)

TDQS

A4.6/5.0
Behavior5/5

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

Even with `readOnlyHint: true` and `idempotentHint: true`, the description adds valuable behavioral context: it is not an approval, it only reflects current regulations and current funds, it intentionally ignores future market changes, and it does not infer future sale/jeonse prices. It also states that response `assumptions` and `uncertainties` should be conveyed, and that optional declarations trigger parallel scenarios.

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

Conciseness5/5

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

The description is long but every sentence of it contributes: it opens with a precise single-sentence judgment and then groups all boundaries into numbered, scannable items. The use of bolded terms, self-contained bullet sections, and explicit sibling names means there is no wasted or repetitive prose.

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 tool with 22 parameters and no output schema, the description covers the most important contextual ground: core calculation flow, consumer interpretation of input declarations, parallel scenarios, and decisive limitations. Some fine return-structure detail is left implicit, but given the very complete schema cascades of this, the remaining gap is small.

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 schema already covers 100% of parameter descriptions, giving it the baseline score of 3 without needing detailed parameter repetition in the tool description. The tool description does set a high-level declaration-led framing for borrower type and future price inputs, but that level of detail is already reflected clearly in the input schema itself.

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 exact purpose: 'does this presale close using my own funds?' and gives the deterministically evaluated values: required funds at each payment stage, the necessary final loan amount, whether it fits regulatory caps (LTV/value-band/DSR), and the shortfall. It also clearly names the question type this handles ('이 분양 당첨되면 진행 가능해?') and distinguishes itself from sibling tools by listing what it does not cover.

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 exclusion criteria and alternates: savings planning, refinancing strategy, market-price comparison, and policy rule lookup are called out as outside the tool, with `realty_presale_vs_market` and `realty_policy_rules` named. It also states that the server does not judge borrower type/income and does not estimate future prices or jeonse, so an agent knows exactly when to rely on declarations.

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.

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.