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., "@@roompanda/mcp check availability for a double room this weekend"
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 Model Context Protocol server for the Roompanda booking API. Point any MCP-compatible AI client at it and the agent can search availability, price rooms, and make real bookings — scoped to a single property by the API key.
Built on @roompanda/sdk.
Add to your MCP client (e.g. Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"roompanda": {
"command": "npx",
"args": ["-y", "@roompanda/mcp"],
"env": { "ROOMPANDA_API_KEY": "sk_live_…" }
}
}
}(Use an sk_test_… key while developing — bookings are simulated.)
Related MCP server: Amadeus Hotel API MCP Server
Tool | Does |
| The connected property |
| Per-date open/closed/min-stay (date picker) |
| Room content, photos, facilities |
| Bookable rooms + priced rates for a stay |
| Rate plans & cancellation policies |
| Add-ons / upsells |
| Make a booking (returns a |
| Retrieve a booking |
| List bookings |
Env | |
| required — |
| optional API base override |
MIT
Create a real booking. Use room ids + rate ids from search_availability. Pay-at-hotel rates confirm immediately; rates needing an online deposit return a payment_url to send the guest to.
| Name | Required | Description | Default |
|---|---|---|---|
| guest | Yes | ||
| rooms | Yes | One entry per room to book | |
| checkin | Yes | YYYY-MM-DD | |
| checkout | Yes | YYYY-MM-DD | |
| currency | No | ||
| promo_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It reveals that pay-at-hotel rates confirm immediately while deposit rates require a payment_url, addressing a key uncertainly. However, it omits side effects like idempotency and authorization needs.
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?
Two sentences, front-loaded with purpose ('Create a real booking'), no redundant information. Every phrase 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 lacks details on return value (e.g., booking ID, confirmation status) and error handling. Given the tool's complexity (nested objects, conditional payment), the description could be more complete.
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 50%; the description adds value by linking room_id and rate_id to search_availability and explaining payment implications. However, it does not elaborate on fields like guest, currency, or promo_code, which remain covered only by the schema.
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 'Create a real booking' and specifies input sources (room ids + rate ids from search_availability), distinguishing it from read-only tools like get_booking and list_bookings.
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 provides context on when to use this tool (after search_availability) and conditional behavior (pay-at-hotel vs deposit rates), but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a booking by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'retrieve' without mentioning permissions, error handling, rate limits, or any side effects. This leaves the agent uninformed about important behavioral aspects.
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 sentence, which is concise, but it is too sparse. While it avoids waste, it could be slightly expanded to include minimal behavioral or parameter context without becoming verbose.
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 is insufficient. It does not explain the response structure, what happens if the id is invalid, or any other contextual details needed 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 schema has no descriptions, and the tool description only adds 'by its id' without explaining the parameter format, constraints, or possible values. With 0% schema coverage, the description should compensate but fails to provide meaningful semantic detail.
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 action (retrieve), the resource (booking), and the identifier (by its id). It effectively distinguishes from siblings like create_booking, list_bookings, and search_availability.
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 usage when you have a booking id, which is clear for a retrieval tool. However, it does not explicitly mention when not to use it or provide alternatives like list_bookings or search_availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-date availability for a date range: which dates are closed, closed-to-arrival/departure, and min-stay. Use to drive a date picker before searching.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End date YYYY-MM-DD | |
| from | Yes | Start date YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It describes the type of data returned but omits other traits like read-only nature, authorization, or rate limits. Acceptable but not thorough.
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?
Two efficient sentences conveying purpose and usage without redundancy. Front-loaded with essential information.
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 lack of output schema, description explains key output types (closed, closed-to-arrival/departure, min-stay) sufficient for driving a date picker, though more structural detail would improve completeness.
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 both parameters with descriptions. Description adds context of date range but no new meaning beyond schema. Baseline score applies due to high 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 states the tool returns per-date availability for a date range, specifying closed dates, closed-to-arrival/departure, and min-stay. This distinguishes it from sibling search tools like search_availability.
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?
Explicitly instructs 'Use to drive a date picker before searching', indicating when to use it. Lacks explicit exclusions or alternatives but context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the property this key is connected to (name + id).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states that the tool retrieves property name+id, implying a non-destructive read, but omits details like authentication, rate limits, or side effects.
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?
A single, precise sentence conveys the entire purpose without any extraneous information. It is effectively front-loaded.
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 zero parameters and no output schema, the description minimally covers what the tool returns (name+id). However, it lacks details on input context (e.g., how 'this key' is provided) and potential variations, making it moderately complete.
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?
There are no parameters, so schema coverage is 100%. The description does not add beyond the schema, but with zero parameters, a baseline of 4 is appropriate as no further explanation is needed.
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 verb 'Get' and resource 'property', with additional context 'this key is connected to (name + id)'. It distinguishes the tool from siblings like get_booking or get_calendar by targeting a different entity, but does not explicitly differentiate.
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 provided on when to use this tool versus alternatives such as get_booking or list_rooms. There are no exclusions or context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the property's bookings, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation, but without annotations it does not explicitly state idempotence or safety. It mentions ordering and lists bookings, which is fairly transparent, but lacks details on pagination, return format, or side effects.
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 very concise (one sentence) but at the cost of omitting important details. It earns its place but could be expanded to include parameter info and usage context.
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 is insufficient. It does not mention that all bookings are listed, how to paginate, or what fields are returned. The tool's behavior is incomplete for an AI agent to use confidently.
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?
Parameter description coverage is 0%, and the tool description does not explain the purpose or usage of 'limit' and 'offset'. The description entirely fails to add meaning beyond the schema's basic type constraints.
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 it lists the property's bookings ordered newest first. It uses a specific verb ('list') and resource ('bookings'), and the ordering distinguishes it from other tools like search_availability.
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 vs alternatives such as get_booking (single booking) or search_availability (filtered search). The description fails to mention that it lists all bookings with no filtering capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the add-ons / upsells catalogue.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'List' without disclosing behavioral traits such as side effects, data freshness, or pagination. The tool appears read-only but lacks explicit transparency.
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 sentence that efficiently conveys the tool's function without any unnecessary words or repetition.
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 simplicity of the tool (no parameters, no output schema), the description adequately explains its purpose. However, mentioning the output format could enhance completeness.
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?
With no parameters, the description does not need to add parameter meaning. Following the baseline of 4 for zero parameters 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 uses a specific verb ('List') and resource ('add-ons / upsells catalogue'), distinguishing it from sibling tools focused on bookings, rates, rooms, and availability.
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 usage when needing the catalogue of extras but does not explicitly state when to use or avoid this tool versus alternatives like search_availability or list_bookings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List rate-plan definitions and cancellation policies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry full burden. It only states what the tool lists, without disclosing side effects, authentication needs, or data scope.
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, clear sentence with no wasted words. It could be slightly more structured but is efficient.
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 parameters, the description is minimally adequate. It does not describe the return format or pagination, which would be helpful for a list operation.
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?
There are no parameters, so the baseline is 4. The description adds no parameter info but none is needed.
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 verb 'List' and the resources 'rate-plan definitions' and 'cancellation policies', distinguishing it from sibling tools like list_bookings or list_extras.
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 provided on when to use this tool versus alternatives. The description lacks context such as prerequisites or conditions for listing rates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the property's rooms with descriptions, photos and facilities (unpriced).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool lists rooms with certain details, which is basic behavior. However, it does not disclose authentication requirements, whether it returns only active rooms, or any rate limits. For a simple 0-param tool, this is adequate but not comprehensive.
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 12-word sentence that is front-loaded and contains no redundant information. Every word 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?
For a simple list tool with 0 params and no output schema, the description adequately explains the response content. However, it does not specify the return format or any potential limitations like pagination. A slightly more detailed output structure would improve completeness.
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 input schema has no parameters (0 params, baseline 4). The description adds value by specifying the output content (descriptions, photos, facilities, unpriced), compensating for the lack of parameter descriptions. Schema coverage is 100% vacuously.
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 verb 'List' and the resource 'the property's rooms', specifying included content (descriptions, photos, facilities) and a limitation (unpriced). This uniquely distinguishes it from sibling tools like list_bookings or list_extras.
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 about when to use this tool versus alternatives. The '(unpriced)' hint suggests not using it for pricing, but no alternative tools (e.g., list_rates, search_availability) are recommended for pricing queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find bookable rooms and priced rate plans for a stay. Returns each room's rates with total_price and a rate id to book.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Adults (default 2) | |
| checkin | Yes | Check-in date YYYY-MM-DD | |
| checkout | Yes | Check-out date YYYY-MM-DD | |
| currency | No | ||
| children_ages | No | Ages of any children |
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 return values (total_price, rate id) but does not mention behavior like auth requirements, rate limits, or whether the tool is read-only. A score of 3 is appropriate as it is partially transparent but not comprehensive.
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 sentences long, front-loaded with purpose, and contains no redundant information. Every word adds value, making it highly concise 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?
Given the tool has 5 parameters, no output schema, and no annotations, the description is relatively brief. It covers the basic purpose and return values but omits details like pagination, error handling, or what happens when no rooms are available. Completeness is adequate but not thorough.
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 80%, so the input schema already documents most parameters. The description does not add additional meaning beyond the schema; it only mentions output fields (total_price, rate id). Baselined at 3 due to high 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 states the tool finds bookable rooms and priced rate plans for a stay, with a specific verb (Find) and resource (bookable rooms and rate plans). It distinguishes from siblings like create_booking or list_rooms by focusing on availability checking.
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 when to use (checking availability before booking) but does not explicitly state when not to use or provide alternative tools. No exclusion criteria or prerequisites are mentioned, leaving some ambiguity for the AI agent.
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.
v0.1.0create_bookingget_bookingget_calendarget_propertylist_bookingslist_extraslist_rateslist_roomssearch_availabilityScored across 9 tools
Each tool has a clearly distinct purpose: creating bookings, retrieving them, checking availability, listing rooms/rates/extras, and property info. There is no confusion or overlap.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_booking, list_rooms, search_availability), making them predictable and easy to understand.
9 tools is well-scoped for a property management and booking system. Each tool covers a necessary operation without excess or deficiency.
The set covers the core workflow (search, create, retrieve, list bookings, and property details). Minor gaps exist: no update or cancel booking, but these are secondary operations.
Travel tools for AI agents: plan and edit real trips, search stays and tours, import travel videos.
Vacation rental discovery, direct booking, and property protection for AI agents.
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
