Skip to main content
Glama

korea-realty

by app.sallim
OverviewDiscussionsAdmin

청약 가점 계산 — 선언된 기간·인원에 배점표(84점) 적용

realty_subscription_score
Read-onlyIdempotent

민영주택 일반공급 청약 가점(만점 84)을 배점표로 계산한다.

민영주택 일반공급 가점제 점수(만점 84)를 **선언된 값**에 배점표를 적용해 계산한다 —
무주택기간 32 + 부양가족 35 + 통장 가입기간 17. "내 청약 가점 몇 점이야?"의 자리다.

경계를 지켜라: ① 세 입력 전부 **선언**이다 — 기산점·부양가족 인정은 등본·혼인관계
사실판단이라 서버가 판정하지 않고, 응답 traps(오기입=부적격 당첨 취소 사유)를 반드시
함께 전하라. ② 산출 점수는 realty_subscription_odds의 my_score로 넘겨 당첨 커트라인과
비교하는 것이 다음 수다. ③ 배점표 원문·기산 규칙은
realty_policy_rules(topic=subscription_account)가 진실원이다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
is_homeownerNo현재 유주택 여부 — True면 무주택기간 점수가 0점이 된다(소형·저가주택 등 무주택 간주 예외 해당 여부는 사실판단이라 호출자가 반영해 선언)
account_yearsYes청약통장 가입기간(년, 소수 허용 — 예: 0.4=약 5개월). 전환 통장은 종전 통장 최초 가입일 기준 (허용 범위 0~60)
no_house_yearsYes무주택기간(년, 소수 허용 — 예: 7.5). 기산점(만 30세 vs 혼인신고일, 유주택 이력 재기산)은 사실판단이라 호출자가 확정해 선언한다 — 응답의 traps를 함께 전하라 (허용 범위 0~60)
dependents_countYes부양가족 수(본인 제외). 직계존속 3년 동거·30세 이상 미혼자녀 1년 동거 등 인정 요건은 사실판단 — 확정해 선언한다 (허용 범위 0~20)
under30_unmarriedNo만 30세 미만 미혼 여부 — True면 무주택기간 점수가 0점이 된다(무주택기간 기산 전)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_subscription_scoreDictOutput",
-  "type": "object"
-}New value: +null
  2. Changed3 schema fields changed
    • changedInput schema / properties / account_years / description
      Previous value: -"청약통장 가입기간(년, 소수 허용 — 예: 0.4=약 5개월). 전환 통장은 종전 통장 최초 가입일 기준"New value: +"청약통장 가입기간(년, 소수 허용 — 예: 0.4=약 5개월). 전환 통장은 종전 통장 최초 가입일 기준 (허용 범위 0~60)"
    • changedInput schema / properties / dependents_count / description
      Previous value: -"부양가족 수(본인 제외). 직계존속 3년 동거·30세 이상 미혼자녀 1년 동거 등 인정 요건은 사실판단 — 확정해 선언한다"New value: +"부양가족 수(본인 제외). 직계존속 3년 동거·30세 이상 미혼자녀 1년 동거 등 인정 요건은 사실판단 — 확정해 선언한다 (허용 범위 0~20)"
    • changedInput schema / properties / no_house_years / description
      Previous value: -"무주택기간(년, 소수 허용 — 예: 7.5). 기산점(만 30세 vs 혼인신고일, 유주택 이력 재기산)은 사실판단이라 호출자가 확정해 선언한다 — 응답의 traps를 함께 전하라"New value: +"무주택기간(년, 소수 허용 — 예: 7.5). 기산점(만 30세 vs 혼인신고일, 유주택 이력 재기산)은 사실판단이라 호출자가 확정해 선언한다 — 응답의 traps를 함께 전하라 (허용 범위 0~60)"
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds meaningful non-obvious behavior: the server deliberately does NOT adjudicate factual questions (기산점, 부양가족 인정) and treats all three inputs as caller declarations, and it warns that response traps (mis-entry can cause disqualification/cancellation) must be relayed to the user. That is real behavioral context beyond the annotations, though the response shape itself is only hinted at.

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?

Purpose and the numbered boundary block are front-loaded and scannable, with every clause doing routing or constraint work. There is mild redundancy — '만점 84' and the 배점표 framing appear twice, and the '선언' caveat is restated across the body and the schema — but no sentence is filler.

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 read-only calculator with no output schema, the description supplies what matters: the input contract (all values are declarations the server will not verify), the downstream hand-off to realty_subscription_odds, and the obligation to surface response traps. It stops short of sketching the returned score breakdown, which would fully close the loop absent an output schema.

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 carries parameter meaning — each property documents ranges (0~60, 0~20), decimal allowances, and the factual-judgment caveats. The description contributes the 32/35/17 weighting scheme, which clarifies relative importance, but adds no syntax or format detail the schema lacks. 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+resource ('민영주택 일반공급 청약 가점을 배점표로 계산한다') and decomposes the 84-point score into its three weighted components (무주택기간 32 + 부양가족 35 + 통장 가입기간 17). It explicitly distinguishes itself from siblings by naming realty_subscription_odds (cutoff comparison) and realty_policy_rules (rule source), so an agent can place it without opening other schemas.

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 routing: this tool produces the score, which should then be passed to realty_subscription_odds as my_score to compare against the cutoff, while the underlying point table and counting rules live in realty_policy_rules(topic=subscription_account). It also frames the natural user intent ('내 청약 가점 몇 점이야?'), leaving no ambiguity about when to select it.

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