Skip to main content
Glama

korea-realty

by app.sallim

지역 분양가 추이 — 공고 간 연도별 평당 분양가

realty_presale_price_trend
Read-onlyIdempotent

같은 지역 분양 공고들의 연도별 평당 분양가 추이를 낸다 — "지금 넣을까, 기다릴까"에서 기다림의 비용(다음 공고가 얼마에 나올까)을 정량화하는 축이다. 재당첨 제한이 걸린 결정(분양가상한제 10년 등)에서 특히 판단을 가른다.

기준(답변에 그대로 전달): **공급면적(분양평) 평당 최고 분양가**(만원/평), 발코니
확장·유상옵션 미포함. 연도별 주택형 믹스가 다르면 중앙값이 흔들린다 —
announcements가 1~2건인 연도는 추이로 읽지 말고, 평형대를 고정하려면
exclusive_m2_min/max(국평=80~85)를 써라.

이 축의 자리: 개별 공고의 적정성(분양가 vs 실거래)은 realty_presale_vs_market,
실거래 가격 추이는 realty_region_price_stats — 이 도구는 **분양가끼리의 시계열**이다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNo시도 (예: 서울, 경기, 세종)
keywordNo단지명·공급 주소 부분일치 (예: '고덕', '동탄') — 동네·지구 단위 추이는 이걸로
sigunguNo시군구 정확한 이름 (예: 평택시). ⚠️세종은 오염돼 있으니 keyword를 쓰라
exclusive_m2_maxNo전용면적 상한(㎡) — 국평만 보려면 85
exclusive_m2_minNo전용면적 하한(㎡) — 국평만 보려면 80

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark the tool read-only and idempotent, and the description adds meaningful behavioral context: the metric is 공급면적(분양평) means the max price per pyeong, excludes balcony expansion and optional add-ons, and uses a median that can be unstable when the housing-type mix varies across years. This is exactly the kind of operational nuance that annotations cannot convey.

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 longer than minimal but efficient for its purpose: it packs a definition, measurement criteria, a caveat, parameter advice, and sibling-tool routing. A small amount of the message is contextually motivational — e.g., '재당첨 제한... 판단을 가른다' — but it does not prevent an agent from quickly extracting the operational guidance.

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?

The tool has no output schema, so the description carries the burden of explaining what comes back; it does so by stating the result is a per-year per-pyeong presale price trend based on announcements in the same region. It also explains what the answer should be based on, how to handle unstable years, how to fix the size band, and which sibling tool should be used when the risk is not presale-presale time series. Nothing functionally necessary is missing.

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?

All five parameters have solid schema descriptions, so the baseline is 3. The description adds value beyond the schema by explicitly tying exclusive_m2_min/max to the 80–85 ㎡ national standard range and to the median-stability caveat. It also reinforces the keyword-based zone/area trend use case, which elevates the parameter guidance slightly above baseline.

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 states a specific verb and resource: 'same-region presale announcements' annual per-pyeong price trend'. It also separates this tool from adjacent tools by saying it handles presale-to-presale time series, while individual announcement fairness is covered by realty_presale_vs_market.

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 routing: use this tool for presale price time series, realty_presale_vs_market for individual presale vs realized price, and realty_region_price_stats for resale price trends. It adds when-not-to-use guidance: years with only 1–2 announcements should not be read as trends, and exclusive_m2_min/max should be used to hold unit mix constant.

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