Skip to main content
Glama

Server Details

Live prices on package holidays and niche trips from Danish travel agencies, with booking links.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.5/5.0

Scored across 4 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count4/5

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.

Completeness4/5

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 tools
find_tripsFind trips in plain wordsA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
sortNobest = 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
limitNo
adultsNo
marketNodk
monthsNoMonths the trip may start in, YYYY-MM. Use instead of startFrom/startTo for "in February".
offsetNo
placesNoWhere, in plain words, English or Danish: a destination, ski area, region or country ("Ischgl", "Østrig", "Costa del Sol"). Leave out for anywhere.
startToNoLatest day the trip may start, YYYY-MM-DD.
childrenNo
startFromNoEarliest day the trip may start, YYYY-MM-DD.
travelTypeYesThe kind of trip. See the tool description.
durationDaysNoTrip lengths in days that fit, e.g. [7, 8] for a week.
maxPricePerPersonNoHighest price per person, in the market currency (DKK).

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 valueA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
utmNo
nicheYes
racesNo
teamsNo
adultsNo
marketYes
oneWayNo
leaguesNo
pageUrlNo
seasonsNo
adClicksNo
childrenNo
escortedNo
maxPriceNo
minPriceNo
minSeatsNo
minStarsNo
raceDaysNo
terrainsNo
widgetIdNo
countriesNo
distancesNo
durationsNo
fuelTypesNo
gameTypesNo
providersNo
tripTypesNo
waveTypesNo
cabinTypesNo
carClassesNo
diveCenterNo
pickupTimeNo
raceBrandsNo
raceDateToNo
raceSeriesNo
transportsNo
yogaLevelsNo
yogaStylesNo
zeroExcessNo
boundingBoxNo
cruiseLinesNo
cruiseTypesNo
danceLevelsNo
danceStylesNo
danishGuideNo
departureToNo
dropoffTimeNo
facetFieldsNo
matchDateToNo
minBedroomsNo
petsAllowedNo
soloWelcomeNo
ticketTypesNo
tourFormatsNo
tripFormatsNo
arrivalDatesNo
arrivalWeeksNo
carBodyTypesNo
carSuppliersNo
cyclingTypesNo
destinationsNo
gpxAvailableNo
previewTokenNo
raceDateFromNo
arrivalMonthsNo
beachDistanceNo
consentReplayNo
cruiseRegionsNo
dailyDistanceNo
departureFromNo
elevationGainNo
entryIncludedNo
golfTripTypesNo
guideIncludedNo
hotelIncludedNo
matchDateFromNo
mealPlanTypesNo
pickupRegionsNo
routeDistanceNo
transmissionsNo
coachTripTypesNo
courseDistanceNo
drinksIncludedNo
eBikeAvailableNo
flightIncludedNo
maxGuestRatingNo
minGuestRatingNo
onlyDiscountedNo
pickupStationsNo
skiBusDistanceNo
centrumDistanceNo
dropoffStationsNo
golfBagIncludedNo
houseSizeRangesNo
skiLiftDistanceNo
skiPassIncludedNo
vegetarianMealsNo
danishInstructorNo
difficultyLevelsNo
freeCancellationNo
golfRoundsRangesNo
greenFeeIncludedNo
marketingConsentNo
skiPassDaysCountNo
skiSlopeDistanceNo
transferIncludedNo
hikingTripFormatsNo
maxPricePerPersonNo
minPricePerPersonNo
trailheadDistanceNo
accommodationTypesNo
excursionsIncludedNo
identityPersistentNo
meditationIncludedNo
pickupStationTypesNo
surfSchoolIncludedNo
triathlonDistancesNo
yogaRetreatFocusesNo
bikeRentalAvailableNo
consumptionIncludedNo
guaranteedDepartureNo
embarkationCountriesNo
onlyMultiDestinationNo
accommodationFeaturesNo
bikeTransportIncludedNo
departureDateFlexDaysNo
cyclingDifficultyLevelsNo
luggageTransportIncludedNo
includeUnratedGuestRatingNo

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 typeA
Read-onlyIdempotent
Inspect

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
nicheYes
adultsYes
marketYes
childrenYes

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 filterA
Read-onlyIdempotent
Inspect

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.route lists 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

