SlickTrip

Add a hotel bucket list

add_hotel_bucket_list

Idempotent

Use for flexible-date hotel watches on a place or one named hotel: SlickTrip keeps searching stays of the given length across the chosen months or date window and alerts when a stay clears the per-night bar. Returns a bucket_id. When the traveler asks to be alerted, call it now; otherwise offer it first. Not for fixed dates (search_hotels, then track_hotel).

Input Schema

Name	Required	Description
`adults`	No	Adults. A hotel room prices up to 6 guests in all; vacation rentals up to 16.
`months`	No	Months to watch, as names or YYYY-MM, or give start_date + end_date. Leave both empty to watch every month on sale (the default).
`nights`	Yes	Nights, 1-30.
`end_date`	No	Latest check-in, YYYY-MM-DD.
`location`	Yes	A city, area or landmark.
`min_stars`	No	Lowest star class to show, 1-5.
`hotel_name`	No	Pin one exact hotel instead of the whole area.
`start_date`	No	Earliest check-in, YYYY-MM-DD. Give with end_date instead of months.
`user_request`	No	Optional, and it works in the traveler's favor. Quote the traveler's latest message about this trip exactly as they wrote it, in their wording, language and spelling, not a summary. SlickTrip runs its own travel parser on these words: when a search fails or comes back empty, it compares what the traveler said with the arguments sent and returns a corrected search, so you can fix it without asking them again. It has caught Cancun sent as MEX instead of CUN, and travelers dropped from the party. A summary loses exactly the details it checks. If the message only answers a question ("yes, the 20th"), quote the message where they asked for the trip. Send the same quote on every call for this request. Leave out anything not about the trip, and never include names, contact details, or payment or ID information. The words also help SlickTrip improve its search.
`check_in_days`	No	Only check in on these weekdays.
`max_price_per_night`	No	The price bar, USD per night.

Output Schema

Name	Required	Description
`code`	No	On an error: a machine-readable kind, e.g. unknown_place
`kind`	No	Always "hotel"
`note`	No	First results timing
`stay`	No	location, hotel_name, nights, adults
`field`	No	On unknown_place: which argument (origin, destination, ...)
`alerts`	No	Plain-words description of alerts
`months`	No	Month names watched
`status`	No	watching \| error \| sign_in_required
`window`	No	{start, end} date window
`message`	No	Error or sign-in message from the server wrapper
`channels`	No	Alert channels on the record: email, text (booleans)
`bucket_id`	No	The new bucket list record id
`min_stars`	No	Minimum star rating
`saved_url`	No	slicktrip.com saved hotel-buckets link
`suggestions`	No	On unknown_place: places to offer the traveler, each with code, name, kind (airport, all airports in the city, nearby airport), city, country
`places_assumed`	No	Place names this call resolved on its own, e.g. 'Portland = Portland, OR (PDX)'; tell the traveler
`max_price_per_night_usd`	No	Nightly price bar

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 9, 2026

changedInput schema / properties / months / description

Previous value: -"Months to watch, as names or YYYY-MM. Give this OR start_date + end_date."New value: +"Months to watch, as names or YYYY-MM, or give start_date + end_date. Leave both empty to watch every month on sale (the default)."

changedInput schema / properties / user_request / anyOf

Previous value: -[
-  {
-    "maxLength": 300,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 500,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / user_request / description

Previous value: -"Optional. The traveler's current travel request, briefly, in their own words. Used to interpret this search, suggest a corrected search if it fails, and improve SlickTrip's search. Include only this request; not earlier conversation, names, contact details, or payment or ID information."New value: +"Optional, and it works in the traveler's favor. Quote the traveler's latest message about this trip exactly as they wrote it, in their wording, language and spelling, not a summary. SlickTrip runs its own travel parser on these words: when a search fails or comes back empty, it compares what the traveler said with the arguments sent and returns a corrected search, so you can fix it without asking them again. It has caught Cancun sent as MEX instead of CUN, and travelers dropped from the party. A summary loses exactly the details it checks. If the message only answers a question (\"yes, the 20th\"), quote the message where they asked for the trip. Send the same quote on every call for this request. Leave out anything not about the trip, and never include names, contact details, or payment or ID information. The words also help SlickTrip improve its search."

changedInput schema / properties / user_request / examples

Previous value: -[
-  "cheap nonstop to Lisbon early May",
-  "family of 8 in Albufeira, 4 nights mid November"
-]New value: +[
+  "we're 6 friends from madrid, want somewhere cheap and fun in europe dec 20-24, morning flights pls",
+  "necesito llevar a mi mamá de Calgary a Kolkata a fines de octubre, no puede hacer escala en Estados Unidos"
+]

First observedOct 5, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes beyond the annotations (readOnlyHint=false, idempotentHint=true) by explaining the ongoing behavior: SlickTrip keeps re-searching stays of the given length across the chosen months and alerts when the per-night bar is cleared, and it returns a bucket_id. Missing are operational limits an agent might hit — caps on number of watches, how/when alerts are delivered, or cost — which keeps it off 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences: what it does first, return value second, decision rule third, exclusion last. No filler and no repetition of schema detail.

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?

With 11 parameters, an output schema present, and full annotation coverage, the description carries only the parts structured data can't: the alerting model and the call/offer policy. It leaves out limits on how many watches exist and what an alert looks like, minor gaps for an otherwise complete definition.

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 real meaning by explaining how parameters combine into a search: "given length" (nights) across "the chosen months or date window" (months vs start_date/end_date) with a "per-night bar" (max_price_per_night) on a place or "one named hotel". It frames the semantics rather than restating field text.

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 — a flexible-date hotel watch on a place or a single named hotel — and immediately distinguishes it from fixed-date tracking by naming search_hotels and track_hotel as the alternative path. An agent can route correctly without opening the 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?

"When the traveler asks to be alerted, call it now; otherwise offer it first" gives an explicit call-vs-offer decision rule, and "Not for fixed dates (search_hotels, then track_hotel)" names the exclusion and the sibling chain that replaces it.

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

All SlickTrip tools Inspect

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

Need Help?