stay_booking_link예약 가능한 원본 페이지로 가는 링크를 만든다.
이 서버는 예약을 처리하지 않는다 — 사용자를 원본 플랫폼으로 보낸다. 링크는 숙소명·주소로
만든 **검색 링크**이며 특정 객실의 예약 페이지가 아니다(그건 재고 어댑터가 붙어야 나온다).
| Name | Required | Description | Default |
|---|---|---|---|
| stay_id | Yes | stay_search가 준 stay_id | |
| platform | No | 어느 플랫폼 검색으로 보낼지 | naver |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnly/idempotent/non-destructive. Description adds behavioral context: the tool only generates a search link, does not process bookings, and link construction is based on property name/address. This goes beyond the annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs that front-load the core action and provide essential distinctions in each sentence. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema, the description covers purpose, limitations, and link type sufficiently. The presence of an output schema means return format need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions (stay_id from stay_search, platform enum with default). Description adds no extra parameter information, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it creates a link to the original booking-enabled page, clarifies it is a search link (not a specific room reservation page), and contrasts with inventory adapter needs, distinguishing it from siblings like stay_search and stay_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use (when needing to send users to the original platform) and when-not-to-use (does not handle reservations, not for specific room pages, which require inventory adapter). This explicit exclusion clarifies boundaries despite not naming sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are largely distinct: search finds stays, detail shows one, booking_link generates a referral URL, and report_issue handles feedback. The single ambiguity is report_issue combining two kinds (defect and question logging), but its descriptions clarify the usage.
Three tools follow a stay_ prefix pattern (stay_search, stay_detail, stay_booking_link), but report_issue breaks the convention and uses a separate prefix. The structure is mixed (verb, noun, compound) though still readable.
Four tools is well-scoped for a referral service: search, detail, link generation, and issue reporting. Each tool has a clear role with no redundancy or missing essentials.
The surface covers the core journey (find, view, link out) and adds issue tracking. It lacks direct booking or availability filtering, but that is intentionally delegated to external platforms, so the coverage is reasonable for the stated purpose.