Consumer hotel search, live rates, booking, order management, and payment via TourMind.
Scored across 11 tools
Most tools are clearly distinct by action and resource, but search_hotels vs. search_location and query_room_rates vs. check_room_availability have overlapping boundaries. check_skill_update also feels out of place but is not easily confused with booking tools.
Tool names generally follow a consistent verb_noun pattern in snake_case. Minor inconsistency exists between get_hotel_detail, query_booking, and search_hotels, and the batch_ prefix is a slight deviation but still readable.
11 tools is a well-scoped set for a hotel booking server, covering search, rates, booking, payment, and booking management. The count feels appropriate without unnecessary bloat or an obviously thin surface.
The core booking lifecycle is covered: search, details, rates, availability, create, query, pay, and cancel. Missing capabilities like modifying a booking and checking payment status are notable minor gaps but do not create a dead end for typical workflows.
Get live room types and rate products for multiple hotels with partial-success results.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adults in each room | |
| children | No | Number of children in each room | |
| user_key | No | Optional TourMind user key for authenticated ToC access | |
| hotel_ids | Yes | TourMind hotel identifiers to query | |
| room_count | No | Number of rooms using the same occupancy | |
| check_in_date | No | Check-in date in YYYY-MM-DD format | |
| children_ages | No | Ages of the children in each room, each from 0 to 17 | |
| check_out_date | No | Check-out date in YYYY-MM-DD format |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and openWorld hints, so the description only needs to add information beyond those. It contributes the important behavioral detail that calls return partial-success results, which is not stated in the annotations and is useful for an agent deciding whether to tolerate per-hotel failures.
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 efficient sentence with no filler: it front-loads the action and resource, specifies the batch scope, and closes with the key partial-success behavior. Every clause 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?
With a complete input schema, an output schema, and readOnly/idempotent annotations, the description has comparatively little burden. The only potential gap is that partial-success semantics are named but not explained; however, the output schema can reasonably carry that detail.
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 eight parameters, including hotel_ids, dates, occupants, and user_key. The description adds little parameter-level meaning beyond implying that hotel_ids can contain multiple hotels.
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 uses a specific verb ('Get') with a clear resource ('live room types and rate products') and a defined scope ('multiple hotels'), and it highlights the distinctive partial-success result mode. The batch scope differentiates it from sibling query_room_rates without needing to open the schema.
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 explicit when-to-use or when-not-to-use guidance, and no sibling alternative is named. The phrase 'for multiple hotels' and the 'batch' title imply the intended use, but the description leaves the contrast with query_room_rates and check_room_availability to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a booking owned by the authenticated account. Configure a valid TourMind user_key in a trusted local Skill or client integration that supplies the user_key tool argument. Do not ask users to paste user keys into chat.
| Name | Required | Description | Default |
|---|---|---|---|
| user_key | Yes | TourMind user key required for authenticated ToC order access | |
| agent_ref_id | Yes | TourMind booking reference |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Recheck the selected rate code, price, and inventory before booking.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adults in each room | |
| children | No | Number of children in each room | |
| hotel_id | Yes | TourMind hotel identifier | |
| user_key | No | Optional TourMind user key for authenticated ToC access | |
| rate_code | Yes | Rate code returned by query_room_rates | |
| room_count | No | Number of rooms using the same occupancy | |
| check_in_date | No | Check-in date in YYYY-MM-DD format | |
| children_ages | No | Ages of the children in each room, each from 0 to 17 | |
| check_out_date | No | Check-out date in YYYY-MM-DD format |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds modest behavioral context by framing the tool as a re-validation step, but does not describe any additional behavior such as how staleness is handled or what happens if the rate is no longer available.
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 sentence that front-loads the action and context. There is no redundant material or repetition of schema field names.
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?
With a complete input schema, an output schema, and readOnly/idempotent/openWorld annotations, the one-sentence description is enough to place the tool in the booking workflow. Nothing necessary for correct invocation is missing.
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 document all 9 parametes. The description adds the useful hint that the rate_code is a 'selected' one, presumably from query_room_rates, but does not need to compensate for missing schema information.
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 uses a specific verb ('recheck') and names the resources involved ('rate code, price, and inventory'). The phrase 'before booking' and 'selected' clearly distinguishes this from initial rate queries like query_room_rates or batch_query_room_rates.
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 the tool: 'before booking'. It does not explicitly name alternatives or state when not to use it, but the 'recheck the selected...' wording makes the intended workflow position clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a newer TourMind Booking Skill version is available.
| Name | Required | Description | Default |
|---|---|---|---|
| current_version | Yes | Installed Skill semantic version, for example 1.0.0 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description does not add further behavioral details such as network behavior, failure modes, or prerequisites. It only clarifies the subject of the check, which is minor beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Check whether'). Every word contributes to the meaning, with no waste 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 simple one-parameter tool with a read-only, idempotent annotation profile and an output schema, the description is sufficiently complete. It states the core purpose, and the output schema presumably explains return values, so no further explanation is needed.
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 fully describes the only parameter, current_version, with an example. The description adds no additional parameter-specific meaning, but schema coverage is 100%, 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 verb ('Check') and resource ('newer TourMind Booking Skill version'). It unambiguously distinguishes this tool from sibling tools, which all relate to hotel booking operations but none to skill version 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 provides clear context: it is used to check for a newer version of the TourMind Booking Skill. It does not explicitly mention when not to use or name alternatives, but among the sibling tools there is no overlapping functionality, making the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a hotel booking from a verified rate. Configure a valid TourMind user_key in a trusted local Skill or client integration that supplies the user_key tool argument. Do not ask users to paste user keys into chat.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | Yes | Number of adults in each room | |
| children | No | Number of children in each room | |
| currency | Yes | Three-letter booking currency code | |
| hotel_id | Yes | TourMind hotel identifier | |
| user_key | Yes | TourMind user key required for authenticated ToC booking | |
| rate_code | Yes | Verified rate code returned by check_room_availability | |
| guest_name | Yes | Guest full legal name | |
| room_count | Yes | Number of rooms using the same occupancy | |
| total_price | Yes | Verified total booking price | |
| check_in_date | Yes | Check-in date in YYYY-MM-DD format | |
| children_ages | No | Ages of the children in each room, each from 0 to 17 | |
| contact_email | No | Contact email for booking status notifications | |
| check_out_date | Yes | Check-out date in YYYY-MM-DD format |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Get static hotel details, facilities, rooms, policies, and images.
| Name | Required | Description | Default |
|---|---|---|---|
| hotel_id | Yes | TourMind hotel identifier | |
| language | No | Response language, defaults to zh-CN | |
| user_key | No | Optional TourMind user key for authenticated ToC access |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the 'static' nature and lists data categories, which is useful but does not discuss data freshness, auth, or other behavioral traits. No contradiction with 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?
Single, tightly packed sentence that front-loads the verb and resource. Every word earns its place with no redundancy or filler.
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 read-only GET tool with full schema coverage, an output schema, and informative sibling names, the description is complete. It clearly states the returned content (static details, facilities, rooms, policies, images) and implies a read-only 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 covers 100% of parameters with clear descriptions (hotel_id, language default, user_key optional). The description adds no additional parameter-level detail, but the schema already provides sufficient meaning, so the baseline 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?
Specific verb 'Get' with resource 'hotel detail', enumerating content (facilities, rooms, policies, images). The word 'static' hints at differentiation from dynamic sibling tools like check_room_availability, but it doesn't explicitly name alternatives.
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?
'Static' implies use when unchanging hotel information is needed, but the description doesn't explicitly state when to use this tool instead of search_hotels, query_room_rates, or booking tools. Usage context is only implied through the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a payment request for a booking owned by the authenticated account. CNY WeChat Pay and Alipay return a one-time device-aware payment link. Configure a valid TourMind user_key in a trusted local Skill or client integration that supplies the user_key tool argument. Do not ask users to paste user keys into chat.
| Name | Required | Description | Default |
|---|---|---|---|
| user_key | Yes | TourMind user key required for authenticated ToC payment | |
| agent_ref_id | Yes | TourMind booking reference | |
| payment_method | Yes | Payment method: Stripe, 微信支付, or 支付宝 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Query a booking owned by the authenticated account. Configure a valid TourMind user_key in a trusted local Skill or client integration that supplies the user_key tool argument. Do not ask users to paste user keys into chat.
| Name | Required | Description | Default |
|---|---|---|---|
| user_key | Yes | TourMind user key required for authenticated ToC order access | |
| agent_ref_id | Yes | TourMind booking reference |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Get live room types and rate products for a hotel and stay.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | Number of adults in each room | |
| children | No | Number of children in each room | |
| hotel_id | Yes | TourMind hotel identifier | |
| user_key | No | Optional TourMind user key for authenticated ToC access | |
| room_count | No | Number of rooms using the same occupancy | |
| check_in_date | No | Check-in date in YYYY-MM-DD format | |
| children_ages | No | Ages of the children in each room, each from 0 to 17 | |
| check_out_date | No | Check-out date in YYYY-MM-DD format |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld behavior, so the description only needs to add nuance. It adds 'live,' indicating real-time rates, but does not disclose details like response freshness or auth requirements. This is adequate 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?
A single front-loaded sentence with no filler. It conveys the core purpose immediately and leaves details to the schema.
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 read-only query tool with a complete schema, output schema, and safety annotations, the description is nearly sufficient. It could have referenced batch_query_room_rates or clarified that stay dates are optional, but those gaps are minor.
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%, with every parameter explained inline. The description adds no parameter-level detail beyond what the schema already provides, so the baseline 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 uses a specific verb ('Get'), names the resource ('room types and rate products'), and scopes it ('for a hotel and stay'). This clearly distinguishes it from availability checks and booking creation, and the 'live' qualifier signals fresh 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?
There is no guidance on when to prefer this tool over siblings such as batch_query_room_rates or check_room_availability. The description implies a single-hotel/stay query but never states exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search candidate hotels by region, coordinates and radius, or fuzzy keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum fuzzy hotel matches | |
| adults | No | Number of adults in each room | |
| keyword | No | Hotel name or location keyword when region_id and coordinates are unavailable | |
| children | No | Number of children in each room | |
| latitude | No | Latitude of the search center | |
| user_key | No | Optional TourMind user key for authenticated ToC access | |
| longitude | No | Longitude of the search center | |
| radius_km | No | Search radius in kilometers | |
| region_id | No | TourMind region identifier | |
| room_count | No | Number of rooms using the same occupancy | |
| lowest_price | No | Minimum total price filter | |
| check_in_date | No | Check-in date in YYYY-MM-DD format | |
| children_ages | No | Ages of the children in each room, each from 0 to 17 | |
| highest_price | No | Maximum total price filter | |
| location_name | No | Human-readable location used to describe the search scope | |
| check_out_date | No | Check-out date in YYYY-MM-DD format |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint, idempotentHint, and openWorldHint annotations already cover safety and side-effect expectations. The description adds some useful behavioral context with 'candidate hotels' and 'fuzzy keyword,' but it does not disclose much beyond what annotations and parameter descriptions already provide. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('Search candidate hotels') before listing the search modes. Every word earns its place, and there is no redundant or filler content.
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 high parameter count, the description is compact but adequate: the input schema fully documents each parameter, an output schema exists, and the annotations cover safety. The description supplies the key missing semantic information—the three alternative search modes and the 'candidate' nature of results. It could be slightly more explicit about valid parameter combinations, but the schema compensates.
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%, so the baseline is 3. The description adds value beyond the schema by grouping parameters into meaningful search modes: region_id, latitude/longitude/radius_km, and keyword. This helps an agent understand how to combine otherwise independently documented parameters.
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 states a specific verb ('search'), a clear resource ('candidate hotels'), and the three supported search modes: region, coordinates/radius, and fuzzy keyword. This clearly distinguishes it from sibling tools like get_hotel_detail or query_room_rates, which serve different purposes.
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 the tool—when you need candidate hotels by location or keyword—and it names the search modes. However, it does not explicitly mention alternatives or state when not to use this tool, such as pointing to get_hotel_detail for hotel details or query_room_rates for pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a region, point of interest, landmark, shopping mall, or hotel name to TourMind regions, hotels, or coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Region, point of interest, landmark, shopping mall, or hotel name | |
| user_key | No | Optional TourMind user key for authenticated ToC access |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds context by specifying the output types (regions, hotels, coordinates), which goes beyond the annotations. It does not disclose potential error behavior or fuzzy matching, but the read-only, idempotent nature is well-established.
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, extremely concise sentence that immediately conveys the tool's purpose without extraneous information. Every word adds value.
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 lookup tool with a rich output schema and strong annotations, the description is largely complete. It lacks explicit guidance on when to use it versus search_hotels, but given the tool's simplicity and the presence of an output schema, the description is sufficient to guide an agent in most cases.
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%, with 'keyword' and 'user_key' already described in the schema. The tool description essentially repeats the keyword examples without adding new syntax or format details. Per the baseline rule 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 states the tool's function with a specific verb ('Resolve') and resource (region, POI, landmark, mall, or hotel name to TourMind regions, hotels, or coordinates). It distinguishes itself from sibling tools like search_hotels by focusing on name-to-entity/coordinate resolution rather than general hotel 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 implies usage for location name resolution but does not explicitly state when to use this tool versus alternatives like search_hotels. No exclusions or alternative tool references are provided. The context hints at geocoding/lookup use cases but lacks direct guidance.
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.
cancel_booking1 field changedInput schema / properties / user_key / descriptionPrevious value: -"TourMind user key required for authenticated ToC booking operations"New value: +"TourMind user key required for authenticated ToC order access"create_booking1 field changedInput schema / properties / user_key / descriptionPrevious value: -"TourMind user key required for authenticated ToC booking operations"New value: +"TourMind user key required for authenticated ToC booking"pay_order1 field changedInput schema / properties / user_key / descriptionPrevious value: -"TourMind user key required for authenticated ToC booking operations"New value: +"TourMind user key required for authenticated ToC payment"query_booking1 field changedInput schema / properties / user_key / descriptionPrevious value: -"TourMind user key required for authenticated ToC booking operations"New value: +"TourMind user key required for authenticated ToC order access"batch_query_room_ratescheck_room_availability4 fields changedInput schema / properties / adults / descriptionPrevious value: -"Number of adults per room"New value: +"Number of adults in each room"Input schema / properties / childrenAdded value: +{
+ "description": "Number of children in each room",
+ "type": "integer"
+}Input schema / properties / children_agesAdded value: +{
+ "description": "Ages of the children in each room, each from 0 to 17",
+ "items": {
+ "type": "integer"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Input schema / properties / room_count / descriptionPrevious value: -"Number of rooms"New value: +"Number of rooms using the same occupancy"create_booking4 fields changedInput schema / properties / adults / descriptionPrevious value: -"Number of adults per room"New value: +"Number of adults in each room"Input schema / properties / childrenAdded value: +{
+ "description": "Number of children in each room",
+ "type": "integer"
+}Input schema / properties / children_agesAdded value: +{
+ "description": "Ages of the children in each room, each from 0 to 17",
+ "items": {
+ "type": "integer"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Input schema / properties / room_count / descriptionPrevious value: -"Number of rooms"New value: +"Number of rooms using the same occupancy"query_room_rates4 fields changedInput schema / properties / adults / descriptionPrevious value: -"Number of adults per room"New value: +"Number of adults in each room"Input schema / properties / childrenAdded value: +{
+ "description": "Number of children in each room",
+ "type": "integer"
+}Input schema / properties / children_agesAdded value: +{
+ "description": "Ages of the children in each room, each from 0 to 17",
+ "items": {
+ "type": "integer"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Input schema / properties / room_count / descriptionPrevious value: -"Number of rooms"New value: +"Number of rooms using the same occupancy"search_hotels4 fields changedInput schema / properties / adults / descriptionPrevious value: -"Number of adults per room"New value: +"Number of adults in each room"Input schema / properties / childrenAdded value: +{
+ "description": "Number of children in each room",
+ "type": "integer"
+}Input schema / properties / children_agesAdded value: +{
+ "description": "Ages of the children in each room, each from 0 to 17",
+ "items": {
+ "type": "integer"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Input schema / properties / room_count / descriptionPrevious value: -"Number of rooms"New value: +"Number of rooms using the same occupancy"cancel_bookingcheck_room_availabilitycheck_skill_updatecreate_bookingget_hotel_detailpay_orderquery_bookingquery_room_ratessearch_hotelssearch_locationBusiness hotel search, live rates, booking, order management, and payment via TourMind.
Live hotel rates worldwide: search stays, property detail, all-in room prices, human phone desk.
Search and book 3M+ hotels in 200+ countries. Agents pay per reservation in USDC on Base over x402. Hosted, no auth.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Add one secure layer between your agents and this server.
