Skip to main content
Glama

korea-realty

by app.sallim

분양 총 소요자금 계산 — 중도금 이자·취득세·층별 총액

realty_presale_cost
Read-onlyIdempotent

공고 원문(팩트시트) 기반 결정론 계산: 층별 분양가 + 발코니 확장비 + 회차별 중도금 이자(일할) + 취득세(표준세율) = 층별 총 소요자금. "이 분양 실제로 얼마 드나"의 자리다 — 클라이언트마다 손계산하면 입주일 가정 하나로 백만원대가 갈린다(실측 124만원).

경계(신고 #43의 선 그대로): 여기까지가 "공고+세법에서 결정론적으로 나오는 것"이다.
월 상환액·매수 vs 전세 손익분기는 개인 파라미터가 지배하므로 계산하지 않는다 — 전세
시세는 realty_complex_rent_by_pyeong으로 받아 클라이언트가 개인 가정을 얹어라.
자기자금·차주 조건을 **선언**받아 필요 대출액과 규제 상한 통과까지 판정하는 건
realty_presale_funding_plan이 한다. 세율표 자체는 realty_policy_rules가 근거 조문과 함께 준다(중과·감면 등
이 계산이 가정으로 제친 것들이 거기 있다 — assumptions를 반드시 사용자에게 전하라).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keywordNo단지명 일부 (공백 무관)
house_tyNo주택형 (예: '59', '84B') — 생략 시 공고의 주택형 목록을 돌려준다
movein_ymNo입주 년월 YYYYMM 덮어쓰기 — 공고에 입주예정이 없거나 다른 가정을 쓸 때
mid_rate_pctNo중도금 대출 연이율 %(기본 5.0 — 실제 금리는 공고·은행마다 다르다) (허용 범위 0 초과~20)
house_manage_noNo공고 관리번호 (realty_presale의 house_manage_no)
extra_options_krwNo발코니 외 유상옵션 합계(원) — realty_notice_facts의 옵션가에서 골라 넣어라

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already say readOnlyHint, idempotentHint, and non-destructive, so the bar is lower. The description adds meaning beyond those: it is a deterministic calculation, based on specific assumptions, using standard tax rates, and it warns the agent that those assumptions must be conveyed to the user. It also reveals that even the move-in date assumption can change the result by about 1.24M KRW. No contradiction with annotations.

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 well-structured and front-loaded: the first sentence gives the exact formula, the second sentence states the user-facing purpose, and the following sentences give necessary boundary conditions and routing. Each part earns its place without redundant text.

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?

Even without an output schema, the description makes expected output shape clear (“층별 총 소요자금”), enumerates all components that feed into the calculation, and defines the tool’s exact scope. It also conveys key assumptions to pass back to the user, which is essential for correct tool usage.

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?

All 6 input parameters have full descriptions in the schema, so the schema does most of the work and the baseline is 3. The description adds high-level formula context but does not map each parameter to the formula or clarify which parameters interact. That is sufficient, but not beyond the baseline.

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 a precise, deterministic computation: floor-level price + balcony expansion cost + interim loan interest + acquisition tax = total cost. It frames the tool as the place to answer “이 분양 실제로 얼마 드나” and distinguishes itself from sibling tools by explicitly naming the boundaries and not claiming to cover monthly payments or funding plans.

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?

It gives unusually explicit selection guidance: states what the tool does NOT compute (monthly repayments, buy vs. rent decisions), and directly routes the user to realty_complex_rent_by_pyeong for rent prices, realty_presale_funding_plan for funding-plan judgment, and realty_policy_rules for the full tax-rate table. This makes it easy for an agent to choose the right sibling tool.

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