Skip to main content
Glama

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점 이상이 86.7%이고 역이 5km 넘게 떨어진 단지도 90점이 나와 변별력이 없다.
**점수로 순위를 매기거나 '역세권·학군 좋음'을 판정하지 마라.** 점수가 null이면 미측정이지
0점이 아니다. 학군 점수는 학원가 강도 지표이지 학교 배정·수준이 아니다.

complex_key/complex_name이면 단지 행(원시값은 앞 5개 단지), region만 주면 지역 집계 +
점수 상위 5 단지(점수 순이라 순위로 인용 금지). 점수가 없는 단지도 색인에 좌표가 있으면
원시값을 준다. 없는 단지는 not_found — 지어내지 말고 realty_search_complexes로 실존부터
확인하라. complex_key는 공백 1칸으로 정규화돼 다른 도구에 그대로 넣을 수 있다.
시설 **목록**(이름별 거리)이 필요하면 [유료] realty_poi_nearby.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNo지역명 — 단독이면 지역 집계+상위 단지, complex_name과 함께면 검색 범위
complex_keyNo정확한 단지 키 — realty_search_complexes가 돌려주는 complex_key
complex_nameNo단지명 일부 (부분일치)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_location_scoresDictOutput",
-  "type": "object"
-}New value: +null
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses that scores are unverified and have no discrimination power (transit 90+ even for far-away complexes), null means unmeasured not 0, output structure (location_facts at front), and not found behavior (don't fabricate, use search). This is rich behavioral context.

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 dense but well-structured, starting with the core purpose, then the output format, then critical score caveats, then input modes, then fallback. Every sentence adds value, and the use of bold and line breaks makes it scannable.

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 fully explains the output fields, the meaning and caveats of scores, null handling, input modes, and the alternative tool for facility lists. It is complete for an agent to call this tool correctly and interpret results.

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?

Although the schema covers all three parameters, the description adds crucial semantics: the combination of region with complex_name as search scope, the difference between complex_key/complex_name (complex row) vs region alone (aggregation + top 5), and the normalization of complex_key to single space for reuse in other tools.

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 answers with raw location values (station distance, nearby schools, stop counts) and explicitly distinguishes it from score-based tools. It answers specific queries like '역세권이야?' and '학군 어때?', and names the sibling realty_poi_nearby for facility lists, making the purpose unambiguous.

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 provides explicit when-to-use and when-not-to-use guidance: use this tool for raw values and specific questions, use realty_poi_nearby for facility lists, and use realty_search_complexes to confirm existence for not found cases. It also warns against ranking by scores, giving clear boundaries.

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