Skip to main content
Glama
nanwer

trip-search-mcp

by nanwer
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

get_stay_details

Retrieve detailed information for a specific stay property, including booking options, nearby places, amenities, and review scores, using a property token from previous search results.

Instructions

🎯 RENDERING DIRECTIVE — READ FIRST. Render the result as a single rich HTML/React artifact card. The booking_partners array is the headline payload — surface one prominent "Book on [partner]" button per partner, side-by-side in a row, styled as HTML buttons (NOT inline markdown links). Show price per partner on the button or directly under it. The user is drilling into ONE property to book; the card should make the booking-partner choice feel like a real product page, not a wall of text.

Fetch rich per-property details for a single stay (hotel or vacation rental) the user has already seen in a search_stays result.

Takes a property_token (copied from any offer in a search_stays response) plus the same check_in/check_out dates and party size used for the original search. Returns a single StayDetails object — NOT a list.

USE THIS TOOL WHEN: the user has narrowed down to a specific property from a previous search_stays result and wants more detail before booking — typical phrasings: "tell me more about [hotel name]", "what's it like inside", "show me the booking options", "what's near it", "is breakfast included".

DO NOT USE THIS TOOL WHEN: the user is still browsing or hasn't specified a property. Use search_stays first.

Returns:

  • description: long-form prose (rentals: usually 1–2 paragraphs; hotels: 1–3 sentences).

  • booking_partners: list of OTAs offering this property with link (direct deep-link to the partner's booking flow), price_per_night, total_price, official (true if the property's own site), free_cancellation. This is the key payload — surface these as prominent "Book on X" buttons.

  • nearby_places: up to ~14 entries (airports, transit stations, restaurants, landmarks) each with name, category, latitude, longitude. Use to answer "what's nearby" questions.

  • amenities / excluded_amenities: the full lists (no top-3 truncation).

  • check_in_time / check_out_time: e.g. "3:00 PM" / "11:00 AM".

  • star_rating, review_score (0–5), review_count, location_rating.

address is NOT in the response. SerpAPI's property_details endpoint doesn't carry a postal address. Use the GPS coordinates + nearby_places to communicate location.

Costs 1 SerpAPI quota call per invocation. Cached aggressively (TTL ~5 min by default) — repeat calls for the same (token, dates) tuple are free.

RESULT PRESENTATION: Render as a single rich card with the booking_partners list prominently displayed (one button per partner, "Book on [name] — €X/night, free cancellation: yes/no"). If the user asked about a specific aspect (location, breakfast, refundability), lead with that. Surface the GPS coordinates on a small map link if you have that capability.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
adultsNo
currencyNoEUR
check_in_dateYes
check_out_dateYes
property_tokenYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Tool Definition Quality

A4.8/5.0
Behavior5/5

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

No annotations provided, so description carries full burden. It discloses: costs 1 SerpAPI quota call, caching with TTL ~5 min, that address is NOT in response, and returns a single object not a list. No contradictions with annotations (none exist).

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 relatively long but well-structured: starts with rendering directive, then purpose, usage guidelines, return fields, and caveats. Every sentence adds value, though the rendering directive could be considered separate guidance for the agent's response rather than tool behavior.

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 the complexity (5 params, extensive output schema with nested objects, caching, quota), the description covers all essential aspects: input parameters, output fields, usage boundaries, and behavioral notes. It also mentions what is NOT returned (address). Output schema exists but description adds context beyond it.

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 0%, but description explains that property_token is 'copied from any offer in a search_stays response' and that dates and adults should match the original search. It provides meaning beyond schema for key parameters, though it doesn't explicitly describe currency (default provided in 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?

The description clearly states: 'Fetch rich per-property details for a single stay (hotel or vacation rental) the user has already seen in a search_stays result.' It uses specific verb (fetch) and resource (per-property details for a single stay), and distinguishes itself from sibling search_stays by specifying it is for a single property already selected.

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?

The description explicitly states when to use: 'USE THIS TOOL WHEN: the user has narrowed down to a specific property...', and when not to use: 'DO NOT USE THIS TOOL WHEN: the user is still browsing or hasn't specified a property. Use search_stays first.' It provides clear context and an explicit alternative.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nanwer/trip-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server