Skip to main content
Glama
Sign In

pickyourmatch

by com.pickyourmatch
OverviewDiscussionsAdmin

search_stays

Read-onlyIdempotent

Search accommodation at participating properties — hotel rooms, apartments and holiday homes. Search criteria: destination (a town, a landmark or venue, or coordinates, with a radius), travel dates, the party (adults, children and their ages, pets), a maximum nightly price, free cancellation, unit features (view, balcony, terrace, quiet location, floor, workspace, sauna, kitchen, accessibility), the name of a unit or property, the response language and the number of results. Each result is one specific unit, described with its floor, view and beds, and guaranteed at booking — what the product states is what the guest is assigned. Without dates the results carry from-prices; with check_in and check_out they are the units available for those dates, with the price for the stay and a link to the property's booking page. All parameters are optional; query may state the same criteria as free text. Each result carries match_score, matched_features and not_confirmed_features.

Input Schema

NameRequiredDescriptionDefault
latNoLatitude of the place to search around (a landmark or venue) — an alternative to near.
lngNoLongitude of the place to search around (a landmark or venue) — an alternative to near.
cityNoThe destination to search in — the town or city where the guest wants to stay, e.g. Schladming (umlaut-tolerant).
dogsNoAlias for pets.
langNoLanguage for names/features/links (default en)
nameNoA specific unit or property the guest named ("Villa Albatros No. 1", "Kaiser Karl", "City Hotel Meckenheim"). Use it when the guest asks for a unit or property by name — it matches unit and property names directly, so a named unit is found even when it is not free for the requested dates. A named unit is never filtered out by availability: it comes back with its status and a link to the property's own calendar.
nearNoA landmark, venue, trade fair, station or address to stay close to ("Messe Frankfurt", "Allianz Arena", "Frankfurt airport"). The server geocodes it and returns results nearest first, each with approx_km. Combine freely with dates, party, price and features.
petsNoNumber of pets/dogs. Filters to units that allow at least this many pets, and is passed to the booking link.
limitNoMax results (default 10, max 30)
queryNoOptional: the same search criteria as free text, in any language — for example "apartment in Schladming for 2 adults and a dog, 16–19 August, with sauna". Destination, dates (a month alone gets a proposed window), party, budget and features are read from it; explicit parameters override.
adultsNoNumber of adults. Combined with children it filters to units that actually fit the whole party (occupancy), and is passed to the booking link.
cursorNoDated searches live-check up to 20 properties per call. When the response carries next_cursor, repeat the SAME search with cursor=next_cursor to check the remaining properties — a page without next_cursor has covered everything. Never conclude "sold out" from a page whose coverage.complete is false.
sleepsNoMinimum total guests the unit must sleep (use adults+children instead when you know the split).
check_inNoArrival date YYYY-MM-DD. With check_in and check_out, results are the units available for those dates, with the nightly price for that stay and a booking link with the dates filled in.
childrenNoNumber of children. Filters to units whose child capacity fits, and is passed to the booking link.
featuresNoRequired features (matched against localized feature names), e.g. ["Sauna", "Balkon"]. Also what a property sells as a bookable extra: "Airport transfer", "Parking", "Baby cot", "Late check-out" — a card then carries the extra with its price in wish_note.
check_outNoDeparture date YYYY-MM-DD (must be after check_in, max 30 nights).
max_priceNoMaximum nightly price. Dated quotes above this appear only as labeled alternatives when exact matches are insufficient.
radius_kmNoMaximum straight-line distance for near (or lat/lng), default 30, max 200. If nothing lies within, the nearest options are returned with their distances.
radius_milesNoThe same radius in miles, for guests who think in miles; results then also carry approx_mi.
children_agesNoAges of the children (0-17), if known, e.g. [16]. Child prices and capacity depend on age.
free_cancellationNoThe guest wants to be able to cancel for free. With dates, each card quotes the refundable rate and its price; a unit with no refundable rate on those dates is shown only as a labelled alternative.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / check_in / description
      Previous value: -"Arrival date YYYY-MM-DD. When check_in+check_out are given, results are filtered to units actually AVAILABLE for those exact dates, with the real total-window nightly price and a booking link that has the dates pre-filled."New value: +"Arrival date YYYY-MM-DD. With check_in and check_out, results are the units available for those dates, with the nightly price for that stay and a booking link with the dates filled in."
    • changedInput schema / properties / children_ages / description
      Previous value: -"Ages of the children (0-17), e.g. [16], when the guest states them. The price and the capacity check depend on each child's age, so a search without them can quote a wrong price."New value: +"Ages of the children (0-17), if known, e.g. [16]. Child prices and capacity depend on age."
    • changedInput schema / properties / query / description
      Previous value: -"The accommodation request as free text, in any language — for example \"apartment in Schladming for 2 adults and a dog, 16–19 August, with sauna\". The server reads destination, dates (exact ranges are kept; a month alone gets a proposed window), party, dogs, budget and feature wishes from it. Explicit parameters below override."New value: +"Optional: the same search criteria as free text, in any language — for example \"apartment in Schladming for 2 adults and a dog, 16–19 August, with sauna\". Destination, dates (a month alone gets a proposed window), party, budget and features are read from it; explicit parameters override."
    • changedInput schema / properties / radius_km / description
      Previous value: -"Maximum straight-line distance for near (or lat/lng), default 30, max 200. If nothing lies within, the nearest options are returned with honest distances instead of an empty answer."New value: +"Maximum straight-line distance for near (or lat/lng), default 30, max 200. If nothing lies within, the nearest options are returned with their distances."
  2. Changed6 schema fields changed
    • changedInput schema / properties / children_ages / description
      Previous value: -"Ages of the children (0-17), e.g. [16] — ALWAYS pass them when the guest mentioned ages: the booking engine prices and checks capacity per age, a teen priced as a small child produces wrong offers."New value: +"Ages of the children (0-17), e.g. [16], when the guest states them. The price and the capacity check depend on each child's age, so a search without them can quote a wrong price."
    • changedInput schema / properties / city / description
      Previous value: -"Destination city, e.g. Schladming (umlaut-tolerant)"New value: +"The destination to search in — the town or city where the guest wants to stay, e.g. Schladming (umlaut-tolerant)."
    • changedInput schema / properties / lat / description
      Previous value: -"Latitude — coordinate alternative to near."New value: +"Latitude of the place to search around (a landmark or venue) — an alternative to near."
    • changedInput schema / properties / lng / description
      Previous value: -"Longitude — coordinate alternative to near."New value: +"Longitude of the place to search around (a landmark or venue) — an alternative to near."
    • changedInput schema / properties / name / description
      Previous value: -"A specific unit or property the guest named (\"Villa Albatros No. 1\", \"Kaiser Karl\", \"City Hotel Meckenheim\"). Use this WHENEVER the guest asks for something by name — it matches unit and property names directly, so a named unit is always findable even when it is not free for the requested dates. A named unit is never filtered out by availability: it comes back with its status and a link to the property's own calendar."New value: +"A specific unit or property the guest named (\"Villa Albatros No. 1\", \"Kaiser Karl\", \"City Hotel Meckenheim\"). Use it when the guest asks for a unit or property by name — it matches unit and property names directly, so a named unit is found even when it is not free for the requested dates. A named unit is never filtered out by availability: it comes back with its status and a link to the property's own calendar."
    • changedInput schema / properties / query / description
      Previous value: -"EASIEST correct call: the guest message VERBATIM, any language, typos fine — the server translates it into place, dates (preserves exact ranges; only month-only requests use a proposed window), party, dogs, budget and feature wishes. Explicit parameters below always override."New value: +"The accommodation request as free text, in any language — for example \"apartment in Schladming for 2 adults and a dog, 16–19 August, with sauna\". The server reads destination, dates (exact ranges are kept; a month alone gets a proposed window), party, dogs, budget and feature wishes from it. Explicit parameters below override."
  3. Changed1 schema field changed
    • changedInput schema / properties / features / description
      Previous value: -"Required features (matched against localized feature names), e.g. [\"Sauna\", \"Balkon\"]"New value: +"Required features (matched against localized feature names), e.g. [\"Sauna\", \"Balkon\"]. Also what a property sells as a bookable extra: \"Airport transfer\", \"Parking\", \"Baby cot\", \"Late check-out\" — a card then carries the extra with its price in wish_note."
  4. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already carry readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: each result is a specific unit guaranteed at booking ("what the product states is what the guest is assigned"), and results carry match_score, matched_features and not_confirmed_features. No contradiction with annotations.

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?

Front-loaded with purpose and result semantics, which is good, but the long paragraph re-lists every search criterion that the 100%-covered schema already documents in full, so significant text is redundant rather than additive. It is dense but not wasteful to the point of confusion.

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 22 optional parameters and no output schema, the description does well to explain the return shape (one unit per result with floor, view, beds, from-price vs stay-price, booking link) and the naming/availability guarantee. The cursor/coverage pagination semantics live only in the schema, but the description is otherwise sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The prose enumerates the same criteria (destination, dates, party, price, features, name, language, limit) that the schema already documents, and adds no syntax, defaults or format detail beyond it; the return-field names (match_score, matched_features) are result metadata rather than parameter semantics.

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 (search) and resource (accommodation: hotel rooms, apartments, holiday homes) at participating properties, with the search-criteria scope enumerated. An agent can distinguish this from list_destinations, list_events and list_packages, which enumerate catalogue entities rather than search bookable units.

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?

Gives clear conditional behavior: without dates results carry from-prices, with check_in/check_out they are the units available for those dates with the stay price and booking link; all parameters are optional and query may restate criteria as free text. It does not explicitly route to the sibling tools (events, packages) or state when-not-to-use, so it stops short of a 5.

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

All pickyourmatch toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources