India Hotels MCP

One hotel's prices and details from every source

get_hotel_details

Read-onlyIdempotent

Retrieve full details for a specific hotel for your dates, including offers, prices in INR, amenities, reviews, and location. Use it to compare options and plan your stay without booking.

Instructions

Everything the sources say about one hotel for the given dates, grouped by source: each source's own name, rating, property type, amenities and link; all its offers (booking site such as Booking.com, Agoda or MakeMyTrip; price in INR and the original currency; taxes; refundability; availability; room and meals as the source names them; link), cheapest first; and its details (description, address, phone, website, photos, distance to the centre, location rating, review scores, pros and cons, review topics, nearby places, important info such as ID rules, amenities it lacks, badges). HotelsCasa's hotel page is fetched for every call; google_prices also fetches Google's page (1 SerpApi search from a monthly quota). The hotel is a hotel_id from search_hotels or plan_stays, or a name with lat/lng. Does not book.

Input Schema

TableJSON Schema

Name	Required	Description
`lat`	No	Hotel latitude, when not giving hotel_id.
`lng`	No	Hotel longitude, when not giving hotel_id.
`name`	No	Hotel name, when not giving hotel_id.
`adults`	No	Adults (18+) sharing the one room searched for.
`check_in`	Yes	Check-in date, YYYY-MM-DD (IST).
`hotel_id`	No	hotel_id (or any of its also_ids) from search_hotels or plan_stays.
`check_out`	Yes	Check-out date, YYYY-MM-DD.
`children_ages`	No	Ages (0–17) of children sharing that room, one entry per child, e.g. [6, 9]; empty for adults only.
`google_prices`	No	Also fetch Google's page for the hotel (1 SerpApi search from a monthly quota, when enabled): a price per booking site, address, phone and website.

Output Schema

TableJSON Schema

Name	Required	Description
`hotel`	Yes	The hotel the prices are for, as the sources list it.
`notes`	Yes	Caveats about the prices.
`sources`	Yes	Each source's own listing of the hotel (name, rating, details, link) with all its offers, cheapest source first.
`check_in`	Yes	Check-in date, YYYY-MM-DD.
`check_out`	Yes	Check-out date, YYYY-MM-DD.
`sources_ok`	Yes	Ids of the sources that answered the re-search near the hotel.
`cheapest_inr`	Yes	Lowest bookable per_night_inr across all sources (null if none in INR).
`priciest_inr`	Yes	Highest per_night_inr across all sources (null if none in INR).
`sources_failed`	Yes	Sources or lookups that did not answer, and why.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.0Oct 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, and the description still adds real cost/side-effect context: HotelsCasa's page is fetched on every call, and google_prices spends 1 SerpApi search from a monthly quota. The 'Does not book' line is redundant with readOnlyHint but harmless.

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?

The scoping facts (dates, source grouping, quota, identifier source, no booking) are front-loaded, but the long mid-sentence enumeration of every offer and detail field is a run-on list that duplicates the output schema. Much of that bulk does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 9-parameter tool with an output schema, the definition covers inputs, identifier provenance, quota cost, and the read-only non-booking nature, so an agent has what it needs to call correctly. The return-field enumeration is redundant with the output schema rather than filling a genuine gap.

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 all nine parameters including the hotel_id/name+lat/lng alternative and the quota note on google_prices are already documented in the schema. The description corroborates but adds no syntax, format, or default detail beyond it, so baseline 3 applies.

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 names a specific verb and resource — everything the sources say about one hotel for given dates, grouped by source with offers and details — and the 'one hotel' scope cleanly separates it from search_hotels and compare_hotels. An agent can identify the tool without opening the schema.

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?

It states where the identifier comes from ('a hotel_id from search_hotels or plan_stays, or a name with lat/lng') and sets an explicit exclusion ('Does not book'), which is clear context. It stops short of naming compare_hotels as the alternative for multi-hotel comparison, so it is clear but not fully routing.

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

Deploy Server