Anywayr

Search hotels

anywayr_search_hotels

Read-onlyIdempotent

Searches hotels for exact dates and one room with real guest ages. Results come best-first the way Anywayr ranks them (guest rating and review count, star class, value, location), 20 at a time; pass sort "top_rated" or "cheapest" to change that, and min_stars / min_guest_rating / max_total / max_distance_km / free_cancellation_only / breakfast_included to filter (e.g. for "somewhere nicer"). Sort "best_deal" returns only hotels in the place priced at or below similar hotels near them in the same search, each with a deal: quote deal.why as given, and say "deal" or "great deal" only when deal.label does; a "pick" is about other hotels in this search, never this hotel's usual price. When fewer than 3 hotels inside the place qualify, nearby ones follow with location.inside_place false: never call them in the place, and give their town and distance as their first why line does. An airport is a point: no hotel is in it, only near it. Never compare Anywayr's prices with other sites. With best_deal a state or country is searched as its most-booked hotel area (narrowed_to). With a room filter, quote matched_room. Each hotel has its address and distance from the centre of the searched place. For the next 20, call again with the same search and cursor set to next_cursor (no new supplier search). Quote all_in_total as the price: it adds fees the hotel collects at the property to what Anywayr charges; when it is null, say the hotel may charge extra at the property. Give both prices per hotel when they differ: cheapest_room (often non-refundable) and cheapest_free_cancellation_room with its free-cancellation date. Unsupported party shapes are refused, not adjusted. Results say whether they are live or cached and whether any source was missing; a provider outage is never reported as no availability. Prices shown are leads, not quotes. Effects: Stores a search snapshot (so rates can be read later) and spends provider search budget. Holds nothing.

Input Schema

Name	Required	Description	Default
`sort`	No
`cursor`	No	Anywayr cursor reference (starts with cur_), as returned by the next_cursor of a previous page.
`currency`	No	Currency for prices. Only USD is supported today; omit it or pass "USD".	USD
`max_total`	No	Highest whole-stay price in USD, including fees the hotel collects at the property.
`min_stars`	No
`date_range`	Yes
`occupancies`	Yes
`request_key`	Yes	Any unique string of 16-128 characters you generate (letters, digits and . _ : -). Reuse the same key only to retry the exact same request.
`destination_ref`	Yes	Anywayr place reference (starts with plc_), as returned by anywayr_resolve_destination.
`max_distance_km`	No	Only hotels within this many km of the centre of the searched place.
`min_guest_rating`	No
`breakfast_included`	No	Only hotels with a room that includes breakfast; prices then quote that room.
`free_cancellation_only`	No	Only hotels with a room that can be cancelled for free; prices then quote that room.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 28, 2026

addedInput schema / properties / breakfast_included

Added value: +{
+  "description": "Only hotels with a room that includes breakfast; prices then quote that room.",
+  "type": "boolean"
+}

addedInput schema / properties / free_cancellation_only

Added value: +{
+  "description": "Only hotels with a room that can be cancelled for free; prices then quote that room.",
+  "type": "boolean"
+}

addedInput schema / properties / max_distance_km

Added value: +{
+  "description": "Only hotels within this many km of the centre of the searched place.",
+  "maximum": 50,
+  "minimum": 0.5,
+  "type": "number"
+}

addedInput schema / properties / max_total

Added value: +{
+  "description": "Highest whole-stay price in USD, including fees the hotel collects at the property.",
+  "exclusiveMinimum": 0,
+  "maximum": 1000000,
+  "type": "number"
+}

changedInput schema / properties / sort / enum

Previous value: -[
-  "best",
-  "top_rated",
-  "cheapest"
-]New value: +[
+  "best",
+  "top_rated",
+  "cheapest",
+  "best_deal"
+]

First observedOct 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the annotations with details the structured fields cannot carry: unsupported party shapes are refused rather than adjusted, results state live vs cached and flag missing sources, a provider outage is never reported as no availability, and prices are leads not quotes. The Effects line explicitly names the snapshot write and provider-budget spend, so the agent is not surprised by the readOnlyHint framing.

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?

Nothing is wasted and the purpose is front-loaded, but the body is one dense block that interleaves pagination, deal-labeling policy, nearby-hotel fallback, and price-quoting rules. Breaking these into distinct sentences or semicolon groups would improve scanability without losing content.

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?

With no output schema and 13 parameters, the description still covers return-shape essentials: all_in_total semantics and the null case, dual cheapest_room vs cheapest_free_cancellation_room pricing, next_cursor pagination, location.inside_place, and how to quote deal.why and deal.label. An agent could call and report results correctly from this alone.

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?

At 62% schema coverage, the description compensates well for the undocumented params: it explains what top_rated/cheapest/best_deal do, that a room filter makes prices quote matched_room, and that a state or country is folded to its most-booked area via narrowed_to. request_key and currency are left to the schema, which is acceptable.

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 with exact scope: "Searches hotels for exact dates and one room with real guest ages." That scope plus the sort/filter machinery distinguishes it cleanly from siblings like list_city_deals or get_hotel_rates.

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 concrete triggers for each mode — pass "top_rated" or "cheapest" to change ranking, use the filter parameters for "somewhere nicer", and re-call with cursor to get the next 20. What is missing is sibling routing: it never says when to prefer list_city_deals or get_hotel_rates instead.

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

All Anywayr tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?