Click on "Install 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., "@Jinko Hotel Booking MCP Server find hotels in Paris for 2 adults from June 25-26"
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.
This repository was originally from https://github.com/jinkoso/jinko-mcp
Original Author: Jinko
Original Repository is no longer available on GitHub
Related MCP server: Amadeus Hotel API MCP Server
We are the first MCP server to give access to 2 millions of hotels with shopping and booking capabilities. You can integrate our MCP and start to sell within minutes in your agents. The prod version is available on request by requesting it on our website https://www.jinko.so/. Feel free to reach out!
MCP (Model Context Protocol) is an open protocol that standardizes how applications provide context to LLMs - think of it as a USB-C port for AI applications, connecting models to external data sources and tools.
Find Place: Convert user's location query into standardized place information with coordinates
Search Hotels: Search for available hotels based on location coordinates and booking requirements
Get Hotel Details: Get comprehensive details about a specific hotel
Book Hotel: Book a hotel by creating a quote and returning a payment link
Get Facilities: Retrieve hotel facilities in different languages for filtering searches
You can install the package globally:
npm install -g jinko-mcp-devOr run it directly with npx:
npx jinko-mcp-devnpm run startnpx jinko-mcp-devThe MCP server uses stdio transport, which means it can be used directly with MCP clients that support this transport type.
You can install our MCP locally for now. Remote support is coming. For developers that want access to the production environment and earn commission on sales, please contact us via our website https://www.jinko.so/.
{
"mcpServers": {
"jinko-travel": {
"command": "npx",
"args": [
"jinko-mcp-dev@latest"
]
}
}
}Convert a user's location query into standardized place information with coordinates.
Parameters:
query: User's input for place search (e.g., 'New York', 'Paris', 'Tokyo')
language (optional): Language for the place search, default: 'en'
This tool is essential when you need latitude and longitude for hotel searches but only have a text description. It accepts city names, hotel names, landmarks, or other location identifiers and returns a list of matching places with their details and precise coordinates.
Search for available hotels based on location coordinates and booking requirements.
Parameters:
latitude: Latitude of the location
longitude: Longitude of the location
check_in_date: Check-in date (YYYY-MM-DD), default: '2025-06-25'
check_out_date: Check-out date (YYYY-MM-DD), default: '2025-06-26'
adults: Number of adults, default: 2
children: Number of children, default: 0
facilities (optional): Facility IDs to filter hotels by, the IDs can be inferred with facilities resource
This tool returns a paginated list of hotels with their key details including name, address, star rating, price range, and available room types. Each hotel includes summary information about amenities and available rates. The results are limited to 50 hotels per request.
Retrieve additional hotel results from a previous search using the session_id.
Parameters:
session_id: Session ID from a previous search-hotels or load-more-hotels response
This tool continues pagination from a previous search-hotels request, returning the next batch of hotels with the same format and details as the original search.
Retrieve comprehensive details about a specific hotel identified by its ID.
Parameters:
session_id: The session ID from a previous search
hotel_id: ID of the hotel to get details for
This tool provides more extensive information than what's available in search results, including complete descriptions, all available room types, detailed rate information, cancellation policies, and full amenity lists.
Initiate a hotel booking process for a specific hotel and rate option.
Parameters:
session_id: The session ID from a previous search
hotel_id: ID of the hotel to book
rate_id: ID of the specific rate option the user has selected
This tool creates a booking quote for the specified hotel and room, and returns a payment link for the user to complete the booking.
Retrieve a list of hotel facilities in the specified language.
Parameters:
language: Language code for facility names (en, es, it, he, ar, de), default: 'en'
This tool must be called before search-hotels whenever the user mentions specific hotel amenities or requirements. It returns facility IDs that must be used with the search-hotels tool's facilities parameter to properly filter hotels.
The standard server provides hotel facilities data as resources in multiple languages:
English (en)
Spanish (es)
Italian (it)
Hebrew (he)
Arabic (ar)
German (de)
These resources can be accessed using the hotel://facilities/{language} URI pattern, where {language} is one of the supported language codes.
The server includes built-in facilities data to provide information about hotel amenities. This data is used to filter hotel searches based on specific amenities requested by users.
Each facility includes:
facility_id: Unique identifier for the facility
facility: Name of the facility in English
sort: Sort order for display
translation: Array of translations in different languages
When using the get-facilities tool, the available facilities are returned as part of the response, allowing LLMs to use the appropriate facility IDs when filtering hotel searches with the search-hotels tool.
A typical workflow for using the standard server would be:
Use find-place to convert a user's location query into coordinates
Use get-facilities to identify facility IDs for any amenities the user requested
Use search-hotels with the coordinates and facility IDs to find matching hotels
Use load-more-hotels if more results are needed beyond the initial 50
Use get-hotel-details to retrieve comprehensive information about a specific hotel
Use book-hotel to initiate the booking process and generate a payment link
To publish this package to npm, follow these steps:
Make sure you have an npm account and are logged in:
npm loginUpdate the version number in package.json:
npm version patch # or minor or majorBuild the project:
npm run buildPublish to npm:
npm publishAfter publishing, users can install and run the package using npm or npx as described in the Installation section.
Initiate a hotel booking process for a specific hotel and rate option.
IMPORTANT WORKFLOW:
Before calling this tool, you MUST present a specific hotel's all available rate options to the user using get-hotel-details
The user MUST select a specific rate option they want to book
This tool will generate a secure payment link that the user needs to open in their browser to complete the booking
The response includes a payment_link that must be prominently displayed to the user, along with booking details such as hotel name, check-in/out dates, and total price.
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_id | Yes | ID of the hotel to book | |
| rate_id | Yes | ID of the specific rate option the user has selected | |
| session_id | Yes | The session ID from a previous search |
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 effectively describes key behaviors: the tool generates a secure payment link (not completing the booking), requires user action in a browser, and returns specific booking details. It doesn't mention error conditions or rate limits, but covers the core transactional behavior well.
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 well-structured with clear sections: purpose statement, numbered workflow steps, and response handling. Every sentence adds value - the workflow steps are essential guidance, and the response details ensure proper user interaction. No wasted words or redundancy.
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 booking tool with no annotations and no output schema, the description provides strong context about the workflow, user interaction requirements, and response expectations. It could be more complete by mentioning error cases or confirmation mechanisms, but covers the essential transactional nature and user workflow adequately.
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%, providing good parameter documentation. The description adds context about parameter relationships (rate_id comes from user selection after get-hotel-details, session_id from previous search) but doesn't provide additional semantic details beyond what the schema already describes. This meets the baseline for 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's purpose with specific verbs ('initiate a hotel booking process') and resources ('specific hotel and rate option'). It distinguishes from sibling tools like 'get-hotel-details' by focusing on booking initiation rather than information retrieval.
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 explicit workflow guidance: it specifies when to use this tool (after presenting rate options via 'get-hotel-details' and user selection), when not to use it (without those prerequisites), and names the alternative tool ('get-hotel-details') for the prerequisite step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this tool to convert a user's location query into standardized place information with coordinates. This is essential when you need latitude and longitude for hotel searches but only have a text description. The tool accepts city names, hotel names, landmarks, or other location identifiers and returns a list of matching places with their details and precise coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language for the place search | en |
| query | Yes | User's input for place search |
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 describes the tool's behavior well: it accepts various location identifiers and returns a list of matching places with details and coordinates. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, which would be helpful for a tool with no annotation coverage.
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 appropriately sized and front-loaded. The first sentence states the core purpose, followed by context and details. Every sentence adds value without redundancy, making it efficient and easy to understand.
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's moderate complexity (2 parameters, no output schema, no annotations), the description is fairly complete. It explains the purpose, usage context, input types, and output format. However, without an output schema, it could benefit from more details about the return structure (e.g., what 'details' include), but it adequately covers the essentials for an agent to use it correctly.
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 schema already documents both parameters thoroughly. The description adds some context by mentioning what types of queries are accepted (city names, hotel names, landmarks), but doesn't provide additional syntax or format details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 purpose: converting location queries into standardized place information with coordinates. It specifies the verb 'convert' and resource 'user's location query', and distinguishes it from sibling tools like 'search-hotels' by explaining this is for getting coordinates needed for hotel searches, not for searching hotels directly.
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 explicitly states when to use this tool: 'when you need latitude and longitude for hotel searches but only have a text description.' It provides a clear context and distinguishes from alternatives by implying this is a prerequisite step before using hotel-related tools like 'search-hotels'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
IMPORTANT: ALWAYS USE THIS TOOL FIRST when a user mentions ANY specific hotel amenities or requirements.
This tool must be called BEFORE search-hotels whenever the user mentions requirements like:
Pet-friendly or traveling with pets/dogs/cats
WiFi or internet access
Swimming pools
Parking (free or paid)
Air conditioning or heating
Fitness center or gym
Restaurant or room service
Family rooms
Non-smoking rooms
Any other specific hotel features
The tool returns facility IDs that MUST be used with the search-hotels tool's facilities parameter to properly filter hotels. Without using this tool first, searches will not correctly filter for user-requested amenities.
Example workflow:
User asks for "pet-friendly hotels in Paris"
Call get-facilities to find the facility_id for "Pets allowed"
Use that facility_id in the search-hotels facilities parameter
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code for facility names (en, es, it, he, ar, de) | en |
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 describes the tool's role in the workflow (returns IDs for filtering), the necessity of using it before search-hotels, and the impact on search results. However, it lacks details on rate limits, error handling, or response format, which would be helpful for a tool with no output schema.
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 appropriately sized and front-loaded with the most critical information ('IMPORTANT: ALWAYS USE THIS TOOL FIRST'). It uses bullet points and an example workflow efficiently, though it could be slightly more concise by integrating some bullet points into prose.
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's complexity (simple parameter, no output schema, no annotations), the description is largely complete. It explains the purpose, usage, and workflow integration thoroughly. However, without an output schema, it could benefit from more details on the return format (e.g., structure of facility IDs).
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 description coverage is 100%, so the schema already documents the single parameter (language). The description does not add any parameter-specific information beyond what's in the schema, such as how language affects facility names or default behavior. Baseline 3 is appropriate when the schema handles parameter documentation.
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 the tool's purpose: to return facility IDs that must be used with the search-hotels tool's facilities parameter. It specifies the verb ('returns facility IDs') and resource ('facilities'), and clearly distinguishes it from sibling tools like search-hotels by explaining its role in the workflow.
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 explicit guidance on when to use this tool vs. alternatives: 'ALWAYS USE THIS TOOL FIRST when a user mentions ANY specific hotel amenities or requirements' and 'must be called BEFORE search-hotels'. It lists specific examples of requirements that trigger its use and explains the consequence of not using it ('searches will not correctly filter').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve comprehensive details about a specific hotel identified by its ID. This tool provides more extensive information than what's available in search results, including complete descriptions, all available room types, detailed rate information, cancellation policies, and full amenity lists.
Use this tool when a user expresses interest in a specific hotel from search results to provide them with all available options and complete booking information.
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_id | Yes | ID of the hotel to get details for | |
| session_id | Yes | The session ID from a previous search |
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 describes the tool as retrieving comprehensive details, which implies a read-only operation, but doesn't explicitly state whether it's safe, requires authentication, has rate limits, or what the response format includes. It adds some context about the depth of information but lacks behavioral specifics like error handling or performance.
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 front-loaded with the core purpose in the first sentence, followed by elaboration and usage guidelines. Every sentence earns its place by adding value—contrasting with search results and specifying when to use it—without redundancy or unnecessary details. It's appropriately sized for the tool's complexity.
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's moderate complexity (2 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, usage, and scope of information returned. However, it lacks details on behavioral aspects like error cases or response structure, which would be helpful since no output schema is provided. It's sufficient but could be more comprehensive.
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 schema already documents both parameters (hotel_id and session_id) adequately. The description doesn't add any additional meaning beyond what the schema provides, such as explaining why session_id is required or how hotel_id should be sourced. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Retrieve comprehensive details') and resource ('about a specific hotel identified by its ID'), distinguishing it from siblings like search-hotels (which finds hotels) and get-facilities (which focuses on amenities). It explicitly contrasts with search results, establishing its unique role in providing deeper information.
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 explicitly states when to use this tool: 'when a user expresses interest in a specific hotel from search results to provide them with all available options and complete booking information.' This gives clear context and distinguishes it from alternatives like search-hotels (for initial searches) or book-hotel (for booking).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve additional hotel results from a previous search using the session_id. This tool continues pagination from a previous search-hotels request, returning the next batch of hotels with the same format and details as the original search.
The response format matches search-hotels and includes information about whether further pagination is possible.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID from a previous search-hotels or load-more-hotels response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a read operation (implied by 'retrieve'), returns results in batches, maintains format consistency with search-hotels, and indicates pagination status. However, it doesn't mention rate limits, authentication needs, or error conditions.
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 front-loaded with the core purpose in the first sentence, followed by supporting details. Every sentence adds value: explaining pagination continuation, response format consistency, and pagination status indication. 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?
For a pagination tool with 1 parameter, 100% schema coverage, and no output schema, the description is largely complete. It explains the tool's purpose, usage context, and response behavior. However, it could benefit from mentioning error handling (e.g., invalid session_id) or performance considerations.
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 description coverage is 100%, so the schema already documents the single parameter. The description adds context by explaining that session_id comes from 'a previous search-hotels or load-more-hotels response,' which clarifies the parameter's origin and purpose beyond the schema's basic description.
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 purpose: 'Retrieve additional hotel results from a previous search using the session_id' and 'continues pagination from a previous search-hotels request.' It distinguishes itself from sibling tools like 'search-hotels' by specifying it's for pagination continuation rather than initial search.
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 explicitly states when to use this tool: 'from a previous search-hotels request' and 'continues pagination.' It also references the alternative 'search-hotels' for initial searches, providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for available hotels based on location coordinates and booking requirements. This tool returns a paginated list of hotels with their key details including name, address, star rating, price range, and available room types. Each hotel includes summary information about amenities and available rates.
The results are limited to 50 hotels per request. If more results are available, you can retrieve them using the load-more-hotels tool with the returned session_id.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adults | |
| check_in_date | No | Check-in date (YYYY-MM-DD) | 2025-06-25 |
| check_out_date | No | Check-out date (YYYY-MM-DD) | 2025-06-26 |
| children | No | Number of children | |
| facilities | No | Facility IDs to filter hotels by, the IDs can be inferred with facilities resource. | |
| latitude | Yes | Latitude of the location | |
| longitude | Yes | Longitude of the location | |
| name | No | Optional location name or hotel name. | |
| search_context | No | A summary of the search context which will be used by the server to better make the recommendation |
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 effectively describes key traits: it returns a paginated list (50 hotels per request), includes specific hotel details (name, address, rating, etc.), and mentions a session_id for pagination via 'load-more-hotels'. It does not cover aspects like error handling, rate limits, or authentication needs, but provides substantial operational context beyond basic purpose.
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 appropriately sized and front-loaded, with the first sentence stating the core purpose. Subsequent sentences efficiently add necessary details (returned data, pagination limit, pagination method) without redundancy. Every sentence earns its place by contributing essential information, resulting in zero waste and clear structure.
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's moderate complexity (9 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, returned data, pagination behavior, and pagination alternative. However, it lacks details on error cases, authentication, or rate limits, which could be relevant for a search tool with many parameters. The absence of an output schema means the description does not explain return values, but it summarizes key details adequately.
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 schema already documents all 9 parameters thoroughly (e.g., 'adults' as number of adults, 'check_in_date' in YYYY-MM-DD format). The description adds minimal value beyond the schema, mentioning 'location coordinates and booking requirements' which aligns with parameters like latitude/longitude and check-in/out dates, but does not provide additional syntax, format, or usage details not already in 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 the specific action ('Search for available hotels') and resource ('hotels'), distinguishing it from siblings like 'book-hotel' (booking), 'find-place' (general places), 'get-facilities' (facility info), 'get-hotel-details' (detailed info), and 'load-more-hotels' (pagination). It specifies the search is based on location coordinates and booking requirements, making the purpose explicit and differentiated.
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 clear context for when to use this tool (searching hotels with location/booking criteria) and explicitly mentions an alternative ('load-more-hotels' for pagination). However, it does not specify when not to use it (e.g., vs. 'find-place' for non-hotel places or 'get-hotel-details' for detailed info), lacking full exclusions or sibling comparisons beyond pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: find-place converts location queries, get-facilities retrieves amenity IDs, search-hotels finds hotels, get-hotel-details provides full hotel info, load-more-hotels handles pagination, and book-hotel initiates bookings. The descriptions explicitly define their roles, preventing misselection.
All tool names follow a consistent verb_noun pattern with hyphens (e.g., find-place, get-facilities, search-hotels). This uniformity makes the set predictable and easy to understand, with no deviations in style or convention.
With 6 tools, the server is well-scoped for hotel booking, covering the full workflow from location search to booking. Each tool earns its place, providing essential steps without bloat or redundancy, typical for a focused domain like this.
The toolset offers complete coverage for hotel booking: location handling (find-place), amenity filtering (get-facilities), hotel search and pagination (search-hotels, load-more-hotels), detailed information (get-hotel-details), and booking initiation (book-hotel). No gaps exist, ensuring agents can handle the entire lifecycle without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Search MCP servers, agent skills and APIs for travel: hotel ID mapping, rates, rooms.
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dumyCq/jinko-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
