Skip to main content
Glama

korea-realty

by app.sallim

지역 추이 — 동일 단지 고정 바스켓 (구성 변화 제거)

realty_region_trend_basket
Read-onlyIdempotent

지역 가격 추이를 양쪽 창에 모두 거래가 있는 동일 단지들로만 계산한다.

**왜 필요한가**: 구 월평균 추이는 '가격이 변한 것'과 '팔린 단지가 바뀐 것'을 구분하지
못한다. 표본이 얇으면 후자가 지배하는데, 그걸 시세 변동으로 읽으면 오답이다
(2026-08-14 실사고: 용산 33평 월 1~7건 표본으로 '전년 대비 −9.6%'를 만들었다).

이 도구는 **naive(전체 평균 변화)와 basket(동일 단지 변화)을 나란히** 주고 그 차이를
`composition_effect`로 보여준다 — 차이가 크면 그 지역 평균 추이는 구성 잡음이다.
단지별 값은 **평당가**라 단지 안의 평형 구성 변화도 흡수한다.

한계를 반드시 함께 전하라: 바스켓이 얇으면(단지 수가 적으면) 이 값도 못 믿는다.
취소·직거래는 제외했고, 단지 내 동·층 구성 변화까지는 보정하지 못한다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionYes시군구명 (예: 용산구, 성동구)
pyeong_bandNopyeong_supply 기준 허용 폭(±평). 넓히면 바스켓이 커지고 평형 혼합이 늘어난다 (허용 범위 1~10)
pyeong_supplyNo분양평(사용자가 말하는 '34평') 필터 — ±3평 창으로 거른다. **좁힐수록 바스켓이 얇아져** 고정 바스켓의 이점이 사라지니 응답의 바스켓 단지 수를 반드시 확인하라 (허용 범위 1~200)
window_monthsNo비교 창 하나의 길이(개월). 최근 N개월 vs 그 직전 N개월을 비교한다 (허용 범위 1~12)
min_tx_per_complexNo바스켓에 넣을 단지의 창당 최소 거래 건수 — 1이면 바스켓이 커지지만 단지별 값이 한 건에 좌우된다 (허용 범위 1~10)

TDQS

A4.3/5.0
Behavior5/5

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

Given the read-only, idempotent annotations, the description adds meaningful behavioral detail: it reveals that calculations use only complexes present in both windows, that per-pyeong price absorbs mix changes, that cancellations and direct deals are excluded, and that floor/unit-number composition is not corrected. It also instructs that the thin-basket caveat must be relayed to the user, which is a behavioral expectation beyond the annotations.

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?

The description is structured in compact paragraphs: core idea, why-needed, decisive method and outputs, and a necessary limitation notification. Bolded headers and emphasis make it skimmable. The 2026-06-14 incident, while useful, lengthens the description somewhat, but each sentence serves a purpose toward the correct carve-out and warnings.

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 complex tool with five parameters and no output schema, the description covers the whole mental activity well: invokes the comparison components (naive, basket, composition_effect), the reason for existence, and a required caveat. What's missing is an explicit return shape, units, or how the response indicates basket quality, but the rest of the definition makes it actionable.

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?

The schema documents all parameters very thoroughly (percent-backed coverage 100%), covering the window range, default values, and consequences for pyeong_supply and min_tx_per_complex. The description adds the conceptual background of the basket-composition effect and the danger of a thin basket, but it does not add detailed parameter-level semantics beyond the schema. Therefore, the 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?

The description opens with a precise, specific statement that the tool computes regional price trends only from complexes that have transactions in both windows, and it distinguishes itself from the naive average approach by naming naive vs basket and composition_effect. The '왜 필요한가' section makes it clear what this tool does and why: it removes composition-change noise from regional trend estimates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly explains when to use this tool: when regional monthly averages are dominated by sample-composition changes in thin samples, illustrated by the 2026-08-14 Yongsan 33p example. It also tells the agent to communicate the limitation that a thin basket is unreliable. It does not explicitly name sibling tools or state exact when-not-to-use conditions, but it implies the old monthly-average method is the alternative.

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