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 user_key account.
| Name | Required | Description | Default |
|---|---|---|---|
| user_key | Yes | TourMind user key required for authenticated ToC booking operations | |
| agent_ref_id | Yes | TourMind booking reference |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, which already signals a destructive operation. The description adds the ownership constraint (owned by user_key), but does not disclose other important behavioral traits such as irreversibility, cancellation policies, or side effects. The additional context is useful but limited.
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 that front-loads the action and key constraint. 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?
The tool is simple and has an output schema, so return values may be covered there. However, given the destructive nature (destructiveHint) and openWorldHint, the description could benefit from mentioning potential consequences, preconditions, or follow-up steps. It is adequate but minimal.
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 parameters are already well-documented. The description adds a minor clarification that the booking must belong to the user_key, but doesn't provide significantly more meaning beyond 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 tool cancels a booking and specifies the scope ('owned by the user_key account'), distinguishing it from siblings like create_booking and query_booking.
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 on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or when not to use it, leaving the agent to infer usage solely from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. A valid user_key is required.
| 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 operations | |
| 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 | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and openWorldHint, so the mutation and external side-effect nature is covered. The description adds the prerequisite of a verified rate and the user_key requirement, which is helpful, but it does not disclose what happens on success, whether the booking is immediately confirmed, or whether charges are incurred. Given the annotation coverage, 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?
Two short sentences with no filler: the first states the action and its essential precondition, and the second states the required authentication. Every word earns its place and the key constraint is 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 the annotations, 100% schema coverage, and an output schema, the description is sufficiently complete for an agent to invoke the tool. It captures the crucial verified-rate and user_key requirements. It could have mentioned the relationship to check_room_availability more explicitly in the description itself, but the schema already establishes that.
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 input schema fully documents all 13 parameters. The description does not add parameter-level meaning beyond what the schema provides, such as the rate_code being tied to check_room_availability. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource — 'Create a hotel booking' — and adds a key qualifier, 'from a verified rate,' which distinguishes it from query_booking, cancel_booking, and rate-checking sibling tools. The purpose is immediately unambiguous.
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 clearly indicates this tool is for creating bookings only after a rate has been verified and requires a valid user_key. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select this over read-only or cancellation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 user_key account. CNY WeChat Pay and Alipay return a one-time device-aware payment link.
| Name | Required | Description | Default |
|---|---|---|---|
| user_key | Yes | TourMind user key required for authenticated ToC booking operations | |
| agent_ref_id | Yes | TourMind booking reference | |
| payment_method | Yes | Payment method: Stripe, 微信支付, or 支付宝 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructiveHint and openWorldHint. The description adds that CNY WeChat Pay and Alipay return a one-time device-aware payment link, which is useful behavior. However, it does not explain Stripe behavior, potential side effects, or lifecycle of the payment request. 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?
Two sentences, with the purpose front-loaded. No filler or repetition. Every word adds value, earning the highest score.
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 3-parameter tool with full schema coverage, output schema, and annotations, the description covers the core operation and a key per-method nuance. It is concise but missing explicit notes about Stripe behavior or prerequisites beyond ownership. Still sufficient for an agent to invoke 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% with each parameter clearly described. The description adds a nuance about payment methods returning a link, but does not go beyond the schema for parameter formats or constraints. Baseline 3 is appropriate given full 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?
Clearly states the action: 'Create a payment request for a booking owned by the user_key account.' This is a specific verb-resource pair and distinguishes from siblings like create_booking or query_booking by focusing on payment. Also adds a unique behavioral detail for WeChat Pay and Alipay.
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 initiating payment on an existing booking owned by the user_key account, giving clear context. It does not explicitly name alternatives or exclusions, but among siblings there is no other payment-specific tool, so the intended use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query a booking owned by the user_key account.
| Name | Required | Description | Default |
|---|---|---|---|
| user_key | Yes | TourMind user key required for authenticated ToC booking operations | |
| agent_ref_id | Yes | TourMind booking reference |
| 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, covering safety and idempotency. The description adds meaningful context about access control: the booking must be owned by the supplied user_key, which is not conveyed by 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?
A single, front-loaded sentence of 9 words. No wasted words, and every word adds value: 'Query a booking' states the action, 'owned by the user_key account' clarifies scope.
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 tool is simple with two well-documented parameters, an output schema, and annotations covering read-only/idempotent behavior. The description is sufficient for correct invocation, though it does not mention behavior for missing bookings or invalid keys—acceptable given the output schema likely covers responses.
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 descriptions cover 100% of parameters, so baseline is 3. The description adds extra semantics by tying user_key to ownership ('owned by the user_key account'), which clarifies the relationship between the two parameters beyond their individual schema descriptions.
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 ('Query') and resource ('a booking'), and adds scope ('owned by the user_key account'). This clearly distinguishes it from siblings like create_booking, cancel_booking, and 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 provides clear context: it queries a booking linked to a specific user_key. It does not explicitly mention when not to use it or name alternatives, but the ownership scope and sibling names imply appropriate usage for read-only booking lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
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.
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Luxury hotel search, rate comparison, booking quotes, and secure checkout handoff.
Search hotels, get live prices, and check out in chat. Guest search needs no sign-in.
Add one secure layer between your agents and this server.
