Skip to main content
Glama

korea-realty

by app.sallim

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

realty_subscription_score
Read-onlyIdempotent

민영주택 일반공급 가점제 점수(만점 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점이 된다(무주택기간 기산 전)

TDQS

A4.9/5.0
Behavior5/5

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

The description adds behavior beyond the annotations: the tool computes only on declarations, never judges legal/factual status, and returns traps that must be passed along. This is valuable, non-obvious behavior that the read-only/open-world annotations do not fully express.

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 dense but tightly structured: purpose, scoring formula, then three numbered boundary rules. Each sentence earns its place, and the critical operational cautions are front-loaded.

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?

Given the 5-parameter schema with 100% coverage and no output schema, the description supplies the essential missing context: declarations, legal boundary, trap handling, downstream use, and source of truth. An agent has enough information to call the tool correctly and interpret its role in the larger workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds the scoring decomposition (32 + 35 + 17) that is not present in the input schema, giving the agent a useful mental model of how the parameters combine. Since schema coverage is 100%, the description does not need to repeat ranges or field meanings.

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 precisely what the tool does: it calculates the 민영주택 일반공급 가점제 score (out of 84) by applying the points table to declared values. It clearly distinguishes the tool from downstream siblings like realty_subscription_odds and realty_policy_rules.

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 guidance: inputs are declared, the server does not adjudicate facts, traps must be relayed, the resulting score feeds realty_subscription_odds, and realty_policy_rules is the source of truth. This tells an agent both when to use the tool and how to route the result correctly.

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