Skip to main content
Glama

korea-realty

by app.sallim

정비사업 분담금 계산 — 선언된 감정평가액·비례율로 권리가액·분담금

realty_redevelopment_burden
Read-onlyIdempotent

재개발·재건축 조합원의 권리가액과 추가 분담금(또는 환급금)을 결정론으로 계산한다 — 권리가액 = 종전자산 감정평가액 × 비례율, 분담금 = 조합원분양가 − 권리가액. "감정평가 3억에 비례율 98%면 얼마 더 내?"의 자리다.

경계를 지켜라: ① 입력 전부 **선언**이다 — 감정평가액·비례율은 조합 자료에서 가져와야
하고 서버는 검증하지 않는다. ② 이 산식은 법정 산식이 아니라 통용 실무 산식이며,
비례율은 관리처분인가 전엔 추정치라 준공까지 계속 변한다 — 응답의 sensitivity(비례율
±10%p 스윙)와 disclosures를 반드시 함께 전하라. ③ 산식 출처·변동 함정의 원문은
realty_policy_rules(topic=redevelopment_rules)의 proportion_formula가 진실원이다.
분양자격 자체가 불확실하면 topic=redevelopment_entitlement(갈림길 지도)부터.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
proportion_rate_pctNo비례율(%, 예: 102.5) — 조합 총회 자료·관리처분계획의 값을 선언. 없으면 아래 사업 전체 3종으로 계산한다 (허용 범위 0 초과~300)
prev_asset_value_10kYes조합원 종전자산 감정평가액(만원) — 감정평가 결과이지 시세가 아니다
total_post_asset_10kNo종후자산 평가총액=분양수입 총액(만원) — 비례율을 직접 계산할 때
total_prev_asset_10kNo종전자산 평가총액(만원) — 비례율을 직접 계산할 때
member_sale_price_10kYes받으려는 주택형의 조합원분양가(만원)
total_project_cost_10kNo총사업비(만원) — 비례율을 직접 계산할 때

TDQS

A4.9/5.0
Behavior5/5

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

annotations는 read-only·idempotent임만 알려 주지만, 설명은 '서버는 검증하지 않는다', '비례율은 관리처분인가 전 추정치라 준공까지 변동한다', '민감도 ±10%p에 대한 정보를 반드시 함께 전달하라'는 중요한 동작 특성을 추가로 공개한다. annotation이 담지 못하는 비모수적·무검증 계산 행동을 정확히 보강한다.

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?

수식, 사용 예시, 세 가지 경계·조건, 대체 도구 안내가 모두 4줄 안에 밀도 있게 담겼다. 불필요한 홍보성 문구나 중복 표현이 없고, 계산 목적이 맨 앞에 와서 핵심을 먼저 파악할 수 있다.

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?

출력 스키마가 없음에도 계산 결과가 무엇인지(권리가액·분담금) 및 함께 보고해야 할 sensitivity·disclosures가 정확히 명시되어 완결성이 높다. 입력 파라미터 조건, 주의사항, 대안 라우팅까지 포함하여 복잡한 재개발 분담금 도구가 에이전트를 오류 상태에 빠뜨릴 요소가 거의 없다.

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?

schema의 파라미터 설명이 100% 커버리지이므로 기본 3점 이상이다. 설명은 그 위에 파라미터 간 연산 관계, 즉 종전자산 감정평가액·비례율과 분담금의 산술 관계를 부여해 각 인자가 어떻게 쓰이는지 명확히 해준다. 다만 비례율이 null일 때 3종 시나리오 계산이 되는 분기는 schema 설명에만 있고 description에는 없지만 schema가 이미 충분히 담당한다.

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?

첫 문장이 자원과 계산 결과를 구체적으로 명시한다: '권리가액과 추가 분담금(또는 환급금)을 계산', '권리가액 = 감정평가액 × 비례율, 분담금 = 조합원분양가 − 권리가액'. 실제 예시 문구('감정평가 3억에 98%면 얼마 더 내?')까지 있어 에이전트가 재개발 관련 형제 도구들과 헷갈릴 여지가 없다.

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?

'경계를 지켜라' 문단에서 입력값은 반드시 조합 자료의 선언값임을 강조하고, 산식이 법정 산식이 아니라 실무 추정치임을 경고하며, 정확성이 불확실하면 realty_policy_rules의 진실원을 따르고 분양자격이 불확실하면 topic=redevelopment_entitlement부터 보라는 전환 안내까지 제공한다. 사용 조건과 대안 경로가 모두 명시되어 있다.

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