Skip to main content
Glama

지역 순위 (시세·상승률·전세가율·교통·학군)

realty_region_rankings
Read-onlyIdempotent

시군구 순위를 가격·상승률·전세가율 같은 축으로 조회한다.

지역(시군구) 순위를 조회한다 — "제일 비싼 동네 어디야?", "요즘 많이 오른 지역은?",
"전세가율 높은 곳은?"류 질문용.

price=거래량 가중 전용 평당가(최소 5건, 최신월은 집계 진행 중일 수 있음) ·
growth=전용 60-85㎡ 고정 YoY(평형 구성 왜곡 제거). 응답 methodology의 산식·단위를
답변에 반영하라. **investment는 원천 정지·기준월 혼재로 보류 중**(대안: realty_rental_yield).
**transit·school도 보류다**(2026-09-26, D-2026W39-16) — 입지 점수는 90점 이상이 86.7%라
변별력이 없어 지역 순위를 내지 않는다. "교통 좋은 동네"는 단지를 특정해
realty_location_scores의 location_facts(최근접역 거리·반경 안 정류장·학교 수)로 답하라.
비교 대상이 두어 곳으로 정해진 질문("A vs B 어디가 나아?")은 [유료]
realty_compare_regions가 시세·추이를 나란히 준다 — 이 도구는 순위·탐색용이다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo(허용 범위 1~50)
orderNodesc=상위부터, asc=하위부터desc
metricYesprice=전용 평당가 / growth=연간 상승률 / investment=전세가율·갭투자 / transit·school=**보류**(입지 점수가 미검증 참고값이라 순위를 내지 않는다 — 호출하면 대안 안내)
regionNo시도명(예: 부산)이면 그 시도 안 순위, 시군구명이면 해당 지역 필터. 비우면 전국

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / metric / description
      Previous value: -"price=전용 평당가 / growth=연간 상승률 / investment=전세가율·갭투자 / transit=교통 점수 / school=학군 점수"New value: +"price=전용 평당가 / growth=연간 상승률 / investment=전세가율·갭투자 / transit·school=**보류**(입지 점수가 미검증 참고값이라 순위를 내지 않는다 — 호출하면 대안 안내)"
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "realty_region_rankingsDictOutput",
      -  "type": "object"
      -}New value: +null
  3. Changed1 schema field changed
    • addedInput schema / properties / limit / description
      Added value: +"(허용 범위 1~50)"
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Despite annotations already indicating readOnly, openWorld, and idempotent behavior, the description adds important behavioral details: growth uses 60-85㎡ fixed YoY to avoid distortion, price uses volume-weighted average with a minimum of 5 transactions, and current month may be incomplete. It explicitly states that investment, transit, and school are unavailable and why (source halted, score lacks discrimination). This goes beyond annotations and provides critical context for correct interpretation.

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 concise and front-loaded with the core purpose. It uses whitespace and bullet-like separators to break down metric explanations. While it contains quite a bit of text, every sentence serves a purpose: defining purpose, giving example queries, explaining metric formulas, and routing to alternatives. The only minor inefficiency is redundancy between the title and the first line, but it's not significant.

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?

Given the tool's complexity (multiple metrics, some unavailable, need for methodology awareness), the description is remarkably complete. It covers all metrics, explains why certain ones are unavailable, provides alternatives, and tells the agent to reflect methodology in responses. The output schema is absent, but the description hints at what the response will contain (rankings, methodology details). An agent can call and use this tool correctly with just this description.

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 parameters are documented, but the description adds crucial nuances beyond the schema. For metric, it explains what each value means and explicitly lists which are unavailable ('보류'), which the schema also mentions but in a more terse way. For region, it clarifies how the value filters (시도 vs 시군구 vs 전체). limit and order are left to schema, but those are straightforward. Overall, the description adds meaningful value beyond the schema.

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's purpose: to look up 시군구 rankings by various axes such as price, growth rate, and jeonse-to-sale ratio. It provides concrete example queries ('제일 비싼 동네 어디야?', etc.) that an agent can match to user intent. It also differentiates from sibling tools by specifying what this tool is NOT for (comparison) and what to use instead.

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 explicitly states when to use this tool (ranking/exploration queries) and when not to use it. It names alternatives for specific cases: realty_compare_regions for fixed comparisons, realty_location_scores for transit/school queries. It also warns about unavailable metrics and directs to realty_rental_yield for investment-related needs. This is exceptionally clear routing.

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.