Skip to main content
Glama
Sign In

korea-realty

by app.sallim
OverviewDiscussionsAdmin

모집공고 팩트시트 — 전매제한·자격·층별 분양가·옵션가·중도금

realty_notice_facts
Read-onlyIdempotent

입주자모집공고 원문에서 추출·검증한 팩트시트를 항목별로 준다.

입주자모집공고 **원문**에서 추출·검증한 팩트시트 — 전매제한·재당첨제한·거주의무·
거주요건, 청약 일정, 층별 분양가표(대지비·건축비·회차별 납부액), 특별공급 배정,
발코니 확장·유상옵션 가격, 중도금 회차 일정, 예비입주자 규칙.

전매제한 기간, 재당첨 제한, 거주의무, 특별공급 자격·배정, 층/타입별 분양가,
발코니 확장비·유상옵션 금액, 중도금 회차와 납부일 — 이 값들을 묻는 질문이 이 도구의
자리다(추정하거나 웹에서 찾을 필요 없이 공고 원문 값이 나온다). 모든 값에 공고 쪽
번호(`p`)가 붙으니 답변에 notice_version(공고 판본)과 쪽 번호를 함께 제시하라.

팩트시트 미추출 공고는 원문 앞쪽(단지 주요정보 표) 텍스트를 unverified_source_text로
준다 — 수치 인용 시 "공고 원문 기준·미검증"을 명시하라. 상세 조항 전문(특공 소득기준,
부적격 처리 등)은 realty_notice_text로 원문 쪽을 직접 읽어라. 여기 없는 값은 지어내지 말 것.

⚠️ 큰 공고는 팩트시트 전체가 도구 결과 한계(64KiB)를 넘는다. 그때 **큰 절부터 떼어**
보내고 `meta.truncated`·`meta.omitted_sections`(절 이름·크기·되부르는 인자)에 그 사실을
적는다 — 뗀 절은 `section='분양가'`처럼 이름을 지정해 전문으로 받아라. **팩트시트에
없다고 공고에 없다고 답하지 마라**(못 봄 ≠ 없음).

`keyword`는 단지명 일부이자 **브랜드**다('자이'·'힐스테이트'): 여러 공고가 걸리면 후보와
**걸린 총 건수(total_matched)**를 준다 — "자이 브랜드 공고 몇 개야?"는 keyword 하나로
여기서 센다(시공사 단위 분양 성적은 realty_builder_presale_record).

Input Schema

