Skip to main content
Glama

시공사·시행사별 분양 성적 — 공급·무순위·청약 배수

realty_builder_presale_record
Read-onlyIdempotent

시공사·시행사별 분양 성적 — 공고 수·공급 세대·무순위(줍줍) 세대와 비율·청약 1순위 배수·미달 세대.

"○○건설 분양 성적", "GS건설 현장 무순위 많이 나왔나", "대전 시공사별 분양", "이 시행사 다른 현장은"류
질문의 자리다. builder(또는 developer)를 주면 그 회사 행과 **현장 목록**(단지·지역·공고일·공급·
무순위·비율·시행사)을, 아무것도 안 주면 공급 상위 N개 회사 순위를, region(시도)을 주면 그 시도로 좁힌다.
행마다 같은 창의 **전국 비율(baseline)**이 비교 기준으로 붙는다.

**결론에 반드시 옮길 것**(meta.disclosures):
· 무순위 세대는 **최종 미분양이 아니다**(당첨 후 계약 포기분 재공급). 무순위 뒤 남은 것은 별도 필드.
· 청약홈 밖 공급(지주택·자체분양·선착순·임의공급)은 없다 — 대구처럼 선착순으로 빼는 지역은 비율이 낮게 나온다.
· **재무 건전성 판정이 아니다** — PF·부채·보증은 DART 영역. "위험"·"부실" 같은 낙인을 붙이지 말고
  수치와 전국 비율만 전하라.
· 공동시공은 각 사에 전량 귀속, 회사명 묶음은 우리 규칙, 무순위 연결률은 meta.match_rate.

view='sites'는 "무순위 청약에서도 신청이 모자란 단지" 목록이다 — 최근 회차 미달 세대(청약 미달이지 미판매·
계약 결과가 아니다)와 시군구 미분양 추이. 그 뒤 선착순 판매 여부는 모른다(meta.disclosures).
**브랜드명(자이·래미안)으로 공고 개수를 세는 질문은 이 도구가 아니다** — realty_notice_facts(keyword).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNosites 정렬shortfall
viewNosites=무순위 청약 미달 단지 목록(최근 회차 △N, since는 최근 회차 월)companies
groupNo순위 모드의 묶음 단위시공사
sinceNo본공고 공고월 하한 YYYY-MM(기본 2024-07)2024-07
top_nNo회사를 안 줬을 때 순위 모드의 행 수(공급 세대 내림차순) (허용 범위 1~50)
regionNo시도로 좁힌다(예: '대전', '경기') — 시군구는 받지 않는다
builderNo시공사명(부분일치, ㈜·주식회사 무시, '지에스건설'→GS건설 같은 별칭 흡수). 주면 그 회사 행 + 현장 목록
developerNo시행사(사업주체)명(부분일치). builder와 같이 주면 그 시행사와 한 현장만 남긴다
min_shortfallNosites: 최근 회차 미달 세대 하한 (허용 범위 0~100000)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / min_shortfall
      Added value: +{
      +  "default": 1,
      +  "description": "sites: 최근 회차 미달 세대 하한 (허용 범위 0~100000)",
      +  "maximum": 100000,
      +  "minimum": 0,
      +  "title": "Min Shortfall",
      +  "type": "integer"
      +}
    • addedInput schema / properties / sort
      Added value: +{
      +  "default": "shortfall",
      +  "description": "sites 정렬",
      +  "enum": [
      +    "shortfall",
      +    "ratio",
      +    "recent"
      +  ],
      +  "title": "Sort",
      +  "type": "string"
      +}
    • addedInput schema / properties / view
      Added value: +{
      +  "default": "companies",
      +  "description": "sites=무순위 청약 미달 단지 목록(최근 회차 △N, since는 최근 회차 월)",
      +  "enum": [
      +    "companies",
      +    "sites"
      +  ],
      +  "title": "View",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description layers on genuinely useful out-of-band caveats (무순위 ≠ 최종 미분양, 청약홈 밖 공급 미포함, co-construction full attribution, meta.match_rate, not a financial-soundness ruling). However, much of this is result-interpretation guidance rather than invocation behavior, and it discloses no auth/rate-limit/pagination traits, so it exceeds the annotation bar without being fully transparent.

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 the purpose sentence, then usage patterns, then disclosure caveats, then the exclusion — a sensible order for a 9-parameter tool. It is long and the disclosure block repeats material that also lives in parameter descriptions, but nearly every sentence carries non-redundant caveat value.

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 return-value burden and does so: it describes the company row, the attached site list columns, the top-N ranking shape, and the per-row national baseline for comparison. Combined with the disclosure caveats, an agent has enough to call the tool and interpret its response.

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 description coverage is 100% and every parameter already carries a substantive inline description (aliases, partial matching, ranges, defaults), so the baseline is 3. The description adds the interaction rule for builder+developer and the effect of region, but that overlaps heavily with what the schema already says.

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 and resource (시공사·시행사별 분양 성적) and enumerates the exact measures returned (공고 수·공급 세대·무순위 세대·비율·청약 1순위 배수·미달 세대). It explicitly distinguishes itself from a sibling by ruling out brand-name notice counting and routing that to realty_notice_facts(keyword).

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?

Enumerates the exact user-question shapes it answers ('○○건설 분양 성적', 'GS건설 현장 무순위 많이 나왔나', '대전 시공사별 분양'). It also states the argument-driven behaviors (builder/developer → company row + site list; no arg → top-N ranking; region → narrowed) and names the alternative tool for the excluded case.

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.