Skip to main content
Glama
Sign In

korea-stay

by app.sallim
OverviewDiscussionsAdmin

예약 페이지 링크

stay_booking_link
Read-onlyIdempotent

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

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

Input Schema

NameRequiredDescriptionDefault
stay_idYesstay_search가 준 stay_id
platformNo어느 플랫폼 검색으로 보낼지 (naver, google, tour)naver

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / stay_id / maxLength
      Added value: +200
  2. Changed1 schema field changed
    • addedInput schema / properties / platform / enum
      Added value: +[
+  "naver",
+  "google",
+  "tour"
+]
  3. Changed2 schema fields changed
    • changedInput schema / properties / platform / description
      Previous value: -"어느 플랫폼 검색으로 보낼지"New value: +"어느 플랫폼 검색으로 보낼지 (naver, google, tour)"
    • removedInput schema / properties / platform / enum
      Removed value: -[
-  "naver",
-  "google",
-  "tour"
-]
  4. First observed

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.

All korea-stay 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