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.4/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/destructive=false, so the bar is lower. The description goes beyond them by disclosing a critical behavioral constraint: it will not adjudicate contested dates/qualifications (사실판단), and it requires traps (misevaluation → disqualification) to be surfaced with the result. It does not describe output shape, but no output schema exists and the trap requirement is the key safety note.

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?

Front-loads the purpose and score composition, then uses numbered boundaries: ① declared inputs + traps, ② next step to odds, ③ source of truth. Every sentence earns its place. However, it is somewhat dense with cross-references and repeated boundary caveats, which slightly reduces crispness.

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?

For a read-only calculator with full schema coverage and no output schema, the description supplies the essential missing context: the declared-not-adjudicated boundary, the trap warning agents must relay, the sibling for comparison, and the policy source of truth. Nothing an agent needs to call it correctly is absent.

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 each parameter description already explains ranges, fractional years, and fact-judgment caveats. The description reiterates the three-part composition but adds no syntax or edge-case details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (계산한다/apply a point table) and resource (민영주택 일반공급 청약 가점, 최대 84점) and names the exact composition (무주택기간 32 + 부양가족 35 + 통장 17). It is clearly distinguishable from sibling realty_subscription_odds, which it explicitly routes to as the next step.

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/when-not/alternatives: it states this handles the declared-value point calculation, that all three inputs must be the caller's declared facts (not server-adjudicated), and that the score should be passed to realty_subscription_odds for odds comparison and that realty_policy_rules(topic=subscription_account) is the source of truth for rules. This is unusually thorough routing guidance.

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