Skip to main content
Glama

korea-realty

by app.sallim

경매 물건 검색

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다

TDQS

A4.9/5.0
Behavior5/5

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

readOnlyHint 등이 이미 안전성을 알기는 하지만, 설명은 '파서는 최소 어댑터라 못 쓰는 축이 있고 못 쓴 조건은 unapplied_conditions에 기록된다'라는 동작상을 추가로 공개한다. 또한 결과를 좁게 해석하지 말고 realty_search_auctions로 재조회하라는 안내와 결과 id를 fetch에 그대로 써서 상세를 보라는 동작까지 설빙을 넘어서 제공한다.

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?

목적이 앞에 배치되고 예시가 바로 뒤따라 하여 전면적으로 잘 구조화되어 있다. 다만 'presale/실패 vs 검색축 구분', '네 가지 파싱 축'과 같은 내용이 여러 곳에서 반복되어 각 문장이 모두 반드시 필요한 것으로 보지는 않는다.

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?

출력 스키마가 없는 상태에서도 unapplied_conditions 존재를 직접 알려주고, 응답에서 이에 따른 후속권한과 fetch(id) 사용법을 제공해 에이전트가 결과를 오해하지 않고 다음 행동을 결정할 수 있다. 대안 도구들과의 관계까지 포함하여 호출·처리·후속 전 과정이 완비되어 있다.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

schema 자체가 query에 대한 설명을 제공하지만, 설명에서 자연어 쿼리 예시, 지역·물건종류·유찰횟수·감정가만 파싱된다는 제약, 지역 표기 유형(수원시 권선구 등), 금액 단위(억/만원), 미지원 축의 대안을 모두 상세히 다룬다. 이는 입력 파라미터를 어떻게 만들어야 하는지에 대해 스키마 이상으로 구체적인 의미를 부여한다.

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?

법원경매 물건을 자연어로 검색한다'라는 구체적 동작과 대상을 명시했고, '경매 전용'이라 못으며 presale/분양가/시세 통계 등 다른 도구를 명시적으로 제외해 형제 도구와 분명히 구분된다. 또한 문장 그대로 검색하는 것과 값으로 검색하는 realty_search_auctions의 차이도 제시하여 목적이 완전하다.

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?

자연어 문장이면 이 도구를 쓰고, 값을 이미 알면 realty_search_auctions를 쓰라는 조건이 명시되어 있다. 또한 면적·기일·층 축이 필요하거나 unapplied_conditions가 비어 있지 않은 경우에 realty_search_auctions로 재조회하라는 안내, 사건번호를 알면 realty_get_auction_case를 쓰라는 안내까지 포함되어 사용 시점과 대안이 모두 제시됨.

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