Skip to main content
Glama

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

realty_region_rankings
Read-onlyIdempotent

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

price=거래량 가중 전용 평당가(최소 5건, 최신월은 집계 진행 중일 수 있음) ·
growth=전용 60-85㎡ 고정 YoY(평형 구성 왜곡 제거) · transit/school=단지 점수의 시군구
평균. **investment는 원천 정지·기준월 혼재로 보류 중**(호출 시 대안 안내 —
전세가율은 realty_rental_yield). 응답 methodology의 산식·단위를 답변에 반영하라.
비교 대상이 두어 곳으로 정해진 질문("A vs B 어디가 나아?")은 [유료]
realty_compare_regions가 시세·추이를 나란히 준다 — 이 도구는 순위·탐색용이다.
**transit/school 점수는 realty_location_scores의 점수와 다른 판본이다**(응답
score_lineage) — 이 순위로 지역을 고르고 단지 점수는 그쪽에서 다시 보되, 두 숫자를
같은 축에 놓고 비교하지 마라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo(허용 범위 1~50)
orderNodesc=상위부터, asc=하위부터desc
metricYesprice=전용 평당가 / growth=연간 상승률 / investment=전세가율·갭투자 / transit=교통 점수 / school=학군 점수
regionNo시도명(예: 부산)이면 그 시도 안 순위, 시군구명이면 해당 지역 필터. 비우면 전국

TDQS

A5/5.0
Behavior5/5

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

readOnlyHint·idempotentHint 등 annotations이 이미 안전한 읽기 동작을 알려주는 가운데, 설명은 price의 거래량 가중·최소 5건·최신월 집계 중 가능성, growth의 60-85㎡ 고정 YoY, investment 원천 정지 상태, score_lineage 판본 차이까지 추가로 공개한다. 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?

용도와 질문 예시를 앞에 배치하고, 그 뒤에 metric 정의·제약·대안 도구를 줄바꿈과 볼드로 구조화했다. 길지만 반복되거나 군더더기 없는 문장으로 모든 문장이 정보를 전달한다.

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?

복잡한 5개 metric과 보류 상태, 형제 도구와의 관계, 응답 methodology 반영 지시까지 빠짐없이 담겨 있다. output_schema는 없지만 설명이 응답의 산식·단위·score_lineage를 안내하므로 에이전트가 도구를 호출하고 결과를 해석하는 데 필요한 맥락이 충분하다.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

input-schema가 100% 커버하지만 그 위에 metric별 산식·단위·보류 상태를 부여하고, region의 시도/시군구 동작도 설명한다. 특히 investment가 enum에는 있으나 실제로는 보류 중이라는 정보는 스키마만으로는 알 수 없는 중요한 의미 보강이다.

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?

첫 문장에서 '지역(시군구) 순위를 조회한다'라는 구체적 동작과 대상을 밝히고, '제일 비싼 동네 어디야?'류 질문 예시로 용도를 명확히 한다. 또한 realty_compare_regions, realty_location_scores 등 형제 도구와의 차이를 직접 언급해 다른 도구와 혼동될 여지가 없다.

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?

순위·탐색용 질문에 쓸 것을 명시하고, 'A vs B'처럼 비교 대상이 정해진 경우에는 realty_compare_regions를 쓰라고 대안을 제시한다. investment가 보류 중일 때 realty_rental_yield로 대체하라는 안내와 transit/school 점수를 realty_location_scores와 같은 축에 놓지 말라는 사용 조건도 포함되어 있다.

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.