Skip to main content
Glama
Sign In

korea-stay

by app.sallim
OverviewDiscussionsAdmin

Server Details

Korean lodging: 84,490 stays from 4 government permit ledgers + KTO TourAPI, honest gaps

Ownership verified
Status
Healthy
Uptime
99.9% over 82 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
ChatGPT
–
Claude
–

TDQS

A4/5.0

Scored across 4 tools

Disambiguation4/5

report_issue is clearly separate from the three stay_* read tools. stay_search vs stay_detail vs stay_booking_link have a natural pipeline relationship (find → inspect → redirect to original platform), and the descriptions explicitly bound each (detail cannot check inventory, booking_link only makes search links). Minor risk that an agent conflates detail with link, but descriptions resolve it.

Naming Consistency4/5

Three tools share a clean stay_<noun> resource prefix (stay_search, stay_detail, stay_booking_link), giving strong domain grouping. report_issue breaks the pattern with a verb_noun form, but it is a distinct concern and remains clearly readable.

Tool Count4/5

Four tools is on the lean side but each maps to a distinct step of the search→detail→book-via-external-link workflow plus a feedback channel. Nothing appears redundant or missing purely on count; it is a deliberately minimal read-only surface.

Completeness4/5

The search → detail → external booking-link lifecycle is covered, with an explicit statement that inventory/booking are out of scope, and report_issue handles the feedback path. Minor gaps (e.g. no explicit region/amenity listing or listing of filter options) are workable since stay_search accepts conditions and error semantics are documented.

Available Tools

4 tools
report_issue답변 오류 신고AInspect

사용자가 답변 오류 제보·개선 요청·문의를 전해 달라고 했을 때만 운영자에게 전달한다.

쓰는 때: 사용자가 "이거 틀렸으니 신고해 줘", "운영자에게 알려 줘", "이 기능도 넣어 달라고
전해 줘"처럼 제보·요청을 부탁했을 때. 보내기 전에 무엇이 전달되는지 사용자에게 알린다.
kind='결함'은 틀린 답 제보, kind='질문기록'은 개선 요청, kind='유료이용문의'·'후원문의'는
사용자가 유료 이용 희망·후원 의사를 운영자에게 전해 달라고 한 경우다.
사용자가 오류·불만·개선 희망·유료 이용 희망·후원 의사를 말했지만 전달을 부탁하지는 않았다면,
부르지 말고 "운영자에게 전해 드릴까요?"를 한 줄로 한 번만 물어 동의할 때만 부른다(거절·무반응이면
다시 묻지 않는다). 응답의 접수번호(ref)와 회신 방법(reply_path)을 사용자에게 알린다.

쓰지 않는 때: 사용자가 요청하지 않았는데 질문을 남기려고 부르지 않는다. 답하기 전에
먼저 부르지도 않는다 — 이 도구는 답변을 대신하지 않는다.

