Skip to main content
Glama

[유료] 단지 통합 리포트

realty_complex_report
Read-onlyIdempotent

[유료] 단지 하나의 시세·전세·기본정보를 통합 조회한다.

입지는 **location.facts(원시값)로 답하라** — 최근접역 이름·직선거리, 반경 500m·1km 안
정류장·병원·마트 수와 1km 안 초·중·고 수를 poi 원장에서 직접 센 값이다. location.overall_score·scores는
미검증 참고값이라(location.score_demotion) 순위·비교·'입지 좋음' 판정에 쓰지 마라.
응답에 좌표(latitude/longitude)와 complex_key가 들어 있다 — 이어서
realty_poi_nearby(시설 목록)·realty_predict_price(예측)에 그대로 넣어 심층 분석하라.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo단지명 (예: 반포자이)
complex_keyNo정확한 단지 키

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the [유료] paid cost, the data-validity disclosure that location.overall_score·scores are unverified (location.score_demotion), the provenance of location.facts as raw counts from the POI ledger, and the chaining contract that the response carries coordinates and complex_key. No contradiction with annotations.

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?

Three dense sentences, each earning its place: the core purpose, the critical location-data protocol, and the downstream chaining instruction. Purpose is front-loaded. Slightly long sentences keep it from a 5, but there is zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 must carry return semantics — and it does for the critical parts: what location.facts contains, why overall_scores are untrustworthy, and that coordinates + complex_key are returned for chaining. Missing is guidance on parameter selection (prefer complex_key vs name, and that realty_search_complexes can resolve a key), which would fully close the loop for a paid, 2-param tool.

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

Parameters3/5

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

Schema coverage is 100% — both name and complex_key have Korean descriptions ('단지명 (예: 반포자이)', '정확한 단지 키'). The description reinforces that complex_key appears in the response for chaining, but it doesn't add parameter-level meaning such as which parameter takes precedence or how to discover a complex_key. Baseline 3 is appropriate since the schema carries the burden.

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: '단지 하나의 시세·전세·기본정보를 통합 조회한다' (integrated query of price, jeonse, and basic info for one complex). This clearly differentiates it from siblings like realty_complex_pyeong_price, realty_complex_rent_by_pyeong, and realty_location_scores, which each target a narrower slice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit workflow routing: the response's coordinates and complex_key should be fed into realty_poi_nearby and realty_predict_price for deeper analysis, and warns that location.overall_score/scores must not be used for ranking or comparison. However, it doesn't explicitly state when to prefer this tool over alternative single-complex tools, leaving some selection logic implicit.

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.