Skip to main content
Glama

korea-realty

by app.sallim
OverviewDiscussionsAdmin

지역 평형대별 시세 구간

realty_area_price_bands
Read-onlyIdempotent

지역의 매매 시세를 평형대 4구간(소형/중소형/중형/대형, 전용면적 기준)으로 조회한다. "○○구에서 무슨 평수대가 얼마쯤 해?"류 질문용 — 특정 단지는 realty_search_complexes를 쓰라.

**이 축의 자리(시세 도구 3종 중)**: 지역의 가격 **수준** 비교는 이게 기본값이다.
이상치 필터(계약해제 제외 + **직거래 중** 같은 평형대 중개거래 중앙값의 50% 미만만 제외)가
적용돼 realty_region_price_stats의 미필터 평균과
값이 다르며, **수준이 갈리면 이쪽을 우선하라**. 월별 **추이**가 필요하면
region_price_stats, 단지가 특정되면 search_complexes.

구간 라벨의 평수는 **전용평**이다. 사용자의 분양평 감각으로는 소형<60㎡≈분양 24평 미만,
중소형 60~85㎡≈분양 24~34평, 중형 85~115㎡≈분양 34~47평, 대형 115㎡+≈분양 47평 이상.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionYes시군구명 (예: 마포구). **법정동까지 넣어도 된다**(예: '마포구 아현동') — 구 하나로 뭉치면 신도심·구도심이 한 값이 된다
by_dongNo법정동 × 평형대 중앙값을 함께 낸다. '이 구에서 어디가 싼가'류 질문의 자리다 — 실측(마포구 6개월, 전용 60~84㎡): 서교동 6.8억 ~ 용강동 27.1억으로 한 구 안에서 4배 갈린다. 표본 3건 이상 칸만 나온다
period_monthsNo집계 기간(개월) (허용 범위 1~24)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_area_price_bandsDictOutput",
-  "type": "object"
-}New value: +null
  2. Changed1 schema field changed
    • changedInput schema / properties / period_months / description
      Previous value: -"집계 기간(개월)"New value: +"집계 기간(개월) (허용 범위 1~24)"
  3. Changed2 schema fields changed
    • addedInput schema / properties / by_dong
      Added value: +{
+  "default": false,
+  "description": "법정동 × 평형대 중앙값을 함께 낸다. '이 구에서 어디가 싼가'류 질문의 자리다 — 실측(마포구 6개월, 전용 60~84㎡): 서교동 6.8억 ~ 용강동 27.1억으로 한 구 안에서 4배 갈린다. 표본 3건 이상 칸만 나온다",
+  "title": "By Dong",
+  "type": "boolean"
+}
    • changedInput schema / properties / region / description
      Previous value: -"시군구명 (예: 마포구)"New value: +"시군구명 (예: 마포구). **법정동까지 넣어도 된다**(예: '마포구 아현동') — 구 하나로 뭉치면 신도심·구도심이 한 값이 된다"
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the outlier filter (excluding contract cancellations and certain direct trades below 50% of the median), explaining why results differ from realty_region_price_stats. It also reveals by_dong behavior: only cells with 3+ samples are shown, and band labels use exclusive-area pyeong rather than the user's '분양평' intuition.

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 longer than minimal, but the structure is efficient: purpose first, then alternatives, then filters, then label conversion. The bolded key phrases and short line breaks make it scannable, though a few clauses are dense enough to require careful re-reading.

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?

With no output schema, the description still conveys the core behavior, band definitions, filtering rules, and parameter semantics. It does not explicitly describe the exact return shape (e.g., whether each band returns median values or ranges), but the title, sample thresholds, and '중앙값' references make the expected result reasonably inferable.

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 schema already covers all parameters at 100%, so the baseline is 3. The description adds real value on top: region may contain a legal dong and warns that using a whole gu hides old/new downtown differences, and by_dong's 'where is cheap in this district' use case is illustrated with a concrete price range example.

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 specific verb+resource: it queries regional sale prices divided into four pyeong-size bands by exclusive area. It also distinguishes itself from siblings by positioning it as the default tool for comparing regional price levels and explicitly directing complex-specific questions to realty_search_complexes.

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?

Usage is clearly scoped: it is for questions like 'what price range is a given pyeong band in ○○구?', it is the default for level comparison, and it names alternatives — realty_region_price_stats for monthly trends and realty_search_complexes when a specific complex is known. It even says to prefer this tool when level estimates diverge.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources