Skip to main content
Glama

korea-realty

by app.sallim

급매 경매 물건

realty_auction_alerts
Read-onlyIdempotent

유찰이 누적돼 최저입찰가가 크게 떨어진 물건을 찾는다. "○○에서 유찰 많은 물건"은 sido/sigungu로 좁혀라.

유찰이 많다는 건 싸다는 뜻이기도 하지만 권리관계·물건 하자 등 팔리지 않는 이유가
있다는 뜻이기도 하다. 결과를 추천으로 제시하지 말고 확인이 필요한 후보로 제시하라.

**같은 축의 다른 문**: realty_search_auctions(min_fail_count)로도 유찰 물건을 거를 수
있다 — 조건 필터·목록이 목적이면 그쪽, 저감 큰 후보 발굴(극단 할인 컷 포함)이면 이쪽.
둘을 합쳐 세지 마라(같은 물건이 양쪽에 나온다).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sidoNo시도 (예: 세종, 경기도)
limitNo반환 개수 (최대 50) (허용 범위 1~50)
sigunguNo시군구 (예: 강남구, 수원시)
usage_nameNo물건 종류 — 원장 값 예: 아파트·오피스텔·다세대·연립주택·단독주택·다가구주택·근린시설·상가·대지·임야·전답. '빌라'는 표준 분류가 아니라 서버가 '다세대'로 매핑하고 그 사실을 응답에 공시한다. 비우면 전 종류
min_bid_countNo최소 유찰 횟수 (허용 범위 0~100)
max_discount_pctNo감정가 대비 최대 할인율(%) — 80%+ 극단 할인은 지분매각·대지권 없음 등 특수물건이 대부분이라, 실수요 후보를 찾을 땐 79 이하로 걸러라 (허용 범위 0~100)
min_discount_pctNo감정가 대비 최소 할인율(%) (허용 범위 0~100)

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already carry the safe read-only, idempotent, open-world profile, so the description only needs to add context beyond that. It does this meaningfully: it explains that repeated failures imply the property may be cheap but often for a reason (권리관계, 하자), and requires that results be presented as '확인이 필요한 후보' rather than as recommendations. This is behavioral guidance about interpreting output that annotations cannot express.

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 short paragraphs each carry a distinct load: purpose and geographic narrowing, result-interpretation guidance, and sibling-tool differentiation. The text is moderately long but every sentence adds information a caller needs, including the interpretive caveat and the no-double-count warning. Clean front-loading of the operation and a competent structure.

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 search tool with 7 optional parameters and no output schema, the description covers the core invocation conditions: what it returns qualitatively, how to narrow scope, how to interpret results, and how to interact with the overlapping sibling tool. The only omission is any description of the output/return shape, which is less critical since parameter schemas are fully descriptive and no output schema exists.

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%, so the seven parameters are already well-documented with defaults, allowed ranges, and even nuanced advice (e.g., '최대 할인율 80% 이상은 특수물건이므로 79 이하로 필터하라'). The tool description adds no new parameter-level meaning, so it correctly rests at the baseline 3.

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: it searches for properties whose minimum bid has fallen significantly due to accumulated failed auctions ('유찰이 누적돼 최저입찰가가 크게 떨어진 물건을 찾는다'). It explicitly disambiguates from realty_search_auctions(min_fail_count) on the same axis, so an agent can tell the tools apart without opening either schema.

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?

It explicitly says when to use the sibling instead ('조건 필터·목록이 목적이면 그쪽') versus this tool ('저감 큰 후보 발굴(극단 할인 컷 포함)이면 이쪽'). It also warns against double-counting results because the same item appears in both tools, and instructs the agent to narrow by sido/sigungu when the user's query is region-specific. Exclusions and alternatives are fully spelled out.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation3/5

The set has very explicit cross-tool guidance and each tool is often given a specific 'role', but there are still many overlapping clusters: auction search vs auction list vs auction detail, regional price bands vs price stats vs rankings, and court auction rate vs public auction rate. The descriptions reduce misselection, but with 51 tools including pairs like `fetch` and `realty_get_auction_case`, confusion is still likely for an agent.

Naming Consistency4/5

Most tools follow a clean `realty_` prefix and use consistent snake_case noun-phrases or verb-noun patterns, e.g. `realty_search_auctions`, `realty_get_auction_case`, `realty_presale_cost`. The exceptions are the generic `fetch`, `search`, and `report_issue`, which break the uniform prefixed convention but are only a small minor deviation from an otherwise consistent naming system.

Tool Count1/5

51 tools far exceeds the recommended threshold, even for a deliberately broad real-estate area; it is effectively an extreme number for a single MCP server. The tool count becomes the hardest usability problem, since agents must handle many tightly related micro-tools instead of interacting with a smaller, more manageable surface.

Completeness5/5

The tool set covers an impressively complete range: auction and public-auction workflows, apartment and non-apartment market, presale/cheongyak processes, tax and loan rules, subscription scoring, redevelopment, demographics, supply, POI, and even a reporting and routing tool. Boundaries and unsupported cases are explicitly documented, so there are no major obvious dead ends.

Resources