NameRequiredDescriptionDefault
keywordNo단지명 일부 (예: '우미린' — 공백 무관 매칭)
sectionNo팩트시트의 한 절만 전문으로 받는다 (예: '분양가층별', '유상옵션', '전매재당첨', '공고개요' — 절 이름은 공고 판본마다 다르니 모르면 비우고 응답의 절 목록을 보라. '공급'은 한 절이 아니라 공고개요·분양가층별 등에 나뉘어 있다). 비우면 전체 — 다만 전체가 도구 결과 한계를 넘으면 큰 절부터 떼어 내고 뗀 절 이름을 meta.omitted_sections에 적는다. 그때 이 인자로 되받아라.
text_matchNotext_query 낱말 처리 — all=모두 포함(기본), any=하나라도all
text_pagesNo원문 쪽 직접 지정('1-3'·'44') — 팩트시트 대신 그 쪽 본문(최대 6쪽). text_query와 택일
text_queryNo**공고 원문 쪽 읽기** — 주면 팩트시트 대신 이 낱말(공백=AND)이 든 원문 쪽을 준다(realty_notice_text와 같은 값). 특공 소득·자산 기준·부적격·계약 유의사항처럼 팩트시트에 없는 세부용. text_pages와 택일
house_manage_noNo공고 관리번호 (realty_presale 응답의 house_manage_no)
text_pages_onlyNotext_query와 함께 true면 본문 없이 일치 쪽 번호+발췌만 — 쪽을 먼저 고를 때

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / text_match
      Added value: +{
+  "default": "all",
+  "description": "text_query 낱말 처리 — all=모두 포함(기본), any=하나라도",
+  "enum": [
+    "all",
+    "any"
+  ],
+  "title": "Text Match",
+  "type": "string"
+}
    • addedInput schema / properties / text_pages
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "원문 쪽 직접 지정('1-3'·'44') — 팩트시트 대신 그 쪽 본문(최대 6쪽). text_query와 택일",
+  "title": "Text Pages"
+}
    • addedInput schema / properties / text_pages_only
      Added value: +{
+  "default": false,
+  "description": "text_query와 함께 true면 본문 없이 일치 쪽 번호+발췌만 — 쪽을 먼저 고를 때",
+  "title": "Text Pages Only",
+  "type": "boolean"
+}
    • addedInput schema / properties / text_query
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "**공고 원문 쪽 읽기** — 주면 팩트시트 대신 이 낱말(공백=AND)이 든 원문 쪽을 준다(realty_notice_text와 같은 값). 특공 소득·자산 기준·부적격·계약 유의사항처럼 팩트시트에 없는 세부용. text_pages와 택일",
+  "title": "Text Query"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / section / description
      Previous value: -"팩트시트의 한 절만 전문으로 받는다 (예: '분양가', '공급'). 비우면 전체 — 다만 전체가 도구 결과 한계를 넘으면 큰 절부터 떼어 내고 뗀 절 이름을 meta.omitted_sections에 적는다. 그때 이 인자로 되받아라."New value: +"팩트시트의 한 절만 전문으로 받는다 (예: '분양가층별', '유상옵션', '전매재당첨', '공고개요' — 절 이름은 공고 판본마다 다르니 모르면 비우고 응답의 절 목록을 보라. '공급'은 한 절이 아니라 공고개요·분양가층별 등에 나뉘어 있다). 비우면 전체 — 다만 전체가 도구 결과 한계를 넘으면 큰 절부터 떼어 내고 뗀 절 이름을 meta.omitted_sections에 적는다. 그때 이 인자로 되받아라."
  3. Changed1 schema field changed
    • addedInput schema / properties / section
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "팩트시트의 한 절만 전문으로 받는다 (예: '분양가', '공급'). 비우면 전체 — 다만 전체가 도구 결과 한계를 넘으면 큰 절부터 떼어 내고 뗀 절 이름을 meta.omitted_sections에 적는다. 그때 이 인자로 되받아라.",
+  "title": "Section"
+}
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "realty_notice_factsDictOutput",
-  "type": "object"
-}New value: +null
  5. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world behaviour, so the bar is lower. The description still adds real operational context: the 64KiB truncation behaviour, meta.truncated/meta.omitted_sections with re-fetch arguments, the unverified_source_text fallback path, and the requirement to cite notice_version plus page numbers.

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?

Front-loaded with purpose, then usage, then the truncation caveat. There is some redundancy — the phrase about extracting/verifying from the original notice is repeated in the opening two paragraphs — and the block is dense, but every remaining sentence carries actionable information.

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?

For a 7-parameter tool with no output schema and complex fallback paths, the description covers the important edges: truncation recovery, unverified text warning, citation discipline, and the sibling tools to use for what it lacks. The only gap is that the general shape of a non-truncated response is not described.

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 would be 3. The description goes beyond the schema by clarifying that keyword doubles as a brand token ('자이', '힐스테이트') and returns total_matched, and by explaining section-name variance across notice versions and the text_query/text_pages/text_pages_only interplay.

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 — a fact sheet (팩트시트) extracted and verified from the original 입주자모집공고 — and enumerates the exact data it holds (resale/re-win restrictions, per-floor price table, option prices, interim payment schedule). This is clearly distinguishable from realty_notice_text (raw page text) and realty_presale (listing data).

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?

Explicitly names the question types that belong here, routes detailed clause reading to realty_notice_text, routes builder-level sales records to realty_builder_presale_record, and forbids fabrication for values not present. It even states the counting use case ('자이 브랜드 공고 몇 개야?') via keyword.

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