Skip to main content
Glama
Sign In

Adónde

by com.getadonde
OverviewDiscussionsAdmin

Stay details

get_stay_details
Read-onlyIdempotent

Reads one hotel in full for given dates. Returns photos, description, amenities (amenities_all has the full list), address and map point, guest score, the rooms and rates (board, refundable, per night and total, room size) each with its own book_link, a cancellation summary, the hotel's stated policies (check-in and check-out times, pets, parking, children, accessibility, payment) and review_highlights. Reads only; nothing is booked. A topic the hotel does not state is absent: say we do not know, never guess. Use for one hotel from search_stays (its hotel_id, same dates and adults) or a question about it; use compare_stays for 2 to 4 hotels, search_stays to find hotels.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "hotel_id": "<hotel_id>",
      "checkin": "<checkin>",
      "checkout": "<checkout>",
      "adults": "<adults>"
    },
    "name": "get_stay_details"
  }
}

Input Schema

NameRequiredDescriptionDefault
fromNoWhat distance_km is measured from, e.g. the centre or a neighbourhood name.
adultsYesNumber of adults, 1 to 8; use the same value as the search_stays call.
checkinYesCheck-in date, YYYY-MM-DD.
checkoutYesCheck-out date, YYYY-MM-DD, after checkin.
childrenNoAges of children travelling, if any, one entry per child.
currencyNoISO 4217 currency code for prices, e.g. EUR. Default USD.
hotel_idYesA hotel_id from search_stays.
distance_kmNoThe stay's distance_km from the search, in km, used for the why line.
match_reasonNoThe stay's match_reason from a describe search, if it had one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnly/idempotent/non-destructive, and the description reinforces this with "Reads only; nothing is booked." It adds behavior the annotations cannot carry: absent topics mean the hotel does not state them, so the agent must say "we do not know" rather than guess.

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

Conciseness4/5

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

Purpose and the read-only guarantee are front-loaded, and no sentence is filler. The return-value enumeration is one long comma-chained sentence that is dense to parse, though it earns its place because there is no output schema.

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 9 parameters, no output schema, and no enums, the description carries the return shape itself: fields returned, per-room rate detail (board, refundable, per-night and total, room size), policies covered, and the missing-data rule. Nothing an agent needs to call or interpret it is missing.

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 coverage is 100%, so every parameter is already documented, including hotel_id from search_stays and adults matching the search. The description only restates the hotel_id/dates/adults linkage and adds no format, constraint, or syntax detail beyond the schema. Baseline 3 applies 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ("Reads one hotel in full for given dates") and immediately enumerates what comes back (photos, amenities, rooms/rates with book_link, policies, review_highlights). It is unmistakably distinct from search_stays (find hotels) and compare_stays (2-4 hotels).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States exactly when to use it: one hotel from search_stays with its hotel_id and the same dates/adults, or a question about that hotel. It also names the alternatives and their selection conditions (compare_stays for 2-4 hotels, search_stays to find hotels).

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

All Adónde 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