India Hotels MCP

Data sources and status

get_data_sources

Read-onlyIdempotent

List every data source the server uses for hotel searches, including status, quotas, and limitations.

Instructions

Lists every data source this server uses: hotel price sources, hotel location data, geocoding, routing and bundled datasets. For each it gives whether it is enabled, whether it is official or an unofficial third-party endpoint, recent success/failure, remaining quota and known limitations. Bundled datasets include their build date and licence. Does not fetch any hotel data.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`providers`	Yes	Every data source and its current status.
`snapshots`	Yes	Bundled datasets, with build date and licence.

Schema Changelog

Changes observed during successful MCP inspections.

Changed20 schema fields changedv0.3.0Oct 7, 2026

addedOutput schema / properties / providers / description

Added value: +"Every data source and its current status."

addedOutput schema / properties / providers / items / properties / disabled_reason / description
```
Added value: +"Why the source is disabled (null when enabled)."
```
addedOutput schema / properties / providers / items / properties / enabled / description
```
Added value: +"Whether the source is in use."
```
addedOutput schema / properties / providers / items / properties / id / description
```
Added value: +"Source id, as used in source fields elsewhere."
```

addedOutput schema / properties / providers / items / properties / kind / description

Added value: +"What the source provides: hotel-prices, hotel-locations, geocoding, routing, fx or dataset."

changedOutput schema / properties / providers / items / properties / last_error / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "at": {
-        "type": "string"
-      },
-      "code": {
-        "type": "string"
-      },
-      "message": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "at",
-      "code",
-      "message"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "at": {
+        "description": "ISO time of the error.",
+        "type": "string"
+      },
+      "code": {
+        "description": "Error code, e.g. UPSTREAM_UNAVAILABLE.",
+        "type": "string"
+      },
+      "message": {
+        "description": "What went wrong.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "at",
+      "code",
+      "message"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedOutput schema / properties / providers / items / properties / last_error / description
```
Added value: +"The most recent failed call since the server started (null if none)."
```

addedOutput schema / properties / providers / items / properties / last_success_at / description

Added value: +"ISO time of the last successful call since the server started (null if none)."

addedOutput schema / properties / providers / items / properties / limitations / description
```
Added value: +"Known limitations of the source."
```
addedOutput schema / properties / providers / items / properties / name / description
```
Added value: +"Human-readable source name."
```
addedOutput schema / properties / providers / items / properties / needsKey / description
```
Added value: +"Whether the source needs an API key."
```

addedOutput schema / properties / providers / items / properties / official / description

Added value: +"true for an official API, false for an unofficial third-party endpoint with no SLA."

addedOutput schema / properties / providers / items / properties / quota_remaining / description

Added value: +"Calls left in the source's current quota window (null when the source has no tracked quota)."

addedOutput schema / properties / snapshots / description

Added value: +"Bundled datasets, with build date and licence."

addedOutput schema / properties / snapshots / items / properties / built_at / description
```
Added value: +"When the dataset was built (null if unknown)."
```
addedOutput schema / properties / snapshots / items / properties / description / description
```
Added value: +"What the dataset contains."
```
addedOutput schema / properties / snapshots / items / properties / id / description
```
Added value: +"Dataset id."
```
addedOutput schema / properties / snapshots / items / properties / licence / description
```
Added value: +"Licence of the data."
```
addedOutput schema / properties / snapshots / items / properties / rows / description
```
Added value: +"Number of records in the dataset."
```
addedOutput schema / properties / snapshots / items / properties / source / description
```
Added value: +"Where the data comes from."
```

First observedv0.1.0Oct 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered; the description goes further by disclosing what each entry contains (enabled flag, official vs unofficial third-party, recent success/failure, remaining quota, known limitations, build date and licence) and explicitly denies fetching hotel data. It stops short of describing ordering or freshness of the reported status, but adds real context beyond 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?

Three sentences, front-loaded with the core action, and the final boundary sentence earns its place by preventing an agent from expecting hotel payloads. The middle sentence is a dense comma list of returned fields, which is slightly heavy but still scannable.

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 no parameters, rich annotations and an output schema present, the description only needs to convey purpose, scope and the negative boundary — all of which it does. Nothing an agent needs in order 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies and there is nothing for the description to disambiguate. It correctly avoids inventing parameter-like filtering language.

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?

States a specific verb and resource ('Lists every data source this server uses') and enumerates the scope: price sources, location data, geocoding, routing and bundled datasets. None of the siblings (search_hotels, resolve_place, travel_times, etc.) do anything similar, so the agent can separate this metadata/status tool from the hotel-lookup tools at a glance.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the enumeration of status/quota/limitation fields suggests it is the diagnostic tool to call before or after a hotel query fails. It closes one boundary explicitly ('Does not fetch any hotel data'), but never says when to prefer it over the sibling tools or what condition should trigger it.

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

Deploy Server