ParametersJSON Schema
NameRequiredDescriptionDefault
utmNo
sortNo
limitNo
nicheYes
orderNo
racesNo
teamsNo
adultsNo
marketYes
offsetNo
oneWayNo
leaguesNo
pageUrlNo
seasonsNo
adClicksNo
childrenNo
escortedNo
maxPriceNo
minPriceNo
minSeatsNo
minStarsNo
raceDaysNo
terrainsNo
widgetIdNo
countriesNo
distancesNo
durationsNo
fuelTypesNo
gameTypesNo
providersNo
tripTypesNo
waveTypesNo
cabinTypesNo
carClassesNo
diveCenterNo
pickupTimeNo
raceBrandsNo
raceDateToNo
raceSeriesNo
transportsNo
yogaLevelsNo
yogaStylesNo
zeroExcessNo
boundingBoxNo
cruiseLinesNo
cruiseTypesNo
danceLevelsNo
danceStylesNo
danishGuideNo
departureToNo
dropoffTimeNo
matchDateToNo
minBedroomsNo
petsAllowedNo
soloWelcomeNo
ticketTypesNo
tourFormatsNo
tripFormatsNo
arrivalDatesNo
arrivalWeeksNo
carBodyTypesNo
carSuppliersNo
cyclingTypesNo
destinationsNo
gpxAvailableNo
previewTokenNo
raceDateFromNo
scoreWeightsNo
arrivalMonthsNo
beachDistanceNo
consentReplayNo
cruiseRegionsNo
dailyDistanceNo
departureFromNo
elevationGainNo
entryIncludedNo
golfTripTypesNo
guideIncludedNo
hotelIncludedNo
includeFacetsNo
matchDateFromNo
mealPlanTypesNo
pickupRegionsNo
routeDistanceNo
transmissionsNo
coachTripTypesNo
courseDistanceNo
drinksIncludedNo
eBikeAvailableNo
flightIncludedNo
maxGuestRatingNo
minGuestRatingNo
onlyDiscountedNo
pickupStationsNo
scoreVariationNo
skiBusDistanceNo
centrumDistanceNo
dropoffStationsNo
golfBagIncludedNo
houseSizeRangesNo
skiLiftDistanceNo
skiPassIncludedNo
vegetarianMealsNo
danishInstructorNo
difficultyLevelsNo
freeCancellationNo
golfRoundsRangesNo
greenFeeIncludedNo
marketingConsentNo
skiPassDaysCountNo
skiSlopeDistanceNo
transferIncludedNo
hikingTripFormatsNo
maxPricePerPersonNo
minPricePerPersonNo
trailheadDistanceNo
variationAgenciesNo
accommodationTypesNo
excursionsIncludedNo
identityPersistentNo
meditationIncludedNo
pickupStationTypesNo
surfSchoolIncludedNo
triathlonDistancesNo
yogaRetreatFocusesNo
bikeRentalAvailableNo
consumptionIncludedNo
guaranteedDepartureNo
embarkationCountriesNo
onlyMultiDestinationNo
accommodationFeaturesNo
bikeTransportIncludedNo
departureDateFlexDaysNo
cyclingDifficultyLevelsNo
luggageTransportIncludedNo
includeUnratedGuestRatingNo

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool update
    • Changedfind_trips1 field changed
      • changedInput schema / properties / sort / description
        Previous 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."
  2. 4 tool updates
    • First observedfind_trips
    • First observedget_facets
    • First observedsearch_init
    • First observedsearch_listings

Related MCP Connectors

Related MCP Servers

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources