Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@webhotelier-mcp Check availability at GOLDENSAND for Sep 3-5 for 2 adults."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A read-only Model Context Protocol (MCP) server for the WebHotelier REST API.
It lets an AI assistant (Claude Code, Claude Desktop, or any MCP-compatible client) answer questions like these with live hotel data:
"Is there a double room at GOLDENSAND for Sep 3–5 for 2 adults, and at what price?" "Which days in August still have availability?" "What's the cheapest rate this weekend, and what's the cancellation policy?"
The assistant picks the right tool, the server calls WebHotelier, and the answer comes back grounded in real availability and real prices — not guesses.
Related MCP server: OfficeRnD MCP Server
MCP is an open protocol that gives language models a standard way to call external systems. The flow for every question:
┌────────────┐ JSON-RPC over stdio ┌─────────────┐ HTTPS ┌──────────────────────────┐
│ MCP client │ ──────────────────────▶ │ server.js │ ───────────────▶ │ rest.reserve-online.net │
│ (Claude) │ ◀────────────────────── │ (this repo)│ ◀─────────────── │ (WebHotelier REST API) │
└────────────┘ tool results └─────────────┘ JSON payloads └──────────────────────────┘On startup, the client launches node server.js as a subprocess and performs the MCP
handshake over stdin/stdout.
The server advertises its 8 tools, each with a name, a natural-language description, and a JSON Schema for its parameters. The model reads these to decide when and how to call each tool.
When the model calls a tool, the server validates the arguments (zod), calls the WebHotelier endpoint with HTTP Basic Auth, slims the response (see Design decisions), and returns JSON text that lands in the model's context.
Errors come back as readable results, not crashes — the model sees a message that tells it what to do next (e.g. "Unknown property code — call list_properties for valid codes.").
All eight tools are read-only. The server implements no write endpoint of any kind.
Tool | What it answers | Required params | Optional params |
| Which hotels exist and their property codes. Local registry lookup — no API call. | — | — |
| Hotel profile + full room catalog (room types, capacities, amenities). |
| — |
| Is there a room for these dates/party, and at what price. The workhorse. |
|
|
| Rate plans and cancellation policies. |
|
|
| Day-by-day availability over a date range. |
|
|
| Cheapest available rate (BAR — Best Available Rate). |
|
|
| Active special offers / packages. |
| — |
| Booking search by property and check-in date range.* | — |
|
All dates use YYYY-MM-DD. property is the WebHotelier property code (e.g. GOLDENSAND);
the model is instructed to call list_properties first when it doesn't know a code.
* get_reservations requires a WebHotelier account with reservations privileges. Without
them the API returns 403 NO_PRIVILEGES, and the tool degrades to a clear message —
"The configured WebHotelier account does not have reservations access; all other tools
work normally." If your credentials are later upgraded, the tool starts working with zero
code changes.
Requires Node.js ≥ 20.
git clone <this repo>
cd webhotelier-mcp
npm install
cp .env.example .env # then fill in WH_USERNAME / WH_PASSWORD
npm run smoke # optional: verify your credentials against the live APInpm run smoke should end with SMOKE PASS.
All configuration lives in .env (gitignored — credentials never enter the repo):
Variable | Required | Purpose |
| yes | WebHotelier API username (HTTP Basic Auth) |
| yes | WebHotelier API password/key |
| no | Absolute path to a JSON file backing |
list_properties reads a local JSON file so the model can discover valid property codes
instead of guessing them. Shape:
{
"hotels": {
"my-hotel": {
"id": "my-hotel",
"name": "My Hotel",
"webHotelierCode": "MYHOTEL",
"rating": 4,
"active": true
}
}
}Only these five fields are ever exposed — anything else in the file is filtered out (and a
unit test enforces that). Without a registry, list_properties explains it is not
configured; every other tool still works if you already know your property codes.
Add to your project's .mcp.json (or to ~/.claude.json for user-wide scope):
{
"mcpServers": {
"webhotelier": {
"command": "node",
"args": ["/absolute/path/to/webhotelier-mcp/server.js"]
}
}
}Restart the session (MCP servers are launched at startup) and check with /mcp — you
should see webhotelier with 8 tools.
Add the same entry under mcpServers in claude_desktop_config.json
(macOS: ~/Library/Application Support/Claude/claude_desktop_config.json), then restart
the app.
Anything that speaks MCP over stdio can use this server — point it at node server.js
with the repo as working directory or use absolute paths as above.
webhotelier-mcp/
├── server.js # entry point: McpServer + stdio transport
├── tools.js # the 8 tool definitions (zod schema + thin handler each)
├── format.js # response slimming before data reaches model context
├── registry.js # hotel-registry loader with strict field whitelist
├── errors.js # WebHotelier errors → actionable text for the model
├── env.js # dotenv loading (must stay the FIRST import of server.js)
├── lib/
│ └── wh-client.cjs # vendored WebHotelier REST client (CommonJS)
└── tests/
├── unit/ # offline unit tests (node:test, no framework deps)
├── fixtures/ # fake registry used by the privacy tests
└── smoke.js # live-API smoke testEverything testable without a network — formatting, registry filtering, error mapping —
is a pure module with unit tests. tools.js stays declarative: schema in, client call,
slimmed JSON out.
lib/wh-client.cjs is a vendored, battle-tested HTTP client: Basic Auth, request
timeouts, and a retry policy for transient failures (408/429/5xx and common network
errors; backoff 500 ms → 1.5 s → 4.5 s, honoring Retry-After on 429). Permanent errors
(400/401/403/404) are never retried.
Read-only by construction. The safety guarantee is structural, not a permission flag: no create/modify/cancel endpoint exists anywhere in the codebase, so no prompt or bug can reach one.
Errors are results, not crashes. A tool failure returns isError: true with text
written for the model: what happened and what to do next. The server process never dies
mid-session because one API call failed.
Responses are slimmed for context windows. WebHotelier payloads carry bulk that a
language model doesn't need: a single property-info response can exceed 100 KB, largely
photo URLs and HTML descriptions. format.js replaces photo arrays with photo_count
and strips/truncates HTML descriptions — while passing every number (prices, allotments,
capacities) through untouched. The model should never quote an altered price.
Registry privacy is tested, not promised. The registry loader whitelists five fields; a unit test feeds it a fixture full of fake sensitive data (emails, credential paths) and asserts none of it survives into the output.
stdout is sacred. stdio-transport MCP servers speak JSON-RPC on stdout. A single
stray console.log corrupts the protocol stream — all logging here goes to console.error
(stderr), which clients surface as server logs.
Credential loading is order-sensitive. The vendored client computes its Basic-Auth
header at module load, so import "./env.js" must remain the first import in
server.js — ESM executes imports in declaration order.
npm test # offline unit tests (node:test — zero test-framework dependencies)
npm run smoke # live smoke test: registry, property info, availability, 403 handling
npm run inspect # MCP Inspector web UI — call tools manually, watch raw JSON-RPCThe MCP Inspector also has a CLI mode, useful for scripted checks:
npx @modelcontextprotocol/inspector --cli node server.js --method tools/list
npx @modelcontextprotocol/inspector --cli node server.js --method tools/call --tool-name list_propertiesSymptom | Cause & fix |
Tools return "credentials rejected (401)" |
|
| Your WebHotelier account lacks reservations privileges ( |
| Set |
Server doesn't appear in the client | MCP servers launch at client startup — restart the session/app after editing the config. Check the path in |
"Unknown property code (404)" | The property code doesn't exist on WebHotelier. Call |
Contributing a change and output looks corrupted | You logged to stdout. Use |
Live availability and prices for a specific stay. Dates are YYYY-MM-DD. Provide checkout OR nights. This is the primary tool for 'is there a room and how much' questions.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | No | Number of rooms wanted | |
| adults | No | ||
| nights | No | ||
| checkin | Yes | ||
| infants | No | ||
| checkout | No | ||
| children | No | ||
| property | Yes | WebHotelier property code, e.g. GOLDENSAND. Call list_properties if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries disclosure burden. It adds 'live' data context and the dates format, but doesn't disclose response structure, error behavior, or whether both checkout and nights causes issues. It's acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with a clear lead, date format, and usage rule. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 params, no output schema, no annotations), the description communicates the core purpose and essential parameter constraints. However, it omits expected return values (e.g., room types, price breakdown) and edge-case behaviors, leaving the agent with gaps for a complete interaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers only 25% of parameters. The description adds two important semantic details: date format (YYYY-MM-DD) and the checkout-vs-nights mutual exclusivity. This goes beyond schema, though other params like adults/children/rooms are left to names and schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Live availability and prices for a specific stay', specifying the resource (availability/prices) and scope (specific stay). It also positions it as the primary tool for 'is there a room and how much' questions, distinguishing it from siblings like get_rates or get_best_rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states this is the primary tool for room availability/pricing queries, providing clear usage context. It also gives a key usage rule ('Provide checkout OR nights') but does not explicitly mention when to prefer alternatives like get_rates for pure pricing or get_calendar for date-level views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cheapest available rate (BAR) for a property, optionally for a specific date (YYYY-MM-DD).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| adults | No | ||
| children | No | ||
| property | Yes | WebHotelier property code, e.g. GOLDENSAND. Call list_properties if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It states the core outcome (cheapest available rate) but does not disclose output format, error behavior, how optional parameters like date affect results, or any rate-specific details (taxes, currency, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the core purpose. No redundant words or filler; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more context about return values or rate details. It also omits the adults/children parameters, which are likely relevant for rate calculation. The description is minimal and leaves significant gaps for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (property only). The description adds the date format and optionality, which is helpful, but it fails to mention the 'adults' and 'children' parameters that are present in the schema, leaving their semantics unclear. The description does not sufficiently compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (property) and scope (cheapest available rate, optional date), distinguishing it from get_rates by explicitly stating 'Cheapest'. However, it lacks an explicit verb, relying on the tool name for the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied (when you need the cheapest rate for a property) but the description does not explicitly state when to use this tool versus alternatives like get_rates or get_availability, nor does it provide exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Day-by-day availability over a date range (YYYY-MM-DD). Good for 'which days are free in August'.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| adults | No | ||
| children | No | ||
| property | Yes | WebHotelier property code, e.g. GOLDENSAND. Call list_properties if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It reveals that the tool returns day-by-day availability, but it does not disclose the output format, whether the range is inclusive, or any auth/rate limits. The lack of such details is a significant gap for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core behavior and then a practical example. No redundant or filler content is present, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description is too thin. It does not describe the response structure, meaning of optional parameters (adults/children), or how it relates to the similar-sounding get_availability sibling. The existing context is not enough for an agent to fully anticipate tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20% – only property has a description). The description mentions a date range and format YYYY-MM-DD, but this is redundant with the schema's pattern. It does not explain the adults/children parameters or how they interact with availability, leaving a large semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'day-by-day availability over a date range', which is a specific verb+resource+scope. It distinguishes from siblings through 'day-by-day' granularity, but doesn't explicitly name alternatives like get_availability, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Good for "which days are free in August"' implies a use case for checking availability across a range, but it does not provide explicit when-to-use versus alternatives or exclusions. The guidance is implied through example rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Currently active special offers/packages for a property.
| Name | Required | Description | Default |
|---|---|---|---|
| property | Yes | WebHotelier property code, e.g. GOLDENSAND. Call list_properties if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the scoping detail 'currently active' but omits other important traits such as read-only nature, return format, pagination, or permission requirements. This is minimal disclosure for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with minimal word count. It front-loads the key information ('Currently active special offers/packages') and contains no filler or redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description conveys the core purpose and scope. However, the absence of annotations and output schema means the agent lacks information about return format, pagination, or access restrictions, leaving noticeable gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level details beyond the schema, but the schema coverage is 100% with a clear explanation and example (GOLDENSAND) plus a helpful pointer to list_properties. Per the baseline for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'currently active special offers/packages for a property', which distinguishes it from sibling tools like get_rates or get_availability. However, it is phrased as a noun fragment rather than a verb phrase ('Get active offers'), slightly reducing actionability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use get_offers versus alternatives such as get_rates or get_best_rate. The only contextual hint is 'for a property', which is already evident from the schema. There are no mentions of when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hotel profile and full room catalog (room types, capacities, amenities) for one property.
| Name | Required | Description | Default |
|---|---|---|---|
| property | Yes | WebHotelier property code, e.g. GOLDENSAND. Call list_properties if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a read operation returning profile and room catalog, but it does not mention potential errors, response format, or any access requirements. For a simple get tool this is adequate, but it adds minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the main purpose and parenthetically lists the catalog items. Every word adds value and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description is sufficient: it tells the agent exactly what data will be returned (profile and room catalog) and the scope (one property). It could add notes about error behavior or return shape, but those are not critical for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter fully with a description including an example and a fallback instruction. The tool description adds no additional parameter semantics, but the schema already provides sufficient detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a hotel profile and full room catalog (room types, capacities, amenities) for one property. This distinguishes it from siblings like list_properties (which lists properties) and get_rates/get_availability (which focus on pricing and availability). The scope is specific: 'for one property'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for fetching comprehensive property details and room catalog for a single property, but it does not explicitly state when to prefer it over siblings. It lacks explicit 'when to use' or 'when not to use' guidance. The schema mentions calling list_properties if the property code is unknown, but that is not in the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate plans with cancellation policies for a property, optionally filtered to one room type.
| Name | Required | Description | Default |
|---|---|---|---|
| room | No | Room code to filter by | |
| property | Yes | WebHotelier property code, e.g. GOLDENSAND. Call list_properties if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the full burden of behavioral disclosure, but it only states the content ('rate plans with cancellation policies') and the optional filter. It does not explicitly indicate that this is a safe read-only operation, nor does it mention error conditions, permissions, or output structure. The lack of a verb leaves the action implicit, and no behavioral traits beyond a noun phrase are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the core resource and follows with the scope and optional filter. Every word contributes meaningful information with no redundancy, making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema or annotations, the description adequately conveys what is returned ('rate plans with cancellation policies') and the optional filtering behavior. It does not detail the return shape, but the low complexity and full schema coverage mean this is not a significant gap. Overall, it is sufficiently complete for an agent to understand the tool's basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, with property described as the WebHotelier code and room as the code to filter by. The description's phrase 'optionally filtered to one room type' adds no new meaning beyond what the schema already provides for the room parameter. It also does not introduce any syntax or format details, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'rate plans with cancellation policies' scoped to a property with optional room-type filtering. It does not use an explicit verb like 'get' or 'list', but the tool name and the noun phrase combine to make the purpose unambiguous. This also distinguishes it from siblings like get_best_rate by focusing on rate plans rather than best available rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_best_rate, get_availability, or get_offers. The only usage-related hint is the optional room-type filter, which is a parameter detail rather than a selection criterion. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bookings, optionally by property and check-in date range (YYYY-MM-DD). NOTE: requires a WebHotelier account with reservations access; without it the tool returns a clear permission message.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest check-in date | |
| from | No | Earliest check-in date | |
| property | No | WebHotelier property code, e.g. GOLDENSAND. Call list_properties if unknown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully discloses the permission requirement (WebHotelier account with reservations access) and the behavior when access is missing (returns a clear permission message). It also adds the date format (YYYY-MM-DD) and confirms that filters are optional. However, it does not explicitly state that the operation is read-only, though 'search' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no redundant information. The first sentence states the core purpose and filters; the second adds a necessary permission note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, optional filters, date format, and a crucial permission prerequisite. Given that all parameters are optional and well-described in the schema, this is sufficient for an agent to select and invoke the tool. The lack of an output schema is not compensated for, but the description implies the tool returns matching bookings, which is adequate for a simple search. Could be slightly improved by mentioning that no filters returns all reservations, but this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no new meaning beyond the schema: the schema already documents each parameter with descriptions (e.g., 'Earliest check-in date', 'WebHotelier property code'). The description merely notes the date format, which the schema's pattern also defines. Therefore, the description does not significantly enhance parameter understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Search') and resource ('bookings'), and specifies optional filters (property, check-in date range). This distinguishes it from sibling tools like get_rates and get_availability, which target other data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives or when not to use it. The only context provided is the permission requirement, which is more of a prerequisite than a usage guideline. There is no mention of sibling tools or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all known hotels with their WebHotelier property codes. Call this first whenever you don't know a property code. Local lookup — no API call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the 'Local lookup — no API call' behavior, which is an important trait (no network latency, likely cached). However, it does not describe the exact return structure or whether the list is sorted/filterable, which for a zero-parameter list tool is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action. It avoids wasted words and includes the usage cue in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stateless, zero-parameter lookup tool with no output schema, the description covers the essential points: what it lists (hotels and codes), when to call it (first, when code unknown), and a key behavioral trait (local lookup). This is complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes 0 parameters, and the schema coverage is 100%. The baseline for zero-param tools is 4, and the description does not need to explain parameters. It adds value by clarifying the output includes property codes, but that's not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all known hotels with their WebHotelier property codes,' using a specific verb and resource. It also differentiates from sibling tools (get_rates, get_availability) by focusing on the property registry rather than pricing or availability data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear guidance: 'Call this first whenever you don't know a property code,' which tells the agent when to invoke this tool. The additional note 'Local lookup — no API call' provides context that it is a fast, prerequisite lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_availabilityget_best_rateget_calendarget_offersget_property_infoget_ratesget_reservationslist_propertiesScored across 8 tools
Most tools target distinct data types: rates, property info, availability, calendar, best rate, offers, and reservations. get_availability and get_calendar overlap slightly, but descriptions clarify one is for a specific stay and the other for a date range. get_best_rate is a distinct query for the cheapest rate.
All tools use a verb_noun pattern, predominantly 'get_'. The single exception is 'list_properties', but this is still a clear verb and similar in style. The naming is predictable and consistent.
8 tools is well within the ideal range. Each tool serves a clear purpose in the hotel query domain without redundancy.
The toolset covers the core read-side operations: property lookups, rates, availability, calendar, best rate, offers, and reservations. It lacks write operations, but the server appears intentionally read-only. Minor gap: no tool to fetch a single reservation by ID, but search can accomplish this.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Unofficial read-only MCP server for VeryChic hotel offers
The Ferryhopper MCP server is a connector for LLMs and AI Agents in maritime travel that exposes ferry routes, schedules, and booking options. It enables AI assistants to search ports and connections across 33 countries and 190+ ferry operators, provide real-time ferry itineraries with indicative prices, and assist users with planning island-hopping or multi-leg journeys by processing natural language queries about ferry times, passenger counts, and travel durations.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
