Skip to main content
Glama

korea-realty

by app.sallim
OverviewDiscussionsAdmin

경매 물건 검색

search
Read-onlyIdempotent

법원경매 물건을 자연어 문장으로 검색한다(경매 전용 — 청약·시세는 다른 도구다).

법원경매 물건을 자연어로 검색한다. **경매 전용** — 청약·분양 공고는 realty_presale,
분양가 적정성은 realty_presale_vs_market, 시세 통계는 realty_region_price_stats.

지역·물건종류·유찰횟수·감정가를 질의에서 뽑아 필터링한다.
예: "서울 강남구 아파트", "유찰 2회 이상인 경기도 오피스텔", "서울 아파트 감정가 5억 이하".

이 파서는 최소 어댑터라 못 쓰는 축(면적·기일·층 등)이 있다. 못 쓴 조건은 응답의
`unapplied_conditions`에 적히므로, 그게 비어 있지 않으면 결과 범위를 좁게 오인하지 말고
`realty_search_auctions`로 조건을 직접 지정해 다시 조회하라.

각 결과의 id는 이어서 fetch(id)에 그대로 넣으면 상세를 볼 수 있다.

**이 축의 자리** — 경매 검색은 둘이고 입력 형태로 갈린다. 사용자의 말을 문장 그대로
넘길 때가 이 도구(`search`)이고, 지역·종류·감정가·유찰횟수를 **값으로 이미 알 때**는
`realty_search_auctions`다(면적·기일·층 등 이 파서가 못 쓰는 축도 거기서 지정한다).
상세는 `fetch`로 이어간다 — 여기 나온 id를 그대로 넣으면 된다.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes경매 물건을 찾는 **자연어 한 줄**. 예: '서울 강남구 아파트' · '유찰 2회 이상인 경기도 오피스텔' · '서울 아파트 감정가 5억 이하'. 이 파서가 읽는 축은 넷뿐이다 — 지역(시도는 '서울'·'서울특별시' 둘 다 되고, 시군구는 '강남구'·'평택시'처럼 원장 표기, 특례시는 '수원시 권선구'), 물건종류(아파트·오피스텔·다세대·연립주택·단독주택·근린시설·상가·대지·임야·전답 등), 유찰횟수, 감정가(억/만원 표기). 면적·기일·층은 못 읽고 unapplied_conditions로 실토하니 그 축이 필요하면 realty_search_auctions를 쓰라. 사건번호를 이미 아는 경우는 검색이 아니라 realty_get_auction_case다

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "searchDictOutput",
-  "type": "object"
-}New value: +null
  2. Changed1 schema field changed
    • addedInput schema / properties / query / description
      Added value: +"경매 물건을 찾는 **자연어 한 줄**. 예: '서울 강남구 아파트' · '유찰 2회 이상인 경기도 오피스텔' · '서울 아파트 감정가 5억 이하'. 이 파서가 읽는 축은 넷뿐이다 — 지역(시도는 '서울'·'서울특별시' 둘 다 되고, 시군구는 '강남구'·'평택시'처럼 원장 표기, 특례시는 '수원시 권선구'), 물건종류(아파트·오피스텔·다세대·연립주택·단독주택·근린시설·상가·대지·임야·전답 등), 유찰횟수, 감정가(억/만원 표기). 면적·기일·층은 못 읽고 unapplied_conditions로 실토하니 그 축이 필요하면 realty_search_auctions를 쓰라. 사건번호를 이미 아는 경우는 검색이 아니라 realty_get_auction_case다"
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value: it discloses that the parser is a limited adapter, that unread axes surface in the response's `unapplied_conditions`, and warns not to misread narrow result scope when that field is non-empty.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening two sentences say the same thing ('법원경매 물건을 자연어로 검색한다' appears twice), and the routing to realty_search_auctions is repeated three times across the body. Information is front-loaded but the redundancy costs it marks.

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?

With no output schema, the description compensates by naming the `unapplied_conditions` response field and explaining the id→fetch follow-up. It covers the parser's limitation and the handoff clearly, leaving only minor gaps about full return shape.

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 the schema itself exhaustively documents the query axis set (지역 표기, 물건종류, 유찰횟수, 감정가). The description largely restates the same examples and axis list, so it adds reinforcement rather than new meaning — the baseline 3 applies.

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: searches court-auction (법원경매) properties from a natural-language query. It immediately scopes itself against siblings, naming realty_presale, realty_presale_vs_market and realty_region_price_stats as out-of-scope, so an agent can distinguish it without opening any 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?

Gives explicit routing rules: pass the user's sentence verbatim here, use realty_search_auctions when the axes are already known as values, use realty_get_auction_case when the case number is known, and use fetch for details on a returned id. When-to-use and when-not are both covered with named alternatives.

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