Skip to main content
Glama

korea-realty

by app.sallim

지역 실거래 시세 통계

realty_region_price_stats
Read-onlyIdempotent

지역의 아파트 실거래 시세 추이(월별)를 조회한다. 경매가가 싼지 판단하는 기준선이 된다.

**이 축의 자리(시세 도구 3종 중)**: 월별 흐름·방향이 필요할 때 이걸 쓴다. 지역의
가격 **수준**을 인용할 거면 realty_area_price_bands를 쓰라 — 이 축은 이상치(지분·
증여성 직거래)가 필터되지 않아 평균이 눌리며, **두 도구 값이 갈리면 bands 쪽이
정상 매매에 가깝다**(세종 소형 실측 4,400만원 차). 단지가 특정된 질문("○○아파트
얼마야")은 realty_search_complexes가 기본이다 — 지역 평균은 단지 간 편차(같은 동
같은 평형에서 단지 평균 24% 차)를 뭉갠다.

region은 시군구명(예: '강남구') 또는 **법정동까지**(예: '강남구 대치동',
'세종특별자치시 나성동') — 세종처럼 시군구가 하나인 도시는 동 단위로 좁혀야 신도심·
구도심이 섞이지 않는다(2026-08-08, 8/7 테스터 제안 수용). 동명 지역이 여럿이면
시도를 앞에 붙여라 — 안 붙이면 거래량 최다 지역 기준으로 답하고 region_candidates로
나머지 후보를 실토한다(그 목록을 사용자에게 전달할 것).
metric: price(매매) | rental(전월세). rental도 **months 창 월별 추이**(monthly_trend:
전세 평균·중앙, 월세 보증금·월세, 건수 분리)를 준다 — "전세 떨어지는 중이야?",
역전세 판단용(입주 물량은 realty_move_in_supply와 조합). 상단 필드는 최신월 스냅샷.

**면적은 사용자가 말한 단위 그대로 넣어라 — 환산은 서버가 한다**(2026-08-22 제보):
- ㎡로 말했으면 → area_m2_exclusive(전용 84㎡ → 84) / area_m2_supply(공급 112.8㎡ → 112.8)
- 평으로 말했으면 → pyeong_supply(분양 "34평") / pyeong_exclusive(전용 실평수 25.4평)
㎡ 값을 평 인자에 넣으면 조용히 환산하지 않고 사유와 두 방향 출구를 적어 거절한다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
metricNoprice=매매, rental=전월세price
monthsNo조회 개월 수 (허용 범위 1~60)
regionYes지역명 — 시군구까지(예: '강남구', '수원시 권선구') 또는 **법정동까지**(예: '강남구 대치동', '세종특별자치시 나성동'). 시도 약칭은 서버가 정식명으로 펴지만('서울 마포구' → '서울특별시 마포구'), 동명 지역이 여럿이면 시도를 앞에 붙여라 — 안 붙이면 거래량 최다 지역으로 답하고 나머지 후보를 region_candidates로 실토한다. 단지명은 여기 넣지 마라(단지는 realty_search_complexes·realty_complex_pyeong_price 담당)
pyeong_supplyNo분양평수(공급면적, 평) — 흔히 말하는 '34평'이 이것이다. 내부에서 ×0.745로 전용 실평수로 환산한다. **㎡로 말했으면 area_m2_supply를 쓰라**
area_m2_supplyNo공급(분양)면적을 **㎡ 그대로** 받는다(예: 112.8). pyeong_supply와 동시에 주면 거절한다 (허용 범위 0 초과~800)
pyeong_exclusiveNo전용면적 기준 **실평수(평)** — ㎡가 아니다. 전용 84㎡면 25.4를 넣는다. **사용자가 ㎡로 말했으면 이 인자가 아니라 area_m2_exclusive를 쓰라** (㎡ 값을 여기 넣으면 60평 초과로 거절된다). 1평=3.3058㎡
area_m2_exclusiveNo전용면적을 **㎡ 그대로** 받는다(예: 84, 59, 114.98). 사용자가 '전용 84㎡'라고 말했으면 환산하지 말고 84를 여기 넣어라 — 서버가 평으로 환산하고 그 사실을 응답에 적는다. pyeong_exclusive와 동시에 주면 거절한다 (허용 범위 0 초과~500)

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's job is lighter. The description goes beyond with valuable behavioral details: that area anomalies (redeemed/market-friendly direct deals) are not filtered causing average to be pulled down, that the two values being split means bands is closer to normal trades, that the rental metric also returns the monthly_trend with separating average/median, deposit/rent, count, that 'if the two field values differ' logic, that the upper fields are a latest-month snapshot, and that inputting ㎡ into pyeong params will be rejected with a reason and two-way exit. It even documents response shape (monthly_trend structure) without an output schema. Slight gap: no explicit note on what happens for regions with no data or how pagination works (probably N/A).

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 dense and active-voice, with bold emphasis and bullet splitting for units. The structure is front-loaded with the core question ('가격 추이'), then alternatives, then parameters. Some may argue it is longer than typical, but each part earns its place: alternative selection, behavioral caveats, unit-conversion guidance, and regional disambiguation. Minor deduction: could be more telegraphic — the '7/8 test suggest' provenance notes ('2026-08-08, 8/7 테스터 제안 수용', '2026-08-22 제보') are maintainers' breadcrumbs that distract an agent and don't add invocation value.

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 complex 7-parameter tool with no output schema, the description covers the critical cogs: return semantics (top-field snapshot vs monthly trend), unit-coercion rules (㎡ vs pyeong, server conversion, rejection behavior), multi-region disambiguation, and the trade-off against two sibling tools ( bands as normal-transaction baseline, complexes for specific complex). It lacks an explicit return-value block, but the absence of an output schema is compensated by prose describing monthly_trend and the snapshot structure. It also mentions a related tool realty_move_in_supply for contextual usage. No critical missing piece.

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 description coverage is 100%, so the baseline is 3. The description adds significant value on top: it explains which parameter to use depending on the unit the user says (㎡→area_m2_supply/exclusive, pyeong→pyeong_supply/exclusive), provides a real-world conversion example (전용 84㎡ → 84 not 환산), explains that server does conversion and states rejection behavior, and clarifies that same-name regions require pre-pending the city-do name. It also explains region granularity (시군구 vs 법정동, special case Sejong). This converts the flat schema list into practical usage guidance — but some of it duplicates the schema's own description field, so 4 rather than 5.

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?

Description states a specific verb+resource: '지역의 아파트 실거래 시세 추이(월별)를 조회한다' and clearly distinguishes itself from sister tools realty_area_price_bands and realty_search_complexes, explaining that this one focuses on monthly trends/flow while the others focus on price level/valuation. It even includes a concrete discrepancy (세종 소형 실측 4,400만원 차) to differentiate from bands. The Korean phrasing is vivid and memorable, making the tool's purpose unmistakable.

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 provides explicit when-to-use guidance: use this when you need monthly flow/direction; use realty_area_price_b вents when citing a price level; use realty_search_complexes when the question concerns a specific complex. It also includes when-not-to-use warnings (regional averages hide inter-complex deviations) and when to disambiguate region (e.g., same-named towns need municipality prefix). This is exemplary, actionable usage 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
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