Skip to main content
Glama

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

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)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / region / description
      Previous value: -"시군구명 (예: 용산구, 성동구)"New value: +"시군구명 (예: 용산구, 성동구). **여러 시도에 같은 이름이 있는 시군구**(중구·동구·서구·남구·북구·강서구)는 시도를 함께 주라(예: '서울 중구') — 안 주면 합치지 않고 후보를 실토하며 거절한다"
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "realty_region_trend_basketDictOutput",
      -  "type": "object"
      -}New value: +null
  3. Changed4 schema fields changed
    • changedInput schema / properties / min_tx_per_complex / description
      Previous value: -"바스켓에 넣을 단지의 창당 최소 거래 건수 — 1이면 바스켓이 커지지만 단지별 값이 한 건에 좌우된다"New value: +"바스켓에 넣을 단지의 창당 최소 거래 건수 — 1이면 바스켓이 커지지만 단지별 값이 한 건에 좌우된다 (허용 범위 1~10)"
    • changedInput schema / properties / pyeong_band / description
      Previous value: -"pyeong_supply 기준 허용 폭(±평). 넓히면 바스켓이 커지고 평형 혼합이 늘어난다"New value: +"pyeong_supply 기준 허용 폭(±평). 넓히면 바스켓이 커지고 평형 혼합이 늘어난다 (허용 범위 1~10)"
    • changedInput schema / properties / pyeong_supply / description
      Previous value: -"분양평(사용자가 말하는 '34평') 필터 — ±3평 창으로 거른다. **좁힐수록 바스켓이 얇아져** 고정 바스켓의 이점이 사라지니 응답의 바스켓 단지 수를 반드시 확인하라"New value: +"분양평(사용자가 말하는 '34평') 필터 — ±3평 창으로 거른다. **좁힐수록 바스켓이 얇아져** 고정 바스켓의 이점이 사라지니 응답의 바스켓 단지 수를 반드시 확인하라 (허용 범위 1~200)"
    • changedInput schema / properties / window_months / description
      Previous value: -"비교 창 하나의 길이(개월). 최근 N개월 vs 그 직전 N개월을 비교한다"New value: +"비교 창 하나의 길이(개월). 최근 N개월 vs 그 직전 N개월을 비교한다 (허용 범위 1~12)"
  4. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses key behaviors: only complexes transacting in both windows are included, results are compared as naive vs basket, the composition_effect is exposed, values are per-pyeong, cancellations and direct deals are excluded, and dong/floor composition changes are not corrected. It also explicitly warns about thin-basket unreliability. 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 core calculation is front-loaded in the first sentence. The 'why' section earns its place with a concrete worked example of the failure mode, and the limitations paragraph is essential for safe interpretation. There is no filler or redundant restating of schema fields.

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?

This is a complex analytical tool with no output schema, but the description still explains the output shape (naive, basket, composition_effect), the unit used (per-pyeong), what is excluded, and the key limitation to communicate to the user. For an analysis tool with one required parameter and well-documented optional parameters, this is complete.

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?

Schema description coverage is 100%, so the input schema already fully documents every parameter with ranges and caveats. The description adds useful conceptual context such as the basket concept and composition effect, but it does not need to repeat parameter-level syntax or semantics. This matches the high-coverage baseline of 3.

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 statement of what the tool does: it calculates regional price trends using only complexes with transactions in both comparison windows. It clearly distinguishes this from a naive average by introducing the basket/naive contrast and the `composition_effect`, which sets it apart from sibling region-stat tools.

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 '왜 필요한가' section gives a clear when-to-use rationale: naive monthly averages are misleading when sample composition shifts, especially with thin samples. It also warns when the basket itself is unreliable. However, it does not explicitly name alternative sibling tools or give an explicit 'do not use when X' rule, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.