Search hotels, compare room offers and public or masked wholesale rates, then continue on Brek.
Scored across 3 tools
The three tools split cleanly along search vs. undated property facts vs. dated live offers, and the descriptions explicitly state what each excludes (e.g., details has no availability or prices). The only risk is that get_accommodation_details and get_accommodation_offers both accept the same propertyId/hotelName identifiers and both return property data, so an agent could pick the wrong one for a vague 'tell me about this hotel' request.
All three follow a clear verb_noun pattern (search_/get_ + resource), which is predictable and readable. The minor deviation is singular 'accommodation' in the get_ tools versus plural 'accommodations' in search, plus the noun is repeated across all names.
Three tools map exactly to the three core jobs of a wholesale hotel lookup: discover/compare, inspect a property, and price a specific stay. It is on the lean side, but each tool clearly earns its place and nothing appears redundant.
Discovery, property facts, and dated room offers with pricing form a coherent read-only lifecycle, and the descriptions signal that actual booking/purchase happens on Brek. The gap is that no reservation or availability-check operation exists, so an agent cannot complete a booking end to end within this surface.
Returns undated facts for one identified Brek property ID, including address, description, photos, amenities, check-in and checkout times, star rating, and guest-review data. When the user refers to a hotel from a previous search_accommodations result by full or partial name or list position, copy that result's propertyId exactly if the match is unique; never shorten, combine, or use a placeholder ID. Ask for clarification if several hotels match. If no exact property ID is available, hotelName and optional destination can identify a unique hotel. No stay dates are needed. Availability, room offers, prices, breakfast, and cancellation terms are not included.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | Only specify a currency when the traveler explicitly requests one. Otherwise omit it so Brek can use the visitor country, then locale, then USD. Supported: EUR, USD, INR, GBP, AUD, CAD, ARS, TRY, COP, CLP, SEK, MXN, IDR, BRL. | |
| hotelName | No | Hotel name when no propertyId is available; a unique match is required. | |
| propertyId | No | Exact Brek property ID copied from a previous search result. Do not guess, truncate, combine, or pass a placeholder; use hotelName if unsure. | |
| destination | No | Optional city or region to disambiguate hotelName. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| images | Yes | |
| status | No | |
| address | Yes | |
| latitude | Yes | |
| amenities | Yes | |
| longitude | Yes | |
| highlights | Yes | |
| starRating | Yes | |
| checkinFrom | Yes | |
| description | Yes | |
| reviewCount | Yes | |
| reviewScale | Yes | |
| reviewScore | Yes | |
| propertyType | Yes | |
| checkoutUntil | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuine context beyond them: the no-dates constraint, the strict ID-integrity rule (never shorten, combine or placeholder), and an explicit list of data that is not returned. These are real behavioral constraints an agent cannot infer from 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?
The identifying behavior and usage rules are front-loaded in the first two sentences, and every clause carries an actionable constraint. It runs slightly long with some repetition of the ID-integrity warning that also appears in the schema, but nothing is filler.
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 an output schema present, the description does not need to explain return values and correctly focuses on identity resolution and scope boundaries. For a four-optional-parameter lookup tool, everything needed to call it correctly is stated.
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 100%, so parameter documentation is already strong and the baseline is 3. The description adds priority semantics between propertyId and hotelName, including when to prefer the fallback, which the schema hints at but does not fully rank.
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 ('Returns undated facts for one identified Brek property ID') and enumerates the payload fields (address, photos, amenities, check-in/out, rating, reviews). It also explicitly excludes availability, room offers, prices, breakfast and cancellation terms, which cleanly separates it from get_accommodation_offers.
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 concrete routing rules: copy the propertyId from a prior search_accommodations result when the user references a hotel by name or list position, fall back to hotelName plus optional destination when no ID exists, and ask for clarification if multiple hotels match. It also notes no stay dates are needed, so the agent knows when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one named or identified hotel's full-stay property data and live room offers for specified dates and occupancy. When the user refers to a hotel from a previous search_accommodations result by list position or partial name, copy its propertyId exactly if the match is unique; never shorten, combine, or use a placeholder ID. Ask for clarification if several hotels match. Use hotelName and optional destination when no exact propertyId is available. Includes wholesale room types and photos, breakfast, refundability, cancellation terms, public-rate comparisons, masked wholesale rate bands, and Brek links. Public-only room types are excluded. Wholesale options priced above their public comparison are marked sold_out without a price; the public comparison remains available. Single-room and multi-room stays are supported through aggregate occupancy plus optional per-room arrangements. Exact private wholesale prices are available on Brek.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | No | Number of rooms. Each room requires at least one adult. | |
| adults | No | Total adult guests. | |
| currency | No | Only specify a currency when the traveler explicitly requests one. Otherwise omit it so Brek can use the visitor country, then locale, then USD. Supported: EUR, USD, INR, GBP, AUD, CAD, ARS, TRY, COP, CLP, SEK, MXN, IDR, BRL. | |
| timeZone | No | Optional IANA time-zone fallback for resolving relative stay dates; destination or property location takes precedence. | |
| hotelName | No | Exact hotel name when propertyId is unavailable. | |
| dateIntent | No | Use only when the user explicitly requests tonight. Resolves check-in as the current local date and check-out as the following date; otherwise provide both stay dates. | |
| propertyId | No | Exact Brek property ID copied from a previous search result or Brek stay URL. Do not guess, truncate, combine, or pass a placeholder; use hotelName if unsure. | |
| checkinDate | No | Required with checkoutDate unless the user explicitly requested tonight. Use YYYY-MM-DD. | |
| destination | No | Optional city or region for disambiguating hotelName. | |
| checkoutDate | No | Required with checkinDate unless the user explicitly requested tonight. Use YYYY-MM-DD. | |
| childrenAges | No | Age of each child at check-in. | |
| roomArrangements | No | Exact per-room occupancy. Example: room 1 has 2 adults and room 2 has 2 adults plus children ages 4 and 2 => [{adults:2,childrenAges:[],infants:0},{adults:2,childrenAges:[4,2],infants:0}]. Array length equals rooms, and aggregate guests equal adults and childrenAges. | |
| availabilityToken | No |
| Name | Required | Description |
|---|---|---|
| stay | Yes | |
| offers | Yes | |
| status | No | |
| property | Yes | |
| propertyId | Yes | |
| priceDisclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so the bar is low, yet the description still adds substantial behavior: public-only room types are excluded, wholesale options above their public comparison are marked sold_out with no price while the public comparison remains, and exact private prices live on Brek. These are non-obvious result-shaping rules an agent needs to interpret output correctly.
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 core action, then the ID-resolution rule, then result contents and edge cases. Dense and mostly waste-free, though the final three sentences on rate bands, exclusions, and Brek pricing could be tightened into a single bullet-like clause.
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 13-parameter tool with an output schema, this covers everything an agent must know: how to identify the hotel, how occupancy maps to rooms, and what quirks to expect in the returned offers. Nothing material is left to inference.
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 92%, so the baseline is 3, but the description adds real value beyond the schema: the propertyId provenance rule and the aggregate-occupancy-vs-per-roomArrangements relationship for multi-room stays. It does not re-explain currency, time zone, or dateIntent, which the schema already covers well, keeping it above baseline without being 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?
Specific verb and resource: returns one identified hotel's full-stay property data plus live room offers for given dates and occupancy. It is clearly distinguishable from search_accommodations (which produces the propertyId you pass in here) and implicitly from get_accommodation_details by its focus on priced room offers rather than general details.
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 routes between two identification paths: copy propertyId verbatim from a prior search_accommodations result when unique, otherwise fall back to hotelName plus optional destination. It also states the when-not case (ask for clarification on ambiguous matches) and forbids shortening/combining/placeholder IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches and compares multiple hotels in a city, neighborhood, airport, landmark, or other destination. Every search requires both checkinDate and checkoutDate, or dateIntent=tonight when the user explicitly asks for tonight. If the user supplied neither, ask for stay dates before calling; do not choose dates for them. Supports occupancy, price range, star rating, guest score, property types, amenities, cancellation preference, and sort order. Returns an ordered list with property IDs, hotel facts, masked wholesale price bands, public-rate comparisons, and Brek links. For a follow-up by position or partial hotel name, match against the most recent relevant search list. If one hotel matches, copy its propertyId exactly into get_accommodation_details or get_accommodation_offers; never shorten, combine, or replace IDs with placeholders. If the ID is unavailable, pass hotelName and optional destination instead. If several hotels match, ask which hotel the user means. Intended for destination discovery and multi-hotel comparison; room-level offers for one property are not included. Exact private wholesale prices are available on Brek.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | Result order: top-picks, distance, total price ascending, total price descending, or guest reviews. | top-picks |
| rooms | No | Number of rooms. Each room receives the default of 2 adults when adults is omitted. | |
| adults | No | Total adult guests. When omitted, Brek defaults to 2 adults per room. | |
| children | No | Total child guests; when omitted, uses childrenAges.length. | |
| currency | No | Only specify a currency when the traveler explicitly requests one. Otherwise omit it so Brek can use the visitor country, then locale, then USD. Supported: EUR, USD, INR, GBP, AUD, CAD, ARS, TRY, COP, CLP, SEK, MXN, IDR, BRL. | |
| latitude | No | Optional latitude when already known. | |
| timeZone | No | Optional IANA time-zone fallback for resolving relative stay dates; destination or property location takes precedence. | |
| amenities | No | Amenities required in every result. | |
| longitude | No | Optional longitude when already known. | |
| dateIntent | No | Use only when the user explicitly requests tonight. Resolves check-in as the current local date and check-out as the following date; otherwise provide both stay dates. | |
| checkinDate | No | Required with checkoutDate unless the user explicitly requested tonight. Use YYYY-MM-DD. | |
| destination | Yes | City, neighborhood, airport, landmark, or other broad destination. | |
| starRatings | No | Exact accepted hotel star classifications. | |
| user_locale | No | Optional traveler locale from the Claude client context, such as en-US. Omit if unavailable; do not infer it from the hotel destination. | |
| checkoutDate | No | Required with checkinDate unless the user explicitly requested tonight. Use YYYY-MM-DD. | |
| childrenAges | No | Age of every child at check-in. The array length must equal children. | |
| maximumPrice | No | Maximum nightly price in the selected currency. | |
| minimumPrice | No | Minimum nightly price in the selected currency. | |
| propertyTypes | No | Accepted accommodation types, such as hotel, motel, resort, hostel, or apartment. | |
| minimumStarRating | No | Minimum hotel star classification from 1 to 5; distinct from guest review score. | |
| minimumReviewScore | No | Minimum guest review score out of 10; distinct from hotel star classification. | |
| user_location_city | No | Optional approximate traveler city supplied by the Claude client. Omit if unavailable; this is not the hotel destination. | |
| freeCancellationOnly | No | Whether results require free cancellation or refundable rates. | |
| user_location_region | No | Optional traveler state or region supplied by the Claude client. Omit if unavailable; do not infer it from the hotel destination. | |
| user_location_country | No | Optional two-letter traveler country supplied by the Claude client, such as US. Omit if unavailable; do not infer it from the hotel destination. | |
| user_location_timezone | No | Optional IANA timezone of the traveler supplied by the Claude client. Omit if unavailable; this does not set the hotel's local stay dates. |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| total | Yes | |
| search | Yes | |
| status | No | |
| message | No | |
| totalPages | Yes | |
| requiredInput | No | |
| accommodations | Yes | |
| priceDisclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description still discloses that results carry masked wholesale price bands with public-rate comparisons and that exact wholesale prices live on Brek. It also warns that ID handling must be verbatim, which is real behavioral guidance. Pagination and result-size behavior are not described, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then date rules, then filters, then return shape, then follow-up routing — a sensible precedence order with no filler. It runs long and the closing line about exact prices on Brek is closer to marketing than instruction, which costs it the top mark.
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 27-parameter tool the description covers the hard parts: when it is legal to call (dates), what comes back at a high level, and how to continue after the call. The output schema documents the return payload and the input schema documents every field at 96% coverage, so nothing essential is left for the description to carry.
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 96%, so the schema carries most semantics and baseline 3 applies. The description still adds decision-level meaning the schema cannot: the date invariant, the dateIntent fallback, and a grouped inventory of the filter families (occupancy, price range, stars, guest score, property types, amenities, cancellation, sort) so the agent knows what is available without reading 27 properties.
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 ("searches and compares multiple hotels") plus the destination scope, and closes with an explicit exclusion: "room-level offers for one property are not included." That sentence alone separates it from get_accommodation_offers and get_accommodation_details without opening either 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 concrete gating conditions (both stay dates required, or dateIntent=tonight only on explicit request) and an instruction for the missing case: ask the user, never pick dates. It also routes follow-ups: single match goes to get_accommodation_details or get_accommodation_offers, multiple matches require asking the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_accommodation_detailsget_accommodation_offerssearch_accommodationsSearch 650,000 hotels, get each hotel's direct price with full offer lists, match rooms, book.
Search hotels worldwide, compare live room rates, and create booking payment links.
Live hotel rates worldwide: search stays, property detail, all-in room prices, human phone desk.
Find last-minute hotels, compare room offers, and continue on RoomLast to book.
Add one secure layer between your agents and this server.