India Hotels MCP

Compare hotels by travel time

compare_hotels

Read-onlyIdempotent

Compare up to 10 hotels by travel time and distance to selected places like stations, airports, or attractions; rank by total minutes and show the price from the search.

Instructions

Compares up to 10 hotels by travel time to a set of labelled places, such as tonight's arrival station, tomorrow's departure airport and attractions. Hotels are hotel_ids from search_hotels (which also supplies their cheapest price) or name + lat/lng. Places are lat+lng, station code, IATA code or place name. Returns, per hotel, the time and distance to every place, total minutes, the cheapest price from the search that found it (with its source, fetch time and dates) and a rank by total minutes. Does not fetch new prices; get_hotel_details does.

Input Schema

Name	Required	Description	Default
`mode`	No	drive (car/taxi, with traffic allowance) or walk.	drive
`hotels`	Yes	Hotels to compare.
`places`	Yes	Places to measure from each hotel; set label, e.g. 'arrive NDLS 20:10'.

Output Schema

Name	Required	Description	Default
`notes`	Yes	How times are computed, caveats and attribution.
`hotels`	Yes	Hotels sorted by rank.

Schema Changelog

Changes observed during successful MCP inspections.

Changed19 schema fields changedv0.3.0Oct 7, 2026

addedOutput schema / properties / hotels / description
```
Added value: +"Hotels sorted by rank."
```

changedOutput schema / properties / hotels / items / properties / cheapest / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "check_in": {
-        "type": "string"
-      },
-      "check_out": {
-        "type": "string"
-      },
-      "fetched_at": {
-        "type": "string"
-      },
-      "per_night_inr": {
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "seller": {
-        "type": "string"
-      },
-      "source": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "per_night_inr",
-      "seller",
-      "source",
-      "fetched_at",
-      "check_in",
-      "check_out"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "adults": {
+        "description": "Adults in that search.",
+        "type": "number"
+      },
+      "check_in": {
+        "description": "Check-in date of that search, YYYY-MM-DD.",
+        "type": "string"
+      },
+      "check_out": {
+        "description": "Check-out date of that search, YYYY-MM-DD.",
+        "type": "string"
+      },
+      "children_ages": {
+        "description": "Ages of children in that search.",
+        "items": {
+          "type": "number"
+        },
+        "type": "array"
+      },
+      "fetched_at": {
+        "description": "ISO time the source returned this price.",
+        "type": "string"
+      },
+      "per_night_inr": {
+        "description": "Per-night price converted to INR (null if no exchange rate).",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "seller": {
+        "description": "Booking site the price is from; the source id when the source names no seller.",
+        "type": "string"
+      },
+      "source": {
+        "description": "Id of the data source that returned the price.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "per_night_inr",
+      "seller",
+      "source",
+      "fetched_at",
+      "check_in",
+      "check_out",
+      "adults",
+      "children_ages"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

changedOutput schema / properties / hotels / items / properties / cheapest / description

Previous value: -"Cheapest price from the search that returned this hotel, for that search's dates."New value: +"Lowest per-night INR price across sources from that search, for its dates and party."

addedOutput schema / properties / hotels / items / properties / hotel_id / description
```
Added value: +"hotel_id as given (null when the hotel was given by lat/lng)."
```
addedOutput schema / properties / hotels / items / properties / lat / description
```
Added value: +"Hotel latitude."
```
addedOutput schema / properties / hotels / items / properties / legs / description
```
Added value: +"Travel from this hotel to each place, in the order given."
```
addedOutput schema / properties / hotels / items / properties / legs / items / properties / from / description
```
Added value: +"Label of the origin."
```

addedOutput schema / properties / hotels / items / properties / legs / items / properties / minutes / description

Added value: +"Travel time after the traffic multiplier, minutes; equals minutes_raw for walking (null when no route)."

addedOutput schema / properties / hotels / items / properties / legs / items / properties / minutes_raw / description
```
Added value: +"Free-flow travel time from the router, minutes (null when no route)."
```
addedOutput schema / properties / hotels / items / properties / legs / items / properties / road_km / description
```
Added value: +"Road distance along the route, km (null when no route was found)."
```
addedOutput schema / properties / hotels / items / properties / legs / items / properties / straight_km / description
```
Added value: +"Straight-line distance, km."
```
addedOutput schema / properties / hotels / items / properties / legs / items / properties / to / description
```
Added value: +"Label of the destination."
```
addedOutput schema / properties / hotels / items / properties / legs / items / properties / traffic_multiplier / description
```
Added value: +"Factor applied to free-flow drive time for traffic, higher in metro areas; 1 for walking."
```
addedOutput schema / properties / hotels / items / properties / legs / items / properties / warning / description
```
Added value: +"Set when no route was found or a point is over 500 m from the nearest road."
```
addedOutput schema / properties / hotels / items / properties / lng / description
```
Added value: +"Hotel longitude."
```
addedOutput schema / properties / hotels / items / properties / name / description
```
Added value: +"Hotel name (the coordinates when no name was given)."
```
addedOutput schema / properties / hotels / items / properties / rank / description
```
Added value: +"Position by total_minutes, then per_night_inr; 1 is best."
```
addedOutput schema / properties / hotels / items / properties / total_minutes / description
```
Added value: +"Sum of minutes over all legs (null when any leg has no route)."
```

addedOutput schema / properties / notes / description

Added value: +"How times are computed, caveats and attribution."

First observedv0.1.0Oct 5, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real behavioral context: it characterises the returned data (per-place time and distance, total minutes, rank by total minutes), and flags that prices are stale 'from the search that found it' with source, fetch time and dates. No contradiction with the annotations.

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?

One dense but front-loaded block: purpose first, then input sourcing, then return shape, then the 'does not fetch prices' caveat. Every sentence carries information, though the output enumeration is long enough to push against the value of the 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?

An output schema exists so return values need not be explained, yet the description still orients the agent on what comes back, where inputs originate, and the key limitation (no fresh pricing). For a 3-parameter read-only comparison tool, nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: which values count as a hotel (hotel_id OR name + lat/lng), the mutually exclusive place forms (lat+lng, station code, IATA, place name), and a label convention example ('arrive NDLS 20:10'). This helps an agent build correct payloads rather than merely restating fields.

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 plus its scope limit ('Compares up to 10 hotels by travel time to a set of labelled places'). It distinguishes itself from siblings by naming where hotel_ids come from (search_hotels) and which tool handles the thing it does not do (get_hotel_details).

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 clear context for inputs (hotel_ids come from search_hotels, which also supplies price) and an explicit exclusion with the alternative named: 'Does not fetch new prices; get_hotel_details does.' It does not, however, say when to prefer this over travel_times or plan_stays.

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

Deploy Server