Skip to main content
Glama

단지 평형별 매매 실거래 내역

realty_complex_pyeong_price
Read-onlyIdempotent

특정 단지·특정 평형의 최근 6개월 매매 실거래를 건별(계약일·층·가격)로 조회한다. 평형별 시세 요약만 필요하면 realty_search_complexes의 prices_by_area로 충분하다.

응답에는 **층 밴드별 시세 집계 `price_by_floor_band`**(저층~초고층 밴드별 평균가·건수·
최저 밴드 대비 프리미엄 %)가 함께 온다 — "저층 사면 손해야?", "고층 프리미엄 얼마야?"류
**층별 시세 질문은 이 도구가 담당**이다(층 밴드 축은 다른 도구에 없다).

transactions는 **계약일 내림차순**이고, average_price·median_price는 그 정렬 기준
최근 5건(summary_basis에 그 5건을 그대로 싣는다)이다. 이상 거래는 지우지 않고
`outlier=true`로 표시만 하며(판정 근거는 outliers.method), 층 밴드에는 이상치 제외 값을
`*_ex_outliers`로 병기한다 — **밴드 프리미엄이 몇 건의 산물인지 확인하고 말하라.**

**이름이 더 긴 이웃 단지는 분리해서 뺀다**(0.58.0) — 백엔드가 단지를 이름 부분일치로
찾아 '○○센트레빌' 조회에 '○○센트레빌Ⅱ'가 섞여 들던 자리다. 무엇을 뺐는지·못 가른
면적이 무엇인지는 `meta.complex_isolation`에 그대로 실린다. **못 가른 것은 빼지 않고
못 갈랐다고 적는다** — 그 평형 수치는 단정하지 말고 그 사실을 함께 전하라.

**면적은 사용자가 말한 단위 그대로 넣어라 — 환산은 서버가 한다**(2026-08-22 제보:
"잠실엘스 34평형=전용 84㎡" 질문에서 84가 pyeong_exclusive로 갔다):
- ㎡로 말했으면 → area_m2_exclusive(전용 84㎡ → 84) / area_m2_supply(공급 112.8㎡ → 112.8)
- 평으로 말했으면 → pyeong_supply(분양 "34평") / pyeong_exclusive(전용 실평수 25.4평)
네 개 중 **하나는 필수**다. ㎡ 값을 평 인자에 넣으면 조용히 환산하지 않고 사유와 두
방향 출구를 값으로 적어 거절한다 — 조용한 환산은 사용자의 말을 바꿔치기하는 것이다.
이 도구는 매매 전용이다 — 전월세는 realty_complex_rent_by_pyeong을 쓴다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo개별 거래 내역 수 (허용 범위 1~50)
regionNo동명 단지 구분용 시군구명 (예: 마포구)
complex_nameYes단지명 (예: 마포래미안푸르지오2단지)
pyeong_supplyNo분양평수(공급면적, **평**) — 사용자가 말하는 '34평'이 보통 이것이다. **㎡로 말했으면 여기가 아니라 area_m2_supply를 쓰라** (허용 범위 0 초과~400)
area_m2_supplyNo공급(분양)면적을 **㎡ 그대로** 받는다(예: 112.8). pyeong_supply와 동시에 주면 거절한다 (허용 범위 0 초과~800)
pyeong_exclusiveNo전용면적 기준 **실평수(평)** — ㎡가 아니다. 전용 84㎡면 25.4를 넣는다. **사용자가 ㎡로 말했으면 area_m2_exclusive를 쓰라** — ㎡ 값을 여기 넣으면 서버가 조용히 환산하지 않고 사유를 대고 거절한다(1평=3.3058㎡) (허용 범위 0 초과~400)
quoted_price_10kNo사용자가 **들은 가격**(호가·중개사 제시가·매물 가격, 만원). 주면 실거래 분포와 대조해 `quote_check`로 돌려준다. 이 서버는 **호가 데이터가 없다** — 실거래(MOLIT)뿐이라 '호가가 비싸다/싸다'를 판정하는 게 아니라 **실거래 어디쯤인지 위치만** 알려준다. 사용자가 가격을 말했는데 이 인자를 안 주면 모델이 그 값을 검증 없이 전제로 삼게 된다
area_m2_exclusiveNo전용면적을 **㎡ 그대로** 받는다(예: 84, 59, 114.98). 사용자가 '전용 84㎡'라고 말했으면 환산하지 말고 84를 여기 넣어라 — 서버가 평으로 환산하고 그 사실을 응답에 적는다. pyeong_exclusive와 동시에 주면 거절한다 (허용 범위 0 초과~500)
quoted_prices_10kNo사용자가 **매물 목록에서 복사·다운로드해 온 호가 여러 개**(만원 배열). 값이 2개 이상이면 단일 대조 대신 **호가 분포 ↔ 실거래 분포**를 비교한다(중위 대 중위, 두 구간이 겹치는지). 호가는 사용자가 가져온 것이라 서버는 **출처·수집시점·중복 매물 여부를 모른다** — 그 한계도 함께 응답에 싣는다

TDQS

A4.8/5.0
Behavior5/5

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

With readOnlyHint=true and destructiveHint=false already in annotations, the description still adds significant behavioral context beyond them: transactions are sorted by contract date descending, average/median are based on the most recent 5 records, outliers are not deleted but marked with outlier=true, and floor bands report both raw and *ex_outliers values. It also discloses the complex-name partial-match isolation behavior (0.58.0) and the refusal-with-reason rejection of silently converting user-given units. No contradiction with annotations exists.

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 long but front-loaded: the primary purpose is stated in the first sentence, and each following paragraph delivers a distinct behavioral contract (sorting, outliers, isolation, units, rent routing). A few maintenance details such as version '0.58.0' and the dated bug report are near-noise for an agent, but the density per sentence is high and no paragraph is filler.

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?

There is no output schema, so the description must carry the full burden of return semantics — it does, naming price_by_floor_band, meta.complex_isolation, outliers.method, summary_result, *_ex_outlier fields, and quote_check. It also explains edge behavior (unseparated equal-myeong is kept but reported, rejected input returns the reason plus two exit doors). For a 9-parameter domain tool with a subtle unit-conversion pitfall, an agent has what it needs to call and interpret the tool correctly.

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 coverage is 100%, so each parameter is already documented individually. The description adds semantic relationships the schema does not spell out: the four area parameters are mutually coordinated with '네 개 중 하나는 필수' and the rule '면적은 사용자가 말한 단위 그대로 넣어라 — 환산은 서버가 한다', including the concrete failing example of putting 84 in pyeong_exclusive. This materially clarifies parameter interplay and prevents a known mis-call, which is beyond the per-parameter schema coverage.

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 opening sentence names a specific verb + resource + scope: '특정 단지·특정 평형의 최근 6개월 매매 실거래를 건별(계약일·층·가격)로 조회한다'. It is further differentiated from its siblings by explicitly stating what it is not: summary-only pricing goes to realty_search_complexes prices_by_area, and rental questions go to realty_complex_rent_by_pyeong. An agent can tell this tool apart without opening the schema.

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 gives explicit when-to-use and when-not-to-use guidance with named alternatives: use realty_complex_rent_by_pyeong for 전월세, and use realty_search_complexes' prices_by_area when only 평형별 시세 요약 is needed. It also assigns floor-band price questions ('저층 사면 손해야?', '고층 프리미엄 얼마야?') to this tool because 그 층 밴드 축은 다른 도구에 없다, leaving no ambiguity about tool selection.

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.

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.