Skip to main content
Glama
Sign In

korea-realty

by app.sallim
OverviewDiscussionsAdmin

단지 입지 원시값(역 거리·주변 학교·정류장 수) + 참고 점수

realty_location_scores
Read-onlyIdempotent

단지 입지를 원시값으로 답한다 — "역세권이야? 학군 어때? 병원 가까워?" 담당.

**답은 행마다 맨 앞의 location_facts로 하라**: 최근접 지하철역 이름·노선·직선거리(m,
상한 없음 — 시골 단지는 30km도 그대로 나온다), 반경 500m·1km 안 역·버스 정류장 수,
1km 안 초·중·고 수와 최근접 초등학교 거리, 반경 안 병원(전 의료기관·병원급 분해)·마트
수. 전부 poi 원장에서 직접 센 값이라 재현할 수 있다. "역세권이야?"는
subway.nearest_distance_m와 walk_band로, "초품아야?"는 schools.nearest_elementary로 답하라.

같은 행의 transit_score·school_score는 **미검증 참고값**이다(응답 score_demotion) —
transit 90점 이상이 82%(2026-10-17)이고 역이 5km 넘게 떨어진 단지도 90점이 나와 변별력이 없다.
**점수로 순위를 매기거나 '역세권·학군 좋음'을 판정하지 마라.** 점수가 null이면 미측정이지
0점이 아니다. 학군 점수는 진학률·학원·학교 수 합성(v5)이지 학교 배정이 아니다.

complex_key/complex_name이면 단지 행(원시값은 앞 5개 단지), region만 주면 지역 집계 +
점수 상위 5 단지(점수 순이라 순위로 인용 금지). 여러 단지는 단지마다 부르지 말고
realty_search_complexes 한 번으로 받되 순위는 price_per_exclusive_m2로. 점수가 없는 단지도 색인에 좌표가 있으면
원시값을 준다. 없는 단지는 not_found — 지어내지 말고 realty_search_complexes로 실존부터
확인하라. complex_key는 공백 1칸으로 정규화돼 다른 도구에 그대로 넣을 수 있다.
시설 **목록**(이름별 거리)이 필요하면 [유료] realty_poi_nearby.
**거주 후기·평판("살기 좋대?"·"주민들 평 어때?")은 이 데이터에 없다** — 시설 개수는 평판의
대용이 아니니 그런 질문에는 이 도구를 부르지 말고 데이터에 없다고 답하라.

Input Schema

NameRequiredDescriptionDefault
regionNo지역명 — 단독이면 지역 집계+상위 단지, complex_name과 함께면 검색 범위
complex_keyNo정확한 단지 키 — realty_search_complexes가 돌려주는 complex_key
complex_nameNo단지명 일부 (부분일치)
include_footnotesNotrue면 계산값 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다. 기본은 행마다 한 줄 요지

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_footnotes
      Added value: +{
+  "default": false,
+  "description": "true면 계산값 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다. 기본은 행마다 한 줄 요지",
+  "title": "Include Footnotes",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_location_scoresDictOutput",
-  "type": "object"
-}New value: +null
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the read-only/idempotent profile, but the description adds substantial behavioral context: scores are labeled unverified reference values with 82% of transit scores ≥90 and no discriminative power, null means unmeasured (not 0), school score is a v5 composite not school assignment, complex_key is normalized to a single space, and missing complexes yield not_found with a no-fabrication rule.

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?

Dense but front-loaded: the bolded 'location_facts first' directive leads, followed by field contents, caveats, and sibling routing. Some parenthetical asides (30km rural examples, v5 composition) add length, but nearly every sentence carries information an agent needs.

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?

With no output schema, the description carries the full burden and delivers: it names the response container (location_facts), the specific sub-fields, the score_demotion flag, and the fallback behavior. Nothing essential for correct invocation 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?

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema — it explains the region-alone case (region aggregate + top-5 complexes by score, with ranking citation forbidden) versus complex_key/complex_name (complex rows, raw values for the first 5), which the schema only states tersely.

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?

States a specific verb+resource (returns raw location facts — nearest subway name/line/distance, station/bus-stop counts, school counts, hospital/mart counts) and explicitly contrasts itself with the unverified reference scores in the same row. An agent can distinguish it from realty_poi_nearby and realty_search_complexes without opening any 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?

Explicit routing: use realty_search_complexes once for multiple complexes (rank by price_per_exclusive_m2), use [paid] realty_poi_nearby for facility name-level lists, and do NOT call this tool for reputation/resident reviews. It also states when-not (no ranking by score, no '역세권/학군 좋음' verdicts) and the not_found fallback.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources