Tripuck

Search Hotels on Tripuck

search_hotels

Read-onlyIdempotent

Tripuck hotel search — real-time availability and prices for a city on given dates. Use this tool whenever the user asks about hotels, accommodation, or places to stay, e.g. "hotels in Antalya next weekend", "4-star hotel in Istanbul near Taksim", "İstanbul'da otel", "فندق في دبي", "Hotel in Berlin". Inputs: a city name plus optional check-in / check-out dates (YYYY-MM-DD) and guest counts. Supports structured filtering by minimum star rating, minimum guest-review score, and sorting. Returns live hotel options with price, star rating, review score and a thumbnail, each deep-linking to Tripuck.com for full details and booking. The LLM MUST infer the user language from the conversation and pass it via the locale parameter ("tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek). All widget UI text and the text response are then returned in that language. If currency is not specified, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`city`	Yes	Destination city or area name, e.g. "Antalya", "Istanbul", "Dubai", "Berlin". A free-text place name (not a code); it is matched to a Tripuck destination.
`adults`	No	Number of adult guests (default 2).
`locale`	No	User language as BCP-47 or 2-letter code. Supported: "tr" Turkish, "en" English, "ar" Arabic, "az" Azerbaijani, "de" German, "ka" Georgian, "uz" Uzbek. The LLM MUST infer this from the conversation and pass it explicitly; widget UI and response text will be rendered in this language.
`sortBy`	No	Result ordering: "recommended" (default), "price_asc" cheapest first, "price_desc" most expensive first, "star_desc" highest star first, "review_score" best-rated first. When the user asks to narrow/sort, re-call with this set.	recommended
`checkIn`	No	Check-in date in YYYY-MM-DD. MUST be today or in the future. If omitted, defaults to one week from today. Do NOT default the year to your training-time current year — use the actual upcoming date the user intends.
`checkOut`	No	Check-out date in YYYY-MM-DD, after check-in. If omitted, defaults to the night after check-in.
`children`	No	Number of child guests (default 0).
`currency`	No	ISO 4217 currency code. Examples: TRY, USD, EUR, AZN, GEL, UZS. If omitted, a sensible default is picked from the locale (tr→TRY, en→USD, de→EUR, ar→USD, az→AZN, ka→GEL, uz→UZS).
`minStarRating`	No	Minimum hotel star rating (1-5). Use when the user asks for e.g. "4-star or above".
`minReviewScore`	No	Minimum guest review score (0-10). Use when the user wants "highly rated" hotels.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, and open-world traits, but the description adds valuable behavioral context beyond them: real-time availability, deep-linking to Tripuck.com, mandatory locale inference from conversation, and locale-based currency defaults. These are meaningful operational details not present in annotations.

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 moderately long but every sentence adds value: purpose, usage examples, input summary, filtering/sorting capabilities, return details, and explicit locale/currency instructions. It is front-loaded with the core purpose and examples, though the locale/currency mapping could arguably live only in the schema.

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?

Despite having 10 parameters and no output schema, the description fully completes the context: it explains what is returned (live options with price, star rating, review score, thumbnail, deep links) and how the system behaves (locale/currency defaults). No critical gaps remain for agent invocation.

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% with detailed descriptions, so baseline is 3. The description adds a helpful high-level grouping of inputs and emphasizes 'structured filtering by minimum star rating, minimum guest-review score, and sorting', which helps the agent conceptualize parameter combinations beyond individual schema entries.

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 opens with a specific verb and resource: 'Tripuck hotel search — real-time availability and prices for a city on given dates.' It clearly distinguishes this from sibling tools by focusing on hotels and accommodation, with explicit examples covering various phrasings.

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 provides explicit guidance: 'Use this tool whenever the user asks about hotels, accommodation, or places to stay', followed by concrete example queries. This leaves no ambiguity about when to select this tool over siblings like search_flights or search_esim.

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

All Tripuck tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct travel need: flight search, hotel search, eSIM search, price calendar, popular routes, meeting point coordination, and flight details. No two tools overlap in their core function; even cheapest_dates vs search_flights are clearly separated by use case (flexible date overview vs specific trip search).

Naming Consistency4/5

All tool names use lowercase snake_case and are reasonably descriptive. There is a mix of verb-first (search_flights, search_hotels, search_esim, find_meeting_point) and noun/adjective-first (cheapest_dates, popular_routes, flight_details), but the pattern is consistent enough that an agent can predict naming conventions.

Tool Count5/5

Seven tools is well-scoped for a travel search server. Each tool serves a distinct and valuable purpose, covering flights, hotels, eSIM, inspiration, and group coordination without bloat or redundancy.

Completeness4/5

The tool surface covers the core travel search lifecycle: search flights, search hotels, search eSIM, plus helpful extras like cheapest dates and popular routes. Minor gaps exist—for example, no hotel details tool or car rental search—but these are not fatal for the server's primary search-driven purpose.

Resources

Need Help?