Korea Realty vs Hudoc
A side-by-side look at the Korea Realty and Hudoc MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Korea Realty for real estate work over a hosted endpoint; choose Hudoc for legal as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Korea Realty when
- You need dedicated capabilities in the Real Estate domain.
- You prefer a remote HTTP/SSE transport.
- Its auth model fits you: No auth required.
- You have the keys it needs:
REALTY_BACKEND_URL. - You want tools like
search, fetch, realty_search_auctions.
Choose Hudoc when
- You need dedicated capabilities in the Legal domain.
- You prefer a local stdio subprocess transport.
- You want tools like
echr_search, echr_judgment.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Real Estate | Legal |
| Quality signal | 65/100 · Great | 59/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Remote HTTP/SSE | Local subprocess (stdio) |
| Auth | No auth required | Not declared |
| Pricing | Freemium | Not declared |
| Required env vars | REALTY_BACKEND_URL | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 0 | 0 |
| Directory activity | 0 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | 56 | 2 |
| Full listing | View Korea Realty | View Hudoc |
Tools & capabilities
Korea Realty tools 56
search법원경매 물건을 자연어 문장으로 검색한다(경매 전용 — 청약·시세는 다른 도구다). 법원경매 물건을 자연어로 검색한다. **경매 전용** — 청약·분양 공고는 realty_presale, 분양가 적정성은 realty_presale_vs_market, 시세 통계는 realty_region_price_stats. 지역·물건종류·유찰횟수·감정가를 질의에서 뽑아 필터링한다. 예: "서울 강남구 아파트", "유찰 2회 이상인 경기도 오피스텔", "서울 아파트 감정가 5억 이하". 이 파서는 최소 어댑터라 못 쓰는 축(면적·기일·층 등)이 있다. 못 쓴 조건은 응답의 `unapplied_conditions`에 적히므로, 그게 비어 있지 않으면 결과 범위를 좁게 오인하지 말라. 지역·종류·감정가·유찰횟수라면 `realty_search_auctions`로 값을 직접 지정해 다시 조회하면 되지만, **면적·층·기일 범위는 그 도구에도 인자가 없다**(외부 QA 2026-10-04 ③) — 기일은 `exclude_past=true`(오늘 이후만)·`sort="date_asc"`까지만 되고, 면적·층은 결과 행과 `fetch` 상세의 값을 보고 직접 걸러야 한다. 없는 인자로 재호출하라고 안내하지 마라. 각 결과의 id는 이어서 fetch(id)에 그대로 넣으면 상세를 볼 수 있다. **이 축의 자리** — 경매 검색은 둘이고 입력 형태로 갈린다. 사용자의 말을 문장 그대로 넘길 때가 이 도구(`search`)이고, 지역·종류·감정가·유찰횟수를 **값으로 이미 알 때**는 `realty_search_auctions`다(면적·층·기일 범위는 **어느 쪽에도 필터가 없다** — 위 참조). 상세는 `fetch`로 이어간다 — 여기 나온 id를 그대로 넣으면 된다.fetchsearch가 돌려준 id로 경매 사건의 전체 내용을 가져온다. id 형식은 "법원명|사건번호" (예: "서울동부지방법원|2025타경51727"). 사건번호는 법원 간 중복되므로 법원명 없이 조회하면 후보 목록이 돌아올 수 있다. rights(매각물건명세서 요약)가 있으면 법원 공시의 전달로만 인용하고, 없으면(rights_note 참조) 권리관계를 지어내지 말 것 — 권리분석 판단은 이 도구의 데이터 밖이다. **이 축의 자리** — 사건 상세도 둘이고 입력과 응답 형태로 갈린다. 이 도구는 `search`가 준 `"법원명|사건번호"` 한 덩어리를 그대로 받아 **문서형 텍스트**를 돌려준다(ChatGPT 커넥터 규격). 사용자가 사건번호를 말로 불러줬거나, `rights`·`min_bid_source` 같은 필드를 **값으로** 다뤄야 하면 `realty_get_auction_case`(사건번호·법원명을 따로 받는 구조화 응답)를 써라. 유찰 이력·기일별 저감은 어느 쪽도 아니고 `realty_auction_history`다.realty_search_auctions법원경매 물건을 지역·종류·감정가·유찰횟수로 필터링해 조회한다. **이 축의 자리** — 조건을 **값으로 아는** 검색이 이 도구다. 사용자의 자연어 한 줄밖에 없으면 `search`가 먼저다(질의에서 조건을 뽑아 준다). 개별 사건의 상세는 여기가 아니라 `realty_get_auction_case`(사건번호+법원명)·`fetch`(search가 준 id)다. **이 도구는 법원경매(민사집행법·각급 법원)만 조회한다 — 공매는 여기가 아니다.** 공매(국세징수법·국유재산법 등, 한국자산관리공사 온비드)는 **이 서버에 따로 있다**: 물건은 `realty_search_onbid`, 낙찰가율은 `realty_onbid_sale_rate` (물건 25,669개 · 개찰 결과는 2026-06-01 개찰분부터 누적, 지금 범위는 응답 `sample_period`). 여기서 안 나온다고 "그런 물건 없다"고 답하지 말고 **공매 도구로 다시 걸어라.** 구분 신호는 번호 형식이다 — 법원 사건번호는 `2025타경1234`, 공매 물건관리번호는 `2026-0600-031235`(하이픈 세 토막·'타경' 없음)다. **두 원장을 합쳐 세거나 낙찰가율을 섞어 평균내지 마라** — 근거법·주관기관·권리 인수 규칙·저감 방식이 다르다. 감정가(min_price_10k/max_price_10k)는 **만원** 단위다 — 5억은 50000. 유찰이 많을수록 최저입찰가가 감정가 대비 낮아진다(`min_bid_rate`가 그 비율). ⚠️ **이 목록에는 매각기일이 이미 지난 행이 섞여 있다**(백엔드가 기일로 걸러주지 않는다 — 인천 아파트 3억 이하 실측 48건 중 43건이 지난 기일). 지난 기일 행에는 `past_auction_note`가 붙고 응답의 `past_auction_count`가 그 페이지의 건수다. "지금 살 수 있어?"류 질문이면 `exclude_past=true`로 걸러라 — 지난 기일 물건은 매각·취하됐거나 다음 기일이 아직 반영되지 않은 것이라 현재 매물로 인용하면 오답이다. ⚠️ **`sort=date_asc`(기일 임박 순)는 지난 기일이 목록 앞쪽을 통째로 차지한다** (2026-08-21 실측 94,279건 중 앞 57,241건=60.7%). `exclude_past=true`면 서버가 그 접두를 건너뛰고 읽으므로 첫 호출부터 실물이 온다 — 건너뛴 행 수는 `meta.past_prefix_skipped`, 실제로 읽은 자리는 응답의 `offset`(요청값은 `requested_offset`)이다. **items가 비어도 `has_more`가 true면 '조건에 맞는 물건이 없다'는 뜻이 아니다** — 그 창이 전부 지난 기일이었을 뿐이니 `next_offset`으로 이어서 호출하라. note가 둘 중 어느 쪽인지 매번 말한다. ⚠️ **최저입찰가는 출처를 반드시 확인해라** — 건별 `min_bid_source`가 붙는다. · `court_schedule` — 법원 기일표 정본이다. 그대로 믿어도 된다(2026-10-17 실측 활성의 23.2%). · `item_list` — 물건목록값이다. 유찰이 있으면 **저감 한 단계만큼 낡아 실제보다 높을 수 있다**(2026-08-04 실측: 유찰 1회 이상에서 정본과 3%만 일치, 25~43% 과대). 이 경우 `min_bid_note`가 함께 온다. 사용자에게 단정적으로 말하지 말고 그 한계를 전해라. 저감률로 역산해 추정하지 마라 — 재감정으로 최저가가 **오르는** 사건도 있다. 응답의 `min_bid_stale_risk_count`가 그 페이지에서 낡았을 수 있는 건수다. 회차별 정확한 가격은 realty_auction_history의 court_schedule에 있다. 목록에는 요약 필드만 담긴다. 특정 물건의 전체 정보(면적·법원 계·주소 상세 등)는 돌아온 id로 realty_get_auction_case를 호출해 받아라. "유찰 많이 돼 싸진 물건 찾아줘"류 발굴 질문은 realty_auction_alerts가 지름길이다 (min_bid_count로 여기서 걸러도 같은 축 — 결과를 합쳐 세지 마라).realty_get_auction_case사건번호로 경매 물건의 상세를 조회한다. 재매각 사건의 입찰보증금처럼 **사건마다 다른 매각조건** 질문도 사건을 특정하는 여기서 시작한다. 사건번호는 법원 간 유일하지 않다(전국 평균 2.8개 법원에서 중복). court_name을 생략하면 중복 시 오류와 함께 후보 법원 목록이 돌아오니, 그걸 보고 법원을 지정해 다시 호출하라. `rights` = 매각물건명세서 핵심(최선순위 설정·인수되는 권리 원문·위험 플래그·배당요구종기). 이것은 법원 공시의 전달이지 권리분석 판단이 아니다 — 답할 때 rights.disclaimer를 함께 전하고, 등기부·임차인 현황 전체가 아님을 밝혀라. rights가 null이면 명세서 미수집 상태(rights_note에 사유)이므로 권리관계를 절대 지어내지 말 것. ⚠️ `rights.claim_amt_10k`는 **경매신청 채권자의 청구금액**(만원)이다 — 임차인 보증금이 아니다(claim_amt_note 참조). 보증금 액수는 이 데이터에 없다. `min_bid_source`가 item_list면 최저가가 낡았을 수 있다 — 함께 오는 `min_bid_note`를 사용자에게 전하고 단정하지 마라(목록 도구와 같은 경고다). 유찰 이력·기일별 저감·사진은 realty_auction_history가 담당이다. 재매각 보증금 비율은 법원이 사건마다 정하는 특별매각조건이라 규범 표에 없다 — 응답에 그 값이 없으면 매각물건명세서·매각기일 공고에서 확인하라고 전하라(비율을 기억으로 단정하지 말 것). **이 축의 자리** — 사건번호·법원명을 **따로 받아 구조화 필드**로 돌려주는 상세가 이 도구다. `search` 결과의 id(`"법원명|사건번호"`)를 그대로 들고 있다면 `fetch`가 그 덩어리를 쪼개지 않고 받아 문서형 텍스트로 준다 — 둘은 대체재가 아니라 입력·응답 형태가 다른 짝이다. 조건으로 여러 건을 훑는 것은 `realty_search_auctions`다.realty_compare_auction_vs_market경매 물건의 최저입찰가를 같은 단지 실거래 시세와 대조해 할인율·표면수익률을 낸다. 기본은 **오늘 이후 기일 물건만**이다(지난 기일이 섞여 나오던 결함 수리, 2026-08-08). 주소·단지명 정규화 정확매칭으로 붙이며, 감정가가 기준선의 50~150% 범위인 건만 비교한다 (지분경매·특수물건을 배제하기 위함). 결과의 `signal`은 주의/관심/보통/낮음/판정보류다. **시세 기준선은 같은 단지의 같은 면적대(±10%) 실거래 평균이다**(2026-08-16 수리 — 종전엔 단지 전 평형 혼합 평균이라 대형·소형이 섞인 단지에서 할인율이 통째로 어긋났다). 면적을 맞추지 못하면 `discount_vs_market_pct`는 **null**이고 signal은 '판정보류'다 — 그 자리를 `discount_vs_all_types_pct`(혼합평균 대비)로 대신 채워 말하지 마라. ⚠️ 유찰 물건은 `auction.min_bid_source`를 확인하라 — item_list면 최저가가 낡았을 수 있고(`min_bid_note` 동봉) 그 최저가로 계산된 할인율·수익률도 함께 틀어진다. 이 도구는 다른 도구보다 느리다(출처 조회 포함 2~4초). **이 축의 자리(경매 가격판단 3종 중)**: "이 물건 싸?"는 이게 1차다(시세 자동 조인). 입찰가 책정은 realty_auction_sale_rate(감정가 대비 실제 낙찰가율)와 함께 쓰되, 이 도구의 할인율(시세 대비)과 낙찰가율(감정가 대비)은 **분모가 달라 섞으면 안 된다**. 기준 시세를 손으로 잡을 땐 realty_area_price_bands(수준)/region_price_stats(추이).realty_auction_sale_rate"이 지역 이 물건은 보통 감정가의 몇 %에 낙찰되나"를 실제 매각결과로 답한다. 입찰가를 정할 때 쓰는 핵심 지표다. `by_fail_count`에 유찰 횟수별 분포가 들어 있어 "2회 유찰된 물건은 보통 몇 %에 낙찰되는가"를 바로 읽을 수 있다. 낙찰가율 = 낙찰가 / 감정가 × 100. 100%를 넘으면 감정가보다 비싸게 팔린 것이다. **"감정가 12억에 최저가 7.68억이면 몇 번 유찰됐나"는 이 도구가 아니다** — 그건 낙찰 통계가 아니라 저감 산수다(최저가 = 감정가 × (1−저감률)^유찰횟수, 법원별 저감률 실측표와 예시는 realty_policy_rules(topic='auction_rights', section='minimum_price_reduction')). 사건번호가 있으면 realty_auction_history의 기일별 이력이 정본이다(T-2026W34-353 피드백). 표본의 집계 기간은 응답의 `sample_period`(매각기일 min~max)에 있다 — "요즘"류 질문에는 이 범위를 함께 전하라. 기간을 좁히는 파라미터는 백엔드가 지원하지 않는다 (요청해도 조용히 무시됨을 실측했다 — 그래서 노출하지 않는다). usage_name에 '빌라'를 넣으면 표준 분류인 '다세대'로 자동 매핑해 집계한다(원문 '빌라'는 소수 비표준 표기 행만 잡혀 표본이 조용히 왜곡된다 — 응답에 매핑 사실이 공시된다). 연립주택 통계는 usage_name='연립주택'으로 따로 물어라. **평형을 섞지 마라(2026-08-16 축 신설)**: 응답의 `by_area_band`가 전용면적대별 낙찰가율이다. 2026-10-17 실측(사건 중복 제거): 아파트 전국 전체 78.8%인데 전용 59㎡ 이하 75.7%, 60~84㎡ 81.4%, 서울은 82.4% vs 98.1%다. 대상 물건의 평형을 알면 `area_band`로 좁히고, 지역 요약 하나로 입찰가를 정하지 마라. '면적 미상' 밴드는 공고에 면적 표기가 없거나 공고 원장에 사건이 없어 면적을 못 붙인 사건이지 0이 아니다. **이 축의 자리(경매 가격판단 3종 중)**: 이 %는 **감정가 대비** 통계다. 특정 물건이 실거래 **시세** 대비 싼지는 realty_compare_auction_vs_market이 자동 계산한다 — 분모가 다르니 두 %를 한 문장에 섞지 마라(감정가는 시세와 다른 시점·기준의 값이다).realty_search_onbid한국자산관리공사 **온비드 공매** 물건을 지역·용도·재산구분·감정가로 조회한다. 법원경매가 아니다. 공매는 국세징수법(압류재산)·국유재산법·공유재산법에 따른 처분이고 주관은 캠코다 — 아래 '이 축의 자리'와 응답의 `not_court_auction`을 반드시 함께 전하라. **이 축의 자리** — 공매 축은 도구가 둘뿐이다. 물건을 찾고 회차별 최저가 일정을 보는 것이 이 도구, "보통 감정가의 몇 %에 낙찰되나"는 realty_onbid_sale_rate다. **법원경매를 물었다면 여기가 아니라 realty_search_auctions**이고, 사건번호에 '타경'이 들어 있으면 그쪽이다. 사용자가 그냥 "경매"라고만 했으면 **어느 쪽인지 되물어라** — 둘을 합쳐 세거나 섞어 평균내면 그 답은 틀린다. **행이 물건이 아니다.** 원장의 한 행은 물건이 아니라 **공매조건(회차)**이다 — 한 물건이 1~10회차 입찰 일정을 미리 갖고 회차마다 최저입찰가가 내려간다(실측: 물건당 3.51행). 이 도구는 **물건 단위로 접어서** 돌려준다: `rounds_total`(전체 회차)·`rounds_remaining` (마감 전 회차)·`next_round`(다음 입찰 회차의 기간과 최저입찰가)·`last_round`(마지막 예정 회차 = 더 안 팔리면 도달하는 바닥값). 응답의 `condition_rows`가 접기 전 행 수다 — **행 수를 물건 수로 인용하지 마라**(71% 과대). ⚠️ **최저입찰가 '비공개'** — 원문이 숫자가 아니라 '비공개'인 회차가 있다(529행). 그 회차의 금액은 **null**이지 0이 아니다. `min_bid_undisclosed_rounds`가 그 수이고, 평균·최저값 계산에서 빠져 있다. ⚠️ **압류재산 주소는 번지가 가려진다** — 결과 원장 기준 압류재산의 61.7%가 '강원특별자치도 춘천시 ***********' 꼴이다. 물건 목록 쪽은 번지까지 나오지만 (실측 마스킹 0건), 같은 물건을 결과에서 다시 찾을 때는 시군구까지만 유효하다. ⚠️ **시도 표기를 우리가 손봤다** — 원천에 '전남광주통합특별시' 같은 통합 표기가 7,757행 있어 시군구로 분해해 `sido`에 넣었다. 손보기 전 원문은 `sido_source`, 분해 근거는 `sido_basis`('as_is' = 원문 그대로 / 'split_by_sgg' = 시군구로 갈랐다)에 있다. 권리분석·감정평가서·공고 원문은 이 원장에 없다. 공매의 권리 인수 규칙은 법원경매와 다르므로 realty_policy_rules(민사집행법 기준)의 답을 여기에 옮기지 마라.realty_onbid_sale_rate공매가 "보통 감정가의 몇 %에 낙찰되나"와 "얼마나 유찰되나"를 실제 개찰 결과로 답한다. **법원경매의 realty_auction_sale_rate와 같은 이름의 다른 지표다.** 분모가 둘 다 감정가지만 평가 주체·저감 규칙·매물 성격이 달라 **두 %를 한 문장에 섞으면 안 된다**. "경매 낙찰가율"을 물었으면 어느 쪽인지 확인하라. **이 축의 자리** — 공매 축 2종 중 통계 쪽이다. 개별 물건과 회차별 최저가는 realty_search_onbid다. 낙찰가율은 재산구분별로 갈라 읽어라(`by_property_type`). ⚠️ **표본은 2026-06-01 개찰분부터 누적이고, 그중 '낙찰' 건만 낙찰가율에 든다.** 범위·행 수는 응답 `sample_period`(`ledger`)가 정본이다 — 고정 기간이 아니다. 낙찰 외 행은 유찰·취소·개찰중이다. `outcome_mix`가 그 분포이고 여기서 나온 낙찰 비율은 **성립률이지 낙찰가율이 아니다**. ⚠️ **낙찰가율은 원천이 준 값을 그대로 쓴다**(`apslPrcCtrsScfbPrcRto` = 감정가 대비 낙찰가율). 낙찰 3,824건 중 이 값이 있는 것은 2,896건이다 — 나머지는 감정가가 원장에 없는 건이라 **모르는 것이지 0이 아니다**(`ratio_missing`). ⚠️ **평균이 아니라 중앙값을 인용하라.** 지분·산지 물건이 감정가의 386%에 팔린 사례가 실제로 있어(공유자 경합) 평균이 위로 끌린다. `median_pct`가 정본이고 `p25_pct`· `p75_pct`로 폭을 함께 전하라. ⚠️ **지역은 물건명에서 되찾은 것이다.** 입찰결과 원장에 지역 컬럼이 아예 없어서, 물건 목록과 붙여 보려 했으나 **낙찰 3,824건 중 물건 목록에서 찾아지는 것은 83건 (2.2%)뿐이다** — 물건 목록은 현재 진행분 스냅샷이라 이미 팔린 물건이 빠져 있다. 그래서 물건명 접두의 시도·시군구 표기를 파싱해 쓴다(전체 96.1%·낙찰 90.0%에서 잡힌다). 파싱이 안 된 건은 지역 필터에서 **조용히 빠지므로** 응답의 `region_basis`를 함께 전하라.realty_auction_alerts유찰이 쌓여 최저입찰가가 크게 떨어진 경매 물건을 골라낸다. 유찰이 누적돼 최저입찰가가 크게 떨어진 물건을 찾는다. "○○에서 유찰 많은 물건"은 sido/sigungu로 좁혀라. 유찰이 많다는 건 싸다는 뜻이기도 하지만 권리관계·물건 하자 등 팔리지 않는 이유가 있다는 뜻이기도 하다. 결과를 추천으로 제시하지 말고 확인이 필요한 후보로 제시하라. **같은 축의 다른 문**: realty_search_auctions(min_bid_count)로도 유찰 물건을 거를 수 있다 — 조건 필터·목록이 목적이면 그쪽, 저감 큰 후보 발굴(극단 할인 컷 포함)이면 이쪽. 둘을 합쳐 세지 마라(같은 물건이 양쪽에 나온다).realty_auction_history경매 사건 하나의 유찰 이력·가격 변동·물건 사진을 조회한다. 경매 사건의 유찰 이력(기일별 최저가 저감 시계열)·가격 변동 이벤트·물건 사진 URL을 조회한다. "몇 번 유찰됐어? 얼마나 떨어진 거야? 사진 있어?"류 질문의 담당 도구. 사진은 법원 원천에서 기일 후 소멸해 **수집 시점 보존본만 존재**한다(국내 공개 API에 드문 축). court_schedule에서 result='유찰'인 행이 유찰 이력, min_bid_10k의 저감이 가격 흐름이다. result가 null인 행은 미래 기일이거나 미해독 법원 코드(result_code 원문 병기)다 — 의미를 지어내지 말고 그대로 전하라. **최저가(min_bid_10k)가 없는 행에는 `kind_note`가 붙는다 — 그 행은 입찰 기일이 아니다**(원천 전수에서 최저가·유찰 표기는 kind_code=01에만 붙는다). fail_count가 기일표의 유찰 행 수와 다르면 `fail_count_note`가 그 이유를 댄다 (출처가 목록 원천 vs 기일표로 갈린다) — 둘을 합쳐 세지 마라. tracking·price_events는 2026-07-23 이후 일일 스냅샷 비교분이라 비어 있을 수 있다(비어 있음 ≠ 변동 없음, court_schedule이 정본). ⚠️ court_schedule이 빈 물건(기일표 미수집)의 `current_min_bid_10k`는 건별 `min_bid_source`를 봐야 한다 — item_list면 낡았을 수 있어 min_bid_note가 함께 온다. 그 경우 현재 최저가를 단정하지 말고 note를 사용자에게 전하라(목록·상세와 같은 경고).realty_region_price_stats지역의 아파트 실거래 시세 **추이**(월별)를 조회한다. 경매가가 싼지 판단하는 기준선이 된다. **이 축의 자리(시세 도구 3종 중)**: 월별 흐름·방향이 필요할 때 이걸 쓴다. 지역의 가격 **수준**을 인용할 거면 realty_area_price_bands를 쓰라 — 평형(pyeong)을 지정하면 이 축은 셀 평균이라 직거래 이상치가 안 걸러지고(전체 평형은 해제·직거래 이상치 제외 — 행 avg_basis), **평형 지정 값이 bands와 갈리면 bands 쪽이 정상 매매에 가깝다**(세종 소형 실측 4,400만원 차). 단지가 특정된 질문("○○아파트 얼마야")은 realty_search_complexes가 기본이다 — 지역 평균은 단지 간 편차(같은 동 같은 평형에서 단지 평균 24% 차)를 뭉갠다. region은 시군구명(예: '강남구') 또는 **법정동까지**(예: '강남구 대치동', '세종특별자치시 나성동') — 세종처럼 시군구가 하나인 도시는 동 단위로 좁혀야 신도심· 구도심이 섞이지 않는다(2026-08-08, 8/7 테스터 제안 수용). 동명 지역이 여럿이면 시도를 앞에 붙여라 — 안 붙이면 **고르지 않고 거절**하며(region_ambiguous) 토큰이 정확히 같은 후보를 준다(그 목록을 사용자에게 되묻고, 고른 이름을 그대로 다시 넣어라). 지역은 토큰 정확일치로만 맞춘다 — '동구'는 '남동구', '서구'는 '달서구'가 아니다. metric: price(매매) | rental(전월세). rental도 **months 창 월별 추이**(monthly_trend: 전세 평균·중앙, 월세 보증금·월세, 건수 분리)를 준다 — "전세 떨어지는 중이야?", 역전세 판단용(입주 물량은 realty_move_in_supply와 조합). 상단 필드는 최신월 스냅샷. **rental엔 평형 인자가 안 먹는다** — 전월세 통계는 평형별로 나뉘어 있지 않아 pyeong_exclusive·pyeong_supply·area_m2_* 를 줘도 전체 평형 기준 값이 오고 warning_pyeong_fallback으로 실토한다(값이 잘못 나가는 게 아니라 **다른 모수**다). 평형별 전월세가 필요하면 단지 단위 realty_complex_rent_by_pyeong으로 가라. **면적은 사용자가 말한 단위 그대로 넣어라 — 환산은 서버가 한다**(2026-08-22 제보): - ㎡로 말했으면 → area_m2_exclusive(전용 84㎡ → 84) / area_m2_supply(공급 112.8㎡ → 112.8) - 평으로 말했으면 → pyeong_supply(분양 "34평") / pyeong_exclusive(전용 실평수 25.4평) ㎡ 값을 평 인자에 넣으면 조용히 환산하지 않고 사유와 두 방향 출구를 적어 거절한다. **가격순 '목록'이 필요하면 top_n을 준다**(2026-09-07 외부 신고 T-2026W34-352): "강남구 신고가 상위 5개"·"제일 비싸게 팔린 아파트"처럼 개별 거래를 나열하는 질문은 이 인자 없이는 답이 안 나온다 — 종전엔 그런 질문이 이 도구로 라우팅된 뒤 집계 (최고/평균/중앙)만 받고 목록을 못 줬다. top_transactions에 단지·평형·금액·계약일·층이 온다. **다만 그것은 '창 안의 고가 거래'이지 신고가(역대 최고가 경신)가 아니다** — 그 경계는 top_n을 준 응답이 같은 블록에서 적는다(이 도구 설명은 필드 이름을 대지 않는다 — 조건부로만 실리는 키를 설명이 무조건 지목하면 top_n 없이 부른 응답에서 없는 이름을 찾게 만든다, S364). **기준일 전후 비교·단지별 층/평형 분해는 여기서 한 번에**: 단지 목록엔 단지마다 층 밴드 분해(평형 미지정이면 평형대 4구간도)가 붙고 compare_from을 주면 전후 비교가 붙는다. 창은 months 전체(6개월 고정 아님)·계약해제 제외다. '고층 신고가냐 시세 상승이냐'는 전후 창의 층 분해로 가른다. 한쪽 3건 미만이면 변화율은 판정 보류, 기준일 이후 창은 신고기한 30일로 미완결.realty_region_trend_basket지역 가격 추이를 **양쪽 창에 모두 거래가 있는 동일 단지들로만** 계산한다. **왜 필요한가**: 구 월평균 추이는 '가격이 변한 것'과 '팔린 단지가 바뀐 것'을 구분하지 못한다. 표본이 얇으면 후자가 지배하는데, 그걸 시세 변동으로 읽으면 오답이다 (2026-08-14 실사고: 용산 33평 월 1~7건 표본으로 '전년 대비 −9.6%'를 만들었다). 이 도구는 **naive(전체 평균 변화)와 basket(동일 단지 변화)을 나란히** 주고 그 차이를 `composition_effect`로 보여준다 — 차이가 크면 그 지역 평균 추이는 구성 잡음이다. 단지별 값은 **평당가**라 단지 안의 평형 구성 변화도 흡수한다. 한계를 반드시 함께 전하라: 바스켓이 얇으면(단지 수가 적으면) 이 값도 못 믿는다. 취소·직거래는 제외했고, 단지 내 동·층 구성 변화까지는 보정하지 못한다.- +44 more on the listing page
Hudoc tools 2
echr_searchSearch European Court of Human Rights (ECHR / Strasbourg) case law by free text, Convention Article, respondent state and/or date. Returns case name, application number(s), Article(s) engaged, the conclusion (violation/no violation), importance level and the itemid to read the full judgment with echr_judgment. Use for "what has Strasbourg ruled on Article 8 against France", "recent Article 10 freedom-of-expression judgments", etc. Covers judgments by default; pass collection to search decisions, advisory opinions, resolutions, communicated cases or reports instead.echr_judgmentFetch the full text of one ECHR document by its itemid (from echr_search, e.g. "001-249132"). Returns the judgment/decision body converted to plain text, paged. Very recently published items (within a few days) sometimes have no converted text yet — the tool says so rather than returning nothing silently; echr_search's `conclusion` field is available immediately even then.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Korea Realty
{
"mcpServers": {
"korea-realty": {
"command": "npx",
"args": [
"-y",
"korea-realty"
],
"env": {
"REALTY_BACKEND_URL": "YOUR_REALTY_BACKEND_URL_HERE"
}
}
}
}
Hudoc
{
"mcpServers": {
"hudoc": {
"command": "npx",
"args": [
"-y",
"@pipeworx/mcp-hudoc"
]
}
}
}
Frequently asked questions
Korea Realty is categorized under Real Estate and uses a remote HTTP/SSE transport. Hudoc belongs to Legal and uses a local stdio subprocess. Pick Korea Realty for real estate work and Hudoc for legal.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Korea Realty is listed as freemium — a free tier with paid plans. Auth: no auth required. Hudoc has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add korea-realty and hudoc as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Korea Realty has a quality signal of 65/100 (Great) with 0 views, 0 installs and 0 GitHub stars. Hudoc has 59/100 (Good) with 2 views, 0 installs and 0 GitHub stars.