HotelsCasa

Hotel details

get_hotel

Read-onlyIdempotent

Full details of one hotel from search_hotels by its hotel_key: address, description, amenities, photos, check-in/check-out times, places nearby, a summary of guest opinions and the page url. With check_in/check_out it also checks availability live and returns an availability block: available true/false for those dates, with the real price when a room is free. availability.checked false means the supplier did not answer — the price is a catalogue price for other dates, not a confirmation. Always give the traveller the url of every item as a clickable link, unchanged: it is the only way to book or buy.

Input Schema

TableJSON Schema

Name	Required	Description
`lang`	No	Language of the answer and of the links: es, en, de, fr, it, pt, tr or ru. Default es.
`adults`	No
`check_in`	No	YYYY-MM-DD.
`children`	No
`check_out`	No	YYYY-MM-DD.
`hotel_key`	Yes	hotel_key returned by search_hotels.
`nationality`	No	Guest nationality, ISO-3166 alpha-2.
`children_ages`	No	Ages of the children, comma separated, e.g. "4,9".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`hotel`	No
`nearby`	No
`photos`	No
`address`	No
`message`	No
`city_url`	No
`amenities`	No
`description`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 23, 2026

addedInput schema / properties / children

Added value: +{
+  "maximum": 4,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / children_ages

Added value: +{
+  "description": "Ages of the children, comma separated, e.g. \"4,9\".",
+  "type": "string"
+}

addedInput schema / properties / nationality

Added value: +{
+  "description": "Guest nationality, ISO-3166 alpha-2.",
+  "type": "string"
+}

First observedSep 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds valuable behavior beyond annotations: the live availability check behavior, the meaning of availability.checked=false (supplier did not answer, catalogue price is not a confirmation), and the mandatory instruction to provide the traveler with clickable, unchanged URLs. This is meaningful behavioral context not available in structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no filler. It front-loads the core purpose, then adds the availability caveat, then the critical URL-formatting instruction. Every sentence carries operational weight, and the structure guides the agent from the primary function to edge-case semantics to user-facing obligations.

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 read-only detail tool with an output schema, the description is complete: it explains the primary data returned, the conditional availability block with its failure semantics, and the required link-handling behavior. The output schema covers return structure, so nothing critical is missing for an agent to call and interpret the result correctly.

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 75%, so the schema already documents most parameters. The description adds meaning for hotel_key (returned by search_hotels) and check_in/check_out (triggers live availability block), but it does not add semantic value for lang, adults, children, nationality, or children_ages. This is a reasonable baseline score with modest added value.

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?

The description opens with a specific verb-plus-resource statement: 'Full details of one hotel from search_hotels by its hotel_key'. It enumerates the exact content fields (address, description, amenities, photos, check-in/check-out times, places nearby, guest opinions, page URL) and clearly distinguishes this tool from search_hotels, get_property, get_activity, and get_vehicle.

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?

The description clearly implies the tool is used after search_hotels by requiring its hotel_key as input, and it explains that check_in/check_out enable live availability. It does not explicitly name alternatives or state when-not-to-use, but the 'from search_hotels by its hotel_key' phrasing gives enough contextual guidance for correct invocation.

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

All HotelsCasa 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.