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).

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.8/5.0
Behavior5/5

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

Annotations already establish the safe read-only/idempotent profile, but the description adds substantial behavioral context beyond them: the meta.disclosures warnings that 무순위 세대 is not final unsold inventory, that off-Cheongyak supply (지주택·자체분양·선착순) is excluded and deflates ratios in some regions, that this is not a financial-soundness verdict, joint-construction full attribution, and meta.match_rate. These are genuine caveats an agent needs to avoid misreporting.

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?

The description is long and dense, but it is front-loaded (what it is, then trigger questions, then per-parameter behavior, then disclosure list) and every section carries actionable content. The disclosure block is verbose but not redundant against the schema or annotations.

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?

For a 9-parameter, multi-mode tool with no output schema, the description still tells the agent what comes back: company rows, site lists with specific columns, a national baseline attached per row, and meta.disclosures/match_rate. Nothing needed to invoke or interpret results correctly 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 adds real semantics: builder matches partially with alias absorption ('지에스건설'→GS건설), and combining builder+developer narrows to a single site. It also clarifies that in sites mode `since` is reinterpreted as the most recent round month, which goes beyond the schema's '하한' wording.

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 opening line names a specific verb+resource: presale performance broken down by 시공사/시행사, enumerating exactly which metrics (공고 수, 공급 세대, 무순위 세대·비율, 청약 1순위 배수, 미달 세대). The example-question list ('○○건설 분양 성적', 'GS건설 현장 무순위 많이 나왔나') anchors this as a builder/developer-level aggregation tool, distinguishing it from sibling per-complex tools like realty_presale or realty_presale_context.

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 rules are given: pass builder (or developer) to get that company's row plus its site list, pass nothing to get top-N supply companies, pass region to narrow to a province. view='sites' is also explicitly framed with its own intent ('무순위 청약에서도 신청이 모자란 단지'). No inference required to pick the right mode.

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.