Find hotels worldwide by amenities and check a hotel's amenity profile, plus typical nightly prices.
Scored across 4 tools
Each tool targets a clearly distinct step: find_place resolves a name to an ID, search_hotels finds hotels by features, get_hotel_facts returns amenities for one hotel, and get_price_guide gives budget orientation. The descriptions even cross-reference each other (place_id needed by search_hotels, prices deferred to get_price_guide), eliminating overlap. No two tools could plausibly be confused.
All four tools follow a consistent verb_noun snake_case pattern: find_place, get_hotel_facts, get_price_guide, search_hotels. The verbs (find/get/search) are conventional and the nouns name the target resource. Perfectly predictable.
Four tools cleanly map to the natural sequence of a hotel discovery flow (resolve place -> search -> inspect amenities -> check price). Each tool earns its place with no redundancy, and the count sits comfortably within a well-scoped range.
The surface covers the core discovery lifecycle: location resolution, hotel search, amenity lookup, and price orientation. Minor gaps exist (no ratings/reviews data surfaced, no date-specific availability or booking), but descriptions explicitly scope these out as living on the website, so agents can work around them.
Use when a city, region or island name has to be turned into a place_id (needed by search_hotels, get_hotel_facts and get_price_guide): returns up to 5 matching places with place_id and country. If several fit, choose by country or ask the user.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | City, region or island name, in any language. | |
| language | No | The user's language: de, en or tr (default en). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| places | Yes | |
| source | No | |
| website | No | |
| response_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds useful context: capped at 5 results, returns place_id and country, and defines the ambiguity-handling policy. It stops short of discussing matching/fuzzy-failure behavior, so not 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?
One front-loaded 'Use when' clause followed by a single disambiguation sentence; every clause carries actionable information with zero 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 a full schema, an output schema, and rich annotations, the description supplies exactly the missing pieces — the trigger condition, the consumers, and the multi-match policy — leaving nothing an agent needs unanswered.
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% and already documents query (city/region/island, any language) and the language enum, so the description only restates the query semantics without adding format constraints or examples. Baseline 3 applies.
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 transformation (city/region/island name → place_id) and identifies the exact consumers of that id (search_hotels, get_hotel_facts, get_price_guide), so it is unmistakable against its siblings.
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 an explicit trigger ('Use when ... has to be turned into a place_id'), names the downstream tools that require it, and prescribes resolution behavior when multiple matches exist ('choose by country or ask the user').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks what one specific hotel offers (e.g. does it allow pets, is there a sauna, halal food). Returns its amenities as stated by the hotel, with section and origin; extra_charge marks a stated surcharge (no mark means no information, not free). Identify the hotel by its hoteldiscount24.com URL (e.g. from search_hotels), or by name plus place_id; other_matches lists similar names at that place.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Hotel name, if no URL is known (needs place_id). | |
| hotel | No | hoteldiscount24.com hotel URL or slug. | |
| language | No | The user's language: de, en or tr (default en). | |
| place_id | No | place_id from find_place. |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| city | No | |
| name | Yes | |
| note | No | |
| stars | No | Star category as listed by the hotel. |
| notice | No | |
| source | No | |
| summary | No | |
| website | No | |
| amenities | Yes | |
| country_code | No | |
| other_matches | No | |
| response_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is read-only, idempotent, and non-destructive, so the bar is lower. The description adds useful behavioral context beyond annotations: amenities are as stated by the hotel, extra_charge indicates a stated surcharge, and an absent mark means no information rather than free.
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 description is compact and front-loaded with the usage condition. Every sentence contributes either routing guidance, return semantics, or identification details, with no redundant restatement of the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, annotations, and fully documented parameters, the description covers what the tool does, when to use it, how to identify the hotel, and important return-value nuances. Nothing essential for correct invocation appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents each parameter. The description still adds meaning by explaining the two identification paths: URL from search_hotels, or name plus place_id, and notes that other_matches lists similar names at that place.
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?
The description states a specific verb and resource: it answers what one specific hotel offers and returns its amenities. It clearly distinguishes the tool from search_hotels (which supplies the URL) and find_place (which supplies place_id), so an agent can select it confidently.
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?
It gives a clear usage trigger with concrete examples such as pets, sauna, and halal food. It also routes the agent to sibling tools for hotel identification, though it does not explicitly say when not to use this tool or compare it with get_price_guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for budget questions (what does a night cost in …): typical price range per night (2 adults) at a place, measured from recent searches, with date. For orientation only — current prices for specific dates are on hoteldiscount24.com. has_price_data=false means no reliable data for this place and month.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Travel month YYYY-MM (default: current month). | |
| stars | No | Star category (default any). | |
| language | No | The user's language: de, en or tr (default en). | |
| place_id | Yes | place_id from find_place. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| month | No | |
| place | Yes | |
| source | No | |
| website | No | |
| sentence | No | |
| typical_eur | No | |
| response_date | No | |
| has_price_data | Yes | |
| typical_low_eur | No | |
| typical_high_eur | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description adds genuine context beyond that: the data provenance ('measured from recent searches'), the orientation-only caveat, and the meaning of a has_price_data=false result.
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?
Three sentences, each doing distinct work: trigger, scope/provenance, caveat plus error semantics. Front-loaded with the use case and free of repetition.
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?
An output schema exists, so return values need not be detailed, yet the description still explains the has_price_data flag, which is the key edge case. It omits any hint about how the stars filter affects results, a minor gap for a tool that is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents place_id, month, stars and language with defaults and patterns. The description adds only marginal semantic value ('per night, 2 adults', 'this place and month'), which is the expected baseline when the schema does the heavy lifting.
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?
The description states a specific resource and scope: 'typical price range per night (2 adults) at a place, measured from recent searches.' It implicitly separates itself from search_hotels by framing the result as orientation data rather than live bookable prices, but it never names a sibling tool to make that distinction explicit.
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?
It gives a clear trigger ('Use for budget questions (what does a night cost in …)') and a boundary ('For orientation only — current prices for specific dates are on hoteldiscount24.com'). The exclusion points to an external website rather than to the sibling search_hotels tool, so the routing guidance is good but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user wants hotels at a place with specific features (pool, sauna, pets allowed …). All given amenities must match, as stated by the hotels; with few or no results, try fewer amenities. Returns up to 10 hotels with links, ordered by star rating — no prices (see get_price_guide) and no ratings. A notice field carries a condition the user should know (e.g. pets are decided case by case). Halal, kosher, wheelchair access, non-smoking and cribs are not search filters — check them per hotel with get_hotel_facts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of hotels (default 10). | |
| language | No | The user's language: de, en or tr (default en). | |
| place_id | Yes | place_id from find_place. | |
| amenities | Yes | Amenity keys from the list, e.g. pool, sauna, pets-allowed. | |
| min_stars | No | Minimum star rating. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| place | Yes | |
| hotels | Yes | |
| notice | No | |
| source | No | |
| website | No | |
| response_date | No | |
| more_on_website | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the readOnly/idempotent annotations: AND-semantics of the amenity filter, up to 10 results, star-rating ordering, intentional absence of prices and ratings, and the notice field carrying a caveat. It also warns that several apparent filters (halal, kosher, wheelchair access, non-smoking, cribs) are not supported here, which prevents a bad query.
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?
Dense but front-loaded: usage condition first, then result shape, then negative constraints, then exclusions with their alternative tool. No sentence is filler; each carries a distinct operational fact.
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 5-parameter search tool with an output schema and full annotations, this covers what the structured fields cannot: filter semantics, result count and ordering, unsupported filters, and the notice field's meaning. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: amenities are conjunctive (all must match), and the result cap of 10 corroborates the limit maximum. It doesn't elaborate on min_stars or language, which the schema already covers adequately.
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 action (find hotels) and the qualifying condition (at a place, matching specific amenities), including the place_id + amenities framing that maps directly to the required parameters. It is clearly distinguishable from find_place, get_hotel_facts, and get_price_guide.
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 tells the agent when to use it ('user wants hotels at a place with specific features'), gives a fallback for thin results ('try fewer amenities'), and names the alternatives for adjacent needs — get_price_guide for prices and get_hotel_facts for per-hotel checks. This is a complete routing statement.
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.
find_placeget_hotel_factsget_price_guidesearch_hotelsHotel prices, ratings, reviews and amenities from Google Hotels for any city, dates and guests.
Search hotels worldwide, compare live room rates, and create booking payment links.
Google Hotels prices for any dates and guests, ratings, amenities and every booking site's price.
Live hotel rates worldwide: search stays, property detail, all-in room prices, human phone desk.
Add one secure layer between your agents and this server.