Skip to main content
Glama

[유료] 서울 재개발·재건축 사업장

realty_redevelopment
Read-onlyIdempotent

[유료] 서울시 정비사업(재개발·재건축·가로주택) 사업장 목록을 조회한다.

[유료] 서울시 정비사업(재개발·재건축·가로주택 등) 사업장 목록 — 사업명·유형·
진행 단계·위치. "○○구 재개발 어디까지 진행됐어?"류 질문용.

**커버리지는 서울 한정**(정보몽땅 원천) — 타 시도는 이 도구로 답할 수 없다고 밝혀라.
세대수·준공예정은 원천 목록이 제공하지 않아 null이다(지어내지 말 것). 진행 단계
필터는 미지원 — 결과의 stage 필드(한글: 조합설립인가·관리처분인가 등)로 판별하라.
재건축 **유망도 점수**는 이 도구가 아니라 realty_reconstruction이 담당하고,
"지금 사면 조합원 지위 승계돼?"는 realty_member_transfer_check(무료)가 담당한다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo(허용 범위 1~50)
offsetNo페이지네이션 오프셋
sigunguNo시군구 (예: 강남구). 비우면 서울 전체
project_typeNoreconstruction=재건축, housing_redevelopment=재개발(주택정비형), urban_redevelopment=재개발(도시정비형), street_housing=가로주택정비, small_reconstruction=소규모재건축, small_redevelopment=소규모재개발, regional_housing=지역주택, remodeling=리모델링. 비우면 전체

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "title": "realty_redevelopmentDictOutput",
      -  "type": "object"
      -}New value: +null
  2. Changed1 schema field changed
    • addedInput schema / properties / limit / description
      Added value: +"(허용 범위 1~50)"
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already carry readOnly/idempotent/non-destructive, so the description focuses on the gaps those annotations can't express: coverage is Seoul-only, stage filtering is unsupported (agent must filter client-side on the stage field), and generation count/completion dates come back null and must not be invented. These are meaningfully non-obvious behaviors; return shape specifics are the only notable omission.

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-loads the paid-scope and subject, then layers coverage limits and sibling routing. Slightly dense with bracket tags and repetition of the '[유료]' marker across sentences, but every sentence carries routing or constraint value.

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 read-only filtered-list tool with a fully covered schema and no output schema, the description covers scope, coverage ceiling, null-field guidance, filtering limitation, and sibling routing. It could say a word about pagination/return shape, but for this complexity it is substantively complete.

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 each parameter (limit, offset, sigungu, project_type) is already documented, including the enum label mapping for project_type. The description adds no syntax beyond the schema, so it sits at the baseline.

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 (조회한다/목록) plus resource (서울시 정비사업 사업장) and enumerates the project categories it covers. It explicitly distinguishes itself from two named siblings (realty_reconstruction, realty_member_transfer_check), so an agent can route without opening other schemas.

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?

Provides explicit when-to-use ('○○구 재개발 어디까지 진행됐어?'류 질문), when-not (타 시도는 이 도구로 답할 수 없다고 밝혀라), and names the alternative tools for adjacent needs. Boundaries are stated rather than implied.

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.