Kompare travel search
Server Details
Live prices on package holidays and niche trips from Danish travel agencies, with booking links.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 4 tools
The four tools split into two result-returning searches (find_trips, search_listings) and two metadata tools (search_init, get_facets), which are clearly distinct. The main ambiguity is find_trips vs search_listings, since both return bookable trips; the descriptions mitigate this by framing find_trips as the quick plain-words option and search_listings as the filter-rich one, but an agent could still misselect when a plain query also fits structured filters.
All names follow a verb_noun snake_case pattern (find_trips, get_facets, search_init, search_listings), which is predictable. The only minor wrinkle is that two near-identical search operations use different verbs (find vs search), but the overall convention is consistent and readable.
Four tools is on the lean side but each has a defined role: init/overview, facet exploration, quick search, and filtered search. Given the very broad domain (20 niches via one filter-rich search tool), the surface is well-scoped, though the find_trips/search_listings overlap makes the count feel slightly redundant rather than minimal.
The surface covers discovery (search_init), filtering (get_facets), and searching/booking handoff (find_trips, search_listings returning bookingUrl), with rich aggregate and paginated results. There is no dedicated single-listing detail tool and no booking execution, but booking is delegated to seller URLs, so core workflows are largely covered.
Available Tools
4 toolsfind_tripsFind trips in plain wordsARead-onlyIdempotentInspect
The quickest way to search: describe the trip in plain words and get bookable trips back in one call.
travelType, one of:
ski: ski and snowboard holidays
golf: golf holidays
surf: surf camps and holidays
diving: diving holidays
hiking: hiking and walking holidays
charter: package holidays: sun and beach trips with flight and hotel
cycling: cycling holidays
football: football trips: a match ticket with travel and hotel
carrental: car rental
f1: Formula 1 race trips
running: running races abroad, marathons and the like
americanfootball: NFL game trips
yoga: yoga retreats
triathlon: triathlon races and training camps
cruise: cruises
coach: coach (bus) tours
holidayhome: holiday homes and cottages
roundtrip: round trips and guided tours through several places
citybreak: city breaks
dance: dance holidays
places: destinations, ski areas, regions or countries in plain words, English or Danish ("Ischgl", "Østrig", "Costa del Sol"). Leave it out for anywhere. When: startFrom/startTo (the window the trip starts in) or months. Party: adults and children, since prices depend on them. Optional: durationDays, maxPricePerPerson, sort (best, cheapest, soonest), limit.
Response: { understood, ...{ total, accommodationCount, offset, results: [{ name, country, destination, stars, guestRating, tripsAvailable, trips: [{ start, end, durationDays, adults, children, price, pricePerPerson, currency, priceBeforeDiscount, transport, meals, unit, seller, bookingUrl }] }] } }
understood says how the request was read: the places searched, placesNotFound and placesAmbiguous. When a place was not found or is ambiguous, tell the user instead of presenting other trips as theirs.
price is the whole party's price; pricePerPerson divides it. Quote them as given, in currency — never convert or round them into a different claim.
trips holds the first few dates in sort order; tripsAvailable says how many more exist. Page with offset (it counts accommodations).
seller is the travel agency that sells the trip. bookingUrl opens that trip on the seller's site — give it to the user as the way to book. It is null when the seller can only be compared, not booked, through Kompare.
start/end are the trip's own first and last day. When nothing matches, the response holds alternatives (counts with one filter removed) to suggest what to relax. When no place matched at all, it holds a message and nothing was searched.
For a filter this tool lacks (meal plan, stars, transport, ski pass, distance to the lift, ...) use search_listings.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | best = Kompare’s ranking, cheapest = lowest price per person, soonest = earliest start. Kompare’s ranking weighs the price against similar trips, hotel stars, guest ratings, how well the trip fits the party and the commission the travel agency pays Kompare. Agencies with a commission agreement always rank above those without. | best |
| limit | No | ||
| adults | No | ||
| market | No | dk | |
| months | No | Months the trip may start in, YYYY-MM. Use instead of startFrom/startTo for "in February". | |
| offset | No | ||
| places | No | Where, in plain words, English or Danish: a destination, ski area, region or country ("Ischgl", "Østrig", "Costa del Sol"). Leave out for anywhere. | |
| startTo | No | Latest day the trip may start, YYYY-MM-DD. | |
| children | No | ||
| startFrom | No | Earliest day the trip may start, YYYY-MM-DD. | |
| travelType | Yes | The kind of trip. See the tool description. | |
| durationDays | No | Trip lengths in days that fit, e.g. [7, 8] for a week. | |
| maxPricePerPerson | No | Highest price per person, in the market currency (DKK). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: the full response shape, the meaning of 'understood' and the instruction to report placesNotFound/placesAmbiguous rather than substituting trips, pagination via offset, and that bookingUrl is null when a seller can only be compared. These are operational facts an agent cannot get from the annotations.
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?
Front-loaded with the one-line purpose, then parameters, then response, then fallback routing — a sensible order. It is long, but most of the bulk is the 20-value travelType reference and the dense response-shape line, both of which carry information the schema does not.
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?
There is no output schema, so the description must carry return semantics, and it does: field-by-field meaning, price vs pricePerPerson, the never-convert-the-currency rule, seller/bookingUrl handling, and the no-match alternatives path. For a 13-parameter tool with no output schema this is complete.
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 coverage is 62%, and the description more than compensates: it enumerates all 20 travelType values (the schema explicitly defers to it with 'See the tool description'), explains places as English/Danish plain words with leave-out-for-anywhere semantics, distinguishes startFrom/startTo from months, and ties adults/children to pricing. Only 'market' is left unexplained.
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?
Opens with a specific verb+resource+mechanism: describe a trip in plain words and get bookable trips back in one call. It is clearly separable from search_listings, which is named as the tool for filters this one lacks, so an agent can route between the two without opening a schema.
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?
States an explicit when-not with an alternative: 'For a filter this tool lacks (meal plan, stars, transport, ski pass, distance to the lift, ...) use search_listings.' That is strong routing. It gives no guidance, however, on how this relates to the other two siblings, get_facets and search_init, leaving part of the decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_facetsCount trips per filter valueARead-onlyIdempotentInspect
Get facet counts for filterable fields, respecting current filters.
CRITICAL: You MUST include ALL established filters in every call — especially niche, market, adults, children, and arrivalWeeks/arrivalMonths. The facetFields parameter only controls which breakdowns are returned, NOT which filters are applied. If you omit a filter like arrivalWeeks, the counts will include ALL dates — giving misleading numbers that won't match actual availability for the user's requested dates.
Example — WRONG: User wants ski in France next week for 2 people. You call get_facets with niche="ski", market="dk", countries=["france"], facetFields=["destinationSlug"]. This returns counts across ALL dates — showing destinations that may have 0 results for next week.
Example — RIGHT: Same scenario. You call get_facets with niche="ski", market="dk", countries=["france"], arrivalWeeks=["2026-W15"], adults=2, children=0, facetFields=["destinationSlug"]. This returns only destinations with actual availability for next week with 2 adults.
Returns: { totalCount, facets: { fieldName: { value: count, ... }, ... }, hierarchical } hierarchical lists field pairs (e.g. country ↔ destination) whose bucket counts are not expected to sum to totalCount.
Common use cases:
Check destination availability: facetFields=["countrySlug", "destinationSlug"] — include arrivalWeeks + adults + children
Check date availability: facetFields=["arrivalYearWeek", "arrivalYearMonth"] — include destination/country + adults + children
Explore filter options: facetFields=["durationDays", "provider"] — include ALL current filters
Answer "where else can I go?": facetFields=["countrySlug", "destinationSlug"] — include ALL current filters (dates, travelers)
Facetable fields — common (every niche): countrySlug, destinationSlug, provider, centrumDistanceRange, priceRange, pricePerPersonRange, durationDays, arrivalYearWeek, arrivalYearMonth, arrivalDate, stars, guestRatingBucket, transport, accommodationType, mealPlanType, accommodationFeatures. Niche-scoped (only meaningful on that niche): ski — skiPassIncluded, skiLiftDistanceRange, skiBusDistanceRange, skiSlopeDistanceRange, guideIncluded, transferIncluded; golf — greenFeeIncluded, courseDistanceRange, golfRoundsRange, golfTripType, golfBagIncluded, guideIncluded, transferIncluded; surf — surfSchoolIncluded, beachDistanceRange, waveType; diving — diveCenter; hiking — difficultyLevel, dailyDistanceRange, trailheadDistanceRange, tripFormat, routeDistanceRange, elevationGainRange, luggageTransportIncluded, guideIncluded, gpxAvailable; charter — beachDistanceRange, guideIncluded, transferIncluded; cycling — difficultyLevel, cyclingType, tripFormat, routeDistanceRange, elevationGainRange, eBikeAvailable, luggageTransportIncluded, guideIncluded, bikeRentalAvailable, gpxAvailable; football — league, homeTeam, awayTeam, team, matchDate, hotelIncluded; carrental — carSupplier, carClass, carBodyType, transmission, fuelType, seats, zeroExcess, pickupStation, pickupStationType; f1 — guideIncluded, hotelIncluded, race, season, raceDate, ticketType, raceDays, transferIncluded; running — guideIncluded, hotelIncluded, race, season, raceDate, transferIncluded, distances, terrain, raceSeries, entryIncluded; americanfootball — guideIncluded, league, homeTeam, awayTeam, team, matchDate, hotelIncluded, season, transferIncluded, gameType; yoga — transferIncluded, retreatFocus, yogaLevel, yogaStyles, meditationIncluded, vegetarianMeals, danishInstructor; triathlon — guideIncluded, hotelIncluded, race, season, raceDate, transferIncluded, entryIncluded, tripType, triathlonDistance, raceBrand, bikeTransportIncluded; cruise — guideIncluded, cruiseType, cruiseLine, cabinType, cruiseRegion, embarkationCountry, flightIncluded, drinksIncluded, excursionsIncluded; coach — guideIncluded, excursionsIncluded, coachTripType, pickupRegion; holidayhome — beachDistanceRange, maxPersons, bedrooms, houseSizeRange, petsAllowed, consumptionIncluded, freeCancellation; roundtrip — excursionsIncluded, tourFormat, danishGuide, guaranteedDeparture; citybreak — transferIncluded, excursionsIncluded, escorted; dance — transferIncluded, danceStyles, danceLevel, soloWelcome.
Always pass facetFields to limit which facets are returned (improves performance). Filtered facets exclude their own filter to keep all options visible.
| Name | Required | Description | Default |
|---|---|---|---|
| utm | No | ||
| niche | Yes | ||
| races | No | ||
| teams | No | ||
| adults | No | ||
| market | Yes | ||
| oneWay | No | ||
| leagues | No | ||
| pageUrl | No | ||
| seasons | No | ||
| adClicks | No | ||
| children | No | ||
| escorted | No | ||
| maxPrice | No | ||
| minPrice | No | ||
| minSeats | No | ||
| minStars | No | ||
| raceDays | No | ||
| terrains | No | ||
| widgetId | No | ||
| countries | No | ||
| distances | No | ||
| durations | No | ||
| fuelTypes | No | ||
| gameTypes | No | ||
| providers | No | ||
| tripTypes | No | ||
| waveTypes | No | ||
| cabinTypes | No | ||
| carClasses | No | ||
| diveCenter | No | ||
| pickupTime | No | ||
| raceBrands | No | ||
| raceDateTo | No | ||
| raceSeries | No | ||
| transports | No | ||
| yogaLevels | No | ||
| yogaStyles | No | ||
| zeroExcess | No | ||
| boundingBox | No | ||
| cruiseLines | No | ||
| cruiseTypes | No | ||
| danceLevels | No | ||
| danceStyles | No | ||
| danishGuide | No | ||
| departureTo | No | ||
| dropoffTime | No | ||
| facetFields | No | ||
| matchDateTo | No | ||
| minBedrooms | No | ||
| petsAllowed | No | ||
| soloWelcome | No | ||
| ticketTypes | No | ||
| tourFormats | No | ||
| tripFormats | No | ||
| arrivalDates | No | ||
| arrivalWeeks | No | ||
| carBodyTypes | No | ||
| carSuppliers | No | ||
| cyclingTypes | No | ||
| destinations | No | ||
| gpxAvailable | No | ||
| previewToken | No | ||
| raceDateFrom | No | ||
| arrivalMonths | No | ||
| beachDistance | No | ||
| consentReplay | No | ||
| cruiseRegions | No | ||
| dailyDistance | No | ||
| departureFrom | No | ||
| elevationGain | No | ||
| entryIncluded | No | ||
| golfTripTypes | No | ||
| guideIncluded | No | ||
| hotelIncluded | No | ||
| matchDateFrom | No | ||
| mealPlanTypes | No | ||
| pickupRegions | No | ||
| routeDistance | No | ||
| transmissions | No | ||
| coachTripTypes | No | ||
| courseDistance | No | ||
| drinksIncluded | No | ||
| eBikeAvailable | No | ||
| flightIncluded | No | ||
| maxGuestRating | No | ||
| minGuestRating | No | ||
| onlyDiscounted | No | ||
| pickupStations | No | ||
| skiBusDistance | No | ||
| centrumDistance | No | ||
| dropoffStations | No | ||
| golfBagIncluded | No | ||
| houseSizeRanges | No | ||
| skiLiftDistance | No | ||
| skiPassIncluded | No | ||
| vegetarianMeals | No | ||
| danishInstructor | No | ||
| difficultyLevels | No | ||
| freeCancellation | No | ||
| golfRoundsRanges | No | ||
| greenFeeIncluded | No | ||
| marketingConsent | No | ||
| skiPassDaysCount | No | ||
| skiSlopeDistance | No | ||
| transferIncluded | No | ||
| hikingTripFormats | No | ||
| maxPricePerPerson | No | ||
| minPricePerPerson | No | ||
| trailheadDistance | No | ||
| accommodationTypes | No | ||
| excursionsIncluded | No | ||
| identityPersistent | No | ||
| meditationIncluded | No | ||
| pickupStationTypes | No | ||
| surfSchoolIncluded | No | ||
| triathlonDistances | No | ||
| yogaRetreatFocuses | No | ||
| bikeRentalAvailable | No | ||
| consumptionIncluded | No | ||
| guaranteedDeparture | No | ||
| embarkationCountries | No | ||
| onlyMultiDestination | No | ||
| accommodationFeatures | No | ||
| bikeTransportIncluded | No | ||
| departureDateFlexDays | No | ||
| cyclingDifficultyLevels | No | ||
| luggageTransportIncluded | No | ||
| includeUnratedGuestRating | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description clears the lower bar and then adds substantial context: the filter-propagation trap, that facetFields controls only output breakdowns, that filtered facets exclude their own filter, and that hierarchical bucket counts may not sum to totalCount. This is exactly the non-obvious behavior an agent needs.
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?
Front-loads the critical filter-inclusion warning before any enumeration, and the WRONG/RIGHT example is high-value. The long facetable-field lists are load-bearing given 0% schema coverage, but they make the description dense; slight trimming of niche field lists would help.
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 129-parameter tool with no output schema, the description supplies the return shape (totalCount, facets, hierarchical), the facetFields contract, and the filter-propagation rule. Nothing an agent must know to call it correctly is missing.
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 0% across 129 params, so the description carries the full burden. It documents facetFields semantics thoroughly and enumerates the facetable fields by niche, but the vast majority of filter parameters (the other ~120) are only touched by example, not defined. It compensates well for the critical params but not exhaustively.
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?
States a specific verb and resource ('Get facet counts for filterable fields') and adds the key behavioral qualifier 'respecting current filters'. An agent can immediately tell this is an aggregation/faceting tool distinct from find_trips or search_listings, which return results rather than counts.
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?
Explicitly says when to use it via four concrete use cases (destination availability, date availability, filter exploration, 'where else can I go?'), and the CRITICAL block warns when NOT to omit filters with a wrong/right worked example. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_initOverview of one travel typeARead-onlyIdempotentInspect
Get a comprehensive overview of the available travel data for ONE niche before searching. Call this FIRST.
Required parameters (all four):
niche: ONE travel type — "ski", "golf", "surf", "diving", "hiking", "charter", "cycling", "football", "carrental", "f1", "running", "americanfootball", "yoga", "triathlon", "cruise", "coach", "holidayhome", "roundtrip", "citybreak", "dance". Single niche per call; to compare niches, call once per niche.
market: market code (one of "dk")
adults: number of adult travelers (1-20)
children: number of children (0-20)
Occupancy is required because counts and prices depend on group size — the overview is scoped to this exact cohort.
Returns:
totalCount: total listings for this niche and group size
priceRange: { min, max } total price range
pricePerPersonRange: { min, max } per-person price range
averages: { price, pricePerPerson, stars, durationDays } — useful for setting expectations
dateRange: { earliest, latest } departure date range
destinationCount: total unique destinations available
availability.byMonth: array of { period: "2026-04", count, minPrice } — listings per month with cheapest price. Use this to suggest optimal travel months.
ratingDistribution: star-bracket counts
topDestinations: array of { destinationSlug, countrySlug, count, minPrice } — top 15 destinations sorted by popularity
facets: unfiltered facet counts for the main filterable fields (countries, providers, durations, etc.)
Use availability.byMonth to guide users toward dates with the most options and best prices. Use topDestinations to suggest popular destinations. Use averages to set price expectations.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | ||
| adults | Yes | ||
| market | Yes | ||
| children | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read-only, idempotent, non-destructive call, and the description adds substantial context on top: the single-niche constraint, the mandatory cohort scoping, and a full enumeration of return fields. With no output schema present, this disclosure of what comes back is doing real work rather than restating annotations.
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?
Front-loaded with the purpose and the 'Call this FIRST' directive, then organized into parameters and returns. The returns list is long, but with no output schema it substitutes for one and each field earns its place; slight verbosity is the only deduction.
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?
Given four required parameters, no output schema, and no schema descriptions, the definition supplies parameter meanings, the group-size scoping rationale, the complete return shape, and prescriptive guidance for using byMonth, topDestinations, and averages. Nothing an agent needs to call this correctly is missing.
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 0%, so the description carries the full burden and does: it enumerates the niche values, the lone market code, and the 1-20 / 0-20 bounds. More importantly it explains the semantics behind the required occupancy parameters — 'counts and prices depend on group size — the overview is scoped to this exact cohort' — which is meaning the schema cannot express.
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?
States a specific verb and resource ('Get a comprehensive overview of the available travel data') and pins the scope to exactly one niche. The instruction 'Call this FIRST' plus 'before searching' clearly positions it ahead of siblings find_trips, get_facets, and search_listings, so an agent can pick it without opening a schema.
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?
Strong ordering guidance ('Call this FIRST') and an explicit multi-call rule for comparing niches ('call once per niche'). It does not name the sibling tools or state when this overview is unnecessary, but the sequencing guidance is unambiguous enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_listingsSearch trips with every filterARead-onlyIdempotentInspect
Search for travel listings with filters, sorting, and pagination.
This is the main search tool. Use it after search_init to find specific travel deals.
Required parameters:
niche: ONE travel type — "ski", "golf", "surf", "diving", "hiking", "charter", "cycling", "football", "carrental", "f1", "running", "americanfootball", "yoga", "triathlon", "cruise", "coach", "holidayhome", "roundtrip", "citybreak", "dance". Single niche per request.
market: market code (one of "dk")
Common filters (valid for every niche):
adults (ALWAYS include — prices depend on group size)
children (ALWAYS include — prices depend on group size)
departureFrom (YYYY-MM-DD)
departureTo (YYYY-MM-DD)
onlyDiscounted (boolean — only trips with a discount)
onlyMultiDestination (boolean — only trips that sleep in more than one place (round trips, stage tours))
countries (array of country slugs — use EXACT slugs, e.g. ["austria"])
destinations (array of destination slugs in country_destination format, e.g. ["austria_zell-am-see"] — use EXACT slugs. Also returns round trips and stage tours that stop there; their
accommodation.routelists every stop)providers (array of provider slugs)
centrumDistance ({ min, max } meters to town centre)
minPrice (total price, not per person)
maxPrice (total price, not per person)
minPricePerPerson (per-person price)
maxPricePerPerson (per-person price)
durations (array of trip lengths in days, e.g. [7, 14])
arrivalWeeks (array of ISO weeks, e.g. ["2026-W15"] — use for "next week")
arrivalMonths (array of months, e.g. ["2026-04"] — use for "in April")
arrivalDates (array of exact arrival dates, YYYY-MM-DD)
departureDateFlexDays (0-7, day flex around arrivalDates)
minStars (minimum hotel star rating, 1-5)
minGuestRating (guest review score 0-10 (TripAdvisor scores are ×2 normalized))
maxGuestRating (guest review score 0-10)
includeUnratedGuestRating (boolean — keep unrated hotels in rated searches)
transports (array: bus, train, car, flight_bll, flight_cph, flight_aal, flight_arn, flight_got, flight_ham, flight_aar, flight_krp, flight_rnn)
accommodationTypes (array: hotel, apartment, cabin, chalet, villa, hostel, resort, pension, house, other)
mealPlanTypes (array: all_inclusive, breakfast, full_board, half_board, none)
accommodationFeatures (array, e.g. pool, wifi, sauna, spa, parking, bar)
Niche-specific filters (only valid when niche matches):
Ski: skiPassIncluded (boolean), skiPassDaysCount ({ min, max } bundled lift-pass days), skiLiftDistance ({ min, max } meters), skiBusDistance ({ min, max } meters), skiSlopeDistance ({ min, max } meters), guideIncluded (boolean), transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled)
Golf (accommodation-centric like ski; greenFeeIncluded says whether ANY golf is in the price, golfRoundsRanges/golfBagIncluded refine it further; guideIncluded is a golf host, not a generic tour guide): greenFeeIncluded (boolean — the package price includes green fees (any rounds or unlimited golf); false = golf is bought separately), courseDistance ({ min, max } meters, hotel to nearest course), golfRoundsRanges (array: none, 1-3, 4-5, 6+, unlimited — rounds included per golfer ('none' = green fee not included)), golfTripTypes (array: stay, school, group, longstay, tour — 'stay' is the default golf-hotel package), golfBagIncluded (boolean — golf bag carried on the flight at no extra charge), guideIncluded (boolean), transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled)
Surf: surfSchoolIncluded (boolean), beachDistance ({ min, max } meters), waveTypes (array)
Diving: diveCenter (boolean)
Hiking: difficultyLevels (array), dailyDistance, trailheadDistance ({ min, max } meters), hikingTripFormats, routeDistance ({ min, max } km), elevationGain ({ min, max } meters), luggageTransportIncluded (boolean), guideIncluded (boolean), gpxAvailable (boolean)
Charter: beachDistance ({ min, max } meters), guideIncluded (boolean), transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled)
Cycling: cyclingDifficultyLevels (array: easy, moderate, challenging, hard, expert), cyclingTypes (array: road, gravel, mountainbike, e_mountainbike, e_bike, bike_cruise, event), tripFormats (array: self_guided, guided_group, private_custom, club_event, race_event), routeDistance ({ min, max } km), elevationGain ({ min, max } meters), eBikeAvailable (boolean), luggageTransportIncluded (boolean), guideIncluded (boolean), bikeRentalAvailable (boolean), gpxAvailable (boolean)
Football (match-centric; the match ticket is always included, transport fly/kør-selv via the shared transports filter): leagues (array of league slugs, e.g. ["premier-league", "la-liga"] or ["nfl"] — use EXACT slugs from the league facet), teams (array of team slugs, e.g. ["wolverhampton-wanderers"] or ["kansas-city-chiefs"] — use EXACT slugs from the team facet; matches the home OR away side), matchDateFrom (YYYY-MM-DD, kickoff date), matchDateTo (YYYY-MM-DD, kickoff date), hotelIncluded (boolean)
Carrental (groups by car group at a pickup station; adults/children do not price a car — they only set minSeats; prices are per rental, not per person): carSuppliers (array of rental-brand slugs, e.g. ["avis"] — use EXACT slugs from the carSupplier facet), carClasses (array: mini, economy, compact, intermediate, standard, fullsize, premium, luxury, special), carBodyTypes (array: car, suv, estate, van, convertible, other), transmissions (array: manual, automatic), fuelTypes (array: petrol, diesel, hybrid, electric), minSeats (integer 1-20, minimum seats — set it from the party size), zeroExcess (boolean — only rate tiers without an excess (ingen selvrisiko)), pickupStations (array of pickup-station slugs, e.g. ["london-heathrow-t5"] — use EXACT slugs from the pickupStation facet), pickupStationTypes (array: airport, city, rail, port, other)
F1 (event-centric (one card = one Grand Prix weekend); the race ticket is always included, hotel via hotelIncluded, transport fly/kør-selv via the shared transports filter; guideIncluded = a tour leader travels with the group): guideIncluded (boolean), hotelIncluded (boolean), races (array of race slugs, e.g. ["monaco"] (f1), ["berlin-marathon"] (running) or ["ironman-kalmar"] (triathlon) — use EXACT slugs from the race facet), seasons (array of season years, e.g. [2026]), raceDateFrom (YYYY-MM-DD, race day (not the travel dates); a triathlon camp: its departure date), raceDateTo (YYYY-MM-DD, race day (not the travel dates); a triathlon camp: its departure date), ticketTypes (array: grandstand, general_admission, hospitality), raceDays (array: 3_day, 2_day, 1_day (Fri–Sun / Sat–Sun / race day only)), transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled)
Running (event-centric (one card = one race edition); the race entry is NOT always included (entryIncluded), arrival/departure are the travel window around the race day, hotel via hotelIncluded): guideIncluded (boolean), hotelIncluded (boolean), races (array of race slugs, e.g. ["monaco"] (f1), ["berlin-marathon"] (running) or ["ironman-kalmar"] (triathlon) — use EXACT slugs from the race facet), seasons (array of season years, e.g. [2026]), raceDateFrom (YYYY-MM-DD, race day (not the travel dates); a triathlon camp: its departure date), raceDateTo (YYYY-MM-DD, race day (not the travel dates); a triathlon camp: its departure date), transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled), distances (array: 5k, 10k, half_marathon, marathon, ultra, other — matches a package offering ANY of them), terrains (array: road, trail), raceSeries (array: majors, superhalfs — World Marathon Majors / SuperHalfs), entryIncluded (boolean — the race entry (bib / startnummer) is bundled; false = not bundled (it may be a paid add-on or not offered at all — never promise the traveller can buy one))
Americanfootball (event-centric (one card = one NFL game, mostly the International Series in London/Paris/Madrid/Munich plus the Super Bowl); the game ticket is always included, hotel via hotelIncluded; a Super Bowl sold before the bracket has no teams — use gameTypes ["super_bowl"], not teams): guideIncluded (boolean), leagues (array of league slugs, e.g. ["premier-league", "la-liga"] or ["nfl"] — use EXACT slugs from the league facet), teams (array of team slugs, e.g. ["wolverhampton-wanderers"] or ["kansas-city-chiefs"] — use EXACT slugs from the team facet; matches the home OR away side), matchDateFrom (YYYY-MM-DD, kickoff date), matchDateTo (YYYY-MM-DD, kickoff date), hotelIncluded (boolean), seasons (array of season years, e.g. [2026]), transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled), gameTypes (array: preseason, regular_season, playoffs, super_bowl (International Series games abroad are regular_season))
Yoga (destination-centric (one card = one retreat venue); yogaStyles is OR-matched, and unknown booleans are unset, never false): transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled), yogaRetreatFocuses (array: yoga, yoga_hiking, yoga_surf, yoga_wellness, yoga_active, yoga_culture, teacher_training — what the retreat pairs yoga with; teacher_training = a 200h/500h course), yogaLevels (array: beginner, all_levels, intermediate, advanced), yogaStyles (array: hatha, vinyasa, yin, ashtanga, kundalini, iyengar, restorative, yoga_nidra, power, aerial, somatic, other — matches a retreat teaching ANY of them), meditationIncluded (boolean — meditation or mindfulness is part of the programme), vegetarianMeals (boolean — the kitchen is vegetarian (not just a vegetarian option on request)), danishInstructor (boolean — the yoga teacher teaches in Danish)
Triathlon (event-centric: one card = one race edition (tripTypes race) or one training camp (tripTypes camp, its departures are the offers); the race entry is usually NOT included (entryIncluded); raceDate* = race day for races, departure date for camps): guideIncluded (boolean), hotelIncluded (boolean), races (array of race slugs, e.g. ["monaco"] (f1), ["berlin-marathon"] (running) or ["ironman-kalmar"] (triathlon) — use EXACT slugs from the race facet), seasons (array of season years, e.g. [2026]), raceDateFrom (YYYY-MM-DD, race day (not the travel dates); a triathlon camp: its departure date), raceDateTo (YYYY-MM-DD, race day (not the travel dates); a triathlon camp: its departure date), transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled), entryIncluded (boolean — the race entry (bib / startnummer) is bundled; false = not bundled (it may be a paid add-on or not offered at all — never promise the traveller can buy one)), tripTypes (array: race, camp — race = a package to a named race, camp = a dated training camp), triathlonDistances (array: full, half, olympic, sprint, other — full = IRONMAN, half = 70.3, olympic = 5150; matches ANY of them), raceBrands (array: ironman, challenge, other), bikeTransportIncluded (boolean — the athlete’s own bike flies with the package; false = an add-on or not offered)
Cruise (one card = one sailing (ship + embarkation port + length); cruiseLines is the ship operator, never the reselling agency; flightIncluded/drinksIncluded/excursionsIncluded/guideIncluded are all null when the line does not say): guideIncluded (boolean), cruiseTypes (array: ocean, river, coastal, expedition), cruiseLines (array: msc, costa, royal_caribbean, celebrity, norwegian, princess, holland_america, carnival, cunard, p_and_o, disney, virgin_voyages, oceania, regent, azamara, silversea, seabourn, explora, windstar, ponant, viking, hurtigruten, havila, ambassador, fred_olsen, aida, tui_cruises, amawaterways, nicko, a_rosa, avalon, uniworld, scenic, other — the ship operator, not the reselling agency), cabinTypes (array: inside, oceanview, balcony, suite — cheapest bookable category the offer prices), cruiseRegions (array: mediterranean, norwegian_fjords, northern_europe, baltic, british_isles, atlantic_islands, arctic, antarctica, caribbean, north_america, alaska, south_america, asia, middle_east, africa, oceania, transatlantic, world, rhine, danube, douro, seine, rhone, elbe, nile, mekong, other_river), embarkationCountries (array of country slugs the ship departs from), flightIncluded (boolean — flight to/from the embarkation port is bundled), drinksIncluded (boolean — an onboard drinks package is bundled), excursionsIncluded (boolean — excursions are bundled (shore excursions on a cruise, sightseeing on a coach tour or city break))
Coach (destination-centric like cycling (one card = one seller's tour, departures are the offers); pickupRegions matches a tour boarding in ANY chosen Danish region; guideIncluded/excursionsIncluded are shared with cruise and null when the operator does not say): guideIncluded (boolean), excursionsIncluded (boolean — excursions are bundled (shore excursions on a cruise, sightseeing on a coach tour or city break)), coachTripTypes (array: round_trip, city_break, christmas_market, holiday_stay, garden, event, wellness, other), pickupRegions (array: north_jutland, central_jutland, south_jutland, funen, zealand, copenhagen, bornholm — the Danish region the coach boards in, matches ANY chosen region)
Holidayhome (one card = one specific rentable house; price is per HOUSE for the stay, never per person — adults/children only set a capacity floor (maxPersons >= adults + children), same mechanism as carrental minSeats; beachDistance is shared with surf/charter; maxPersons is that ROW's price-band top (a house priced by party size emits one row per band, e.g. a "2-person offer"), never the house's real capacity — when telling the visitor what a house sleeps, use houseCapacity, and never phrase a result as "max N persons"): beachDistance ({ min, max } meters), minBedrooms (minimum bedrooms), houseSizeRanges (array: 0-60, 60-80, 80-100, 100-130, 130-170, 170-250, 250+ — living area in m², matches ANY of them), petsAllowed (boolean — pets are allowed in the house), consumptionIncluded (boolean — electricity, water and heating are included in the price), freeCancellation (boolean — only prices that can be cancelled free of charge (refundable rate); without it a house shows its cheapest rate, often non-refundable)
Roundtrip (coach's shape (one card = one seller's multi-stop tour, departures are the offers); the overnight places are route stops, so a town search finds every tour sleeping there; price is the party total (per person in a shared double for even parties, single supplement included for one traveller or an odd party); danishGuide/guaranteedDeparture/excursionsIncluded are null when the seller does not say): excursionsIncluded (boolean — excursions are bundled (shore excursions on a cruise, sightseeing on a coach tour or city break)), tourFormats (array: guided_group, small_group, self_drive, private — self_drive is a fly & drive round trip in a rental car with a fixed day plan, not a car-rental search), danishGuide (boolean — a Danish-speaking tour guide is stated; null when the seller does not say), guaranteedDeparture (boolean — the departure is guaranteed to run; null when the seller does not say, never read as "not guaranteed")
Citybreak (charter-shaped: one card = one city hotel, each offer a date x stay length x departure airport x party; the price is the party total for the stay as the seller quotes it; escorted = a fixed-date trip with a tour leader (a plain city-break search is a free flight+hotel stay, so set escorted only when the visitor wants a leader); centrumDistance is the key city-break quality signal; transferIncluded/excursionsIncluded are null when the seller does not say): transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled), excursionsIncluded (boolean — excursions are bundled (shore excursions on a cruise, sightseeing on a coach tour or city break)), escorted (boolean — a fixed-date trip with a tour leader and a programme; absent = everything, including free flight+hotel stays)
Dance (destination-centric like yoga (one card = one dance week at one venue); danceStyles is OR-matched, and unknown booleans are unset, never false): transferIncluded (boolean — the transfer from the airport/station (or circuit) to the accommodation is bundled), danceStyles (array: ballroom, latin, tango, swing, linedance, flamenco, dance_fitness, other — matches a dance week teaching ANY of them), danceLevels (array: beginner, all_levels, intermediate, advanced), soloWelcome (boolean — true = the page says you can come without a dance partner; false = a partner is needed (pardans); most weeks leave it unset, so for a solo traveller prefer danceStyles linedance or dance_fitness over this filter)
Distance filters are { min, max } objects (both bounds optional), e.g. { "max": 500 } for "within 500 m".
Sorting & pagination:
sort: one of "price", "pricePerPerson", "departureDate", "stars", "kompareScore" (Kompare’s ranking weighs the price against similar trips, hotel stars, guest ratings, how well the trip fits the party and the commission the travel agency pays Kompare. Agencies with a commission agreement always rank above those without.), "discountPercentage", "distanceToCentrum", "distanceToLift" (ski ONLY — silently sorts by price on every other niche, so never offer it there), "providerMix"
order: "asc" or "desc"
limit: results per page (1-100)
offset: pagination offset
IMPORTANT: countries and destinations use EXACT slug matching — always use the exact slugs returned by search_init (topDestinations) or get_facets (countrySlug/destinationSlug facets). Do NOT guess slugs.
Response — the matching accommodations with their trips: { total, accommodationCount, offset, results: [{ name, country, destination, stars, guestRating, tripsAvailable, trips: [{ start, end, durationDays, adults, children, price, pricePerPerson, currency, priceBeforeDiscount, transport, meals, unit, seller, bookingUrl }] }] }
price is the whole party's price; pricePerPerson divides it. Quote them as given, in currency — never convert or round them into a different claim.
trips holds the first few dates in sort order; tripsAvailable says how many more exist. Page with offset (it counts accommodations).
seller is the travel agency that sells the trip. bookingUrl opens that trip on the seller's site — give it to the user as the way to book. It is null when the seller can only be compared, not booked, through Kompare.
start/end are the trip's own first and last day.
Pass limit (5-10 is plenty) to keep the reply short. If the filters match nothing, the response instead contains alternatives (facet counts with one filter removed) — use them to suggest what the user could relax.
Tips:
ALWAYS pass ALL established filters (adults, children, arrivalWeeks/arrivalMonths, niche, market, countries, destinations, etc.) — never drop previously established filters
Prices depend on group size — always include adults and children
Start with broad searches, then narrow down with filters
Use sort=pricePerPerson&order=asc to find cheapest deals
Use sort=kompareScore&order=desc for Kompare's ranking (see sort above)
Use sort=providerMix&order=desc for fair provider diversity (round-robin interleave)
Check search_init first to know valid filter values (topDestinations has exact country/destination slugs)
Call get_facets before search_listings to verify results exist — use the EXACT SAME filters
| Name | Required | Description | Default |
|---|---|---|---|
| utm | No | ||
| sort | No | ||
| limit | No | ||
| niche | Yes | ||
| order | No | ||
| races | No | ||
| teams | No | ||
| adults | No | ||
| market | Yes | ||
| offset | No | ||
| oneWay | No | ||
| leagues | No | ||
| pageUrl | No | ||
| seasons | No | ||
| adClicks | No | ||
| children | No | ||
| escorted | No | ||
| maxPrice | No | ||
| minPrice | No | ||
| minSeats | No | ||
| minStars | No | ||
| raceDays | No | ||
| terrains | No | ||
| widgetId | No | ||
| countries | No | ||
| distances | No | ||
| durations | No | ||
| fuelTypes | No | ||
| gameTypes | No | ||
| providers | No | ||
| tripTypes | No | ||
| waveTypes | No | ||
| cabinTypes | No | ||
| carClasses | No | ||
| diveCenter | No | ||
| pickupTime | No | ||
| raceBrands | No | ||
| raceDateTo | No | ||
| raceSeries | No | ||
| transports | No | ||
| yogaLevels | No | ||
| yogaStyles | No | ||
| zeroExcess | No | ||
| boundingBox | No | ||
| cruiseLines | No | ||
| cruiseTypes | No | ||
| danceLevels | No | ||
| danceStyles | No | ||
| danishGuide | No | ||
| departureTo | No | ||
| dropoffTime | No | ||
| matchDateTo | No | ||
| minBedrooms | No | ||
| petsAllowed | No | ||
| soloWelcome | No | ||
| ticketTypes | No | ||
| tourFormats | No | ||
| tripFormats | No | ||
| arrivalDates | No | ||
| arrivalWeeks | No | ||
| carBodyTypes | No | ||
| carSuppliers | No | ||
| cyclingTypes | No | ||
| destinations | No | ||
| gpxAvailable | No | ||
| previewToken | No | ||
| raceDateFrom | No | ||
| scoreWeights | No | ||
| arrivalMonths | No | ||
| beachDistance | No | ||
| consentReplay | No | ||
| cruiseRegions | No | ||
| dailyDistance | No | ||
| departureFrom | No | ||
| elevationGain | No | ||
| entryIncluded | No | ||
| golfTripTypes | No | ||
| guideIncluded | No | ||
| hotelIncluded | No | ||
| includeFacets | No | ||
| matchDateFrom | No | ||
| mealPlanTypes | No | ||
| pickupRegions | No | ||
| routeDistance | No | ||
| transmissions | No | ||
| coachTripTypes | No | ||
| courseDistance | No | ||
| drinksIncluded | No | ||
| eBikeAvailable | No | ||
| flightIncluded | No | ||
| maxGuestRating | No | ||
| minGuestRating | No | ||
| onlyDiscounted | No | ||
| pickupStations | No | ||
| scoreVariation | No | ||
| skiBusDistance | No | ||
| centrumDistance | No | ||
| dropoffStations | No | ||
| golfBagIncluded | No | ||
| houseSizeRanges | No | ||
| skiLiftDistance | No | ||
| skiPassIncluded | No | ||
| vegetarianMeals | No | ||
| danishInstructor | No | ||
| difficultyLevels | No | ||
| freeCancellation | No | ||
| golfRoundsRanges | No | ||
| greenFeeIncluded | No | ||
| marketingConsent | No | ||
| skiPassDaysCount | No | ||
| skiSlopeDistance | No | ||
| transferIncluded | No | ||
| hikingTripFormats | No | ||
| maxPricePerPerson | No | ||
| minPricePerPerson | No | ||
| trailheadDistance | No | ||
| variationAgencies | No | ||
| accommodationTypes | No | ||
| excursionsIncluded | No | ||
| identityPersistent | No | ||
| meditationIncluded | No | ||
| pickupStationTypes | No | ||
| surfSchoolIncluded | No | ||
| triathlonDistances | No | ||
| yogaRetreatFocuses | No | ||
| bikeRentalAvailable | No | ||
| consumptionIncluded | No | ||
| guaranteedDeparture | No | ||
| embarkationCountries | No | ||
| onlyMultiDestination | No | ||
| accommodationFeatures | No | ||
| bikeTransportIncluded | No | ||
| departureDateFlexDays | No | ||
| cyclingDifficultyLevels | No | ||
| luggageTransportIncluded | No | ||
| includeUnratedGuestRating | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds substantive behavior beyond them: the no-match fallback returns alternatives with facet counts, offset paginates accommodations rather than trips, bookingUrl is null when a seller can't be booked, distanceToLift silently degrades to price sort on other niches, and prices must not be converted. This is rich operational context.
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?
Purpose is front-loaded and the body is organized under clear headers and bullets, which is essential at this scale. However it is enormously long and repeats identical boilerplate verbatim many times (the same transferIncluded definition appears in a dozen niches; the race-facet slug sentence is duplicated across f1/running/triathlon), which is genuine waste.
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?
With 136 parameters and no output schema, the description compensates by inlining the response shape (total, accommodationCount, offset, results/trips fields) and pagination semantics. A handful of parameters and any return-value subtleties remain uncovered, but an agent has nearly everything needed to call this correctly.
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 0% across 136 params, so the description carries the burden and does so well for the domain filters — formats, units, and semantic traps are spelled out (minPrice is a party total not per person, adults/children drive pricing, centrumDistance is {min,max} meters). It leaves the tracking/infra params (utm, adClicks, pageUrl, widgetId, scoreWeights, boundingBox, pickupTime) undocumented, so it's strong but not exhaustive.
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?
States a specific verb and resource ("Search for travel listings with filters, sorting, and pagination") and explicitly positions itself as "the main search tool" to be used after search_init. An agent can distinguish it from get_facets/search_init/find_trips without opening any schema.
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?
Gives explicit sequencing (use after search_init, call get_facets first with the EXACT SAME filters), an inclusion rule ("ALWAYS pass ALL established filters — never drop previously established filters"), a search strategy (broad then narrow), and concrete sort recipes (sort=pricePerPerson&order=asc for cheapest). When/where guidance is unusually complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
find_trips1 field changed- changed
Input schema / properties / sort / descriptionPrevious value: -"best = Kompare’s recommendation, cheapest = lowest price per person, soonest = earliest start."New value: +"best = Kompare’s ranking, cheapest = lowest price per person, soonest = earliest start. Kompare’s ranking weighs the price against similar trips, hotel stars, guest ratings, how well the trip fits the party and the commission the travel agency pays Kompare. Agencies with a commission agreement always rank above those without."
4 tool updates
- First observed
find_trips - First observed
get_facets - First observed
search_init - First observed
search_listings
Related MCP Connectors
Realtime package holiday and charter flight prices from Denmark. Inventory not on Google Flights.
Realtime package holiday and charter flight prices from Norway. Inventory not on Google Flights.
Realtime package holiday and charter flight prices from Sweden. Inventory not on Google Flights.
Realtime package holiday and charter flight prices from Finland. Inventory not on Google Flights.
Related MCP Servers
- AlicenseAqualityAmaintenanceVacation rental software. A signed stay offer on the host's own domain. Agents discover a host domain, verify an Ed25519-signed offer (VRP), and send the guest to that domain to book and pay the host. Do not compare hosts or prices. HemmaBo + VRP, 6 runtime tools: 2 HemmaBo tools, 2 host onboarding tools, and 2 VRP verification tools. Not an OTA. Not a marketplace.76556 npm3Apache 2.0
- AlicenseAqualityFmaintenanceReal-time last-minute tour and activity booking across 18 suppliers in 15 countries via the OCTO open standard. Search available slots, create Stripe checkout sessions, and check booking status.41MIT
- AlicenseAqualityFmaintenanceAI-native travel search MCP with affiliate booking links and optional x402 premium intelligence.5586 npmMIT
- AlicenseBqualityAmaintenanceOfficial MCP server for MAQAMI, a hotel and flight booking platform with 3M+ hotels. Search live hotel rates and flights, look up places, airports and hotel details, then prebook and book. Remote Streamable HTTP endpoint, no API key required.1241428 npm2MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.