전달 내용(인자)과 같은 접속 주소 단위의 30분 안 직전 호출 최대 5건 요약이 운영자 검토용으로
저장된다(공유 망 뒤에서는 다른 사용자의 호출이 섞일 수 있다 · 주소 단위를 못 가리면 싣지 않는다)
(개인정보처리방침 https://stay.sallim.app/privacy). 연락처(contact)는 사용자가 회신을 원해
직접 준 경우에만 담고, 그 건의 회신에만 쓴다. 무인증 공개 서버라 쓰기 표면을 이 도구
하나로 묶어 시간당 상한을 건다(CLAUDE.md 규칙 2).
NameRequiredDescriptionDefault
kindNo'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 정보도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다. '유료이용문의'=사용자가 유료 이용·한도 확대를 원한다며 운영자에게 전해 달라고 한 경우. '후원문의'=사용자가 후원 의사를 전해 달라고 한 경우. 사용자가 요청하지 않은 내용을 기록용으로 넘기지 않는다결함
contactNo회신받을 연락처(이메일 등, 200자 이내) — **사용자가 회신을 원한다며 직접 알려 준 값만** 넣는다. 넣기 전에 '운영자가 회신에만 쓰고 개인정보처리방침에 따라 보관한다'고 알리고 동의를 받는다. 대화에서 짐작하거나 다른 데서 가져와 채우지 않는다
problemNo사용자가 제보한 문제. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'·'유료이용문의'·'후원문의'면 필수(문의 내용), kind='질문기록'이면 비워도 된다.
expectedNo사용자가 맞다고 본 값
questionNo사용자가 제보·개선 요청과 함께 전달하기로 한 질문(kind='질문기록'이면 필수). 이름·연락처·정확한 거주지 같은 개인 식별 정보는 빼고 일반형으로 적는다(예: '○○동 △△빌라 사는 김□□, 부모님 팔순으로 속초 2박' → '가족 3인 속초 2박'). 무인증 공개 서버의 로그다
tool_usedNo문제가 된 답을 만든 도구
wrong_valueNo틀린 수치·문장
missing_axisNoanswered_fully=false일 때 **없어서 못 답한 것**(예: '실시간 빈방', '가격대 필터 없음', '반려동물 동반 가능 여부 미수록')
answered_fullyNokind='질문기록' 전용 — 이 서버 도구만으로 그 질문에 완결된 답을 했는가. false면 missing_axis에 무엇이 없었는지 적는다

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important side effects: the submitted content and a 30-minute summary of up to five recent calls are stored for operator review, contact info is used only for replies, and an hourly rate limit applies on an unauthenticated public server. These details materially help the agent understand privacy and operational consequences.

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?

The description is long but front-loads the critical condition in bold, then separates when-to-use, when-not-to-use, and data-handling notes. Some repetition exists around consent and user requests, but the length is justified by the privacy and safety constraints.

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?

For a mutation tool with privacy, consent, and rate-limit implications, the description covers invocation conditions, consent flow, side effects, data retention, and authentication context. The output schema exists and the description still usefully notes that ref and reply_path should be shown to the user.

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 input schema already provides rich per-field guidance for kind, contact, problem, question, and the other arguments. The description adds high-level meaning for kind and contact handling, but it largely repeats what the schema already documents rather than adding new parameter-level detail.

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 action: forwarding an answer-error report, improvement request, or inquiry to the operator only when the user asks. It clearly distinguishes this from answering questions directly and from silently logging feedback.

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 gives explicit when-to-use triggers, when-not-to-use conditions, and a consent protocol: do not call unless the user asks, ask once before sending, and do not ask again after refusal or silence. This leaves little ambiguity for an agent deciding whether to invoke the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

stay_booking_link예약 페이지 링크A
Read-onlyIdempotent
Inspect

원본 플랫폼(네이버·구글·관광공사)의 검색 결과로 가는 링크를 만든다.

이 서버는 예약을 처리하지 않는다 — 사용자를 원본 플랫폼으로 보낸다. 링크는 **검색 링크**이며
특정 객실·예약 페이지가 아니고 예약 가능 여부도 확인하지 않는다. 검색어는 naver·google이
숙소명+주소, tour는 숙소명만이다(주소가 안 들어가 같은 이름의 다른 숙소가 섞일 수 있다).
관광공사 행이 인허가 원장에서 폐업으로 공시되면(stay_detail의 ledger_closure가 closed_in_ledger*)
응답에 ledger_closure(status·close_date·같은 주소 영업 등록)와 note 한 문장을 함께 싣는다.
NameRequiredDescriptionDefault
stay_idYesstay_search가 준 stay_id
platformNo어느 플랫폼 검색으로 보낼지 (naver, google, tour)naver

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing that the link is a search link, not a specific room/booking page, that availability is not verified, and that tour search may mix up same-named stays. It even documents a conditional response field (ledger_closure with status, close_date, note) when a closure is disclosed in the ledger.

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 purpose, then uses short paragraphs for the non-booking caveat, platform-specific search terms, and the ledger_closure behavior. Dense but every sentence carries distinct information; the parenthetical detail on tour is slightly heavy but justified.

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?

Covers the non-obvious behaviors an agent needs: no booking processing, search-vs-booking-page distinction, per-platform query composition, and the conditional ledger_closure payload. With an output schema present, return format needn't be explained further.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds semantic value: it explains what search terms each platform receives (naver/google = name+address, tour = name only) and the resulting risk for tour. It doesn't restate the stay_id requirement beyond the schema.

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 and resource: builds a link to the original platform's (Naver/Google/Tourism Org) search results. It explicitly distinguishes itself from a booking tool ("이 서버는 예약을 처리하지 않는다") and from siblings implicitly by scoping to link generation only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly explains what the tool does not do (no booking processing, no availability check) and describes platform-specific search-term behavior. It does not explicitly say when to prefer stay_detail or stay_search instead, so it is clear context without explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

stay_detail숙소 상세A
Read-onlyIdempotent
Inspect

숙소 하나의 상세 정보(이름·주소·좌표·종류·원장 출처)를 조회한다. 재고는 조회하지 못한다 — 이 서버에 붙은 재고 채널이 0개라 날짜·인원을 줘도 availability는 항상 unknown이다(사유는 unavailable_reason에 실린다). 만실도 빈방 있음도 아니다. 빈방·요금은 stay_booking_link로 원본 검색 링크를 받아 직접 확인하라.

관광공사(tourapi) 행에는 인허가 원장의 폐업 등록과 이름·주소 정확 일치로 대조한 결과가 ledger_closure로 온다 — closed_in_ledger면 원장 기준 폐업이고, 같은 주소의 영업 중 원장 등록도 찾지 못했다(대조한 주소 범위는 note에 있다). closed_in_ledger_address_active면 폐업 등록과 함께 같은 주소에 다른 상호로 영업 중인 원장 등록이 있다(same_address_active) — 같은 업소인지 판정하지 못하니 둘 다 전하라. closed_in_ledger_address_unchecked면 폐업 등록은 있지만 같은 주소의 영업 등록 대조를 이번에 못 했다(확인 안 됨). 폐업 등록을 못 찾은 것은 영업 중의 확증이 아니다.

NameRequiredDescriptionDefault
guestsNo인원(1~30)
checkinNo체크인 YYYY-MM-DD
stay_idYesstay_search가 준 stay_id (예: tourapi:2671267)
checkoutNo체크아웃 YYYY-MM-DD
include_footnotesNotrue면 계산값(건수·요금)의 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다(기본은 행마다 한 줄 요지)

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the readOnly/idempotent annotations: it discloses that availability is always unknown because zero inventory channels are attached, that the reason surfaces in unavailable_reason, and gives a careful reading guide for ledger_closure states with an explicit caveat that absence of a closure record is not proof of operation. This is exactly the kind of domain caveat annotations cannot carry. It does not, however, mention pagination, latency, authentication, or any rate/size limits.

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-loaded with purpose and the decisive 'no inventory' caveat, and every sentence carries information with no filler. It is nonetheless dense and roughly half the text interprets output field values (ledger_closure states, unavailable_reason), which is close to duplicating an output schema's job rather than describing the invocation.

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?

Given a read-only, five-parameter tool with an output schema, the description covers everything an agent needs to call it correctly and interpret the result: scope, the stay_id provenance, the always-unknown availability trap, and the ledger closure interpretation rules. Nothing material is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds a genuinely useful semantic that the schema cannot express: supplying checkin/checkout/guests does not produce real availability, so those parameters are effectively inert for the question most users would bring. It does not clarify date format or guest-range behavior beyond the schema, hence not a 5.

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?

Opens with a specific verb + resource + enumerated fields (이름·주소·좌표·종류·원장 출처), then explicitly carves out what it does NOT return (재고/availability). It distinguishes itself from siblings by name, so an agent can separate it from stay_search and stay_booking_link 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?

States both when to use it (fetch detail for a stay_id obtained from stay_search) and when not to (any vacancy/rate question), and routes the agent to a named alternative, stay_booking_link, for that case. The 'not full, not vacant' clarification prevents a very plausible misuse of an unknown availability value.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

stay_search숙소 검색A
Read-onlyIdempotent
Inspect

조건에 맞는 국내 숙소를 찾는다.

**재고를 확인하지 못한 숙소를 결과에서 지우지 않는다.** availability가 unknown이면
빈방 여부를 모른다는 뜻이고, 만실이라는 뜻이 아니다. 사용자에게 그렇게 전달하라.
NameRequiredDescriptionDefault
limitNo반환 개수 (1~50)
guestsNo인원(1~30)
regionNo지역. '강원 속초', '서울 마포구'처럼 시도+시군구. 전국은 region을 비운다(빈 값 = 지역 조건 없음 — '전국'·'한국'은 지역 이름이 아니라 주소 글자로 걸린다). 정식명·구명·약칭 다 받는다('제주도'='제주'='제주특별자치도'). 행정구역 어휘와 대조해 걸고, 어휘에 없는 말(읍·면·동·도로명)은 주소 부분문자열로 내려간다 — 어느 쪽이었는지는 meta.region_matched_on에 적힌다. 0건이면 복구 경로가 meta.unapplied_conditions로 **반드시** 오고, 다시 걸 이름을 댈 수 있을 때만 meta.region_retry가 함께 온다(0건 = '없다'가 아니다). region_retry는 대개 질의가 건 시도 안의 이름이지만, 토큰이 **한 시도에만 있는** 시군구를 이름으로 불렀는데 건 시도가 그 시도가 아니면 **다른 시도 이름**이 온다('경북 군위' → '대구광역시 군위군' — 군위는 대구로 편입됐다) — 그때는 meta.region.tokens[].other_sido_sigungu와 meta.unapplied_conditions가 '건 시도의 시군구가 아니다'를 공시한다. 같은 이름이 여러 시도에 있거나('서구') 앞 두 글자만 겹친 다른 시도 이름은 region_retry가 아니라 meta.region_retry_other_sido로 갈라 온다. 시도를 안 줬으면 region_retry는 토큰이 이름으로 부른 시군구만 담는다. **로마자는 시도만 받는다**('Seoul'·'Jeju-do'는 통하고 'Gangnam'은 안 통한다) — 시군구 이하는 한글로 써라. **숙소 이름 검색은 없다**(이름 대신 그 숙소의 주소를 넣어라) · 업종어('펜션'·'게스트하우스')는 region이 아니라 category로 건다
checkinNo체크인 YYYY-MM-DD. checkout과 **둘 다** 주고 재고 채널이 붙어 있을 때만 재고(availability)를 조회한다 — 한쪽만 줬거나 채널이 없으면 날짜로 거르지 않고 availability=unknown이며(미조회 사유는 각 행의 unavailable_reason), 날짜가 적용되지 않은 사실은 meta.unapplied_conditions에 실린다. 채널이 있어도 목록은 날짜로 거르지 않는다(재고 표시에만 쓴다) — 지난 날짜면 재고는 조회하지 않는다(목록은 그대로 나온다)
categoryNo숙소 종류. 라벨은 두 원천의 어휘에서 오고, 같은 숙소라도 원천마다 이름이 다르다. TourAPI 마케팅 라벨: 관광호텔·콘도미니엄·유스호스텔·펜션·모텔·민박·게스트하우스·홈스테이·서비스드레지던스·한옥 인허가 원장 법정 업종명: 관광호텔·여관업·숙박업(생활)·여인숙업·일반호텔·숙박업 기타·휴양콘도미니엄업·농어촌민박업·외국인관광 도시민박업·한옥체험업 두 어휘에 다 있는 라벨: 관광호텔 — 양쪽 원천을 함께 거른다. 그 밖의 라벨은 자기 원천의 숙소만 거르고, 다른 원천의 같은 종류 숙소는 빠진다(예: '펜션'으로 걸면 원장의 '농어촌민박업'이 빠진다). 전체를 보려면 다른 어휘의 대응 라벨로 한 번 더 걸어라.
checkoutNo체크아웃 YYYY-MM-DD
include_footnotesNotrue면 계산값(건수·요금)의 근거 전문(산식·모집단·기간·원천)을 footnotes에 싣는다(기본은 행마다 한 줄 요지)

Output Schema

NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior4/5

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

Although annotations already declare readOnly/idempotent/non-destructive/openWorld, the description adds a genuinely non-obvious behavioral rule: results with unknown availability must not be dropped, and unknown means 'vacancy undetermined', not 'fully booked', which must be conveyed to the user. That guards against a likely misinterpretation the annotations do not cover. It stops short of describing pagination, result ordering, or scale, so it is not a 5.

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?

Two short blocks: the purpose first, then the critical caveat in bold, which is a good front-loaded structure. The un-bolded sentence slightly restates the bolded one, a small redundancy that keeps the definition from a perfect score.

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?

Annotations are rich, an output schema exists, and the schema documents all 7 parameters at full coverage, so the description need not explain return shapes. It covers purpose and the single most dangerous interpretation pitfall; only sibling routing and typical follow-up (detail/booking) are missing.

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 region, category, and date parameters carry exhaustive in-schema documentation (including retry semantics and label vocabularies). The description body adds no parameter-level meaning of its own, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: '조건에 맞는 국내 숙소를 찾는다' (find domestic accommodations matching conditions), with an explicit domestic and condition-filtered scope. It never names the sibling tools (stay_detail, stay_booking_link), so the agent must infer from their names that detail and booking are elsewhere; the purpose is clear but not differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contains no when-to-use or when-not-to-use guidance and no routing to stay_detail or stay_booking_link, even though they are natural follow-ups. The second paragraph guides post-result interpretation ('사용자에게 그렇게 전달하라') but that is output handling, not tool selection, so real selection guidance is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedstay_search2 fields changed
      • changedInput schema / properties / checkin / description
        Previous value: -"체크인 YYYY-MM-DD. 주면 재고 조회를 시도한다 — 지난 날짜면 재고는 조회하지 않는다(목록은 그대로 나온다)"New value: +"체크인 YYYY-MM-DD. checkout과 **둘 다** 주고 재고 채널이 붙어 있을 때만 재고(availability)를 조회한다 — 한쪽만 줬거나 채널이 없으면 날짜로 거르지 않고 availability=unknown이며(미조회 사유는 각 행의 unavailable_reason), 날짜가 적용되지 않은 사실은 meta.unapplied_conditions에 실린다. 채널이 있어도 목록은 날짜로 거르지 않는다(재고 표시에만 쓴다) — 지난 날짜면 재고는 조회하지 않는다(목록은 그대로 나온다)"
      • changedInput schema / properties / region / description
        Previous value: -"지역. '강원 속초', '서울 마포구'처럼 시도+시군구. 전국은 region을 비운다(빈 값 = 지역 조건 없음 — '전국'·'한국'은 지역 이름이 아니라 주소 글자로 걸린다). 정식명·구명·약칭 다 받는다('제주도'='제주'='제주특별자치도'). 행정구역 어휘와 대조해 걸고, 어휘에 없는 말(읍·면·동·도로명)은 주소 부분문자열로 내려간다 — 어느 쪽이었는지는 meta.region_matched_on에 적힌다. 0건이면 복구 경로가 meta.unapplied_conditions로 **반드시** 오고, 다시 걸 이름을 댈 수 있을 때만 meta.region_retry가 함께 온다(0건 = '없다'가 아니다). region_retry는 질의가 건 시도 안의 이름만 담고, 시도를 안 줬으면 토큰이 이름으로 부른 시군구만 담는다. **로마자는 시도만 받는다**('Seoul'·'Jeju-do'는 통하고 'Gangnam'은 안 통한다) — 시군구 이하는 한글로 써라. **숙소 이름 검색은 없다**(이름 대신 그 숙소의 주소를 넣어라) · 업종어('펜션'·'게스트하우스')는 region이 아니라 category로 건다"New value: +"지역. '강원 속초', '서울 마포구'처럼 시도+시군구. 전국은 region을 비운다(빈 값 = 지역 조건 없음 — '전국'·'한국'은 지역 이름이 아니라 주소 글자로 걸린다). 정식명·구명·약칭 다 받는다('제주도'='제주'='제주특별자치도'). 행정구역 어휘와 대조해 걸고, 어휘에 없는 말(읍·면·동·도로명)은 주소 부분문자열로 내려간다 — 어느 쪽이었는지는 meta.region_matched_on에 적힌다. 0건이면 복구 경로가 meta.unapplied_conditions로 **반드시** 오고, 다시 걸 이름을 댈 수 있을 때만 meta.region_retry가 함께 온다(0건 = '없다'가 아니다). region_retry는 대개 질의가 건 시도 안의 이름이지만, 토큰이 **한 시도에만 있는** 시군구를 이름으로 불렀는데 건 시도가 그 시도가 아니면 **다른 시도 이름**이 온다('경북 군위' → '대구광역시 군위군' — 군위는 대구로 편입됐다) — 그때는 meta.region.tokens[].other_sido_sigungu와 meta.unapplied_conditions가 '건 시도의 시군구가 아니다'를 공시한다. 같은 이름이 여러 시도에 있거나('서구') 앞 두 글자만 겹친 다른 시도 이름은 region_retry가 아니라 meta.region_retry_other_sido로 갈라 온다. 시도를 안 줬으면 region_retry는 토큰이 이름으로 부른 시군구만 담는다. **로마자는 시도만 받는다**('Seoul'·'Jeju-do'는 통하고 'Gangnam'은 안 통한다) — 시군구 이하는 한글로 써라. **숙소 이름 검색은 없다**(이름 대신 그 숙소의 주소를 넣어라) · 업종어('펜션'·'게스트하우스')는 region이 아니라 category로 건다"
  2. 1 tool update
    • Changedreport_issue4 fields changed
      • addedInput schema / properties / contact
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "회신받을 연락처(이메일 등, 200자 이내) — **사용자가 회신을 원한다며 직접 알려 준 값만** 넣는다. 넣기 전에 '운영자가 회신에만 쓰고 개인정보처리방침에 따라 보관한다'고 알리고 동의를 받는다. 대화에서 짐작하거나 다른 데서 가져와 채우지 않는다",
+  "title": "Contact"
+}
      • changedInput schema / properties / kind / description
        Previous value: -"'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 정보도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다. 사용자가 요청하지 않은 질문을 기록용으로 넘기지 않는다"New value: +"'결함'=사용자가 답이 틀렸다고 제보해 달라고 한 경우(기본). '질문기록'=사용자가 '이런 질문에도 답하게 해 달라'·'이 정보도 넣어 달라'처럼 **개선 요청을 전해 달라고 한 경우** — 그 질문과 무엇이 없었는지를 넘긴다. '유료이용문의'=사용자가 유료 이용·한도 확대를 원한다며 운영자에게 전해 달라고 한 경우. '후원문의'=사용자가 후원 의사를 전해 달라고 한 경우. 사용자가 요청하지 않은 내용을 기록용으로 넘기지 않는다"
      • changedInput schema / properties / kind / enum
        Previous value: -[
-  "결함",
-  "질문기록"
-]New value: +[
+  "결함",
+  "질문기록",
+  "유료이용문의",
+  "후원문의"
+]
      • changedInput schema / properties / problem / description
        Previous value: -"사용자가 제보한 문제. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'이면 필수, kind='질문기록'이면 비워도 된다."New value: +"사용자가 제보한 문제. 사용자가 지적한 말을 그대로 옮겨도 된다. kind='결함'·'유료이용문의'·'후원문의'면 필수(문의 내용), kind='질문기록'이면 비워도 된다."

Related MCP Connectors

Related MCP Servers

  • stay-search MCP

    ilhae-ai
    F
    license
    A
    quality
    D
    maintenance
    Enables searching and comparing Airbnb (Korea) and Yanolja accommodation prices, with tools for price distribution, historical trends, and snapshot management, storing collected data in SQLite.
    4
    -

  • korea-data-mcp

    YoungsoonLee
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to query Korean public data from OpenDART, data.go.kr and law.go.kr — corporate filings and financials, stock prices, apartment trades, business registration status, holidays, statutes in force on a given date, and court rulings. It corrects the live APIs' known traps (mislabeled periods, not-yet-in-force laws, cancelled trades, changed district codes) so answers come back right, with evidence.
    7
    Apache 2.0

  • taxfood-mcp

    man2service
    A
    license
    Not graded
    quality
    D
    maintenance
    Exposes public agency dining expense data from Korean public institutions, enabling AI agents to search, rank, and retrieve details of tax-funded restaurant visits with transparency links and KakaoMap deep links.
    MIT
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