Skip to main content
Glama

korea-realty

by app.sallim

지역 평형대별 시세 구간

realty_area_price_bands
Read-onlyIdempotent

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

**이 축의 자리(시세 도구 3종 중)**: 지역의 가격 **수준** 비교는 이게 기본값이다.
이상치 필터(P75의 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)

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover safety and idempotence. The description adds key behavioral context beyond that: the outlier filter (excluding values below P75's 50%), the resulting discrepancy with region_price_stats, and the area-unit conversion (전용평 vs 분양평). It stops short of explaining the exact return shape or median semantics, so it is strong but not perfect.

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 description is front-loaded and each sentence earns its place: core behavior, use-case positioning, sibling alternatives, outlier caveat, and unit conversion are all compact and organized under clear headings. Although dense, the structure makes it easy to scan and every block addresses a distinct decision or knowledge need.

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 tool with no output schema and three parameters, the description covers the main scoping, alternatives, exception-handling rule, and the important user-facing unit conversion. The only clear gap is that the base result's exact value measure (whether median or other) is not spelled out for the non-by_dong call, though by_dong's schema mentions median. It is very close to complete but has this minor ambiguity.

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 input schema is already very descriptive for all parameters (region example, by_dong explanation, period range), so schema coverage is 100%. The description contributes the pyeong-band conversion table, but that relates more to result interpretation than to the actual parameter schema. It adds no new constraint or format guidance for the inputs, so the baseline of 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 clearly states the tool '조회한다' (retrieves) '지역의 매매 시세' split into four specific sizes by dedicated area. It also distinguishes the tool from realty_search_complexes immediately, making the purpose unmistakable and separable from siblings.

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?

It explicitly names the default use case (지역 가격 수준 비교), and gives clear exclusions: for monthly trends use region_price_stats, for specific complexes use search_complexes. It also adds the rule to prioritize this tool when price levels conflict with the unfiltered stats. This is exemplary routing 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